MODX: Total creative freedom

Many web site builders shy away from the MODX CMS because they think (or have heard) that it’s primarily for developers who are skilled at PHP and JavaScript coding.

While MODX has powerful components for skilled coders to use, there are many advantages for less tech-savvy designers too. The most important of these is the creative freedom that MODX provides. It allows you to easily make your web site look exactly the way you want it to, with no compromises.

MODX was developed by web programmers who were frustrated with the creative limitations of other CMS platforms. They hated having to work on systems that had built-in notions of how a web site should be built and where to put things so they would work.

They also wanted to do a better job of separating the content of a web site from the code that presented that content — a practice that makes it much easier to redesign and maintain websites.

Templates

What might be called the “first principle” of MODX is, whenever possible, to let the site designer do whatever he or she wants, and do it easily. At the heart of this creative freedom are MODX templates and MODX tags.

A MODX template is nothing more than a page of HTML code (and optionally MODX tags and JavaScript). You can pick a page on a non-CMS site and paste the HTML code for that page into a MODX template, adjust the URLs for any CSS files, and then tell MODX to use that template when showing a particular document on the site. That would take less than 5 minutes, and when you viewed the MODX page, it would look exactly the same as it did on the original site. The one restriction is that you can’t have any PHP code on the page (more on that later).

Pasting the code for a whole page into a template would ignore many of the powerful features of MODX, but it helps demonstrate just how much freedom you have in creating MODX web sites.

Tags

The main power of MODX comes from MODX tags. Essentially, MODX tags represent things that you move out of the template and put somewhere else for convenience and added flexibility. What remains in the template is typically the HTML shell and the MODX tags.

The basic operation of the MODX engine is incredibly simple. When a web page is requested by a browser, MODX checks to see what template is associated with that page. It gets the template, replaces any MODX tags in the template, and sends it off to the browser. That’s it.

The ability to have a dynamic, creative web site in MODX comes from what the tags can represent. There are a number of kinds of tags, and each one is replaced by something different. All the tags are optional and any tag can go anywhere in the template. Let’s look at a simple example involving what are called “chunk” tags.

Note: The examples here are for MODX Revolution. MODX Evolution uses a slightly different tag style, but the concepts are the same.

In MODX, a “chunk” is just a bit of HTML code that you want to use on more than one page. It might be a header, footer, sidebar, menu, or anything else. Let’s say it’s a footer that you want to show on every page (or some subset of your pages). You create the chunk in the MODX Manager, type in the HTML code for the footer, give it a name (FooterChunk), and then save it. Now, in your template, you just put the following tag where you want that footer to appear:

[[$FooterChunk]]

Every page that uses that template will show the footer chunk in that location. If you decide to change the text or HTML of the footer, you just edit the FooterChunk and the new version will appear on all your pages. If you want the footer somewhere else on the page, you just move the tag in the template.

Another kind of tag in MODX is the “resource content” tag (usually referred to as a “content” tag for short). In MODX, each web page corresponds to a document stored in the MODX database. When you create a new page for a MODX web site, you’re presented with a form that you can fill in with information about the document.

There are text input fields for a Title, Longtitle, Description, Summary, Alias (to be used in the URL), Content (the main content of the page) and Menu Title (automatically used in menus). There are checkboxes that indicate whether the document is published and whether it should be hidden from menus.

There are also date fields to indicate future publication or unpublication dates and the date when the document was published.

There are other fields as well, but here again we see the flexibility of MODX — all the fields except the Title and Alias are optional! Every page has to have a title and something to put in the URL of the page, but it’s entirely up to you whether to use the other fields or not. What goes in the other fields is also largely up to you. You almost certainly want to put the main content of the page in the content field, but you don’t have to. If you want to use the Long Title field to store the astrological sign of the user profiled on the page, go right ahead.

To get back to the “content” tags, they represent the fields of the form. When MODX sees a content tag, it replaces it with the value of the named form field. At the spot where you want the main content of the page to appear, for example, you put this tag in the template:

[[*content]]

Where you want the Long Title of the page to appear (if you want it at all), you put this tag:

[[*longtitle]]

For the main title, you’d use this tag:

[[*pagetitle]]

If you decide you want the Title or Long Title to appear somewhere else, you just move the tags in your template. If you don’t want to show the Long Title, you remove the tag from your template. If you want whatever is in the Long Title to appear in the page footer, you can even move its tag into the FooterChunk we mentioned earlier. To use an unlikely example, you could even put the URL of the path to the CSS file you want to use for the page into the Long Title field and put this tag in the head section of your template:

<link rel="stylesheet" type="text/css" href="[[*longtitle]]" />

MODX is very simple-minded when it comes to tags. When it sees a MODX tag, it replaces it with what it represents. It doesn’t care what it is or why you’re putting it there. It assumes that you know what you want and acts accordingly. There’s no struggling to figure out what MODX wants or why it’s not doing what you want because it just does what you tell it to. Trust me, it’s a pleasant change from having to deal with a CMS that thinks it knows more about what you want than you do, or has preconceived notions about how things should be displayed or where they should be located.

Snippets

Earlier in the article, I mentioned PHP code. In MODX, PHP code goes in a snippet, which is just any bit of PHP code you want to use on the site. When MODX sees a snippet tag, it replaces it with whatever is returned from the snippet. Putting PHP code in snippets makes the site much more secure and easier to maintain because the code is separated from the content. If some hacker manages to put a page on your site that contains malicious PHP code, MODX will ignore the code because it’s not in a snippet.

If you’re not a PHP coder, you’ll still use snippet tags because there are MODX add-on components (usually called “extras” in MODX) that will do a lot of the heavy lifting on your site.

The Wayfinder snippet, for example, will produce a menu from the documents on your site. If you create a new page, it will automatically appear in the menu. In its simplest form, you just put a tag like this where you want the menu to appear:

[[Wayfinder]]

MODX will replace that tag with a menu of all the pages on your site. By default, Wayfinder displays the menu options as links in an unordered list, but you can configure it to create any kind of menu you want.I’ve seen drop-down flyout menus, horizontal menus, vertical menus, fisheye menus, megamenus, popup menus, and even circular menus, all produced with Wayfinder. In fact, I have yet to see a menu that can’t be produced with Wayfinder.

You can also use Wayfinder to show menus from just a part of your site and you can have more than one Wayfinder menu on the same page. Remember the “Hide From Menus” and “Published” checkboxes we mentioned earlier? Wayfinder won’t show unpublished or hidden pages unless you tell it to.

Another often-used snippet is getResources. The getResources snippet will show selections of documents on your site, formatted however you like (using MODX tags, of course), sorted, selected, and displayed however you want them. A common use of getResources would be to show the title and summary of the five or ten most recently created documents on the site, each with a link to the full document.

Both Wayfinder and getResources use chunks for their formatting (this kind of chunk is called a Tpl chunk in MODX) with HTML code and MODX tags for the various elements to be shown. If you want to change the formatting or content of their output, you can simply edit the Tpl chunks (or create your own).

Blogging with MODX

At one time, it was somewhat difficult to create a blog in MODX (a definite drawback for many people). Now, however, the Articles extra is a full-featured blog component for MODX that’s easy to use and configure. Articles has comments, tags, moderation, threaded discussions, and everything else you might want for your blog, making MODX an attractive alternative to WordPress.

In Conclusion

This article has barely scratched the surface of MODX. Hopefully I’ve whetted your appetite about MODX and shown you a little about how much freedom it gives you in creating the web site you have in your head. Moving a non-MODX site to MODX is surprisingly easy. For a brief description of the process, see this page.

If you are a web designer and you want a CMS that allows you the creative freedom to make your site look exactly the way you want it to, you should definitely give MODX a try.

Bob Ray

Bob Ray is an author and web developer. He is the author of MODX: The Official Guide and more than 25 MODX add-on components. You can follow him on Twitter: @BobRay or Facebook. His web site is Bob's Guides.