Our Roadmap

We have a lot of great ideas for the future of MODx. Some of the more immediate plans that are in the process of being implemented are listed below. With that in mind, we also want to know what you think. What do you think would be a great new feature or improvement to MODx? Join our community today, and start helping to shape the future of MODx.

Roadmap of MODx 0.9.7 Features

A few of the features planned for the future of MODx. Something else you'd like to see?

  • Object-oriented core – Rewritten from the ground up using xPDO
  • Improved API – A new object-oriented API features increased coverage of MODx core objects using a more consistent architecture.
  • New Manager - We're losing the frameset and bringing you fully customizable manager templates complete with AJAX connectors for flexible validation and processing. A fresh new interface driven by a custom implementation of the new MODx core + Smarty + Ext2.
  • Core Installation and Upgrade – A new, more flexible core setup and upgrade facility will allow installation paths to be 100% customizable. No more conflicts with external directories or resources with the same name as a MODx resource.
  • Transport packaging - Facilities for easier installation, upgrade, and migration of MODx managed content and related dependencies. Packages will feature fully automated installation and upgrade capabilities and will help isolate add-ons from the MODx core, further improving your ability to develop, deploy changes, import and export core or even custom data, and upgrade the core without overwriting your already working components.
  • Unified User and Security Model – Manager users and web users become simply users, manager user/document groups and web user/document groups simply become user and document groups.
  • Contexts – This new concept will allow MODx configuration settings to be overridden, extended, isolated, or shared across domains, sub-domains, sub-sites, multi-sites, cultural-specific sections, specific web applications, etc.
  • Improved i18n and l10n support – Cultures and Contexts can work together to provide granular internationalization settings throughout the framework to allow you to define language, currency and date formats, or anything else that might need to be localized in a deployment.
  • No eval() – Snippets, plugins, and modules get included (once) and executed as functions, improving efficiency, stability, capabilities, error reporting, and reducing security risks. To quote the creator of PHP, Rasmus Lerdorf: "If eval() is the answer, you're almost certainly asking the wrong question."
  • Database-managed sessions – New default session handler provides more control and allows more configuration options, including compatibility with web server clustering techniques.
  • Improved caching – New core and partial-page caching techniques help reduce overall cache file-size as well as server resource loads on cache directories by organizing cache files into a hierarchical folder structure.
  • Database result-set caching – The new core also allows database result sets to be cached to file, memory (via memcached), or a custom cache handler, further reducing database loads and extending the ability to comfortably serve high-traffic sites.
  • Core logging – Provides various error levels and output targets including ECHO, HTML, and FILE. You can also use it in add-ons for audit logs, error logs, debugging, or other logging needs.
  • Simplified, concise terminology – Some core MODx concepts changed to be more intuitive and more concise, in accordance with modern accepted web terminology. The most important of these changes are:
    • Web Resources – (formerly Documents and Web Links) represent any content managed by MODx that is directly accessible via a URL.
    • 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.
    • Content Tags – New name for existing and new tags that are parseable, but that are not content elements; i.e. they do not define their source content within the MODx content database.
  • Content Filtering – New Input Filters and Output Filters are PHP classes which replace the current concepts of MODx Widgets and @bindings, as well as the extensions provided by the PHx add-on. It further expands on PHx, allowing the features to apply to any Content Element.
    • Input filters – Mutate source content and properties/parameters before processing
    • Output filters – Mutate output content after processing
  • Improved Content Parser – Features fully recursive, source-order processing without reliance on less efficient and less flexible regular expression patterns currently used. To quote Jamie Zawinski, "Some people, when confronted with a problem, think “I know, I'll use regular expressions.” Now they have two problems."
    • Any element represented by a tag can be cached per page using the ! Token; e.g. [[!snippet]] or [[!$chunk]] or [[!*content]].
    • Embed tags of the same type; embedded tags are processed before the containing tag; e.g. [[~[[++site_start]]]] or [[!snippet? &tpl=`[[!getTemplate]]` &msg=`[[*introtext]]`]]
  • Simplified, unified tag format – To simplify parsing logic, improve parsing performance and avoid confusion with many new adopters, all tags are now of a single format, differentiated by a token or a set of tokens which appear before a string which identifies the Content Element or Content Tag to be processed; e.g. [[tokenIdentifier]].
Table 1: Tag Format Changes for Content Elements and Content Tags
Content Tag Old tag format New tag format
Content Elements
Templates no tag representation no tag representation
Template Variables [*templatevar*] [[*templatevar]]
Chunks {{chunk}} [[$chunk]]
Snippets [[snippet]] [[snippet]]
Plugins no tag representation no tag representation
Modules no tag representation no tag representation
Content Tags
Placeholders [+placeholder+] [[+placeholder]]
Links [~link~] [[~link]]
System Settings [(system_setting)] [[++system_setting]]
Language no tag representation [[%language_string_key]]
  • Even more extensible; even less hacking - The new object-oriented core allows you to provide your own custom implementations of many core features without ever hacking the core code. This helps protect your upgrade path.
    • Web Resources – Easily define your own classes to define and implement custom resources, from web services, to AJAX processors, to rich-media content handlers, or even integrate third-part templating applications (e.g. Smarty).
    • Content Elements and/or Tags – Define your own content elements that define custom or integrate external source content from a database, processes it however you want, and returns an output. Use them like you would any content element. You can even define tag tokens to allow a custom tag representation to be used or just extend the Content Tag base class directly for simpler custom elements that don't need a database table; e.g. [[-bobsCustomElement]].
    • Content Parser – Provide your own custom parser class to override and/or extend the core parsing capabilities.
    • Request handling – Extend or override the core request handling methods.
    • Response handling – Extend or override the core response handling methods.
    • Session handling – Provide your own custom class to handle user sessions per PHP standards.
    • Error handling – Provide your own custom class to handle PHP errors.
    • Partial-page caching – Provide your own custom cache capabilities globally or via custom Web Resource and/or Content Elements/Tags.
    • Database result-set caching – Provide your own database result-set caching implementation.

( back to top )