next »

[crossconnect]

Please see a brief review comparing MODx and CMS here:

http://rahul.rahul.net/reviews/modx-vs-cmsms.html

Rahul

[Jesse R.]

It would be nice if you had some sort of benchmarks to make the criteria more objective.

[splittingred]

Rahul, I hate to say it, but I think that your review of MODx comes from a core misconception of what MODx is supposed to be. Most things do not come "out-of-the-box" with MODx, because that's _not_ what MODx intends to be. MODx is not a CMSMS, nor a Drupal - it offers far more flexibility and depth of code. And with increased flexibility, you by necessity decrease the amount of pre-developed, this-way-or-no-way code that is so familiar in CMSMS, Joomla or Drupal.

Anyway, I have some comments to your review:

Documentation - I agree the current 096 documentation efforts are lacking - however, I can state with assurance that the documentation in 0.9.7 far surpasses this. I would also venture to say that 097 core code is far more documented than any other CMS currently.

As for your sitemap example, I was easily able to find multiple available snippets for doing a sitemap in MODx just in one Google search "sitemap":
Ditto - http://webbake.com/tutorials/modx-cms/google-sitemap-with-ditto
Sitemap - http://modxcms.com/forums/index.php/topic,5754.0.html
GoogleSiteMap_XML - http://modxcms.com/forums/index.php?topic=5521

Among others...

Previous and Next Links - This is easily done in a snippet. Would take very little time. And I don't agree with your comment for the necessity of p&n links - I find them to be more confusing, as where exactly *do* next links go when you're done with a section?

A good site would not employ P&N links - it would use an intuitive menu structure and document heirarchy that made navigation easy and familiar.

All of this is easily done in MODx - MODx lets the user determine the site content structure; so I found your criticism invalid in the sense that you seemed to have a user-generated problem here.

Caching - MODx _does_ do caching - see siteCache.idx.php. It does have problems with sites over 5000 pages (although if you're creating a site with more than 5000 pages, you might be needing e-commerce instead of a CMS, so it's probably a concept flaw in applicability) - but, 0.9.7 will fix that entirely. I dismissed most of the rest of your comments on site performance because of this oversight.

As for your flat-structure site; that's invalid because someone doing a blog would _surely_ not make a flat-structure site: they would have the articles indexed by date (year/month,etc) and stored in archive folders. Ditto and Jot traverse this easily.

I have found MODx to perform superbly on large-scale sites, and unlike your article, I *have* tested it and deployed it in those contexts. I would recommend to drop your comments on that, or at least provide some benchmarks.

Management Interface - I wholly disagree that it would be *easier* and *faster* to do things without javascript. Imagine trying to select the parent for a document without the JS parent selector in MODx - you'd have to have a gigantic dropdown select with all the documents in it (ugh!), or a textbox where you'd type an ID # (double ugh!). Either of those non-JS solutions are horridly slow and inefficient, and that's just one example.

Usability of Manager - For one, when you say that you didn't use the WYSIWYG and then write an article about usability, you lose a ton of credability. That's like saying, "I'm going to review this 2006 Camaro but take out it's exhaust system."

Secondly, the sizability of the text box is fixed in 0.9.7, using Ext2's growing textarea feature.

Backups/Restores - 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. Easiest way of backup there is. As someone who backs up a 1200+ document MODx site daily, I can attest to the easability of this practice.

Web Login - WebLoginPE. That's all I have to respond to this. Easily found via a forum search.


Some things in your article are very helpful and informative, so regardless of how this response may sound, thank you for writing the article. We at MODx appreciate any and all critique and inspection given. It helps us grow and improve. This response was solely written to clarify some of the issues you were experiencing.

We hope you'll continue to use MODx, and believe you'll find it to far surpass your initial review.

[rthrash]

Hi Rahul,

Great analysis overall and very much appreciated. However, I think your analysis is a bit skewed on a few key points. Splittingred raises some good points above, but in reality the only issues I have with the review are noted below. Really the only major problem I have with it is raised in the first point below and I think that creates a factual inaccuracy with your review that negatively paints an inaccurate picture of MODx. The rest are simply problems related to the MODx legacy code we're taking care of with 097 or the often-lacking documentation and sometimes-crazy search results. On those issues, seem my last paragraph below.

First and foremost, caching. MODx uses caching, since I noticed your benchmark was for 095 (more than a year old and already having two successor releases with a third on its way soon), I can almost guarantee that the template switcher plugin came into play. This was used to enable switching between demo templates on the front end demo site and it totally disables caching and honestly creates all sorts of problems in many cases. It was removed entirely from subsequent releases. Heck you could probably just re-run your tests after deleting that plugin and you'd have grossly different results.

Second: 0.9.5 ... see above as it's simply very out of date. (And I did note your disclaimer ... but I'm not the one that chose your publishing schedule! 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.)

Thirdly, global previous next links? I can only recall one site I've built with that and that's the MODx site for the documentation section. How is that a benchmark of a CMS when it's not a pervasive feature for ever site and also when it's quite easy to accomplish.

Your points on documentation and site usability are very well taken and totally right on and we're working on it. Care to get involved in helping rectify these issues?

[ganeshXL]

[2] Management interface usability would be rated "excellent" for both CMSes if they provided protection against accidental erasure of the contents of a web page.

I don't get this part at all. Deleting a document in the MODx manager is a two-step procedure: You can still un-delete a page if you want to, and there's warnings popping up if you want to delete stuff. If people then still "accidentally" erase content... guess it's more of a user-error than a flaw with the application.

And yes, not using the WYSIWYG editor when testing a CMS is just odd. I can't imagine ONE client who would want to give up WYSIWYG functions. They have no intention whatsoever to start learning HTML and CSS.

Also... it IS possible to resize the content-window vertically in the manager; it's just a custom setting which is off by default.

[crossconnect]

Great responses so far!  I appreciate that you all read the review and put down your reactions to it.

In the near future, I will make factual corrections in it based on your feedback, and I will also post my rebuttal where it's just a difference of opinion.

Rahul

[rthrash]

There will always be differences of opinions and the stuff being fixed in future releases doesn't address what's broken in the distribution today indeed.

How about the offer to help us sort out the documentation, search and other support site usability concerns?

[crossconnect]

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

[crossconnect]

Splittingred writes:

As for your sitemap example, I was easily able to find multiple available snippets for doing a sitemap in MODx just in one Google search "sitemap":
Ditto - http://webbake.com/tutorials/modx-cms/google-sitemap-with-ditto
Sitemap - http://modxcms.com/forums/index.php/topic,5754.0.html
GoogleSiteMap_XML - http://modxcms.com/forums/index.php?topic=5521

Alas, no, factual error here. All three above are for generating a site map for Google, not for humans.

Please see what I wrote:

Result: mention of a "sitemap" snippet, which generates a site map for search engines. This was not what I wanted, since I wanted to generate a site map for human access.

Rahul

[crossconnect]

NEXT/PREVIOUS LINKS

Rthrash writes:

Thirdly, global previous next links? I can only recall one site I've built with that and that's the MODx site for the documentation section. How is that a benchmark of a CMS when it's not a pervasive feature for ever site and also when it's quite easy to accomplish.

There are two factual errors here.

Please note my requirements: “By following all the Next links, I can traverse web pages in a useful order, visiting each page exactly once....This lets me traverse the web site as if it were a book. You can read a book from beginning to end if you wish”

The MODx documentation does use Next and Previous links, but they do not conform to my requirements. As an example, if you go to http://modxcms.com/editor-guide.html, you will see a Next link pointing to “Designer's Guide”. If you follow this Next link, you will have missed viewing all of the pages in the “Content Editor's Guide” section. So these Next links do not let you visit each page exactly once. They let you visit some of the pages, and you will miss many pages. It's as if you turned a page in a book, and 10 pages were stuck together, so you missed reading them.

Hence, we have a factual error.

The second factual error is that the PrevJumpNext snippet (to which the link in the quoted text points) does not implement Next/Previous links according to my requirements. If you use the snippet, you will get the same effect as described in the previous paragraphs, i.e., you will miss some pages.

By all means please feel free to disagree with my requirements, but the above are errors of fact, not differences of opinion.

Rahul

[ganeshXL]

mention of a "sitemap" snippet, which generates a site map for search engines. This was not what I wanted, since I wanted to generate a site map for human access.

I don't know what the fuss is all about. Creating a sitemap with modx couldn't be more simple: A simple, basic [!Wayfinder!] call will do exactly that: create a sitemap (for humans). That's documented in various places, in forums, articles, the Wiki etc. Also, Wayfinder is one of the most prominent modx snippets, already built-in and therefore difficult to miss. The sample pages you can install features one such sitemap example.

[crossconnect]

I don't know what the fuss is all about....That's documented in various places....

These, I believe, were the very same last words of all the folks running all the search engines before Google.

Rahul

[rthrash]

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.”

Is there a reason a simple link or weblink, to a page that contained the weblogin bits would not work? That's a simple implementation decision, or am I not understanding the requirement?

Further help me understand the previous/next links bits if you could. How many websites do you see that actually implement this, and why is this a requirement for evaluation? It would be trivial to author a snippet to parse through the menu indexes of the pages in your site and create those links. How do next/previous links work in sites with deep hierarchy? How would they work on a site like apple.com or adobe.com or any non-blog site for that matter?

[crossconnect]

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.”

Is there a reason a simple link or weblink, to a page that contained the weblogin bits would not work? That's a simple implementation decision, or am I not understanding the requirement?

A single link entitled 'Sign in', 'Log in', etc., is all you need. You can see this in use at http://www.google.com/, http://en.wikipedia.org/, and http://rahul.rahul.net/, among others. However, after logging in, the user should be able to easily return to the page from where he came, and various web sites succeed in facilitating this to various degrees. At http://en.wikipedia.org/, you just follow another link to return to the page. At http://rahul.rahul.net/, you need to use your back button a couple of times (not so good). At http://www.google.com/, most of the time, you end up where you wanted to be after you log in, but in some cases, you do not, depending on what you were trying to do. So implementations vary in their quality. Ideally, after you log in, you should find yourself back on the page from where you followed the login link.

You can see it NOT in use at http://www.drupal.org/, http://scottydelicious.com/, and some of the MODx web sites, all of which repeatedly present a login box, a password box, a lost password link, and a registration link, to every user, on every screen, whether or not the user has any intention of ever logging in or registering.

More later re your second question.

Rahul

[crossconnect]

Further help me understand the previous/next links bits if you could. How many websites do you see that actually implement this, and why is this a requirement for evaluation? It would be trivial to author a snippet to parse through the menu indexes of the pages in your site and create those links. How do next/previous links work in sites with deep hierarchy? How would they work on a site like apple.com or adobe.com or any non-blog site for that matter?

General rule 1: Every web page should suggest some next web page for the viewer who is uncertain as to where to go next.

Corollary: Every web page needs a reasonable Next link.

General rule 2: Don't make the user go in circles.

Corollary: All the Next links should let the user visit each page exactly once before he eventually reaches his initial location.

As to how many web sites do this--very few, primarily because they use CMSes or web design software that makes it hard to do. But remember, we are talking here not about web site design, but about CMS design. A CMS should provide facilities that will allow good web sites to be designed. If a web site could fruitfully provide a Next link on each page, the CMS should make this easy.

So you will ask: In what order should the Next links point? Just look at the web site tree on the left-hand-side of the manager screen. The designer needs to order them in some manner that makes sense to him. That's the order. Just do a preorder traversal of the tree.

Here are example sites.

Look for a link near the bottom of each page, and follow the links all the way to the end:

  http://www.avicraft.co.uk/
  http://www.lincombehouse.co.uk/

This one has REL links:

  http://www.christchurchguildford.com/index.php?page=finances-and-giving

Rahul

[sottwell]

Seems to me that's a design decision, and as has already been stated, would be very easy to implement with custom snippets.

It's not something I feel the need for; a good menu structure is my answer to that. I don't see why most users would be at all interested in going from page to page, when a clear menu structure will let them go exactly where they want to go to begin with. Most users will go away if they don't find what they want within a click or two, and paging through a site from one end to the other is not what most of my users are at all interested in doing.

Besides, any serious site will have a prominently linked "site map" so a user can see the whole site at a glance and decide where he wants to go.

On a personal note, this "sheep" idea, that your users need to be gently (or not so gently) herded along in the direction you deem appropriate is not what I think the Web is all about. But again, that's my reason why I would never implement such a feature on my sites, and it is a personal design decision. I appreciate MODx giving me the flexibility to do as I choose in my design decisions.

[crossconnect]

[2] Management interface usability would be rated "excellent" for both CMSes if they provided protection against accidental erasure of the contents of a web page.

I don't get this part at all. Deleting a document in the MODx manager is a two-step procedure: You can still un-delete a page if you want to, and there's warnings popping up if you want to delete stuff. If people then still "accidentally" erase content... guess it's more of a user-error than a flaw with the application.

Yes and no. Mostly, no.  Here is another opinion about warnings and accidents:

  http://www.alistapart.com/articles/neveruseawarning

But the real problem here isn't so much deleting a page, which is rarely fatal in MODx, but overwriting its contents, which is always fatal. If you absent-mindedly hit ^A to select the entire page while editing it, then type a couple of words and then save, you are SOL.

Rahul

[davidm]

But the real problem here isn't so much deleting a page, which is rarely fatal in MODx, but overwriting its contents, which is always fatal. If you absent-mindedly hit ^A to select the entire page while editing it, then type a couple of words and then save, you are SOL.

Sure... but the only solution to that is versionning (which will be avalaible in the future), and I am not aware of many CMS having this, does CMSMS now have it ?

Interresting thread by the way, too bad I don't have much time at the moment to jump in... I had written a quick comparison of txp vs cmsms vs modx vs EE a while, back and I am planning to upgrade it...

[dev_cw]

MODx does have the REVERT option in the front end editing (quickedit) it is not a failsafe but allows you to view the changes and then revert if needed as long as you keep the edit window open. I would imagine that a true content versioning would lead to a bloated database.

crossconnect: I don't agree with those guidelines at all. I have never needed to include next/prev links in any site other than in multiple page articles. This would be a project specific requirement but not a global one and thus should not be in the core of MODx or any other general purpose CMS. I could see this in purpose specific tools like a dedicated blogging app, but with MODx you never know what will be built.

[Soshite]

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.”

Is there a reason a simple link or weblink, to a page that contained the weblogin bits would not work? That's a simple implementation decision, or am I not understanding the requirement?

A single link entitled 'Sign in', 'Log in', etc., is all you need. You can see this in use at http://www.google.com/, http://en.wikipedia.org/, and http://rahul.rahul.net/, among others. However, after logging in, the user should be able to easily return to the page from where he came, and various web sites succeed in facilitating this to various degrees. At http://en.wikipedia.org/, you just follow another link to return to the page. At http://rahul.rahul.net/, you need to use your back button a couple of times (not so good). At http://www.google.com/, most of the time, you end up where you wanted to be after you log in, but in some cases, you do not, depending on what you were trying to do. So implementations vary in their quality. Ideally, after you log in, you should find yourself back on the page from where you followed the login link.

You can see it NOT in use at http://www.drupal.org/, http://scottydelicious.com/, and some of the MODx web sites, all of which repeatedly present a login box, a password box, a lost password link, and a registration link, to every user, on every screen, whether or not the user has any intention of ever logging in or registering.

More later re your second question.

Rahul

By your logic, mail.google.com should have a login link, which allows you to go to ANOTHER page that has a login box. You said before, the user shouldn't have to go in circles --- what do you think clicking a link to go to another page where you have to click again to login does? 

And some webpages, like mine, don't have a "go here next structure". Like on my website, I have the index + site-related pages, then the consoles, which have sections for the games for those consoles. I'm working on getting a sitemap up in the next few weeks (besides one already on the 404 page), but your "Web 2.0" idea doesn't work for every website. Plus, doesn't "herding" your visitors basically give them the impression that you think they are a bunch of mindless idiots who need someone to guide them every couple seconds, else they get all OMGWHEREDOIGOEZ?!? Those sites you mentioned are "flat" sites, meaning that they don't have a complex hierarchy like my site does, for example. MODx isn't Joomla!, where every site is a cookie-cutter image of the other.

And IIRC, you have to click Save to get a page "overwritten". So if you can't control your mouse enough to not click it, it's your own damned fault. Plus, that's why people should keep database backups handy.