Computers & Programming

The MODX Issue Tracker Still Needs Some Love

Posted: 08.11.2017 23:53

About two years ago I wrote a blog post called Help MODX! Take care of some issues at GitHub. It was actually the first blog post I ever posted on my website. In this post, I urged people to take to the issue tracker at GitHub and start cleaning. Back in 2015 there were, according to my post, 1.4k open issues in the MODX repository.

We have done a lot of cleaning since then, and the number of open issues right now is 588. Even more impressive, the total number of closed issues is over 5.2k! I have compiled the progress into the graph below. The graph displays the number of open issues that are still residing in the bug tracker today. See notes at the end of the post for calculation details. The vertical green lines indicate the dates for the first and second MODX bughunt, held at March 3rd, 2017 and July 7th, 2017. As reflected in the graph, these hunts did a solid dent in the number of open issues, which I think is pretty awesome.

We have worked hard for years to get where we are today, but we are not done yet! 600 open issues is still a lot, and the number of open issues is not proportional to the number of pull requests, forks and stars the repository has. We want this to change! More pull requests, more followers, and most importantly; fewer open issues. Issues and bugs are reported every day, and this is to be expected for a popular software like MODX, but the issues should be dealt with swiftly. Instead, they just gather dust on the 15th page of the issue tracker.

Do your share! Pick up a broom and start cleaning with us. The list below is stolen from my post two years ago:

  • Outdated tickets - Some tickets are many years old and refer to stuff that is no longer valid.
  • Incorrect tickets - Same as above.
  • Tickets that lack information - "It does not work". Well, it works here, what is wrong? Without further information, nothing can be done.
  • Tickets dealing with Extras - Should not be a ticket in the MODX Core. Link to the correct repo.
  • Tickets where the issue is user/server error - If something is not correctly configurated, it will not work. That is not MODXs fault
  • Suggestions that you disagree with - There are many good ideas for new functionality, but not everything deserves to be a part of the MODX core.
  • Duplicates - Many issues deals with the same problem. Tag duplicates with #[github-issue-id] to reference it.

Technical about the graph calculation: The calculation was done with a simple Python script (modx_issues.py). I realize after implementing it that it has a few shortcomings. The script only takes into account the number of total issues, not the time they were opened. This means that there were most likely fewer issues open than reflected in the graph. I am thinking about expanding the current code to take the date the issue was opened into account. This could also populate two other graphs: progression of opened issues and the total number of open issues at any day. I will look at this in a future post.

Feel free to comment or share this blog post.

Please Let 2.6 Be The Last MODX Revolution 2.x Version

Posted: 01.11.2017 19:39

Below is a list of the release dates for each (major) version of MODX Revolution since Revolution came out of beta, including the number of days since the previous version.

  • 2.0.0: 21 July 2010
  • 2.1.0: 24 May 2011 (307 days)
  • 2.2.0: 4 Janunary 2012 (225 days)
  • 2.3.0: 15. July 2014 (923 days)
  • 2.4.0: 19 August 2015 (399 days)
  • 2.5.0: 21 April 2016 (247 days)
  • 2.6.0: 1 November 2017 (559 days)

For the past seven years, we have seen a total of six releases of MODX Revolution. 2.3 took an exceptionally long, and 2.6 is starting to drag on too. Other than 2.3 we have seen a major release once a year, given that we stick to the plan and release 2.6 before 2018.

Edit: After I published this, 2.6 was released, 559 days after 2.5.

Planning The Future of MODX

The posts Keeping MODX Relevant by Jason Coward, that I have written about before, was posted in February of 2015. These posts talked about MODX Revolution needing an overhaul to stay relevant in the future. Years have passed and we have yet to see any of these things incorporated into the MODX Revolution codebase. At the same time, the 2.x versions have grown into a stable and well-working machinery. This has been achieved by various sacrifices and postponed plans. The sacrifices and postponed plans have, in turn, led to MODX Revolution having a lot of technical debt that we are unable to get rid of because of the backward compatibility.

Shifting Focus

I think that instead of planning for a 2.7 release, we should shift our focus and work towards 3.0 instead. According to the list above, each major release takes about a year to finish. We simply do not have the time to invest more time in the 2.x versions right now. 3.0 needs to happen, and it needs to happen soon. The posts by Jason Coward addresses concerns about MODX Revolution, and these concerns are even more relevant today than it was in 2015. 3.0 is most likely going to take a while to put together, and we need to start work on it as soon as possible.

There is no real plan for what is going to happen after 2.6 is released, as far as I know. I am just voicing my opinion and hope that the community (as well as the MAB), can get together then plan what we are going to do next.

Feel free to comment or share this post.

Output Filters For Code Highlighting

Posted: 05.09.2016 12:11

My blog contains some code, and most of us programmers are used to read code with some sort of highlighting, either in our IDE, or in the manager interface via the Ace editor or something similar.

I wanted to have a simple syntax that I could write in the content field that would result in highlighted code. I had earlier attempted to paste code and set the format as pre, however, this turned out to be difficult when I was editing the code back and forth. Instead I decided to use an output modifier and some simple regex to do what I wanted.


Of course I did not write the highlighter myself. What I did was process the content from the content field and add the classes and markup that an existing library expected. I did some research, and the most promessing alternative (by far) was highlight.js. I suggest you check out their website, it is really a nice piece of code! highlight.js is very simple. It just requires one line of code, like so:


The markup highlight.js expected was also self explanatory. It looks like this:

<pre><code class="html">...</code></pre>

Where html can be any of the 166 languages it has highlight support for.

Output modifiers + regex = true

In my template I have the output from the content field. It looks like this:


The parse_content code looks like this:

// For highlight.js
return preg_replace_callback("/<p>```(?P<type>[a-zA-Z]+)?(?P<content>.*)```<\\/p>/m", function($match) {
    // Here we check if the optional type was supplied
    $code = '<pre>';
    if (isset($match['type']) and strlen($match['type']) > 0) {
       $code .= '<code class="' . $match['type'] . '">';
    else {
       $code .= '<code>';
    // Replace first <br> with nothing to avoid that the first line break
    // creates a blank line at the top of our code block
    $match['content'] = preg_replace("/^<br\W*?\/>/", "", $match['content']);
    // Replace <br> with newlines for <pre>
    $code .= preg_replace("/<br\W*?\/>/", "\n", $match['content']);
    // Close the wrapper
    $code .= '</code></pre>';
    // Return the final markup
    return $code;
    }, $input);

To create a code block in TinyMCE, my regex pattern recognizes the pattern:


For example:

echo "Hello world";

Would produce:

echo "Hello world";

The important thing is that the content can not be separated by a full line break. The newlines needs to be <br />. You get this by holding down Shift while pressing Enter. "Regular" newlines you get when you just press Enter actually creates a new paragraph block within TinyMCE, and this breaks my regex expression. I guess I could adjust it to support this, but simply having the entire code as a single paragraph block worked very well.

You can see just how the end result looks by looking at this page and inspecting the source code.

Inline code

The code blocks explained so far is designed for multilevel code that is separated from the rest of the text. I also wanted support for some sort of highlighting that I could have for inline text. I knew StackOverflow had support for this, and I shamelessly copied the CSS they use for their inline code:

main code {
    color: #333333;
    background-color: #EEEEEE;
    font-family: Consolas,Menlo,Monaco,Lucida Console,Liberation Mono,DejaVu Sans Mono,Bitstream Vera Sans Mono,Courier New,monospace,serif;
    padding: 1px 5px;

I also expanded the code in parse_content with the following line:

$input = str_replace(['{‌{', '}‌}'], ['<code>', '</code>'], $input);

This code simply replaces curly brackets with code tags that are allowed to be inlined. The result looks like this and that. It works great for making code or keywords stand out in the middle of a sentence.

Easy as that

I just wanted to share these few couple of lines because I was very satisfied with the outcome myself. I originally tried using pre tags in my markup directly in TinyMCE, but I found it too clumsy to work with. My solution does not need any toggling of formats in the editor. The only thing you need to remember is to not create newlines while expanding or pasting the code.

Easy as that!

Feel free to comment or share.

Using Ext JS to create neat manager pages in no time

Posted: 29.08.2016 12:21

I might have oversold this with my Tweet, but I felt that I should share how I worked with Ext JS to create a manager interface for a project I worked on this summer.

Here goes my article, presentation, showcase, tutorial, or whatever you'd like to call it. Presented in seven chapters (hello Tarantino).

Chapter 1 - Introducton

The background for writing this is that I feel like Ext JS gets a lot of undeserved hate. Sure, it is a complex framework, there is a LOT of magic going on, and it does not help that MODX Revolution is currently on version 3.4 when their latest major release is 6. Despite all this, I truly belive that Ext JS has in some ways benefited MODX and the manager panel. I think that the code powering the manager would be much more confusing in a lot of other technologies.

Short introduction to Ext JS

If you are not too familiar with Ext JS and how it is used in the manager, let me give you a quick introduction. Ext JS is a framework that focuses on components. Once a component is defined, this component can extended further and new functionality can be built on top of existing ones. This way we can reuse a lot of functionality which results in less code.

Ext JS is written by basically defining a HUGE JavaScript object that more or less draws the entire DOM for you. Ext JS translates this nested object that consists of components inside other components inside other components and draws everything out during rendering. The downside of this is that much of the work you usually do in Ext JS feels very abstract as you are not interacting with any DOM objects directly, you are assuming that Ext JS does its job and there is something in the mess of a DOM tree that matches what you expect. Another downside is that just a single error, like a forgotten comma, will lead to the entire tree of components crashing and not rendering.

Below is a very simple introduction code:

// Define our object with a config
My.object = function(config) {
    config = config || {};
    // We can add attributes to our config here
    Ext.apply(config, {
        foo: 'bar'
    // Calling the constructor for our superclass
    My.object.superclass.constructor.call(this, config);

// Here we tell Ext JS that My.object is extending the component MODx.Panel
Ext.extend(My.object, MODx.Panel, {
    // Optional things can go here, like methods or special behavior

// Finally let us register our object in a unique ID that can be embedded later
Ext.reg('my-code', My.object);

Chapter 2 - The task at hand

I worked on a project this summer. In this project I was asked to create a system for categories. This system needed support for two levels of categories, primary and secondary ones. Primary categories are the "root" categories, while secondary categories have primary categories as their parents. To supplement this, it was also requested functionality to drag and drop the categories to reorder and restructure the hierarchy. Functionality to expand and collapse the primary categories would also be a plus, as we would work with many categories. Other functionality such as possibility to add, edit and remove categories was also needed and had to be implemented.

Creating something like this could be pretty easily done in jQuery or other libraries or frameworks, but we wanted to integrate it in the manager panel with the rest of our custom manager pages. This meant that the most logical thing to do was to implement it in Ext JS.

Following this blog post, you can see the exact code I wrote and used in my GitHub repository. It has different branches for the various stages throughout this post. You can find the entire repository at OptimusCrime/modx-category-cmp.

Chapter 3 - Getting started with the component

With the task defined and fleshed out, I started looking at what type of components could be used to create functionality like the one we needed. Drag and drop? Expand and collapse? Hm, this does indeed sound a lot like menus and trees! Menus and trees are found many places in the manager and is extended from a central Ext JS component.

The trees and menus I found in the Manager includes:

  • Resource menu
  • Elements menu
  • Files menu
  • Top menu administration
  • Access controll list administration
  • Property set administration
  • The file browser

If you look at how these trees and menus behave and how they look, it is clear the MODX reuses the same base functionality in many of these components. I wanted to base my component on one of these and extend my code further to implement the features I needed.

Browsing the MODX source code for leads

The next step was to go through the MODX source and look at how each of these components were implement and extended in the original Ext JS code. The idea was to find a components that was not too complex and did not have too many features that we had to remove or override.

The relevant MODX source for the MODX Ext JS implementations lives in the manager/assets/modext directory. From here the directories are divided between:

  • core - The core MODX components that overrides and extends the Ext JS components. Holds the most central components that are reused multiple times in the manager.
  • sections - The base sections for the various views in the Manager.
  • util - Various utilities and reusable snippets of Ext JS code. widgets - The widgets that are included in the base sections. This can be grids, windows, trees, panels and more.
  • workspace - I really don't know what this directory is used for, but it contains more Ext JS code for various parts of the Manager.

I browsed the various locations where this tree/menu behavior is found in the Manager, and inspected the corresponding Ext JS code that it used. I found out which files this was by inspecting the source code and looking at which JavaScript files were included in the various sections. One of the simplest of these tree components turned out to be modx.tree.menu.js. While the entire implementation is more than 300 lines long, it is relatively simple in nature.

At this point I had basically two choices: either extending the tree used for the menus, or copy the content of this file and trim it more and more until I got the functionality I needed. Extending the menu tree would create a hierarchy like this:

Ext.tree.TreePanel -> MODx.tree.Tree -> MODx.tree.Menu -> Category.Tree

But the MODx.tree.Menu had too many features that I had to deal with. I instead decided to not extend the menu tree, resulting in this hierarchy:

Ext.tree.TreePanel -> MODx.tree.Tree -> Category.Tree

Where Category.Tree initially was a 100% duplicate of the MODx.tree.Menu source code.

Cutting and trimming

Below is the current Category.Tree at this stage. As you can see, it is exactly the same menu as you find in the manager interface under Menus. You can browse the exact and complete code I used for creating this component at OptimusCrime/modx-category-cmp/stage1.

The next task was to remove the parts of the component from the source code that I did not want and that was not relevant in my case. I made the following changes in home.tree.js:

,rootVisible: false
,useDefaultToolbar: false

Okey, cool. We got rid of some of the stuff we did not need.

Chapter 4 - Creating processor endpoints

The next step was to change the content of the component. Right now it uses the processors for the menu which fetches the menus we have defined for the manager interface. I would like to swap these for our own endpoints that provide the category data.

Before we swap the endpoints I needed to know what format the tree expects the data to come in. I had to figure out how Ext JS takes the JSON response and draws the tree nodes. I inspected this by using the Chrome inspector and looked at the various ajax calls that were fired upon refreshing the page containing the menu. There were multiple requests running after each other, each fetching a part of the tree. The first request fetched the root menus (the ones without any parents). The form data was:

  • action: system/menu/getNodes
  • node: n_

And the response was:

        "text": "Top Navigation",
        "id": "n_topnav",
        "cls": "icon-menu",
        "iconCls": "icon icon-navicon",
        "type": "menu",
        "pk": "topnav",
        "leaf": false,
        "data": {
        "text": "topnav",
        "parent": "",
        "action": "",
        "description": "topnav_desc",
        "icon": "",
        "menuindex": 0,
        "params": "",
        "handler": "",
        "permissions": "",
        "namespace": "core",
        "childrenCount": "5"
        "qtip": ""
    }, [...]

Similarly, the request for the children of the menu item "Top Navigation" had the following form data:

  • action: system/menu/getNodes
  • node: n_topnav

And response was:

        "text": "Content",
        "id": "n_site",
        "cls": "icon-menu",
        "iconCls": "icon icon-folder",
        "type": "menu",
        "pk": "site",
        "leaf": false,
        "data": {  
            "text": "site",
            "parent": "",
            "action": "",
            "description": "",
            "icon": "",
            "menuindex": 0,
            "params": "",
            "handler": "",
            "permissions": "menu_site",
            "namespace": "core",
            "childrenCount": "6"
        "qtip": ""
    }, [...]

We can easily see the pattern and how we should recreate the response to build our own processor for the categories. Ext JS first asks for the root elements, then assigns each of them an id. This id is used to fetch the children (if any) by sending the id as the value for the node data. If the node data was n_ it meant we were fetching the root elements.

You can see how I adjusted the Ext JS and wrote my own processor in OptimusCrime/modx-category-cmp/stage2, specifically the file getnodes.class.php under processors.

With a similar approach I also created a processor that deals with the sorting of the elements. You can see this code in sort.class.php, also under processors. With the sort processor in place, we also have functionality to drag and drop categories onto, below, and above each other. This greatly illustrates the power of Ext JS. We'll get back to some minor tweaks we'll have to do regarding the sorting later.

You can browse the entire difference between the stage1...stage2 to see what changes were done to create this functionality. As you can see, it is not a whole lot of code.

Note: I know that this part of the article is a lot of "magic", but there is not too much to comment really. You'll need to look at the original processors and understand how they work. Look at how the processors extends their parent classes and what "magically" happens behind the scenes. A good starting point is looking at the get og getList processors for a endpoint in the manager. Look at the code and which methods are overridden. It will make a whole lot of sense after some debugging.

Chapter 5 - New, edit and remove

The next step was to add functionality to create a new category, edit an existing category or remove a category. This section illustrates the power of Ext JS and you'll see just how much we can rely on the magic of the processors and their shorthand classes.

Create new category

Creating a new category is done via a popup box. This box was already in place for the menu functionality. Implementing the same for categories was pretty easy. You can see the steps taking in the difference between stage2...stage3. However, we are not yet finished. The combobox for parents still lists manager menu entries from the original code.

I wrote a new processor for the combobox that fetches the primary categories and wrote a processor that creates our new category. The latter contains some logic to keep track of menuindexes, but should not be too complex. You can see the code for these steps in stage3...stage4. You can browse the entire code up to this point at OptimusCrime/modx-category-cmp/stage4.

Editing an existing category

I already have functionality to create a new category at this point. The operation for editing is more or less identical to creating. The next code block is the only thing we needed to write in Ext JS to add edit functionality. Of course I still needed to hook the code on right click action and write the processor, but the window that pops up when you are updating is no more than these lines of code:

 * This code overrides the window used to create a new category.
Testing.window.UpdateCategory = function(config) {
    config = config || {};
    Ext.applyIf(config, {
        title: _('testing.category_update')
        ,baseParams: {
            action: 'mgr/update'
            ,id: config.record.id
    Testing.window.UpdateCategory.superclass.constructor.call(this, config);

// Note that we extend Testing.window.CreateCategory here!
Ext.extend(Testing.window.UpdateCategory, Testing.window.CreateCategory);
Ext.reg('testing-window-category-update', Testing.window.UpdateCategory);

I belive that this greatly illustrates how you can use Ext JS code more than once with only minor adjustments. Fuctionality like this is also very common. If you need to create something you'll most likely need to edit it somehow too. You can see the rest of the changes done to fully implement functionality to edit a category in stage4...stage5 or browse the entire code at OptimusCrime/modx-category-cmp/stage5.

Remove a category

The final piece of the puzzle is to add support for removing a category from the system. This code for removing menu elements is already present, and only slight modifications were needed. In the processor I also took care of deleting children of primary categories,. This leads to some additional code, but it is mostly a straight forward removal processor. You can see the difference at stage5...stage6.

Chapter 6 - Cleanup and final adjustments

During development this was, we have ignored a few things that might results in problems or bugs. The component should only support two levels of categories, and disable creating categories deeper in the tree. Right now it had support to create child categories of secondary categories. It also allowed dropping a primary category onto a secondary category, which would produce three levels of categories if allowed. It would, in addition, be nice to be able to add a secondary category if we right clicked on a primary category.

Right click to directly create a secondary category

The method getMenu is the one that draws the context menu when you right click something in our tree. This method decides which options to display to the user. I rewrote it a bit to add support for our new functionality.

The new method looks like this:
,getMenu: function(n, e) {
    var m = [];
    // If the node we right click on has no parent, allow to create a category here
    if (n.attributes.data.parent == null) {
            text: _('testing.category_create')
            ,handler: this.createCategory
    // We're always going to allow updating a category
        text: _('testing.category_update')
        ,handler: this.updateCategory
    // This is simply a separator in the menu
    // At the bottom we'll have the "dangerous" stuff
        text: _('testing.category_remove')
        ,handler: this.removeCategory
    return m;

In the method createCategory I needed to make sure it pass the parent value if sat. There was already some code trying to take care of that, but because our data is slightly different from the original code, I needed to adjust it like so:

var r = {
    parent: null
if (this.cm && this.cm.activeNode && this.cm.activeNode.attributes && this.cm.activeNode.attributes.data) {
    r['parent'] = this.cm.activeNode.attributes.data.id;

People may ask, "how the hell do you know which attributes exists and which ones to compare?". Well, truth is that stuff like this is mostly done by trial and error. I cosole.log out all the variables I have available and try to navigate myself though the Ext JS object mess to the correct attributes I need to extract in order to make something useful happen. After a while you'll get the hang of this and you'll know what to look for. I did the same in the next section there I had no code to base my functionality on. In the picture below, I have console.log'ed out the content of this.cm to see what it contains. Simply traversing it is not very difficult.

Disallow dropping primary categories onto secondary categories

This was a bigger problem. I had no code to go from to solve this, but fear not. I already knew that there had to be a ton of functionality tied to dragging and droppig nodes in the trees we were extending. As I found no code that could help me in the source code for MODx.tree.Menu, I tried to go one level up to MODx.tree.Tree. The code for this component resides in modx.tree.js. Around the lines modx.tree.js#L538-L548 I hit jackpot. Worth noting that I was unsure if the correct method to override was _handleDrop or _handleDrag. I did some testing before I found out which one was fired and which attributes and data I could access in each of them.

The code says it all. This is again a result of trial and error. I logged the output of the event and tried dropping categories onto each other, below each other and so forth. After that I inspected the output from the logs and tried to make sense in how I could differentiate between the various states. The following code disables dropping a category onto another if it has children and the target is a secondary category.

,_handleDrop: function(dropEvent) {
    // Let's shortcut things
    var drop_node = dropEvent.dropNode;
    var traget_node = dropEvent.target;
    // If the event is "append" we are just adding a new child in a list, not ON a parent, hence we can ignore it
    if (dropEvent.point == 'append') {
        return false;
    // If our drop node has children AND the target node's parent is not the "root" we are attempting to drop at
    // another node, which results in too many levels of categories. Simply returning false here will disable dropping
    // in this position
    if (traget_node.parentNode.id != 'root' && drop_node.childNodes.length > 0) {
        return false;
    // This is just the code from modx.tree.js to implement some basic functionality
    if (!Ext.isEmpty(drop_node.attributes.treeHandler)) {
        var h = Ext.getCmp(drop_node.attributes.treeHandler);
        if (h) {
            return h.handleDrop(this, dropEvent);

And that is it, really. You can see all the changes from the previous stage at stage6...stage7 or browse the entire code at OptimusCrime/modx-category-cmp/stage7.

At this point we're done with out component. Sure we can add more functionality, but for the sake of illustrating the process from start to finish, I think this will do. If you want to see more, download the GitHub code from the stage7 branch and install it yourself. Instructions are in the README.md file.

Chapter 7 - Final thoughts

It might not have been the easies article, presentation, showcase, tutorial or whatever to follow, but I hope someone learned a thing or two. I did not target people that have developed tons of custom manager pages before. I hope they already are aware of how powerful Ext JS is alread. I wrote this for people that has only been watching Ext JS from the outside with fear and anger. I do understand why many dislike Ext JS and would like to get rid of it, but while it is an integrated part of the manager you might as well learn it and use it for what it's worth.

I've spent many hours debugging stupid blank manager pages because of some dumb syntex error, or gotten so deep in the Ext JS source code that I was afraid I would never get out again. Ext JS is difficult, too difficult perhaps, but I honestly think you can learn it if you decide to do so. I for one am glad I can provide customers with integrated and friendly components directly in the MODX manager as a part of our solutions.

I'd like to thank Catch Media for allowing me to reuse some of the code I wrote in their project for this article.

Feel free to comment or share!

MODX needs to stay relevant

Posted: 06.04.2016 21:07

I've been wanting to write this blog post for a while, but have been putting it off for far too long. I've had these thought for a while and I'd like to share them with you.

Before I begin to rant I should (once again) express my love for MODX. I've been using MODX for some years now (about 5 actually), and I love it just as much as I did when I first began learning it. Please keep this in mind.

Lack of progress on Revo

Revo is a great piece of software. It is so powerful and has endless possibilities. For such a great open source project it hurts me that not more progress is made.

Progress on GitHub

The GitHub repo more or less a giant dump of old and outdated issues and no one seems to be interested in untangling all this mess and sort things out. Several attempts have been made, but they always come short. After a great effort has been put down, new tickets just pour in and we are back to square one.

In order to truly sort things out we need help from the team members to systematically to through everything. Decisions needs to be made. Some features are not wanted, some features are not important and some features does not fit the Revo core. Someone (with authority) has to decide this and make it possible to us to go forward with things. Too many ideas (many good, many bad) have just been left because discussion went nowhere and no one that had anything to say ever did anything.

In addition to issues, open and pending pull requests are just left there every once in a while. Noo ne wants to reject or step in and take over a dead contribution. This makes contributing to Revo less tempting for open source enthusiasts.

Progress on development

In addition to ignoring issues, no new leaps have been made in quite some time. The pull requests mentioned in the previous sections are almost all from non-core members. I though MODX had dedicated developers that were focusing on structuring and laying the path for the rest of the open source people?

No roadmap, no goals

Despite the downsides mentioned in the previous sections, there is still a bigger problem with MODX today. This is the lack of a defined and structured roadmap. There are some milestones sat up at GitHub, but these still lack an overarching goal and there is no depth to the issues that has been assigned a milestone either.

This makes it very difficult for the community to know what is going on in the MODX world these days. What are they planning for? Is there anything we can test, research, look into? I'd love to do some of that, but that is impossible with no direction to go in.

Why does not MODX have anything like this:

I would also love to see something like the apple/swift-evolution repo, which is used for: This maintains proposals for changes and user-visible enhancements to the Swift Programming Language.

Revo and PHP in 2016

Another problem I'd like to mention is that fact that Revo is right now an aging technology. If you go 5 years back it was amazing how well structured Revo was and how new-thinking it was in many ways. However, things have changed in the PHP community over the last years. Autoloading, Composer, various technologies like dependency injection are used all over the place now. As mentioned earlier, Revo 3.0.0 will introduce autoloading, which will make things a little bit better, but there is still a long way to go.

Another huge problem with Revo is how difficult it is to develop with a sensible version control system like Git. Because almost everything is stored in the database, you need to use tools like Gitify or some other component to dump or sync files to your project. This is not optimal at all, and in a world where so much is version controlled this has to change. While this might be difficult, or even impossible for Revo, I suggest looking towards the new MODX product.

Where is MODX Next?

MODX Next was relieved by Jason in a three part medium.com series, which this post is named up after.

These posts were posted over a year ago, in February of 2015. Still we have yet to see any sign of this new software. As far as I know, work has yet to begin on MODX Next too. I can not say this for sure, but no community members (that I know of) have seen any sign of MODX Next.

Like I said, Revo is a great product, but it it too defined now to be structured into something completely new by now. Instead we must love it for what it is and keep it that way. MODX Next can be the new technology that MODX can live on for year to come. If they manage to keep things to customizable as Revo is while introducing autoloading, a simpler ORM system, easier integrating with components and a more loosely coupled manager, MODX can hopefully take its throne as the best open source CMS/CMF there is. I also think this can lead to a far more popular product for MODX. Right now people look at Revo as an aging product, and this is a turn off for many (serious) developers.

In the mean time, other modern CMS are developed. For example:

Not to mention (micro) frameworks like Slim, Symphony and Laravel are getting increasinly popular by the day. If MODX wants to stay relevant for the years to come, something needs to happen, and it needs to happen soon. At the current rate things are going, we will all be over on something else pretty soon, and I'd hate that.

Again, I love MODX. I want to keep using the brilliant freedom I can not find anywhere but MODX, but it is hard when so many other things are negative.

But MODX needs to earn money too!

I know this post is very negative and I more or less attack MODX head on. I'd like to conclude this post by saying that I love all you are doing, and I know you need to generate income by doing work for customers or continue to develop your cloud solution, but I'd like to see more action on the open source front.

I think, and I really mean this, that if you release a modern product that is as fantastic as Revo, with the power of all the new and neat PHP tricks, I think you will earn your money back tenfolds. Just look at the popularity the product I've listed above.

I'd also like to mention and I'd love to help you guy out any way possible. I've offered my help with MODX Next several times before. If there is ever a time you need a new set of eyes, or you need some people to test something, count me in. I really, really look forward to this product. I just hope it comes before it is too late.

Hello world

Posted: 30.12.2015 02:04

Still a lot of work left...

Thoughts on the future of MODX

Posted: 03.03.2015 12:18


This article is my thoughts on the two articles posted by opengeek where he describes his vision for the next major release of Modx (after this simply called modx3).

You can find the articles I am talking about at medium.com, here:


I first of all have to say that I love Modx. I really liked Evo, but I fell in love with Revo. I’ve used it for more than 20 projects and I think it is the very best CMS out there. Despite the negativity I might express regarding Revo, please keep this in mind.

To really explain what I think about the next release of Modx, I really should tell the story of how I met Modx and what I’ve learned since then.

My first experience with Modx

When I finished high school I was lucky to get a job in a local ad firm. They took me in without knowing how good I really was at programming, and really I think I was a pretty bad one. However, I have the ability to focus on something of interest and learn that thing. When I got the job in this firm I got access to a simple Evo site that I could use the learn the framework they used for their projects. This was of course Modx. The first couple of hours were filled with confusion. How does these placeholders get populated? What all these elements and what the hell are snippets and chunks? When I figured out the system and how everything was connected I thought it was one of the best ideas I had ever seen. I had done some work in WordPress earlier and I hated it. Evo on the other hand was a really great CMS. It facinated me so much that I learned everything I could about it. After about half a year I knew everything about Evo there was to know.

Working with Revo

After I had created some sites in Evo, Revo was stable enough for us to move up to the next major version. Once again I was confused by all the new stuff but quickly understood how everything was connected. It was a great platform. A really great platform. Once again I sat down and tried to learn everything about Revo. As it is much more complex than Evo it took some more time, but I think I can say today that I can solve almost every problem I encounter alone. I know the pitfalls, I know the good and I know the bad.

University and new technologies

After a year of full time work in this firm I started studying. I still do work for them, but not nearly as much as I would in the offices. However, because I enjoyed working with Modx so much, I stayed up to date on the newest progress and news about the framework. At the same time I did this I also came across many new pieces of technologies while studying. I've done much, much work in Python frameworks like Django and Flask. I’ve also looked at Slim, Laravel and other frameworks like them. This got me to realize that many aspects of Revo was not that great. xPDO is great, but there are many other ORMs that are simply mind blowing. SQLAlchemy in Python for instance. It is simply brilliant. Eloquent that Laravel uses is also super powerful and sexy. I also realized that creating extras for Revo was far too complicated. It should be an easier process. The manager has become a hassle to extend and change. It is simply too tightly connected to the backend code. Actually, changing anything is rather complex because of these connections going all over the place.

The biggest wow I got was when I was writing my own system from scratch and looked into Composer and the PSR standards. Composer is so powerful I just can’t explain it. Using it with the autoloader from PSR you have more or less revolutionized PHP.

The problem with Revo and the PHP revolution

The problem can be summed up pretty fast. Revo is at this time too complex for a rewrite to follow the PSR standards. It can be done but the work one would have to put into it would be enormous. It would also require a huge redesign of the core and how everything it connected. The mindset for applications now it to keep them as separate as possible. I have no idea how one would do that with the Revo code.

The future of Modx

This takes us to the articles written by opengeek. He expresses his wishes for the next release as a microframework where everything is built upon a small core. This makes much sense considering the standards mentioned earlier, as well as benefiting from Composer and all the available packages it can provide.

In order to achieve this we need to start from scratch. As I explained in the previous section, a rewrite of Revo is not possible without breaking more or less everything. Beginning with white pages is the only logical solution.

Imagining the future

Using Composer and make modx3 extendable by packages would redefine how Modx applications are developed. Just imagine having the manager as a separate module. One could decide which manager interface to use, maybe even use multiple of them for different purposes. Installing a gallery by simply writing it in the composer.json file and running the update/install command. Creating your own extra would be super easy. Place models in one directory, backend code in another, templates in a third and scripts somewhere else. Maybe it would be possible to have a simpler sync between develop and production environments?

Final thoughts

The possibilities are endless with a new canvas and all these tools and the great workflow already defined by standards that are well adopted by millions of users already. It would open up Modx to a whole new audience. Laravel is awesome and all that, but it does not have all the brilliant ideas that Modx has. I believe a great modx3 product could really place Modx on the map as the best CMS out there.

I am looking towards the future with a love of excitement.

Feel free to post any thoughts in the comments and joy the excitement for all the cool things that are coming.

Help MODX! Take care of some issues at GitHub

Posted: 05.11.2015 12:15

After the migration from Redmine to Github, all the issues were transferred. The difference between Redmine and Github is that Redmine offers a lot more filters and custom searches. Because of this, Github ended up being a total mess with over 1600 open tickets assignet to Modx Revo. Many of which was over 2-3 years old.

Some fellow Modxers from irc and I decided to start clean up the mess. If we could close off incorrect issues, issues which lacked information, duplicates, outdated stuff etc, we could make issues useful again.

I urge you all to contribute to this movement! All you need is a Github-account. Head over to modxcms/revolution/issues and comment/share your thoughts!

Stuff to look for

  • Outdated tickets - Some tickets are many years old and refers to stuff that is no longer valid. Incorrect tickets - Same as above
  • Tickets which lacks information - "It does not work". Well, it works here, what is wrong? Without further information, nothing can be done.
  • Tickets dealing with Extras - Should not be a ticket in the Modx Core. Link to the correct repo.
  • Tickets where the issue is user/server error - If something is not correctly configurated, it will not work. That is not Modx's fault
  • Suggestions that you disagree with - There are many good ideas for new functionality, but not everything deserves to be a part of the Modx core.
  • Duplicates - Many issues deals with the same problem. Tag duplicates with #[github-issue-id] to reference it.

How to share your thought

You do not have permission to close tickets, so you should comment on the ticket. Describe why you want the ticket to be closed. If some error is reported, test it, and if it works, report that the issue is fixed and everything now works like it should. Also include what version you tested with.

If you agree with the ticket, suggest making it a part of the 2.3 roadmap.


You should grab a fresh version of 2.3 from Github (from the development branch). This is the latest version and in most cases is the build you should be testing/validating against.

Share the news and lets work together on this! We are down to 1.4k issues at Github at this moment. With some community help, we can get rid of a lot more issues that should have been removed and dealt with a looooong time ago.