Last week we announced the release of MODX Revolution 2.4. Consistent with previous “minor” versions in the Revo branch, this one packs a punch in terms of new features.
So this week, let’s do a deep dive into some of the most delicious goodies in 2.4. First and foremost, undoubtedly, is:
This is dev-speak for…ugh there’s no other way to say it—we have to call it “Package Dependencies”, as geeky as that sounds. We can borrow a line from the Fedora documentation though, to help clarify:
A dependency occurs when one package depends on another.
While this may still seem like nebulous dev-porn, it’s potentially very impactful to all users of MODX, because it allows developers to leverage existing codebase in the Extras repo to enhance their own Extras, thereby delivering more features and functionality with less effort.
Let’s walk through a real life example.
Flatso and Git Package Management
Flatso is an all-inclusive blog theme—perhaps the first to benefit from a truly collaborative effort involving numerous team members here at MODX. Wayne @dubrod crafted the front-end and MODX implementation, using a mini-framework we came up with together, that attempts to address the problem of theme-interchangeability in MODX. John @theboxer helped with packaging, using his amazing Git Package Management tool and the new Package Dependencies feature in 2.4.
Installing an Extra with Dependencies
Flatso isn’t out in the wild just yet, but by the time this post is published, or shortly thereafter, it should be. For this walk-through, I’ve used the “Search Locally for Packages” feature in the Extras Installer, and the Package Management (PM) grid looks like this:
Note this is a local test site, and I have some Extras already installed. When I click “Install” on the “flatso” package, I get this screen:
The interesting bit is that there’s a button labeled “Install all dependencies to continue”, and it’s disabled. We can see there’s a 2nd tab labeled “Dependencies”. Navigating to it returns this screen:
The grid shows a list of packages that are required for Flatso to function. Tagger was already installed, so it doesn’t have a “Download” button.
“mxt” is the mini-framework mentioned above, and it isn’t in the Extras repo yet. Unfortunately in this case, we need to use the “Search Locally for Packages” feature to install “mxt” first, and then come back to this workflow. Once “mxt” is in the repo, it can be installed from this view, just like any other dependency.
Let’s demonstrate that, by clicking the button to download “collections”. After the package is fetched, the button changes to “Install”, like this:
Clicking the “Install” button initiates the normal install process for that Extra, and when it’s done, the grid looks like this:
Only after we repeat that process for every dependency, will the “Setup Options” button be enabled for the Flatso package itself.
Clicking it takes us through the normal install process, and voila! The Extra works, in all its dependent glory.
If you develop MODX Extras, and you haven’t tried the “Git Package Management” (GPM) component, you should give it a whirl. The documentation shows you how to control nearly every controllable aspect of the build script by authoring a simple JSON config file.
Package dependencies are already supported in GPM, and it looks like this in the config:
As you can see, you specify the (lowercase) name of the package, along with a version number and (most commonly) the “greater than or equals” operator.
There are other operators available, and you can specify Package Dependencies directly in your build script, without GPM. Community Revo Integrator Mark Hamstra offers detailed documentation here on rtfm.modx.com.
2.4 doesn’t depend on the package dependency feature to be an awesome release. Ba-dum, crash. Here all night, folks :P
The User Groups management interface is now accompanied by a grid view of Users in the selected Group:
This consolidates all the user management activities in one view, greatly improving the experience and workflow of managing ACLs.
Moar Icons Please
Who doesn’t love icons? Now you can specify icon classes for each Media Source in the Tree:
Notice at the bottom of the Media Source edit view, there’s a custom property “iconCls”—this needs to be created manually if you want a different icon class for each Media Source, like you see in the File Tree on the left.
Otherwise, you can modify the “mgr_source_icon” System Setting to apply an icon class to all Media Sources.
Coffee:check, Donuts:check, Configuration:check
The Dashboard Widget that checks your MODX config for issues has been upgraded with some new and important checks, as well as improved styling on the widget itself:
(Image courtesy MODX.today)
Tip of the Iceberg
As mentioned in the release annoucement, 2.4 contains over 70 improvements and all the patches from version 2.3.6. We’ve only touched on a fraction of them here.
Let us know in the comments what your favorite new feature is—and if you haven’t already done so, try the latest version of MODX for yourself.