Site Navigation

MODx vs CMS Made Simple

This document compares two open source content management systems: MODx (revision 0.9.5) and CMS Made Simple (CMSMS) (revision 1.0.6).

Quick conclusions: A simple navigable web site can be more easily created with CMSMS, but MODx provides a more useful search facility.


I wrote this review in May 2007. I did not make it public at that time because I wanted to do some more verification of some of my observations, especially related to caching. But I didn't have the time to do so, and this review remained dormant and non-public. Since then, newer versions of these CMSs have been released, so some of my observations might no longer be valid. Please handle with care.


Attribute CMSMS MODx
Ease of installation Excellent Good
Ease of making first web site Excellent Fair
Basic documentation Excellent Fair
Advanced documentation Poor Poor
Search Poor Very good[1]
Web site usability Excellent Fair
Management interface speed Poor Poor
Management interface usability Fair[2] Fair[2]
Web site speed Fair Fair; potentially poor[3]
Site map Excellent Excellent
Global Previous and Next links Excellent Poor
Management scalability Probably poor Probably fair
Page caching Fair Poor[3]
Markdown support Excellent Very good
Backups and restores Probably poor Probably poor
Advanced functionality Probably good[4] Probably excellent[4]
Web site login Fair[5] Fair[5]
Value Good[6] Good[6]

Each of these two CMSes has strengths and weaknesses. If we could magically combine the best qualities of both, and add versioning, documentation, and scalability, we would have a killer app.

[1] MODx search would be rated "excellent" if it had a help link explaining the search syntax.

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

[3] MODx Web site speed is rated "fair; potentially poor" because MODx does not seem to do any caching. On a busy web site, lack of caching will likely cause poor performance.

[4] Due to lack of good advanced documentation, a lot of effort may be needed to benefit from the full power of either CMS.

[5] Verbose or unnecessary login clutter on screen, and/or completing login does not put user on the originally-desired URL.

[6] If you were to create a small static web site with small pages, the value rating for each CMS would be "excellent", since the benefit is significant and the cost is zero. However, I have factored in the possibly high cost of coping with lack of good documentation for advanced functionality, and the possibly high cost of losing the contents of a web page with no undo and no rollback.

Why Compare MODx and CMSMS?

I wanted to find an open source CMS. My requirements included those listed below. Only the first one in the list (valid HTML) was non-negotiable.

I eliminated the majority of open source CMSes based on their inability to generate valid HTML. That left only a few to actually try out.

I installed a number of different CMSes. Specifically:


Drupal is probably the most widely-used of the CMSes that I tested. Many production web sites successfully use Drupal.

I eliminated Drupal because:

None of these problems, by itself, was the determining factor. But together, they added up to enough to persuade me to use something else.

Of the CMSes I tested, Drupal is the only one that includes versioning.


Textpattern had a fast and fairly intuitive management interface. Web page updates could be very quickly done using theTextile mark-up language. Textile can do more than Markdown but is not so easy to read in its raw form.

I eliminated Textpattern because:

CMS and MODx

With Drupal and Textpattern eliminated, I was left with CMS and MODx. So I proceeded to evaluate both in some detail.


CMSMS: Very good.

MODx: Good.

The install instructions for both were quite easy to follow. I installed each one in three different directories (and domains) on the same server. Actual installation took quite a bit longer for MODx.

Many users will have shell access, and so could benefit from a shell script that would adjust all appropriate directory and file protections. No such shell script comes with either MODx or CMSMS.

Both packages have a check mode during installation, in which sanity checks are done and the user is invited to fix any problems found before continuing.

Neither package printed the error messages in a form that could be copied-and-pasted to apply fixes. Suppose a number of files are not writable. The CMS installation procedure should ideally print the filenames in a list, so the user can copy-and-paste them into a single command to write-enable the files. Instead, these CMSes tended to print many error messages, one for each file, making copy-and-pase rather tedious.

MODx has a very strict default policy of locking out the administrative user if he mistypes the password three times. When this happens, the user is told that he is locked out, but not for how long. As a result, the initial installation procedure can result in a frustrated user who is locked out and does not know how to get around this problem. A Google search revealed some solutions, but the page that told the user that he was been locked out did not have any help link pointing to any of these solutions. Both in the MODx forums, and at the web site (which lets people evaluate open source CMSes online), I saw complaints that people had been locked out.

If a lock-out is needed despite the risk of denial-of-service attacks that may lock out legitimate users, the default lock-out time should be kept no larger than 30 seconds. This should adequately slow down potential intruders without frustrating new users.

Initial Web Site

MODx: Excellent.

CMSMS: Excellent.

Both packages come with a set of default pages that form an initial web site. They serve as examples to help the user create his own pages. I found it very enlightening to look through these example web pages.

Documentation Notes

In my opinion, good documentation to let a user accomplish a specific task must have at these three properties:

  1. Existence: The documentation must exist in the first place.
  2. Usefulness: The user should be able to fruitfully use the documentation that does exist.
  3. Findability: The user should be able to find that documentation.

MODx has a greater quantity of advanced documentation. So MODx may come closer to satisfying condition 1 (existence). But both MODx and CMSMS fail quite dramatically at satisfying conditions 2 (usefulness) and 3 (findability).

I found the following to be the biggest problems in the documentation that I did find:

See the description of "CMSMS: Pisearch Module" for an example of just how bad documentation can be.

For the more basic operations, however, CMSMS documentation turns out to be satisfactory. It's only when you try to extend the functionality that CMSMS documentation begins to fail.

Basic Documentation

By basic documentation I am referring to documentation needed to make a simple web site in which all content is static with the exception of navigation menus, a site map, and a search facility.

CMSMS: Excellent.

MODx: Good.

CMSMS's basic documentation was nothing short of outstanding. With almost no effort, I was able to create new web pages, form them into a hieararchy, add search boxes, add a site map, and (after some searching) use Markdown for entering text. The example web pages included with CMSMS contained enough help text to do almost all of this. A little effort to look at the CMSMS web site, and all my basic questions were answered.

MODx's basic documentation was not quite as good. Even though the online manual on MODx's web site seemed to be very thorough at first glance, I experienced some confusion actually trying to follow its instructions from beginning to end.

MODx's documentation pages on its official web site had a lot of links. Links at the top of the page. Links in the main content section. Links in the sidebar. More links in the sidebar. I spent some time trying to decide which links would be useful and which were irrelevant to the topic I was studying. And there was no Next link on every page that I could always follow to continue reading the documentation in logical order. I had to carefully examine the menus and figure out where to go next. I often guessed wrong.

Link colors for the MODx documentation's visited and unvisited pages were identical, so I found it difficult to keep track of which pages I had already visited. The CMSMS web site link colors were equally unhelpful; but their layout, which allowed me to navigate in logical order from beginning to end, compensated quite well.

MODx's documentation seemed to be in many pieces in many places. Many of these pieces contained mostly but not entirely redundant information. So, I might end up reading three different web pages, each containing mostly redundant content, but each contributing a little bit that was different from the others.

CMSMS's document was fragmented when I ventured outside its core functionality (e.g., when trying to figure out if a better search module was available). MODx's documentation was fragmented almost everywhere.

Example of Findability

As an example of findability or lack thereof, suppose a user wants to generate a site map. Since almost every web site designer will want to do this at some point, this is something that every good documentation writer will anticipate and describe.

Let's try some searches.


MODx: First Try

  1. I did a Google search for: modx site map.
    • 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.
    • Another result: A document that mentioned MODx site maps, and mentioned that site maps could be generated, and included a link to "Wayfinder updates and support" and a link to "Ditto updates and support".
  2. I followed the "Wayfinder updates and support" link. It led me to a page about the Wayfinder menu generator. This page did not directly tell me how to make a site map, but mentioned generation of menus. Following a link to the author's home page, I saw more links, but no mention of how to make a site map. The only Wayfinder-related link was entitled "Announcing Wayfinder Version 1.5 beta", so I followed this link.
  3. Now I was on the "Announcing Wayfinder Version 1.5 beta" page. It didn't tell me how to generate a site map, but did include a link to a "Wayfinder Snippet Development Area". I followed this link.
  4. Now I was on a page that described "Wayfinder ver. 2.0" features. It didn't tell me how to make a site map, but things did look promising, because I saw an "Examples" link.
  5. Following the "Examples" link, I saw many types of menus described but (sadly) no mention of any site map.
  6. The "Parameters" menu gave me lots of options that Wayfinder can take, but still no mention of how to make a site map.
  7. I had followed five links with no useful result, so at this point the typical user would likely give up, figuring that if there had been any useful site map information here, he would have seen it by now, in the examples if nowhere else.

If the user read the description of all the Wayfinder options, he would with some trial and error figure out how to make a site map. Wayfinder does have the functionality. But findability is very poor. It's not easy to find out just how to use Wayfinder to make a site map. So in this case, the documentation exists (existence: excellent), can be used with much effort to figure out how to make a site map (usefulness: fair), but it's hard to find the right set of options or any examples (findability: poor).

Emulating a user who doesn't know where to look, I did not follow up the "Ditto updates and support" lead. But I did do the following:

I continued down the list of Google hits.

MODx: Second Try

Going further down in what Google found, I saw another hit that seemed promising, which mentioned "The following examples cover usage of the default Navigation/Site Map snippet." Following the link to, I found that the code "[!DropMenu? &showDescription=`1`!]" was supposed to generate a site map.

But when I put this on a test web page, I got nothing. It turns out that you not only have to use this code, but you also have to separately download Dropmenu and install it. The web page didn't say so. The user might eventually discover this, or the user might simply give up instead. The experienced user probably already knows that certain snippets have to be separately installed. But that type of experienced user probably already knows how to generate a site map. The user doing a search for site map very likely does not know which code examples will work directly and which require the installation of some optional module.

Another problem here is that this was not an official MODx web site, so the user may well not ever have gone there. Generally, when looking at documentation, we want something with some sort of official or semi-official status -- either on an official web site, or something to which an official link points, so we have some assurance that the documentation is authoritative.

One way or another, the second try failed.

MODx: Third Try

Going to the official web site, I searched for: site map.

It told me it had found 196 results for "site" shown on 20 pages of links. (Yes, "site" was mentioned but "map" was not. I found no help link explaining the discrepancy.) Pages 1, 2, 3, and 4 contained no mention of site map, except for "GoogleSiteMap" which I guessed was the same one documented in other places, mentioned above and below. Page 5 mentioned a snippet called "ListSiteMap" that was described as generating a site map. (I didn't look at pages 6 through  20.)

So near and yet so far! The ListSiteMap snippet did generate a site map, but this site map included pages that were not supposed to be in any of the public menus. For example, there was a Thank-You page that normally would be visible only when invoked by a submitted form, but was never to be directly accessed, and a 404 error page to be seen only when an error occurred. ListSiteMap included all of these and other pages that ought not to be on a site map.

This didn't work for me.

MODx: Fourth Try

I went to the official wiki at and followed the various links.

FAQ: no site map.

HOWTOs: Alas, it mentioned site maps but this was for search engine site maps (already mentioned above) -- not what we want.

I did a wiki search for site map. Hit 19 mentioned site maps, but it seemed to be in German, so I could not understand it. Hit 20 mentioned site maps, but it was for Google site maps.

There may well be some other searches that will tell the user how to make a site map with MODx. But the user will try a few reasonable searches, and does not know in advance which search to do to find the answer. Good documentation anticipates the likely searches and makes sure the answer can be found with them. In this specific case, MODx documentation didn't do so.


For CMSMS, I began with a Google search for: cmsms site map.

Approximately the sixth hit snippet as shown by Google mentioned: "The map of your site is generated by a simple {sitemap} in any template. ..."

This worked for me.

So CMSMS won hands down--a single Google search told me exactly what to do. Findability: excellent.

In all fairness, we should note that MODx's Wayfinder has many options that will let you adjust the appearance of the site map and decide what entries to include in the site map. But since this section is about documentation, CMSMS is the winner.

Advanced Functionality and Documentation

Once I ventured outside core functionality, I found the documentation for both MODx and CMSMS to be poor. CMSMS's documentation web pages had just as many unnecessary, useless, and irrelevant links as MODx's did. Tables of contents and index, to the extent that they existed, were not very helpful to me. (I was thoroughly confused as soon as I began to search the CMSMS wiki. It asked me which of 16 or 17 namespaces I wanted to search. I had no idea.)

Both CMSes let the web site designer use raw PHP code in various ways. In theory, therefore, the full power of PHP ought to be available.

MODx has entitites called by various names that play slightly different roles. The entities can be invoked by using appropriate tags in the HTML source for a web page. An entity can be just a fragment of HTML, or it can be a fragment of PHP, or some combination of the two. The HTML or PHP can be in the database or in external files.

CMSMS's architecture probably allows the same functionality but perhaps with less flexibility.

But based on the documentation it seems to me that it would be hard to build a web site with significant active functionality with either CMS without a lot of background research

For a one-person project this might not be too great a hurdle. But non-trivial web sites get constructed and maintained by multiple people. A person might be away on vacation, or leave and be replaced by another. If each new person has to go through a steeep learning process without the benefit of useful documentation, the content management system will become a liability.

Usability of Web Site

Here I discuss the ease of creating a usable web site with both CMSes.

Links: Basic Properties

I like to find the following basic link properties in every web site.

Neither CMS provided for all of these link properties in its default configuration. CMSMS came much closer.

Previous and Next Links

I like to be able to navigate with a global Previous and Next link on every web page. These can be normal visible links, they can be REL links shown only when the web browser is asked to display such links. By following all the Next links, I can traverse web pages in a useful order, visiting each page exactly once. The Previous links let me do this in the reverse direction. Thus these links establish a clear "forward" direction and a clear "reverse" direction.

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. Or you can open it at an arbitrary page, and have some idea of where you are, and go forward or back page by page if you wish. When reading a book, as you turn pages forward, you never find yourself at a earlier page; and vice versa.

Without the Previous and Next links, a web site of nontrivial size can act like a maze of twisty little passages, all alike.

Some web sites include Previous and Next links that span some subset of pages, but not the entire web site. These are better than nothing but can't adequately replace global Previous and Next links.

CMSMS by default includes an automatic global Previous and Next link on each page. Navigating them lets me visit every page in the web site exactly once. (Excellent.)

I found no way in MODx of generating global Previous and Next links.

Link to Current Page

I find a link to the current page quite annoying. When I don't know what it is, I waste time following it and wondering why I am still on the current page. When I know what it is, it still annoys me a little, because it seems useless and potentially confusing.

MODx by default shows the current page as a link on menus. (Poor.)

CMSMS by default shows the current page as a non-link on menus. (Excellent.) (But not so on the site map.)

Site Map

Both MODx and CMSMS gave me a nice site map.

With CMSMS, it was relatively easy, with the {sitemap} tag, using one of the example web pages as a guide.

CMSMS's site map includes a link to the current page. I found no documented way of changing this into a non-link.

MODx's default web pages include no example of a site map, I had to work quite a bit harder, spend some time searching for and reading documentation, and finally figured out how to call the Wayfinder module with some options.

(OK, that's not entirely true; the 404 error page included with MODx did include a site map. But not everyone will think of looking there.)

MODx's Wayfinder site map included a link to the current page. I spent some time reading the documentation and figured out how to change the link to the current page into non-link text.

Performance: General

Web site response time

MODx-Generated Web Site: fair: 1 s
CMSMS-Generated Web Site: fair: 1-1.5 s

Management interface response time

MODx Manager Interface: slow: 2-6 s
CMSMS Manager Interface: slow: 1.5-10 s

Performance: Management Interface

Both CMSMS and MODx use Ajax programming techniques in their management interfaces.

The term Ajax programming generally refers to:

  1. A lot of client-side JavaScript. This makes the web browser slower.
  2. Real-time access to the server in the background, i.e., before the user has finished typing. This can make server response seem more fast.
  3. Only small portions of the web page are redrawn as needed. This makes web page updates faster and more efficient.

Ajax programming techniques at their best can make a web site more functional and more responsive. The loss of speed due to item 1 above can be outweighed by the better responsiveness provided by items 2 and 3.

In the case of MODx and CMSMS, however, I think the Ajax programming techniques have resulted in much slower performance compared to old-fashioned plain HTML web pages. Balancing this is a much more intricate look-and-feel.

The MODx management interface, while more fancy than that of CMSMS, is also quite a bit slower. Some of the CMSMS management operations took longer compared to MODx, but on the average, MODx seemed slower than CMSMS.

Neither CMSMS nor MODx provides a non-JavaScript management interface. If one had been provided, I suspect it would have made management much more efficient, even taking into account more mouse clicks and page redraws into account.

Some of CMSMS's management operations still worked in the absence of JavaScript, and most of the rest printed an error message.

MODx failed to detect the absence of JavaScript; it asked the user to wait and then just hung.

The Textpattern management interface, by comparison, mostly functions if JavaScript is disabled, and manages to respond quite quickly.

Usability of Management Interface

Note: Due to my personal preference, I did not use the WYSIWYG editing functionality in either CMS. I stayed strictly in plain-text mode and used Markdown syntax for all pages.

Other than the slow speed, which made me impatient at times, I found the management interfaces of both MODx and CMSMS easy to use.

The one noticeably annoying thing about both was that the window (text box) into which text for a web page is entered was much smaller than my screen. By keeping lines short I could avoid sideways scrolling. But a lot of up-and-down scrolling was needed.

The vertical space was more cramped in the case of MODx, requiring more scrolling.

Neither CMS seemed to give me any choice of making the text-entry box any bigger in the vertical direction.

Also, due to the absence of any ability in CMSMS to apply a change in bulk to a selected set of pages, I sometimes found myself doing a lot of repeated clicking.

Neither CMS allowed me to choose a small section of a web page for editing, the way some wiki software (like MediaWiki and DokuWiki) does. Picking a small section for editing makes editing easier and provides some protection against accidentally changing or deleting a large amount of text.

In CMSMS, if you are editing a long page, then every time you do a save (so you can view the rendered page), the editing window resets to the beginning of the page. Then you have to scroll down again to the point where you were doing the editing. I found this quite inconvenient. MODx also has this problem in its main editing screen, but it has a preview screen on which you can do a "save and refresh" without changing the editing position in the editing window. Allowing the user to edit a small section of a page would have largely alleviated this problem.

Neither CMS provides any protection against accidental edits. Once you save an edited web page, its previous contents are gone forever. There is no undo option.

JavaScript Notes

JavaScript allows the programmer to trap mouse clicks and call a JavaScript function. Reckless JavaScript programmers can therefore make common HTML elements act differently. They can make links act like submit buttons, check boxes act like radio buttons, and so on. Just because they can doesn't mean they should. But they often do.

By and large, both CMSMS and MODx have avoided redefining the meanings of HTML elements so they act very differently from what I would expect. But both had some surprises. If I had to choose, I would pick CMSMS as having fewer surprises.

In MODx, the "Access permissions" check boxes did not entirely act like check boxes. The "Save and Refresh" link did not entirely act like a link.

Once learned, however, I found both CMS management interfaces easy to use.

Using an External Editor

If you are using Markdown, you will want to find some way of using an external text editor so as to escape the confines of the web browser window. Neither provides any support for this. For editing small pieces of text this is not a problem, but for editing a web page, which could be a few hundred lines long, this can be a significant barrier.

I was able to use the Firefox extension called "It's All Text" to invoke an external editor on the text boxes used by both CMSes. However, this did not let me do a save from within the editor and then view the changes in rendered form. I had to essentially finish the editing session, go back to the Firefox text box, submit that, and then view the updates.

So, all in all, updating a long page written using Markdown was quite tedious any way I tried it.

It would be really nice if these CMSes provided a simple mechanism for exporting a web page to a file, and importing it back. This would allow an external editor to be used to update the external file.

Management Interface: Scalability to Many Pages

By scalability to many pages I mean ability to create and modify a web site containing between 1000 and 10000 pages.

The scalability of the management interface will be limited by these factors:

CMSMS shows a complete list of all pages in two situations.

With 1000 pages, each of these displays will have 1000 entries. The user will need to scroll through a menu conatining 1000 entries. Either the user or his web browser will run out of processing capacity.

MODx uses a tree display, and loads portions of the tree as needed. Also, when reordering pages, MODx shows the children of only one node in the tree at a time. CMSMS shows all the nodes.

So MODx is more likely to be able to scale up to 1000 or more pages (though MODx does have a documented limit of 5000 pages.) CMSMS will likely choke at somewhere between 50 and 100 pages.

However, if a web site is designed with a flat structure, as could happen if it's mostly in the form of a blog with daily entries, MODx will show 1000 entries on the screen, and would then not scale well.

MODx has a feature to let some changes be made in bulk to a selected set of pages. For example, a different layout template can be applied to a selected set of pages. CMSMS requires all changes to be made one page at a time (with some exceptions that are rarely helpful).

For the above reasons, while MODx should scale better than CMSMS, neither MODx nor CMSMS is likely to scale very well.

Neither CMS provides any mechanism to migrate pages into an archive section while still preserving the old URL of the page. The URL of a page is tightly connected to the position of the page in the page hierarchy that you access while updating the web site. So you will either need to change the URL of a page when moving it into an archive, or you will need to replace the original page with a redirection page. This will not scale well.

I did not actually test either CMS with a large number of pages, so the above information has not been verified in practice.

Web Site: Performance


Both MODx and CMSMS are supposed to cache web pages to various degrees. The idea behind caching is to generate a web page and then save a copy on disk. Subsequent access to the same web page can cause the saved copy to be sent, saving the effort of repeated database look-ups and repeated string manipulations.

CMSMS actually seemed to do this, but did not ever send a Last-Modified header (see explanation below). So presumably the caching does not fully emulate a static web page.

I never observed MODx actually doing any caching that I could detect. The documentation suggests that tags called as "[!name!]" will be evaluated on each web page access, but tags called as "[[name]]" will be evaluated only once then the result cached. I did not see this make any difference.

I did my tests with small web sites that got almost no traffic other than my own accesses. So lack of caching did not actually cause me any problems. But the caching or lack of it will make a significant difference on a busy web site.

Last-Modified Header. When a web browser receives web page containing a Last-Modified header, it knows the date and time when that page was last modified. When it needs to access the same web page in the future, it can send a request to the web server to send that page afresh only if it has been modified since that previous date and time. If the web server replies that the page has not been modified, the web browser reuses its cached copy.

This works only if the web server sends a Last-Modified header in the first place. Otherwise the web browser will need to get a fresh copy of the web page from the server each time the user goes back to that same web page.

So far as I could tell, neither CMS ever sent a Last-Modified header. So client-side caching will not work even if your web site is entirely static and never changes at all.

Markdown Support

CMSMS: Excellent.

MODx: Good.

Markdown refers to a syntax in which one can write plain-text documentation which can be mechanically converted into valid HTML. Markdown provides a number of significant benefits:

CMSMS supports Markdown out of the box. (Excellent.)

The specific tag name chosen by CMSMS, i.e., {cms_markdown} ... {/cms_markdown}, is not the most convenient to use. Everybody else uses <markdown> ... </markdown>. So copying text across systems requires some editing.

MODx supports Markdown via an additional plug-in. The documentation does not clearly mention that this plugin is available, and installing it requires some manual effort. Once installed, the plugin works nicely.


MODx: Very good. Would be excellent if there was a help link describing permissible search syntax.

CMSMS: Poor. See below.

Search Goals

I would like a good search facility to include the following features. The more, the better.

MODx search

CMSMS search

CMSMS: Pisearch Module

The pisearch module is said to provide an improved search facility. At this web page:

I found these instructions:

Put function.pisearch.php in the plugin directory
Put pisearch.tpl to tmp/template
Read the documentation.
Call it in your template

Fortunately, I was able to find an automatic installation procedure for pisearch, so I did not have to rely on the unhelpful instructions above. The automatic installation could be done from the CMSMS Manager menues:

Extensions -> Module Manager -> P -> pisearch Download & Install

Clicking on this seemed to install pisearch, but I had some difficulty figuring out how to use it. The online help text for pisearch showed two examples:

The second seemed more likely, but I could not be sure, so I decided to try both to see which would work. I made two web pages. Let's call them Page A and Page B. Into Page A I inserted the first example line, and into Page B I inserted the second example line.

On Page A, I saw nothing that pisearch would have generated.

On Page B, I saw a new search box and it had some interesting options. A pull-down list let me pick between Standard, Soundex, Levenshtein, and Similar Text. I also saw a pull-down list letting me choose between "100 Length of Text", "200 Length of Text", "300 Length of Text", and "400 Length of Text".

Page B definitely looked much more promising than Page A. So many choices. But I saw no help link, so I had no idea what choices to make. I tried some searches with the defaults ("Standard", "100 Length of Text"). In every case, the search aborted with an error message similar to:

Fatal error: Allowed memory size of 16777216 bytes exhausted (tried to allocate 46080 bytes)

My web site only had about 15 small pages, so it seemed unlikely to me that the search operation had used up 16 megabytes of memory and needed 46080 more. More likely, something in the pisearch module was not working right.

My quest to find a better search feature in CMSMS ended at this point.

It appears that there are people who are using pisearch successfully. Perhaps they were able to find some documentation that I missed in my searches.

Backups and Restores

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.

Backups are easier than restores. Simply back up the entire database, and the entire directory tree, and you have a backup. But this is a mish-mash backup, because it includes:

You can use this backup to restore both the web site and the CMS into a new server. But if the server already has a newer version of the CMS installed, this backup will overwrite the CMS itself. A smarter backup procedure will separately back up the web site and the CMS, and allow either or both to be restored independently.

I did not find any precise backup-and-restore procedure for either MODx or CMSMS. The recipes that I found required quite a bit of manual decision-making. Overall, I have to rate both CMSes as "probably poor" in the area of backups and restores.

Web Site Login

Almost all nontrivial web sites will offer a user an option to log into a web site and access protected pages.

Ideally, a web site login feature works as follows.

A user browsing the web site follows a login link, and finds himself on a login page on which he may enter his login name and password to log into the web site. After completing the login, he finds himself back on the page from which he originally followed the login/register link, but now he is logged in and can do additional things permitted to him.

Other options, such as new user registration or password recovery, will usually be present on the same login page.

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.

None of the four CMSes I installed for these tests provided this type of compact login link. All of them wasted space on each page with such things as a login box, a password box, a link for registering, and a link for a forgotten password. A completely unprivileged user, who has no ability to log in nor any hope of ever being permitted to log in, will still see all this unnecessary login paraphernalia on each page.

I was able to use MOD'x published features to add a login link similar to the one described above. I had to write a few lines of PHP to do so. MODx still did not provide me with any mechanism for returning the user to the original web page after completing the login.

A web site may offer a visitor an opportunity to log in if he tries to access a URL not available to the public. If he completes the login and is authorized to access the original URL, he should then find himself at that URL, without having to retype it.

MediaWiki, the software that Wikipedia uses, remembers the URL the user most recently accessed, and presents it to the user as a link that he may follow to return to that same URL. So a user who completes a login simply needs to follow that link to continue browsing where he left off.

Many web-based periodicals put the user on the protected page that he originally tried to access as soon as he completes logging in.

But CMSMS and MODx do not. And I found no way in either CMS of implementing such a mechanism myself.

Feedback Request

Please provide factual corrections by posting to the form topics listed below. You can also email me at my email address on the Home page of this web site. I especially request factual corrections for these topics, on which my experiments are much less than complete:

Forum topics: