Creating themes for MODX Revolution (maybe for ThemeForest, strategy and discussion)

Some information that might (or might not) be helpful to those interested in this topic:

Having worked closely with Mike and John in developing the ThemePackagerComponent (TPC), I should note that there are known bugs, especially around uninstalling, as Susan mentioned. Generally, it's a "one-way" ticket: install theme. That's it. There are options to install or not install "sample content", and along with the myriad other configurable options, this makes TPC a relatively "easy" and robust way to package up a theme just the way you want. Nothwithstanding — it's got issues. Some big hairy monsters may lurk still, because the component attempts to do a LOT, dealing with Template IDs for example and resolving them on install. It's huge.

For the risks involved, those who have experience with myComponent, or repoman, or any of the other packaging utilities, might be inclined to stick to those. Packman is a predecessor of TPC and I don't think offers any advantages over TPC — TPC is a frankenstein project made from Packman and Vapor (the technology used to package a standard MODX site for import to MODX Cloud)

All that said, none of these solutions even remotely touch the problem of MODX being inherently "unthemeable". TPC attempts a bit, with an included Snippet to deal with Template IDs, but nothing will make themes interchangeable without a strict set of development "rules" and "standards" (read: stripping away some Creative Freedom).

Internally, we have been tinkering with a set of conventions that, when followed, will make any compliant theme interchangeable, but it's just in its infancy — we're still in the stage of identifying the problems clearly and succinctly, and breaking them out for input on solutions. At some point (hopefully very soon) we'd like to open up the discussion for community input and guidance. Right at the moment it's still too early in our efforts — there's nothing really to share or discuss quite yet.

I'll update this thread when we get closer...if anyone's interested. You can take it or leave it of course. Even when/if it's done and established and accepted by some, it will be purely optional for those who simply don't want to do it that way, or have other ideas/methods.

With great freedom comes great responsibility. But there is certainly a place for plug-and-play solutions for those who don't amuse themselves with tinkering and tweaking at things.

Anybody else remember plugging in things like sound cards, network cards, video cards, then spending half the day figuring out which combinations of jumpers would let them all work together

Anybody else remember plugging in things like sound cards, network cards, video cards, then spending half the day figuring out which combinations of jumpers would let them all work together

Ohhh god yes, that the main reason I've come over to Mac's

That's good information. There are definitely some inherent problems in the whole package management System. MyComponent is fairly good about creating clean uninstalls, but there are often some leftover issues that you have to solve in a resolver. Learning MC is also kind of a big ask for people who just want to create a theme package and nothing more.

One recurring issue in package management is that if you set xPDOTransport::UPDATE_OBJECT => false for an object, it will not be removed when the package is uninstalled. That's why TinyMCE and some other packages leave a bunch of crud around when you completely uninstall them.

You often want UPDATE_OBJECT set to false for an upgrade since you don't want to overwrite resources or System Settings that the user has modified. But if the objects were created by the package, you *do* want to uninstall them when the package is removed. The only solution is to remove them in the UNINSTALL part of a resolver.

Similarly, when you remove a Theme package, it's critical to reset the Manager template back to it's previous value (or at least to the default template), otherwise the Manager crashes when it tries to use the removed theme.

I haven't used TPC, but I know the main drawback of PackMan (besides the things it won't do -- like resources) is the hoops you have to jump through when you update the code of your package and want to release a new version. I imagine that PackMan is also not very smart about uninstalls.