Development workflow

This becomes my habit, that all the custom snippets, chunks, event templates, are using a simple



It works for php, tpl, or html.

For development process, I always use it uncached, but cache it back when the site is deployed.

By doing this, I always edit my tpl templates/tpl chunks/php snippet files/ or php plugins/ outside the manager. I might always clear cache the manager, or just simply delete all the core/cache/ contents.

Good post, and something that has caused us difficulty also.
For lone wolf developers workflow is never an issue, but we may have 3+ developers on one MODx project.

Revolution 2.2 goes a very long way to addressing Workflow and Version Control:

All Elements (Templates, snippets, chunks etc) can be created as static resources (physical files on the filesystem). This is an excellent addition as several developers can use a distributed repository like mercurial or git to update snippets, chunks, plugins and templates, with staging and production sites being built directly from the repository. This allows a larger team to work away.

As Lucas points out, you only really need one snippet (an include snippet)
This include snippet takes in a class and an action (Like any MVC it calls class and function)
We then maintain class files that server multiple snippet calls and return processed chunks etc.
The classes are loaded in a snippet, and accessible on any page.

We are finding this approach far cleaner.
There is no business logic in the DB,

DB backup are essential BTW. Although the above approach relies on files, system settings etc can still get overwritten leading to bugs.

Working within MODx as an IDE is a very bad idea, I would not advise this at all.
There is no history of changes to snippets etc.

Personally I'm finding the whole "work via the manager" thing to be awful. Also, so much seems to exist only in the database that working locally and then moving things live can be an enormous pain in the backside (did you change anything for local dev purposes that ended up in the database? Of course you did. Move it live, miss one thing out of the myriad edits required to move environments and watch the site blow up).

There are 4 config files scattered around that you must edit, you will have assets that are easy to track like css and images but then all sorts of code ends up existing only in the database, custom fields are confusingly referred to as TVs and even have a little television icon associated with them muddying their role a bit further). Just creating and using them is a clunky process.

Having multiple developers work on things makes it all even worse. Trying to sort out which chunk or snippet or TV or whatever is used where under what circumstances and what name can be a pain on a larger site with multiple devs. If you have 2 people coding and a live site you have three environments and just wait until you have to move some non trivial changes live. Your sql dumps will all be different and require some careful diffing to make sure you have the changes you need sorted from the changes that were specific to any one environment.

So far I'm guessing that MODX is liked by people that built sites in things like Joomla previously. If you come from a more Zend Framework,Symfony style coding background MODX and its manager based development style with tons of stuff in the database is a nightmare.

Ricardo, try static elements (Revo 2.2+) or an include snippet as mentioned. It's a matter of preference and thankfully you're not locked in to one specific approach as there are alternatives. Like FEM or MODX-Mirror from Digital Butter which were mentioned before.

Also, you should sign up for the MODX Cloud beta. Dev, staging and production environments are super easy with that.

If any of you have any great ideas on how to simplify your development workflow (everyone's is different), please do post in the topic. Perhaps there's things that can be changed in the core to make it easier. There's already some improvements to developing custom components (+ fully backwards compatible) in the works for 2.3.

Hi everyone,

we should be clear about this, without any fanboyism, modx is awful regarding devoloping, especially in teams and especially regarding versioning. FEM, include snippets and such do help, but just a little - what about TVs, system settings and especially problematic thing - modifying live sites. I mean, basically, I must stop client from adding content while I am doing changes locally, or I must do changes on live site - which is, well...not good. Keeping everything in DB is bad practice and in my opinion bad decision, regardless of benefits that such approach brings. Using resources the "right way" (only as views) would mitigate this to some extent.

What we need is something I like to call xml manager, where everything would be defined in xml. For example, system settings, TVs, resources (ones which are not used for content), elements...would all be defined in xml.

I have started developing this and it would mitigate all the problems I stated above. Actually, one could develop anything with MODX without ever even going in manager. I plan to finish this within next few months.

Regards