Marco's corner : MODx Revolution

MODx Revolution

On this page some remarks regarding MODx revolution can be found. See the sidebar for some Revolution links, see the xPDO page for information regarding database interaction and see the page regarding MODx Revolution packages, for a packages overview.

This website is now finaly on MODx revolution.

There are some disadvantages to MODx revolution:

migrating to MODx revolution is some work (only an issue if you're currently using MODx Evolution);
I'm not sure whether I really like xPDO (the database layer) - I personally think that table-based objects are not always what one should use, while this seems to be one of the main concepts for xPDO;
the manager is slightly slower compared to the Evolution-manager (for small websites) - but is getting faster every new version of MODx Revolution;
the security system user interface could be easier/more logical (is already improving).

But it's the way to go - because of the many positive aspects:

Revolution has a better caching mechanism, which makes it better suited for large websites (> 5000 pages);
A strongly growing number of packages is available for it (see the overview);
the manager of Revolution does look better;
the manager is structured more logically than the Evolution version - for example: while editing an element (template, chunk, snippet) the list of elements is shown as a tree at the left - in Evolution the pages/resource tree list is shown;
the API looks better structured too;
the parsing has been improved (simplified) - which probably provides a better runtime performance and has removed the strange Evolution behaviour regarding caching/not caching of pages or parts of pages;
the packaging mechanism (to prepare and install extra's - but also to "professionally" distribute a site or reusable component for a site) is wonderful - now we're just waiting for even further enhancement (packaging resources).

See below for some revolution remarks - things I found out during the migration/development work.

Working with different Revolution versions/upgrading

If you want to work with different Revolution versions, make sure that you use a different browser for each version (Firefox and Chrome for example - not two instances of firefox). This because otherwise the javascript code from the two versions could be "mixed" - with unexpected and probably unwanted results.

If you switch, for a certain browser, to using a different version of MODx Revolution, make sure you clear your browser cache first (http://www.wikihow.com/Clear-Your-Browser's-Cache). If you don't, you'll be using partly cached javascript (communicating with new PHP-software on the server) and partly new javascript - again with probably unwanted results.

Copying Revolution site

Normally I develop new sites on my own pc (using the newest version of XAMPP). Hopefully at some day I would want to copy the site to the production environment.

According to some discussions in the MODx forums (mostly Bob Ray's comments) the right approach is the following:

Install MODx revolution in the production environment, but do not yet remove the setup directory.
Make sure the charsets/collations for the production database are the same as for the database in your development environment.
Install all the necessary MODx packages (the same packages as in the development environment).
Copy additional needed files (CSS, images, etc.) to the production environment (make sure that the Apache-user/group has the right permissions for these files - using the MODx filemanager would be a good way)
Export the development database.
Import the development database in the production environment.
Run MODx setup again, as an upgrade. Now please do remove the setup directory.

Error handling in MODx revolution

See below for some information about error messages and debugging in MODx Revolution. I hope this information is correct, but I can not guarantee it; checking wouldn't hurt...

The MODx Revolution errorlog can be found in the MODx manager menu: Reports -> Error Log.
Or in the file core/cache/logs/error.log

Error messages to error log

Writing errors to the error log can be done using a statement like:

$modx->log(modX::LOG_LEVEL_ERROR, $modx->lexicon('permission_denied'));

Lexicon is used in this example to make sure that the standard "permission denied" message will be used for the language selected. If only one language needs to be supported and error messages do not need to be standardised, a normal string could be used.

Debugging

Debugging information could be written to the error log using a statement like the following:

$modx->log(modX::LOG_LEVEL_DEBUG, "this is a debug text");

Switch debugging and error logging on

To get the logging of the errors and debugging information working the following statement could be used:

$modx->setLogLevel(modX::LOG_LEVEL_DEBUG);

modError (connectors-processors)

For error reporting in MODx between connectors and processors MODx uses a different kind of error handling, handled by the class modError() in core/model/modx/error/moderror.class.php.

Methods of modError:

getFields
addField
addError
failure
often called like this: return $modx->error->failure($modx->lexicon('notemplate_error'));
success
Often called like this: return $modx->error->success($modx->lexicon('otherpropssuccess'));
hasError
process – delivers an array of the error messages (calls modx->registry->resetLogging at the start)