You ended up on this page. Either via Twitter, Google or another source - but no matter how you got here, you probably want to learn a little something about the MODX system. This article will attempt to explain what MODX entails, what it can be used for and also some basic information on how to do so. If you are already experienced with the system - this article is probably not for you, but don't fear - I have plenty of other MODX Resources you may be interested in!
This article assumes basic knowledge of web development languages such as HTML, CSS and to some extent PHP. It does not assume a certain MODX skill level.
First things first
Now, before I start telling you what is so awesome about MODX, let's start by a short introduction of what it is.
First of all, you should probably know that there are two branches, or two different products. They are called MODX Evolution (version 1.x) and MODX Revolution (version 2.x). While both are developed by the same company, actively maintained and share the same core principals they are quite different still.
MODX Evolution is the legacy code - the code that was first developed back in 2005 based on a different content management system that did not meet the developers' requirements. Since July 31st 2009 (the release date for 1.0.0, which was preceded by over a dozen alpha releases that I cannot find data for anymore, unfortunately) this product has been downloaded roughly 475,000 times and has found its way to a lot of websites.
With the release of MODX Revolution, the Evolution branch has not been deprecated but will be supported for a long time coming. MODX Evolution installs on pretty much all shared servers easily, and is powered by PHP and MySQL.
MODX Revolution, the current flagship product of MODX LLC, is a complete rewrite started somewhere in 2007, based on xPDO (more about that in a later article), and gives a lot more power and freedom to designers, developers and end-users. The first stable release (2.0.0-pl) was released on July 22nd 2010 and has been downloaded over 160,000 times so far - and counting. In June 2011 MODX Revolution 2.1 was released which included a couple hundred fixes compared to 2.0.8 and also marked the removal of deprecated Evolution code that was included in 2.0 to make transitioning easier.
This article was written with MODX Revolution 2.1 in mind, however most of it is also applicable to MODX Revolution 2.0, or MODX Evolution 1.0.5. Revolution 2.2 also shares the same principles, but adds a number of new, fancy features.
What is MODX?
In its purest form, MODX is a php application that allows you to easily manage any content on your website or intranet. However, that's just getting started and does not yet explain why it would be a good match for your next project.
There is no singular definition of MODX, for the simple reason that its flexibility and ease of customization allows you to easily customize the experience for the end-user, without limiting you in any way or requiring hacking into the core files. I guess most web developers and designers will know that there is always the right tool for the right job, but the way MODX has been developed allows you to use this system over and over again, without having to fit your project into certain paradigms, boxes or widgets. On top of that, there is not a single way you can do things within MODX. There's always at least three possibilities and you can choose the right one for you based on your knowledge and time available.
Managing page content
MODX is based around a sitemap-like Resource tree. Resources are, simply put, your website pages, but they could also be used as products, blog posts or even RSS feeds. There are actually four types of resources you can use, which all serve their own purpose:
- Documents are the main resource type that simply holds your content.
- Weblinks are resources that instead of actually containing content, creates a redirect or link to either another resource or an off-site link. This allows you to manage links in dynamic menus or create shortcuts into your website.
- Symlinks are similar to weblinks, but instead of redirecting they create a copy of another resource which remains synchronized. You can change a couple fields in a symlink, to give it a different title or description for examples.
- Static Resources are files on the fileserver that you "link" to that can be used just like other resources. For example for listing PDFs in your dynamic menus.
Roughly 98% of the resource you wil use (depending on the type of jobs you do, obviously) will be Documents, however you will often see the terms "Resource" and "Document" mixed up as it's all some people use.
Trivia: prior to Revolution and Evolution 1.0.0, what is now known as "resources" were actually called "documents". These terms were then streamlined to what it is now.
MODX does not use a templating system
It may sounds weird - but really, there is no templating system in MODX. You are not forced to write in a certain language (though HTML is advised, but that is cause most browsers support that out of the box). You are not forced to put your precious design into a certain block, sidebar, header or footer container. MODX just outputs what you tell it to. There are plenty of screenshots of sites build in MODX in the MODX Sites Showcase and added to the MODX Club that will show you that there are no pre-defined website or markup structures. Your imagination (as well as time and skill, obviously) is the limit.
So how does MODX get this almost impossible infinite freedom?
Basically because it was built to take in basic HTML (or XML, or CSS, or JS(ON), or even that new language you have been developing!), in which dynamic content is inserted using what are called "Tags". Now don't get scared - it is not an entirely different language you will have to learn. Here are a few examples of Tags in MODX Revolution (2.x):
Tags always start and end with two square brackets, and after that there is a token. A token is what defines the type of content to replace the tag with. This can be a resource field (*), system setting (++), link (~) or others. Another type of tag, which does not use a token but just the square brackets, is a snippet. We'll get to those later.
Remember that these are the real basics. Don't let this simplicity fool you though - we are not even touching the tip of the iceberg yet, however as I want to save more advanced (though still easy to use) features for a later article. There is information about the tag syntax in MODX Revolution and Evolution in the Documentation showing the basic possibilities as well as more in depth technical explanations.
Now, to bring this way of templating into context, here is what your HTML5 header part of a template could look like in MODX:
You will see that I have, besides the pagetitle field and site_name setting, also referenced the site_url system setting, but this time I added an exclamation mark (!) in front of what is called the token - this indicates that we want that to be fresh on every page load, and make sure it is not cached. We are using this on the site_url system setting to make sure we are getting the right one at all times - the website may have been accessed at domain.com or www.domain.com, and we don't want stuff breaking (think cross-domain ajax requests) because of that. You can read more about Caching Guidelines in this blog.
What you may also notice is that we added a property to the tag in the canonical link. A property is an option or parameter you pass to a certain tag, which can then be used by whatever it is that is processing the tag. You can apply this to Chunks as well. In this case, we told the link tag processor to use the "full" scheme, which means it will generate a link pointing to the current resource complete with the site url prepended. You can find the technical explanation of the PHP method powering the link tag in the documentation.
For the page you are currently viewing, the above code example would get parsed to the following:
Now this is just an example of course, and there is a lot more that you can do with these tags that will no doubt be explained in upcoming articles. We haven't had all different tags yet though - there are a few more that are directly linked to what are called Elements.
Blocks, Widgets and templating evolved: Elements
Again - elements are just what you make from it.
There are a few types you can use:
- Templates, which just hold the markup you want a resource to output. They are linked to resources directly but can be reused into infinity. We explained the real basics of templating above, but remember that virtually anything is possible.
- Template Variables, which are resource fields on steroids. I've been told this is like the CCK module for Drupal and Joomla!, but then included in the core. Within MODX, you can access these in the same way as resource fields, using the asterix (*) token in a double square bracket tag: [[*tvname]]. Template Variables are very powerful and can probably use a couple of arcticles on its own. There are input types (such as image, file, number, grid data (using MIGX addon), dropdown boxes, checkboxes etc) and output types (raw, html tag, delimited list etc) that can help you set up hassle-free content editing for clients.
- Chunks, reusable chunks of.. anything (except php). Can be accessed with a double square tag, using the dollar sign ($) as token: [[$chunkname]]. These are often used to split up a template into reusable parts, for example that block of code earlier representing a header could be used in a snippet, which is then called in different templates for easy updating.
- Snippets, which are php addons to do whatever the addon developer intended it to do. You can use snippets to create lists of resources (menus, but also including summaries), search the website, or really anything that can be developed in PHP. You can use snippets by just specifying the double square bracket tag, without token: .
- Plugins are developed in PHP and hook into system events, which are triggered throughout the manager as well as on front-end requests. They are used to extend core functionality without breaking upgrade paths. There are plugins available for rich text editing (TinyMCE and CodeMirror for markup), automatically resizing images referenced in a page based on its attrobutes (AutoFixImageSize) and also for internationalization (Babel).
These elements can be catagorized in categories and are all managed from the back-end manager and can (and should!) be easily cached for fast loading.
Now that you have an idea of what different terms refer to in MODx, you're probably good to go and start playing with the software. This is (if even that) only touching the tip of the iceberg though, just to get you understanding the main concepts. I would like to suggest to start by downloading MODx, and installing it on your test server to start working in MODx. Would you rather dive into MODX with some guidance? Check out Mary's MODX tutorial series over at the Coding Pad where she takes everything step by step, creating a full website from a CSS template.
And always remember: there are always multiple ways to do one thing in MODx.