Introduction

MODx is an open-source content management framework authored in PHP. It was originally forked from the Etomite CMS project, where MODx existed as an unofficial set of mods to that project. Unfortunately, the Etomite team did not approve of the mods and decided to ban them from the community, and MODx was born as a separate and unique project.

Evolution

MODx, through the 0.9.6 releases, remained the same in most aspects, with various improvements and changes made, and a growing community of add-on developers. However, after working on the MODx source code for the first year and a half of the project, I started to realize some of the limitations of the existing architecture. Through team collaboration, exhaustive experimentation with various frameworks and tools, and a lot of hours coding prototypes, I finally came up with an object-oriented model for MODx as I envisioned it could be.

After having some success with early prototypes built on Propel, I realized the amount of code Propel generated was a bottleneck to the kind of performance one expected from the current MODx implementation. As a result of this, and after additional research and experimentation, I decided to attempt to create a much lighter version of Propel that would still acheive some of the benefits without all the bulk and the dependence on PHP 5. A few months later, xPDO was coded, and I set out to create a path from the existing MODx to the ideal model I envisioned; this became the version now known as Revolution and represents a stepping stone release to introduce the new object-oriented xPDO-powered API while maintaining a reasonable migration path for existing MODx sites.

Key Concepts

There are a number of key terms and concepts you need to be familiar with before working with MODx Revolution code.

• The xPDO Core

  The core of the new object-oriented rewrite and an essential ingredient in the new power and agility of the new MODx framework.

  • xPDO
    
  • xpdo/xpdo.pkg
    
  • xpdo/xpdo.howto.pkg
    

• Web Resources

  (formerly Documents and Web Links) represent any content managed by MODx that is directly accessible via a URL.

  • modResource
    
  • modx/modx.modResource.cls
    

• Content Elements

  (formerly MODx "resources") represent components that define source content managed within the MODx content database which can be processed and optionally return output.

  • modElement
    
  • modx/modx.modElement.cls
    
  • modParser
    
  • modx/modx.modParser.cls
    

• Content Tags

  New name for existing and new template tags that are parseable, but that are not Content Elements; i.e. they do not define and/or manager their source content within the MODx content repository.

  • modTag
    
  • modx/modx.modTag.cls
    
  • modParser
    
  • modx/modx.modParser.cls
    

The MODx Revolution Core

Previous releases of MODx suffered from heavy dependencies on hardcoded paths (especially the manager directory) expected to always be in the same place in relation to where MODx was installed. The new MODx makes all of that configurable, starting with, most importantly, the location of the MODx core files.

By default (e.g. when exporting from SVN), the new object-oriented MODx core code exists in a subdirectory called simply core. This effectively isolates the core content management framework from any of the actual web directories it will be serving, and allows you to use the MODx core as if it were a stand-alone reusable library, not unlike a PEAR library. This means you can move it out of this location for production deployment, effectively making the files inaccessible directly from the webserver.