For many years I have been discussing the modernization of the MODX core. And it is no secret that countless obstacles seem to continuously appear in my path as I attempt to make headway towards that goal. However, with the help of a dedicated team of contributors, a plan that has been formulated by a number of individuals ready to help move MODX forward, and a new official website for the community to keep track of our progress, it appears we will finally see the next major version of MODX come to fruition.

A discussion covering the question of persistence in the next releases of MODX and current progress on relevant initiatives.

What success MODX has achieved over the past ten years is, in my opinion, entirely due to two core tenets that the community has always stood behind. Those ideals are modularity and extensibility.

It’s been over 10 years since Ryan, Raymond, and myself founded the MODX CMS project and a lot has changed in the world of both content management and web development in that time.

JetBrains—the makers of IntelliJ IDEA—have unsurprisingly created the only PHP development environment worth paying for a license of.

I knew there had to be a simple, efficient, and effective way to build nested menus using getResources instead of Wayfinder, and I finally figured out a way. With this discovery, I’ll likely never use Wayfinder again.

There are a number of benefits to using xPDO instead of writing SQL directly against the database.

A new feature in MODX 2.2 allows Elements to define if tags in default property and property set values are pre-processed. This allows values provided to Elements in this way to use tags in values that are processed before being used by the Element, the same way it would be if the tags appeared directly in the Element tag string.

In an effort to remove the dependency on Ant, the Java-based build tool we have been using to build, test, and produce distribution packages of MODX Revolution, I spent the last week learning Phing, refactoring the xPDO and MODX Revolution build processes to use it, and writing a custom Phing Task to handle our YUICompressor requirements.

I recently published a new Snippet for quickly caching the output of any MODX Element for a configurable amount of time. By default, it uses the Resource caching mechanism and stores it’s data uniquely by Resource, properties, and additional REQUEST parameters. So anytime the page is requested and the cache has expired, the Element will be processed fresh. And that’s just the simplest application…