Proposal to Overhaul Manager Architecture

Imagine the Manager as being rendered just like the content pages: every page content is stored in the database, and built out dynamically at runtime by the document parser. This would really push the true core code down to a user access system, a document parser, an installer and a database access system. Everything else would be ancillary and be the functional equivalent of a plugin to the system.

Because the manager code would be stored in the database (even if it's built out to the filesystem later), it'd be easy to have the capability to do rollbacks by changing the active version of the source code set. Checksums could be calculated during logins to make sure the most current versions were running, or weren't changed .

Code updates could be encapsulated in a single SQL file, and possibly even pulled down transparently in the background when triggered via a cron task at night. The next time someone with the appropriate security level logs in, it'd be just like the Windows or OS X software update that had downloaded the files for you and they're ready to install. Possible security issues?

Conversely, you could also "install" files by dropping them into a folder and having them automagically sucked into the Manager system.

You'd never have to delete the currently running set of files again by overwriting files. The installer would just mark the current state, flag certain files as the previous version and deactivate them once the new version are installed and pass whatever checksum routine they need to pass. Run a bit of code to build the files out to the filesystem for your "local cached" copy from which the system executes, if you're worried about speed. IF you're worried about database size (which I don't think should be a concern for our initial target market) then distribute these "builds" or purge old files if you're happy with the upgrade.

How's this sound?

Sounds better than editing 2.php, /manager/index.php, and writing dynamic.action.php and processor.php files, not to mention editing the language files and css files...however...

I'm not fond of the automatic downloading of updates. I personally would much prefer having to activate an update somehow; perhaps a link in the manager menu, and an opt-in newsletter to announce available updates.

I'm not happy with the idea that my installation is going to be "phoning home" on its own for any reason. I don't much care for all the software on the Mac (including the Apple Update stuff) that is always checking for updates, and no way would I allow automatic updating for anything. What if the modx site gets taken over? Or even if the DNS server got poisoned so the phone-home link went somewhere malicious? I much prefer to check the site myself, and then activate an update check function if I'm satisfied that all is well.

It's kind of like the idea of having groceries delivered once a week, and the grocery store has a set of keys to your house.

All very, very valid and a great reason to turn it off by default, but allow it to happen if admins wanted it to.

Hmmm... how about RSS feeds of new updates on the manager landing page?

Hmmm... how about RSS feeds of new updates on the manager landing page?

This I would have to disagree with. Wordpress does this on their Dashboard and it's annoying and there are hacks out there to get rid of it. If users want to stay informed they should sign up for a low volume email distribution for announcements. Dashboards and landing pages should really show information internal to the system, such as pages in workflow waiting approval, or new pages published, etc.

I see what Ryan has in view, I think, and I guess the babysitting and handholding of clueless newbie users is necessary in some software. I sort of feel that anybody trying to set up a managed website is not in the same league as somebody making a homepage on AOL or .mac (does AOL let you make a home page?). Or shouldn't be, anyway.

However, as long as the "feature" could be disabled, or maybe even make it an optional plugin at installation, it wouldn't be so bad.

Susan I think that's a great idea. Definitely shouldn't be a core chunk of code as the newbie type users aren't in our primary target focus right now. If you haven't noticed, I tend to spend quite a bit of time strategizing on long-term issues.