As a first step, I would like to point out some factual errors in some of the
comments I have seen so far. Let’s take them topic by topic. Two topics are
discussed below. More to follow.
(I used utf-8 curly double-quotes below. They appear OK to me when I
preview this posting.)
WEB SITE LOGIN
My requirements include: “Until the user follows a login link, he should not
see a login box, a password box, a registration link, or a lost password link.
This decreases irrelevant clutter.”
Splittingred writes: “WebLoginPE. That’s all I have to respond to this.
Easily found via a forum search.”
I found WebLoginPE at
http://www.modxcms.com/WebLoginPE-1593.html.
The documentation doesn’t say that this snippet provides a login link without
clutter. The author’s web site at
http://scottydelicious.com/ shows a
login box, a password box, a password recovery link, and an account request
link, on almost every page. If the author is using his own snippet, and I’m sure
he must be, then I don’t see how this snippet eliminates login clutter on each
screen.
You can disagree with my requirements if you wish, but in that case the
appropriate response is to say so, instead of presenting WebLoginPE as the
solution.
BACKUPS AND RESTORES
My requirements include: “A good backup and restore procedure tells you exactly
what to do and asks you to make very few, or no, decisions, other than choosing
which web site to back up and where to restore it.”
Splittingred writes: “I don’t know how you missed the entire Backup section of
MODx. Also, most data in MODx is placed in a MySQL database, so backups and
restores are incredibly simple as they are only a SQL DB dump and import.”
Yes, MODx’s manager interface has a Backup menu. Backups are easy -- just dump
everything. Restores are hard, because you have to figure out how to restore
data without overwriting something important. This presumably is why MODx has a
Backup menu item but no Restore menu item -- because it’s expected that restores
will be done manually, and the user will figure out where things go.
How do you restore your MODx-based web site on top of a brand-new
installation of a newer release of MODx? The Upgrading Guide at
http://wiki.modxcms.com/index.php/Upgrading_Guide illustrates the
problem. It says:
7. Copy any snippets you need into the appropriate parts of MODxNew.
8. Copy any images, css, template files etc into the appropriate parts of MODxNew.
A reliable restore procedure cannot depend on a vague phrase like “appropriate
parts”. You can’t tell a script, or a junior employee, to copy files into
“appropriate parts”.
A CMS (content management system) manages content -- right? So the CMS knows, or
should know, where eveything is. The CMS should know where each “appropriate
part” goes. If the user has to manually figure out where things go, then the CMS
is not acting as a CMS, at least for restores. The desirable way of
doing restores would be to install a new instance of MODx, then go to a Restore
menu, enter the pathname of a backup data set, and have a
restore happen in the right places. The backup data set should contain all the
information about the “appropriate parts” already.
I’m not claiming the problem is technically easy to solve. I’m just claiming
that neither MODx, nor the other CMSes I tested, has solved it.
Once again, you can disagree with my requirements if you wish, but in that case
the appropriate response is to say so, instead of presenting MODx’s Backup menu
as the solution.
Rahul
MODX Staff
Should probably re-run some of it with the latest releases, and at the very least delete that template switcher plugin from MODx as also noted above.)