Directory Structure

I think it's also time to think intelligently about how the directory structure is laid out for MODx.

What I'd like to see is something that makes it dead simple to move sites between servers/domains/staging locations and to backup and upgrade a site quickly and easily.

Keep in mind, the as-yet-unreleased plugins will need to be kept in mind, and every site out there could potentially have a unique collection of plugins. For example, one site we're launching includes a plugin that logs users into IPB when they login to the webuser side of MODx. We also have a custom application that's implemented as a plugin inside of MODx.

So with that said, there's two parts to think about: the front end look-and-feel and application(s), and the Manager-related stuff.

Having most things in the DB makes updating/moving rather simple, but it doesn't address the plugins, images, CSS and other header-linked files or other template-specific files.

Perhaps we need to add a button to the manager that "re-homes" the base paths to facilitate this as well. Other suggestions?

Having most things in the DB makes updating/moving rather simple, but it doesn't address the plugins, images, CSS and other header-linked files or other template-specific files.

This might not be a popular option but why not store them in the DB? That way we get metadata on them (who uploaded it, when) and version tracking. Ditto for CSS and any other files. When they are needed by the public website, we publish it to the local filesystem with the appropriate path.
As for plugins, I have never felt mods like that should be backed up, when you do a fresh MODx install you have to install whatever plugins you're using as well. But that is considering my definition of plugin, yours might be different.

Having most things in the DB makes updating/moving rather simple, but it doesn't address the plugins, images, CSS and other header-linked files or other template-specific files.

This might not be a popular option but why not store them in the DB? That way we get metadata on them (who uploaded it, when) and version tracking. Ditto for CSS and any other files. When they are needed by the public website, we publish it to the local filesystem with the appropriate path.
As for plugins, I have never felt mods like that should be backed up, when you do a fresh MODx install you have to install whatever plugins you're using as well. But that is considering my definition of plugin, yours might be different.

Another possibility related to this issue that would also help address storing all this stuff in the repository: the overlooked, and oft misunderstood WebDAV protocol. I wonder if with mod_dav, we could enable DAV access to the manager? The we could publish and manage documents, snippets, chunks, etc. from the likes of Dreamweaver directly.

Just a thought.

This might not be a popular option but why not store them in the DB? That way we get metadata on them (who uploaded it, when) and version tracking. Ditto for CSS and any other files. When they are needed by the public website, we publish it to the local filesystem with the appropriate path.

This is actually not a bad idea at all, and something Raymond and I talked about a while ago. I believe vBulletin does things this way, which greatly facilitates upgrades and incremental updates. It also makes it pretty straightforward to maintain a version control history as well. The tradeoff is the extra load on occasion for the database, but not a big concern in my mind.

It still doesn't address the need for a logical directory structure for no other reason than to help people understand what's going on in the system, though.

As for plugins, I have never felt mods like that should be backed up, when you do a fresh MODx install you have to install whatever plugins you're using as well. But that is considering my definition of plugin, yours might be different.

Now we're getting into a Taxonomy discussion! (Which is also apropos.) What do you consider a plugin/module/whatever? From a backup standpoint though, I think everything *should* be backed up for disaster contingency purposes. Fresh installs are a different story.

Especially if we are moving to storing everything (presumably pre-cache) I would like to toss out two other aspects I'd like to see:

I would love for everything under manager/ to be able to be placed in a central place and easily allow multiple sites to be run off the code.

Then all site specific files would be in assets/ and you could host multiple, even non-related, websites off the same physical codebase.

With the CSS, templates, content, and all related snippets in the DB, this should be a no-brainer as far as the actual coding goes. How everyone else feels about it, though, might be a bit trickier.

The other thing I'd like to consider is mirrored servers. I, for instance, have a primary server + two slaves that are all fully redundant and uses master/slave MySQL relationships to keep the DB in sync. The filesystems, however, can lag by as much as five minutes. In an ideal world our little project could actually understand such setups and do somethings internally to communicate between all the servers. I suspect this may be a long ways off, but am definitely interested in discussing this further with anyone who may have similiar setups...

While we are discussing such things, something that I have found very useful:

Create a custom class and place it in a separate file "modx_custom.inc.php"

<?
modxCustom extends modx {


};
?>

Then instead of doing a
$modx = new modx;
you'd init the class by doing:
$modx = new modxCustom;

By default, the modxCustom would have nothing in it, of course, but if this was standard in the install and then never shipped in any updates, functions or site specific overrides can be applied in the custom file, and the main class can be updated at will without worrying about overwriting custom features/requirements.

As easy and dumb as it may sound, I'm doing this for a couple of clients and it makes providing updates much, MUCH easier.

Great!

Love the ideas that are being discussed here.

I have mentioned 2 ror 3 times now about gossamer-threads.com and their SQL applications because they have had pretty good success with their plugin/mod download ability.

To be honest I haven't used their scripts in about 3 years so I am not sure how much further they have advanced or not.

But the idea was that you could to the manager and get whatever plugin was available and load it into the system and just activate it.

They offer both free and payed for mods which are clearly stated when you go to download.


Which reminds me, like Ryan menioned in another thread. We are going to need to figure out at one point or another is what legalities are we going to run across if people start offering payed for modules. I wonder if those plugins are truely non-GPL or not. Somewhere I read that if the core code is dependent on the main GPL code base then the following code must also be GPL. hmmmm. To be honest this part of my post should be moved to another time and place on these forums probably.



Also above the problems with updates to the core system is another excellent point. I am definitely in favor of having things as simple as can be so that later on in life when updates do come out that a full reinstall won't be necessary.

An idea could be is to keep all mods/plugins/snippets in a compressed form somewhere in a general download type of directory. After which the end user can install whenever they want. This type of idea will also be beneficial for those who have enough time to come and look but don't have enough time to install everything. They can then come back later to their site and install at a time when they have more time.

At the moment I agree with Ryan that the m/p/s should be backed up. This will save a lot of time for the end user and headaches later.


However, let's keep the ideas rolling