Website Development Workflow - code is stored in db?

I'm looking at building my next project with ModX. I've been trawling the forums and it seems like a great product and thriving community.
Templating seems like it is going to be great and ModX cloud sounds promising.

The one thing that is giving me pause is that code seems to be stored in the database?
This post in the "git workflow on MODX Cloud" mentions syncing databases for "DB records for snippets/chunks/templates/packages".

1. Revisioning databases is generally a PITA
2. Does this mean code is written from inside the admin in a textarea, rather than an IDE?

I'm currently using Joomla for my projects with everything tracked with git:

• Fork of github.com/joomla/joomla-cms
• Branch for each website
• .gitignored configuration-local.php that overrides configuration.php so each install uses its own database while still revisioning changes to site configuration
• php shell script run from a git hook to pull in the db config, dump with --skip-extended-insert (each record is on a new line) --skip-comments --skip-dump-date and then strip irrelevant auto_increment/session/search records with sed

The last allows changes to the database be almost revisionable and mergeable. The joomla assets table however, is not.

Then I have separate repos for the template and/or custom components.

Is there a similar (hopefully less convoluted ) way of working with ModX?

• Everything under revision control
• Dev, Staging, Live with multiple developers
• Coding/debugging within sublime/eclipse

Code (php and html) are stored in the database with the option of using "static" resources and elements, where code is in a file. With static elements, code is editable from both the Manager interface and the file.

With static resources, the content is simply the path to the file. Along with custom types (PDF, etc) a static resource acts as a download interface; you can have the file itself outside of the web root, and the link will be to the resource, not the file, while clicking the link will behave exactly as if a direct link to the file had been clicked (display or download, as the browser is configured).

Almost all CMS platforms store things in the DB by default. Take a look at the VersionX extra -- a nice tool for keep track of versions and reverting things in MODX.

Also, see this discussion: http://forums.modx.com/thread/?thread=80939&page=1

Almost all CMS platforms store things in the DB by default.

Content and configuration in the database, sure... but logic and presentation?

I've designed a page layout and style with a bootstrap-based theme, so I downloaded the Theme.Bootstrap extra - expecting a bootstrap file-structure and intending on merging my project into it to create a MODX template. Then continuing to develop it with bootstrap-sass and revision controlling with git.

... but all of the html and css is in the database in modx_site_htmlsnippets and modx_site_templates!

This is my first attempt with MODX so forgive me if I've missed something obvious. How do I use 'static resources' for my theme instead?

Hmm, okay... had to comment out


from .gitignore to see that the theme was downloaded to assets/components/themebootstrap/
however, modifiying assets/components/themebootstrap/elements/templates/bootstrap.tpl didn't change anything (even after refreshing cache)

Looks like I have some more reading to do. Really hoping themes can be easily edited as files in MODX, there is a lot to like so far.

If you check the "static" checkbox for all those Templates and Chunks, their content can be stored in files. I don't have that Extra, but I think you can find the files in assets/components/themebootstrap/elements. After you check the "static" checkbox, you can link those files to the elements, though you might want to duplicate them and link to your duplicates. Duplicating them will keep the originals for reference and will prevent them from being overwritten if you upgrade the Extra.

Thanks, I copied the package then changed each template and 'chunk' to a static resource and made my changes.
Had to disable caching in order to work on it and see changes in the browser ...

Must say i'm still struggling with the idea that logic and markup code are expected to be edited in a textarea and saved to the database.
It's only early days, I still have a lot to learn about MODX, but so far it seems To use a code editor and the command-line for front-end development with MODX requires effort and compromise. This just seems odd.

My mockup was created with sublimetext (w/ all it's helpful features and plugin), bootstrap-scss & compass (ruby), composer (for a PHP API library) and git. It's by no means finished but modx expects everything to be finalised, cut up and inserted into the database.

I've nowinstalled articles and been greeted with another two templates that i need to create as static resources matching my main template.

Someone help me see the light?

logic and markup code are expected to be edited in a textarea and saved to the database.

I'm not sure I'd say "expected" - that's the default behavior and probably the simplest workflow for everyday changes but it's certainly not the only option.

For minor revisions, I find that editing code directly in the database and using VersionX for version control is adequate.

For more extensive changes, I would recommend developing on a separate install and using transport packages for versioning and transport from dev to production. I gave a talk on this at a user group meeting in Denver, the slides are here: http://prezi.com/0nxhc5xefz_m/staging-from-development-to-production-in-modx-revolution/.

For most purposes, the PackMan extra works well for building transport packages from objects in the database, or if you prefer to develop in files, Bob's myComponent extra is a good solution for easily building your transport package.

For your setup, I would recommend installing myComponent on a development server. Add all of the elements you need, including copies of the Articles templates and whatever you've developed already, to your myComponent configuration. All of these elements would then be stored as files in one directory on your dev server, so you can make that a git repo. Develop the files however you like, and when you're ready to go live with them use myComponent to build a transport package to install onto the live server. This is admittedly some extra effort up front to set up, but it should give you the kind of version control you want.

Thanks very much for your detailed reply freejung. I'll give this a shot

You're welcome. I've been using myComponent more since posting that, and I definitely recommend it. It takes a bit of getting used to, but once you have it figured out it saves a huge amount of work compared to directly coding your transport packages.

Once you have it set up, you can develop elements (snippets, chunks etc) as files on your dev server, push them to your git repo for version control, quickly import them into your dev environment for testing, and easily package them for installation into your production environment.