http://www.cmslesstraveled.com/

So long WordPress, and thanks for all the good times we had.

Alright then.

In addition to syncing the TVs of the Draft resource with the Production resource, I’ve slightly changed the lines of code that dictate which fields NOT to update.  Yesterday I knew that the ‘alias’ field was probably not something we want the draft resource to change (both resources would then have the same alias, which is not allowed).  Today I realized the same thing is true (for me, at least) of the “Parent Resource” field.  Changing either Alias or Parent Resource would alter the URL of the production resource (when friendly URLs are used).

Here’s the newest-latest code for my plugin (changed stuff is bolded):

<?php
$pagetitle = $resource->get(‘pagetitle’);
//if the “draft” flag is in the title AND the user “published” the draft
if (
(preg_match(‘/\(draft-(?P<id>\d+)-\)/’, $pagetitle, $results ))&&
($resource->get(‘published’))
) {
// the ID of the resource  to publish to
$prodID = $results['id'];
// if $prodID represents a real & published resource
if ($prodResource = $modx->getObject(‘modResource’,
array(‘id’=>$prodID,’published’=>1))) {
$newVals = $resource->toArray();
$restrictedFields = array(‘alias’=>”,’parent’=>”); //fields not to update
$filteredVals = array_diff_key($newVals,$restrictedFields);
$prodResource->fromArray($filteredVals);

//take out the “draft” token before setting pagetitle
$prodResource->set(‘pagetitle’, str_replace($results[0], ”, $pagetitle));
$prodResource->save();

$newTVs = $resource->getMany(‘TemplateVars’);
foreach ($newTVs as $TV) {
$newval = $TV->getValue($resource->get(‘id’));
$TV->setValue($prodResource->get(‘id’), $newval);
$TV->save();
}

}
//unpublish the draft resource
$resource->set(‘published’, 0);
$resource->save();
}
return;
?>

You can put any fields that you DON’T want updated into the $restrictedFields array(in my code they are array keys… if you don’t like that feel free to rewrite the PHP to your liking).

Try this out and let me know how it works.  I fully expect there to be glitches with TVs and in other places (it can’t be this easy, can it?)

I’ll probably continue to use this blog space as an RFC forum for this plugin, until such a time as it seems robust enough to actually submit as an add-on package.  Eventually I’d like to automate the “create a draft copy” process, add some permissions checking, and probably some other stuff I’m forgetting or haven’t thought of yet.  Meanwhile, the more of you that try it out, the better (hopefully) I’ll be able to make it.

I know, I know: long-time-no-blog.

I had told myself I wasn’t going to do any more blogging until I had my new and improved blog site set up on a MODx Revolution install.  But I finally broke down today because

1. Setting up the new website is taking a lot longer than expected (mostly due to a lack of spare time)
2. Today I did something so cool I can’t help but write about it.

Today I made major inroads toward solving one of my longest-standing issues with MODx publishing:  the need to work on a “draft” copy of an already-published document, and publish from the “draft” copy to the published version.  In other words:

• A user creates and publishes a resource.
• Later, the user needs to make “work-in-progress” revisions to the resource.  They are going to completely overhaul the original content, but it is going to take time, and they don’t want to publish the changes until they are ready.

MODx (and most other CMSes, as far as I know) have a simple published/unpublished model.  If you publish a document, there is no easy way to “work on” that document without affecting the published version. (Because there is only one ‘version’).  As Shaun McCormick recently wrote to me,

There’s a lot [involved in] workflow in CMSes, and to be frank, there’s a reason most CMSes don’t have it. It’s complex, and requires a lot of work.

Fair enough.  As I’ve thought about this problem over the last six months or so, it seems that every potential solution turned out to be much more complicated than I thought it would be, to the point that it exceeded my abilities and grasp of the concepts.

I don’t know if its because I’ve learned a lot more about MODx, or if its because I’ve reduced the scope of what I’m trying to do.  (Probably a combination of both).  But over the weekend, a light went on in my head.  I realized that the only “workflow” concepts I really needed were:

• The ability to mark a resource as a “draft”
• The ability to specify which resource it is a “draft” of. (To link it to a different, published resource).
• The ability to (when desired) update the published resource with the revisions in the draft resource.

Here’s what I came up with.  Its by no means perfect, but it does exactly what I need it to:

1. Create a “draft” copy of a published resource
   Start by just creating a copy, period. Click the “duplicate” button, and give it a title.
   

   Here I’ll use the same title as the original, but with “(draft)” appended.
   
   That works well in the resource tree – you can pretty clearly see that resource #4 is a draft copy of resource #2.
   
   

2. Unpublish the draft copy.
   This is a draft, after all – the whole point is that it isn’t published. You don’t want it showing up in your menus and such.
   
   

   There – that’s better.

3. Specify which published resource this is a draft of
   To do this, I’m just going to add the resource ID of the published resource to the title of the draft resource.  The new title looks like this:
   
   Note the dashes before and after the id: “(draft-2-)”.  In the next step I’m going to be parsing out the ID number from the title of the draft resource, so it is important to have a consistent & recognizable pattern to search against. You can use any pattern you like, so long as you know how to write a regular expression to identify it and parse out the number.
4. Write the plugin that does all the magic.What we need now is to capture the user’s intent to “promote” the draft copy to published status.  While working on the draft, the user can save over and over again to their liking, while the original resource remains unchanged. But when the user checks the “Published” box on the draft resource, that’s where we need some magic to happen.A MODx Plugin is a PHP script that is tied to a certain System Event. Here we want to tie in to the action of saving of a resource, and potentially (based on certain criteria) make changes to another resource (the production resource).In human terms, we want our Plugin to do this:
   • Run each time a resource is saved (“OnDocFormSave” is the name of the System Event).
   • Test for whether the resource is a “draft” resource AND whether the “Published” box was checked
   • If yes to both, then:
     • parse out the ID of the production resource from the title of the draft resource
     • update the production resource with all the content from the draft resource
     • save the production resource
     • “un-publish” the draft resource
     • save the draft resource

   (Note: we need to “un-publish” the draft resource because we don’t really want the draft resource published; we are repurposing the “Published” checkbox to really mean “copy this in to production”).

   Here’s what the plugin code looks like:
   <?php
   $pagetitle = $resource->get(‘pagetitle’);
   //if the “draft” flag is in the title AND the user “published” the draft
   if (
   (preg_match(‘/\(draft-(?P<id>\d+)-\)/’, $pagetitle, $results ))&&
   ($resource->get(‘published’))
   ) {

   // the ID of the resource  to publish to
   $prodID = $results['id'];

   // if this represents a real & published resource
   if ($prodResource = $modx->getObject(‘modResource’,
   array(‘id’=>$prodID,’published’=>1))) {

   // update the production resource with the values from the draft resource
   $prodResource->fromArray($resource->toArray());

   //take out the “draft” token before setting pagetitle
   $prodResource->set(‘pagetitle’, str_replace($results[0], ”, $pagetitle));

   //save changes to the production resource
   $prodResource->save();
   }

   //unpublish the draft resource
   $resource->set(‘published’, 0);

   //save changes to the draft resource
   $resource->save();
   }
   return;
   ?>
   
   That “preg_match” business is what looks for my particular draft flag pattern “(draft-99-)”.
   That just about does it. One more change to the code:  we can’t overwrite the ‘alias’ of the production resource with the alias of the draft resource.  Since alias dictates the URL when friendly URLs are used, we probably don’t want to be messing with the alias of the production resource at all.  So we’ll have to modify the code to preserve the original alias:
   
   <?php
   $pagetitle = $resource->get(‘pagetitle’);
   //if the “draft” flag is in the title AND the user “published” the draft
   if (
   (preg_match(‘/\(draft-(?P<id>\d+)-\)/’, $pagetitle, $results ))&&
   ($resource->get(‘published’))
   ) {
   // the ID of the resource  to publish to
   $prodID = $results['id'];
   // if $prodID represents a real & published resource
   if ($prodResource = $modx->getObject(‘modResource’,
   array(‘id’=>$prodID,’published’=>1))) {
   $prodAlias = $prodResource->get(‘alias’); // we’re gonna need this
   // update the production resource with the values from the draft resource
   $prodResource->fromArray($resource->toArray());
   $prodResource->set(‘alias’, $prodAlias); // set alias back to original value;
   //take out the “draft” token before setting pagetitle
   $prodResource->set(‘pagetitle’, str_replace($results[0], ”, $pagetitle));
   $prodResource->save();
   }
   //unpublish the draft resource
   $resource->set(‘published’, 0);
   $resource->save();
   }
   return;
   ?>
   

5. Tie the Plugin to the OnDocFormSave System Event
   The plugin will only work if it is tied to the proper system event.  Here we need to tie it to “OnDocFormSave” which fires just after a resource is saved through the manager form:

   

   [Side note: The "OnDocFormSave" event has a parameter called "resource", which refers to the resource being saved. That's where $resource gets its value in the first line of the plugin code.]

There you have it.  Now whenever the draft copy is saved with the “Published” checkbox checked, the “production” copy will be synched with all the changes.

One thing this plugin won’t do (yet):  update Template Variables. I think I know to make that enhancement, but wanted to get this preliminary version out as soon as possible to solicit feedback.

So… let me know what you think.  Does anyone other than me see this as potentially useful?  Or see a better way of doing it?  Lets talk.

Today, just some housekeeping and announcements… just an excuse to post and keep the blog from getting too stale.

No, I’m not moving to Morocco.  But @einsteinsboi is moving to New Zealand.  Best of luck with your move Mary.  Hope you stay active in MODx and keep contributing to the community when you can.

Jason Coward, aka OpenGeek, aka @drumshaman, has a new blog, and it is built on MODx Revolution.

Shaun McCormick, aka splittingred, a.k.a. @splittingred, has a new blog, and it is built on MODx Revolution.

I, a.k.a. me, a.k.a. @jrotering, still have this old blog, not built on MODx Revolution. (My new one will be though, for real).

Here’s an insightful little interview* with co-founder Ryan Thrash and core developer Jeff Whitfield about the past, present and future of MODx.  The interviewer is Patrick Ortman, one more cool and productive member of the ever-surprising MODx community.

See? Lots going on in the MODx world.  It’s all happening.

Two monumental events coming up this month.   First is MODxpo, next week in Dallas.  The first official MODx user conference; the schedule has been posted, and it looks excellent.   I’m really looking forward to meeting the core team and many members of the great user community.  Looking forward to hanging out with my brother for two days, and sharing a room for the first time since I was about 12 years old.  Should be good.  And also hoping to find time to meet a good friend from the PHP community while in the Dallas area.

Second, of course, is the series finale of LOST.  I’m totally psyched, and plan on going all out: having a party, hiring a babysitter to put the kids to bed and keep them upstairs at all costs, and trying to convince my wife to bake a cake like this.  It will be like Superbowl Sunday – except that the best part won’t be the commercials.

What, you may ask, does LOST have to do with MODx?  I’m so glad you asked.  I didn’t realize the connections myself until I started writing this.  But LOST is all about connections and theories… so here are a few.

• Both have really groovy logos, with 4-letter names and interesting capitalization
  
• Both projects started in 2004 and have come a long way from where they started.
• Shaun McCormick and Jason Coward are like the Carlton Cuse and Damon Lindelof of MODx Revolution.
• Therefore Ryan Thrash = J.J. Adams
• Both are really all about the community
• In order to keep MODx running and stable, Jay Gilmore lives in a hatch and pushes a button every 108 minutes**.
  

That’s all I’ve got.

If you’re going to MODxpo, I’ll see you in Dallas next week.

If you’re not, then I’ll see you in another life, brother***.

It’s all happening.

Namaste.

.

.

.

*I especially love the smooth R&B music that comes in halfway through the interview.  It would be really funny if, when Ryan is introduced at MODxpo, they find this song and play it as his theme music as he walks to the stage.

** not actually true.

***Unless you are actually, biologically, my brother. In which case I’ll see you in Dallas.

My goal with jQuery (and also CSS) is to provide customization opportunities at both the template level and at the individual page level.  For me this ties in with my overall template strategy, namely that all my templates will use the same chunk structure (with the variation coming via different properties passed to the chunk, and also via template variables).

Lets dive right in and take a look at my chunk “scriptsBlock”, which handles ALL of the javascript/jquery for EVERY template on my MODx installation:

<!–start scripts_block –>
<script src=”/assets/js/jquery-1.3.2.min.js” type=”text/javascript” charset=”utf-8″></script>
<script src=”/assets/js/jquery.hoverIntent.minified.js” type=”text/javascript” charset=”utf-8″></script>
<script src=”/assets/js/corners_modified.js” type=”text/javascript” charset=”utf-8″></script>

[[$[[+customScriptsChunk]]]]
[[javascript_includes]]
[[customJQuery]]

<!–end scripts_block –>

The three <script> tags at the top are the “core” javascript that is integral to our overall web design. I think this translates to what Greg Smart refers to as being part of the “structural HTML“.  Every template in my system will include those three script calls.

Now lets get in to the next part of the chunk – the MODx tags.  The first one looks like this:

[[$[[+customScriptsChunk]]]]

This nested tag syntax may not be immediately recognizable to many of you, so lets walk through it.  Starting with the inner tag:

[[+customScriptsChunk]]

That syntax ([[+) is a "placeholder" tag in MODx.  It represents a value that will be swapped in upon being specified elsewhere. In this case, being that it is inside the chunk "scriptsBlock", it can be specified in the call to "scriptsBlock".

[[$scriptsBlock]]  // call to “scriptsBlock” chunk with regular syntax

[[$scriptsBlock? &customScriptsChunk=`myJavascriptChunk`]]  // call to “scriptsBlock” chunk with a property passed.

When a chunk is passed a property which corresponds with a [[+placeholder]] tag in the chunk, the passed value is simply substituted in.  Thus [[+customScriptsChunk]] becomes ‘myJavascriptChunk‘.  Thus

[[$[[+customScriptsChunk]]]]

becomes

[[$myJavascriptChunk]]

… a simple chunk call, referring to a chunk that presumably holds some additional javascript.

If no matching property was passed in the chunk call, the placeholder simply disappears during parsing.

Are you starting to see how this works?  Lets say I need to create a new template to be used on pages with lots of tables in them (data tables! full of tabular data! not the other evil kind!).  I want to be able to use the jQuery tablesorter so that users are able to sort these tables by column. I’ll create a chunk called “tablesorter” that simply calls that script:

<script src=”/assets/js/jquery.tablesorter.js” type=”text/javascript” charset=”utf-8″></script>

Then in my new template, I simply refer to ‘tablesorter’ when calling [[$scriptsBlock]] in my template.

[[$scriptsBlock? &customScriptsChunk=`tablesorter`]]

All pages that use this template will get the “core” script calls AND the tablesorter script call:

<!–start scripts_block –>
<script src=”/assets/js/jquery-1.3.2.min.js” type=”text/javascript” charset=”utf-8″></script>
<script src=”/assets/js/jquery.hoverIntent.minified.js” type=”text/javascript” charset=”utf-8″></script>
<script src=”/assets/js/corners_modified.js” type=”text/javascript” charset=”utf-8″></script>

<script src=”/assets/js/jquery.tablesorter.js” type=”text/javascript” charset=”utf-8″></script>
[[javascript_includes]]
[[customJQuery]]

<!–end scripts_block –>

In this way I create individual templates (or groups of templates) that inherit all of the core script calls and add some more of their own.

The final two MODx tags

[[javascript_includes]]
[[customJQuery]]

…are for adding additional javascript and/or jQuery at the per-page level, using snippets and template variables. I’ll save those for another post.

One of the things I’ve done in the process of working with MODx over the past few months is to create a rather elaborate and convoluted template schema.  Initially I was trying to keep everything to one single, swiss-army-knife template.  That’s where the idea to use  a Template Variable to select a content layout came from.

That seemed promising, but as I went further down the road of One-Template-To-Rule-Them-All, I realized I was trying to wring some not-very-straightforward functionality out of MODx.   Things like “I need some Template Variables to be conditional upon other Template Variables”.  As in,  its great to be able to select “three column layout” in a TV, but unless I have additional TVs for “left column content” and “right column content”, I can’t do much with those additional columns.  But it doesn’t make sense to have “left column” and “right column” TVs on pages that don’t have those columns. Et cetera. I had begun to weave an overly-complicated web of confusion that was quickly collapsing upon me.

Thankfully the good folks on the MODx core team finally smacked some sense in to me in a response to a forum post.  At this point I realized that the “one template” concept was a non-starter.

However.

I was still enamored with the overall concept that I think can best be described as “template inheritance”.  I knew that most of my templates would share 90% of their DNA, and only differ from each other slightly – a div here, an additional css file there.  I knew I wanted to keep code repetition to a minimum, and keep the templates themselves very clean and very rarely-needing-to-be-touched.

What I finally settled on was a highly nested chunk structure, with lots of placeholders for custom bits.  One big breakthrough was when I realized that you can pass arguments to a chunk that can then be used as placeholders within a nested chunk.  In other words:

[[$outerchunk? &customdiv=`foo` &customclass=`bar`]]

‘outerchunk’ looks like this:

<div>
<p>some text…</p>
[[$innerchunk]] <!–note how innerchunk doesn’t directly pass any arguments –>
</div>

…and ‘innerchunk’ looks like this:

<div class=”[[+customclass]]”>[[+customdiv]]</div>

And the result looks like this:

<div>
<p>some text…</p>
<div class=”bar”>foo</div>
</div>

Now my template structure really started tightening up. I had arrived at something like this:

<!DOCTYPE html PUBLIC “-//W3C//DTD XHTML 1.0 Strict//EN” “http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd”>
<html xmlns=”http://www.w3.org/1999/xhtml”>
<head>
<title>[[*pagetitle]]</title>
[[$metaBlock]]
[[$cssBlock? &customCssChunk=`...`]]
[[$scriptsBlock? &customScriptsChunk=`...`]]
</head>
<body>
[[$header? &customTopDesignChunk=`...` &customHeaderChunk=`...`]]
[[$content? &navigationChunk=`...` &contentLayout=`...`]]
[[$footer? &customFooterChunk=`...`]]
</body>
</html>

…which I then consolidated even further to look like this:

<!DOCTYPE html PUBLIC “-//W3C//DTD XHTML 1.0 Strict//EN” “http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd”>
<html xmlns=”http://www.w3.org/1999/xhtml”>
<head>
[[$head? &customCssChunk=`...`
&customScriptsChunk=``
]]
</head>
<body>
[[$body? &customTopDesignChunk=`wwwTopDesignBlock`
&customHeaderChunk=`wwwHeader`
&navigationChunk=`wwwNavigation`
&contentLayout=`25_50_25`
&customFooterChunk=`wwwFooter`
]]
</body>
</html>

I’m currently debating whether to take the final step and just put the entire html structure into a single chunk:

[[$tplHTML &customCssChunk=`...`
&customScriptsChunk=`...`
&customTopDesignChunk=`wwwTopDesignBlock`
&customHeaderChunk=`wwwHeader`
&navigationChunk=`wwwNavigation`
&contentLayout=`25_50_25`
&customFooterChunk=`wwwFooter`
]]

I’m hesitant just because for some reason it comforts me to see a little bit of recognizable html in my templates… but really, this is probably the logical conclusion of the path I’ve gone down.  Code repetition is absolutely minimized; inheritance and extensibility are optimized.  Fully centralized control of the “common template family DNA”, and extremely customizable end pages, through a combination of custom chunks (as seen above) and template variables (for adding bits of css, jQuery, etc. on a per-page basis).  What could be better?

The downside?  An extremely convoluted chunk hierarchy that quickly makes my head hurt.

It started driving me nuts trying to visually parse these nested chunks, to see what bits of the final html source code where in which chunk.   I started to yearn for a quick way to grok my chunk nestings.

In the absence of any such utility, and at my wits’ end, finally I was driven out of my inherent laziness and compelled to develop one.

Behind that link is my rough first draft of a template click-through utility.  Currently it only expands chunks.  In the future I plan to enhance it to expand snippets, placeholders, etc.   But first I thought I’d solicit some feedback.  Is this something that anyone besides me would find useful?   As David Letterman would say, “is this anything?“

Take a look, and let me know what you think.  I’d appreciate any feedback whatsoever, either on the template viewer utility or on my convoluted template strategy.  If there is enough interest, I may do a future post on how the utility works, and also possibly release some incarnation of it as an add-on package.

Like Gandalf battling the Balrog, I’ve been lurking in the underworld, fighting to the death with MODx Revolution permissions.

I am working on a MODx Revolution deployment that will replace the current Dreamweaver/FTP-based publishing system on the 5000+ page website of a major state university system.  There are about three dozen or so people doing content publishing – some of them are more dangerous than others and need more restrictions on what they are allowed to do.  Numerous different departments, some with hierarchical relationships.  Everyone needs to be able to see-and-link-to everyone else’s pages, but I have to be sure departments can’t edit-or-otherwise-bungle each other’s pages.

Turns out this whole “figuring out the permissions and user accounts” item on my project to-do list is going to be a huge project in and of itself.

The good news is, I’m exceedingly confident that the MODx Revolution permissions model will ultimately handle everything I need to do.

The bad news is, I’m largely fumbling my way in the dark, boldly going where no one has gone before.  (Or at least where no one has documented before).

I’m still quite far away from producing my own detailed tutorial – at this point if I tried, it would be full of inaccuracies, superstitions and general worthless drivel.  But hopefully I’ll be writing one at some point in the future when I have a better grasp on (a whole lot of) things.

That's me on the right, and someone from the MODx core team on the left.

For now, I’ll say that – although it is pretty densely packed, and may require multiple re-readings – Bob Ray’s article on Revolution Permissions is an absolutely essential first step toward understanding this subject matter.

Go read that. Then read it again.  Then try to write down some of the basic concepts to prove you have them down.

Then read it again.

And if the skies happen to open for you, and you are blessed with a strong and clear grasp of MODx Revolution permissions, then please do the community a favor and write a tutorial!

I’ll be back with mine once the dust has settled.

…realize that a guy my size might take a while just to
try and figure out what all this is for

-Barenaked Ladies, “Pinch Me“

Pinch me, indeed.

Although I had dabbled with MODx Template Variables a little bit, I must confess that until recently I didn’t really have any grasp whatsoever of their real usefulness. Chunks and snippets, those I understood.  But for whatever reason I just couldn’t grasp why a TV would ever be more useful than a chunk or snippet.  In my defense, the example provided in the official documentation doesn’t provide much insight, since the same functionality could be done with a chunk.

But then last week a light bulb finally went on for me.  It began, as do many of my mental breakthroughs, out of stubbornness.   I started transferring our new site design into MODx, setting up an initial template, and breaking it up into logical, reusable bits (chunks).  (All of which, incidentally, is ridiculously easy to do).   For the sake of this discussion, I’ll focus on a few different basic content layouts our site is going to need:

My first instinct was to create a template for each of these layout variations.  That would have worked, would have been okay.  But it somehow struck me as wrong; most of the code stays exactly the same in each variation; only a small bit of div structure changes in each layout.  Why not… use a single template, with a – wait for it - template variable to determine which layout div structure is used?

Now that I finally had the concept of a problem that required a template variable, I was sufficiently motivated to figure out how to go about solving it.   I did so simply by relying on the helpfulness of the MODx user community.  A few posts on the MODx forum, a few Twitter questions, and before long I had exactly what I needed.  It might not seem like a huge deal; in fact In some ways, compared to some of the brilliant MODx tutorials available elsewhere on the web, this seems like the type of thing that is hardly worthy of documenting.  But the way I look at it, if I can help even one other person have the “aha” moment that I had regarding the power of template variables, then I will have done a good thing.  Therefore, what little knowledge I have, I now pass on to you.

Step one:  create your template

Creating a basic MODx template is literally as simple as pasting your skeletal HTML source code into a form field, and then putting in placeholders for the document title and content.  Breaking up some of the HTML into chunks based on functional purpose is an extra step, but actually makes the template even simpler to work with.  Here’s what mine more-or-less looked like, before creating the TV:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<title>[[*pagetitle]]</title>
[[$css_block]]
[[$script_block]]
</head>
<body>
<div id="container" class="container_16">
[[$header]]
[[$contentDisplay]]
[[$footer]]
</div>
</body>
</html>

Notice how I created chunks for the css, javascript, header, and footer.  I find this to be very readable and  intuitive.  Also, by breaking things up into logical bits like this, you rarely ever have to edit the template itself.  If you need to add a new css file, you edit your css chunk.  Need to change your banner structure? Go straight to the header chunk.  A system like this can help keep multiple developers from stepping on each others’ toes, but can also help a lone web developer work more efficiently.

[[$contentDisplay]] here represents one of the content layouts depicted above.  (This is what we’ll soon be replacing with a Template Variable!)

Layout #1, for example, has a div structure that looks like this:

<div id="content" class="grid_12">
[[$fullcontent]]
</div>
 <!-- right column -->
<div id="rightCol" class="grid_4">
[[rightColumnWidgets]]
</div>

The [[$fullcontent]] chunk just serves as a wrapper for the content itself and an <h1> containing the [[*longtitle]] value:

<h1>[[*longtitle]]</h1>
[[*content]]

 

I thought it important/useful to create this wrapper since the H1 and content always go together – it is a “rule” of our site design, if you will, and it is always helpful to capture logical groupings like that.  Furthermore, since there are going to be other chunks (for the other layouts) that also pull in our content, creating this wrapper chunk makes things easier to maintain.  If we later decide that we want to include another bit of information, such as page author, or publication date, we can simply edit the [[$fullcontent]] chunk and know that the changes will be made in every content layout.

But I digress.

Step Two: create your “content layout” chunks

I’ve already shown you one of the content layouts. You might have noticed we are using the 960 Grid System CSS framework to achieve the various layouts. It just makes it ridiculously easy, and we all like easy, right?  Anyway, here are the other two layouts.

(25% left column, 50% center (content) column, 25% right column)
<div id="content" class="grid_12">
<div class="grid_4">
<!-- left column widgets go here -->
</div>
<div id="main" class="grid_8 omega">
[[$fullcontent]]
</div>
<div>
<div class="grid_4 supplemental">
<!-- right column widgets go here -->
</div>


(single content column, 100% width)
<div id="content" class="grid_16">
[[$fullcontent]]
</div>

Now we’ll save these three as chunks. A few important steps here:

1. Create a new category, called something like ‘contentLayouts’, and assign these chunks  to that category.  When we create the Template Variable, what it will be doing is letting you choose a chunk from amongst all the chunks of a given category.
2. Give them short names, using alphanumeric characters and underscores.  For these chunks I used 75_25, 25_50_25, and full_width.   (**I’m not entirely clear what the MODx rules/best practices are here, I just know that for whatever reason it makes me feel really uncomfortable to do otherwise)
3. Use the Description field to give them meaningful descriptions.  When a use is editing a page, they will choose a page layout based on the descriptions.

Here’s what this looks like in my Elements tab:

Step Three: create a snippet to select all “contentLayout” chunks

(From this point on, I’m largely following the formula described in the “Create TV-Based Chunks” page on the MODx Wiki site.  I’ve made a few modifications, so I’ll document exactly what I’ve done to make this work, but that page is an excellent background reference that will greatly help you understand the overall logic of what is happening here.)

As I mentioned earlier, the Template Variable is going to allow the page editor to choose a content layout from amongst all of the chunks in the “contentLayouts” category.  In order to generate that list, we need a snippet, which we’ll name ‘getChunks’.

<?php
/* Get the chunk objects */
$c = $modx->newQuery('modChunk');
$c->leftJoin('modCategory','Category');
$c->where(array('Category.category' => $category));

$chunkArray = $modx->getCollection('modChunk',$c);

$chunkNames=array();

/* Put the chunk names into the array */
foreach($chunkArray as $chunk) {
 $chunkNames[] = $chunk->get('description') .
                 '==' . $chunk->get('name');
}
/* Format the chunknames as a delimited string for the TV */
$l_chunks = implode("||",$chunkNames);

return $l_chunks;
?>

I’m using one of the Revolution versions (with a small modification to the output). Consult the Wiki page for the Evolution version.

What’s happening in this snippet is pretty straight-forward.  First, all of the chunks in a given category (specified in the snippet call) are returned in an array.  Then the array is used to generate a delimited string, which will (with my example chunks) look like this:

25% left column, 50% middle content column, 25% right column==25_50_25||75% left content column, 25% right column==75_25||content spans entire 100% width==full_width

In other words, for each chunk I’m sending

description==name

And using ‘||’ as the delimiter between each chunk.  This delimited string will in turn be used by the Template Variable to generate a dropdown list in MODx Manager, which will look roughly like this:

…and will be constructed of HTML like this:

<select>
 <option value="75_25">Content layout w/ content on left (75%), right column (25%)</option>
 <option value="25_50_25">25% left column goes w/ content, 50% middle column content main, 25% right column</option>
 <option value="full_width">Content spans the entire width of the layout</option>
</select>
 

See how that all works?  No need to thank me for the backstage pass;  it’s complimentary.

Moving on …

Step Four: Create the Template Variable

We’re almost there now.

• Create a new template variable; I’m calling mine [[*content_layout]].
• Give it a caption to help your content editors grasp it’s meaning; i.e.  “Choose a layout for your content.”
• Choose “Listbox (Single-Select) as your Input Type.

The “Input Option Values” field is the one that wants a delimited string of input options; this, then, is where we will call our snippet.

To call a snippet as the data source for a TV, we need to use the @EVAL binding.  We’ll be calling our ‘getChunks’ snippet, and asking it to return all chunks where category=’contentLayouts’.  Here’s what that looks like in an @EVAL binding statement:

@EVAL return $modx->runSnippet(‘getChunks’,array(‘category’=>’contentLayouts’));

Just a couple more fields to fill in and the TV will be complete.

• Default Value:  Enter here the name (not the description) of the content layout that you want to be your default option.  This is important – since we are relying on the content-layout-chunks to deliver the content, if we don’t select one, we simply won’t have any content on the page.
• Output Type:  String.   We will simply be outputting the name of the selected chunk into the body of our template. This will make sense after the next/final step.
• String Format: None.

Before saving the Template Variable, remember to click over to the Template Access tab and allow the appropriate template(s) access to this template variable.  Not much good otherwise…

Step Five: Modify the Template to Receive the TV Output

Now we go back to the original Template, and modify it to give a landing-place to the output from the Template Variable.  If you named your TV ‘content_layout’, you access it with [[*content_layout]].

[[$[[*content_layout]]]]

Just to be clear, here’s how this will work.  If the user selected the chunk ’75_25′, the line above will be parsed to:

[[$75_25]]

… which will then be further parsed to:

<div id="content" class="grid_12">
[[$fullcontent]]
</div>
 <!-- right column -->
<div id="rightCol" class="grid_16">
[[rightColumnWidgets]]
</div>

…which will then be parsed yet again to:  … oh, you get the idea.

The final template, then, will look like this:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<title>[[*pagetitle]]</title>
[[$css_block]]
[[$script_block]]
</head>
<body>
<div id="container"class="container_16">
[[$header]]
[[$[[*content_layout]]]]
[[$footer]]
</div>
</body>
</html>

 

And we’re done!

We now have a rather nifty, versatile MODx template that lets the resource editor drop the [[*content]] into any number of different inner-div structures, allowing for any number of different content layouts.

Pinch me.

Today marks a new ‘first’ for this blog – an informed, thoughtful take on the Drupal vs. MODx debate based on actual experience with each system.

Needless to say, such a rational, measured (not to mention effort-based) approach is well beyond my personal capabilities.  So I’ve brought in some outside help.

Mary L. from The Coding Pad has written some excellent MODx tutorials, and has recently posted two very informative interviews with members of the MODx core team.

She also uses, writes about, and (this is important) *likes* Drupal.

Mary appeared on my MODx radar screen recently over on Twitter, where she writes as @einsteinsboi, when she tweeted the following in an exchange with another user:

I love both MODx and Drupal equally. Each has its strengths and weaknesses, and I say it really depends on what you’re building.

Needless to say, this messed with my narrow-minded world-view.  I had to know more.  I contacted Mary, and, even though I have no credentials beyond being a freak with his own MODx blog, she graciously agreed to answer some questions on the MODx vs. Drupal debate.  I learned a lot from this exchange, and I think the results will be a good read for anyone trying to make an informed CMS decision.

What is your background/history in web programming? I get the impression that its never been your primary career, but it sure seems like you’ve immersed yourself in it.

Well, you’re right about that. I don’t have a formal education in programming and web development and it’s never been my primary career.  It’s been a hobby for the most part, but recently it’s evolving more into a freelancing business and it’s the way I want to it to progress, and perhaps eventually into a fulltime career.  Even though my professional training and career is currently in healthcare, I have a graduate degree in Physics and taught at college (undergrad and grad level) for several years as well as doing Physics related research which involved a lot of time in front of a computer doing data modeling,  simulations, interfacing, and computations. My work at different times involved programming in Fortran, the old MS BASIC, Visual Basic, LabView, Matlab, MathCAD, etc.  I don’t do that as much anymore but it gave me an appreciation and love for all things computing and programming.  I start getting more into web dev as an outlet for that part of my brain and I’ve enjoyed it immensely.  I have an infinite curiosity and a healthy amount of ADD so this kind of work keeps my brain occupied and happy

Well, I started out with plain HTML in the days of geocities, and then moved on to CMSs.  I started out with b2evolution which is what my personal blog was initially built on. I eventually migrated that to WordPress.  Then I discovered Drupal and SMF forums and my love affair with CMSs truly began.  After dabbling with Drupal for a while I started playing with flat file CMSs because the free host I was using at the time only allowed you five MySQL databases, and I had exhausted mine. I tried quite a few but especially nano cms (which seems to have vanished), razor cms which I think is still actively developed, and flatpress.  I also dabbled with Joomla for while, but that didn’t last very long.  But the two that I consistently worked with through this time were WordPress and Drupal, and SMF for forums. I then discovered MODx about a year ago and have been learning and working with it and loving it. Initially when I started exploring it was definitely just out of curiousity, and as a hobby, then I thought it would be cool to have a website, then a blog, then I started thinking of problems to solve, or being approached to solve problems, and it all evolved from there. I have a couple more CMSs on my radar to learn and work with but WordPress,Drupal, and MODx are the primary ones that I’m involved with and actively use at the moment. I’m not by any means an expert in any of them but I learn more and more with each project and task I undertake, and as I teach and share what I know.

Mary L. writes about MODx and Drupal at The Coding Pad

Well, this is a question I get asked a lot.  I’m a strong advocate for using the right tool for the job (if you’re interested on my thoughts on this, you can read http://codingpad.maryspad.com/2009/12/05/the-right-cms/).  The phrase “right tool” is very subjective, because we all have different tools in our arsenal.  Let me give you an example. If a client asked me to build a website with a strong community component, including intricate user functionality, lots of permission structure stuff, commenting, multiblogs, forums, reviews and ratings, lots of community widgets, etc., I would dive for Drupal first, simply because there are already lots of ready made modules and my work would simply be to string everything together, configure, set up, and press go (it sounds simpler when written out like that ).  I would be reluctant to launch into this with MODx because it would involve a lot of custom coding to create all the different components and make them work together.  I think that when I master Revo this might not be the case, but with Evolution I think it would definitely be so. I’m not saying it can’t be done, but I’m not sure I would be able to justify the work involved when I have Drupal available. If a client simply wanted a blog I would dig for WordPress, because that’s what WordPress excels at.  For anything else, I would reach for MODx.  It’s all a matter of functionality, time investment, budget constraints, etc.  Again, this reflects my own personal opinion, preferences, and current skillset.  For someone else it’s bound to be different.  I appreciate the strengths that all these CMSs bring to the table, particularly MODx and Drupal, and feel that I would be cheating myself and my clients if I didn’t exploit these to the best of my ability.

I don’t think Drupal entirely deserves the reputation of having a steep learning curve. Getting the initial concepts, as with everything else, may be challenging to someone not used to dealing with CMSs, but once you get over that initial bump I think it’s not that bad. Besides, there is a LOT of beginner friendly information out there, tutorials, screencasts, etc.  As far as custom coding modules and themes, this may be a little different. I have never tried to intentionally master creating my own modules or themes, so I may not be the most suitable candidate to answer this question. But in terms of just building a Drupal website with what’s already freely and readily available, I disagree to some extent with the steep learning curve reputation.  Again, it might depend on what your background is, what your timeline is, and what your expectations are.  The best way to learn Drupal is to take your time with it.  Learning Drupal when you have a project with a deadline is not necessarily the most optimal approach, and I think this is in part where the steep learning curve reputation comes from.  I believe this is the best read on the topic -> http://learnbythedrop.com/drop/155

I think MODx is intuitive in a lot of ways because of the framework and flexibility aspects of it. In some ways I think of MODx as being more “naked”, for lack of a better word, than most CMSs out there.  This allows a PHP programmer to start working with MODx and “get it” quickly as opposed to Drupal where you have to almost learn a whole new language and way of doing things and deal with modules that aren’t as easy to customize assnippet might be. And let’s not even talk about the theming issues and how much easier it is to template MODx than it is to theme Drupal .

That said, depending on your background, it can be easier to learn Drupal than it is to learn MODx. When I started learning Drupal, I hardly knew any PHP, so the module-based structure of Drupal worked well for me at the time and was easy to learn. I didn’t need to know any PHP or anything to get a pretty functional and even complex site up and running, just using what was freely available.  Then, because I needed to do more, I started looking at the insides, the code, playing with the API, trying to create my own small modules.  Because I had an appreciation for how Drupal itself worked, I could now start focusing on the more complicated stuff. I also started tearing themes apart and looking at them, trying to figure them out, customize them, and replicate them. When I found MODx, I was already more comfortable with PHP from playing with Drupal and customizing WordPress, so then learning MODx was pretty easy for me. I guess what I’m saying is that the learning curve really depends on where you’re coming from.  Drupal has a lot of documentation and user created resources out there that allow for complete rank beginners in anything to start figuring things out and learning without the barrier of not knowing PHP or programming getting in their way.  On  the other hand, a lot of the documentation out there for MODx is more aimed at developers and people with some programming experience, and therefore that makes it easy for some developers to make sense of MODx more easily than they would of Drupal.

All things considered, the MODx community is one of the friendliest, most knowledgeable, and most helpful communities I have ever been part of, and I really feel honored to be counted in their ranks.

Not being an expert in either system, this is a little difficult for me to meaningfully address, but I’ll try.  Let me just say that you may be underestimating Drupal in your CMS 101 statement . When you learn to work with Drupal you learn a paradigm, a way of stringing things together, managing users, managing permissions, creating content types and creating views to present your data as you want it to appear, and so so much more.  Not all these things are common to all CMSs. It may depend on how deeply they’ve developed for Drupal, how much they know, what their skillset is. I don’t know that the knowledge gained developing for Drupal will directly and intuitively translate in the MODx environment. There is no easy plug-and-play functionality in MODx Evolution as yet.  Apart from the initially installed snippets, installing any other snippets involves some copy-pasting, and sometimes tedious and easy to mess up steps.  Ofcourse this is all changing with Revo and package management (yay!!).  Also, snippet calls, cached and uncached status, etc, are concepts that I’ve found people struggle with sometimes when setting up snippets, whereas Drupal modules tend to be pretty straightforward to install and configure once you get the basic concepts.

I would say plain PHP knowledge intuitively and directly translates to MODx.  Both Drupal and MODx have their own APIs, so there’s not a direct translation per se, but there is a translation in the understanding of content management systems and their underlying principles.  Again, depending on your web professionals’ knowledge and skill level, they may be completely flummoxed by MODx or find it easy as pie.

I think generalizations can be a little misleading, since one is not easier to learn than the other at baseline, it all depends on where you’re coming from. If I had met MODx before I met Drupal I would probably have run away screaming. But because Drupal (and WordPress) had given me the foundation I needed and the confidence to build relatively complex websites without knowing a lick of PHP, I was able to start exploring and eventually learn to program PHP, and understand the basic concepts behind content management systems and the separation between content management and layout.

I don’t think there is really anything to unlearn, just new knowledge to gain, a different way of doing things, and a new API.  I can tell you from experience that having been accustomed to the Drupal user management and permissions system, the MODx one simply doesn’t work for me yet, and I find it confusing and limiting at best (I’m talking about Evolution, I haven’t delved into that aspect of Revolution yet).  But this is a reflection on my own knowledge and skill level, and not of the MODx user management system itself. Different strokes for different folks and all that   These are issues that I think you may find reflected in the experience of your web professionals as they migrate to MODx… or not

Well, your answer is in your question.  Working with MODx fits your style and preferences and works for you.  My answer to this is pretty much covered in one of my earlier answers where I talked about the distinctions between MODx and Drupal.  While both can be considered frameworks in their own right, MODx allows you a lot more flexibility when working with PHP and with HTML/CSS in terms, and when integrating your own custom scripts or other third-party scripts.

I think that your statement about a “way-of-life” type choice can be applied to any tool, and will probably become the same of MODx as it matures and becomes more popular and more mainstream and develops an ardent fan base, which it already has.  But this is a personal thing and having this perspective is a personal choice. I know quite a few developers like myself who use Drupal and develop in Drupal, but also use other CMSs and tools as and when needed. As a friend of mine put it, Drupal puts food on my table, but MODx gives me wings.  Depends on your motivation. Right now I get a lot of clients asking me for WordPress sites, so I’m spending a lot of time with WordPress.  Most clients won’t even look twice at MODx because they don’t know what it is. I try to sway them as much as I can when I think MODx or Drupal are a better choice, but people will go with what they’re familiar with and think they can maintain.  Same thing, bigger companies will ask for Drupal sites because they’ve heard the Drupal buzz and know they can easily find Drupal developers if they need them in the future.  Additionally, for a lot of people, once they immerse themselves in and learn one tool, it’s not worth it knowing more than this favorite tool, so they make it a way-of-life. It’s all very subjective.

I don’t know if I would try   People can be very set in their ways and opinions, and I respect that. But here are my thoughts if I were to try. If we were working on a project collaboratively and needed to pick a tool, then I would use examples, prototypes, and pretty much the arguments I covered in earlier answers regarding the ease of use versus flexibility of each tool. If either tool would work just fine, then it would depend on skill level, time constraints, and budget issues.

Just because you can build anything with MODx doesn’t mean you should. Pick the right tool for the job.  MODx is flexible, easy to customize and extend with the right skillset, easy to template, and more aligned with current OOP practices.  Drupal is powerful, has been around for a long time, has tons of documentations and user resources, has tons of modules and extensions already available, and has proven to be stable through several iterations.  It’s actively developed and has proved it’s not going anywhere.

To over-simplify this answer, if you need a powerful scaleable solution AND need lots of hand holding, ready-made components, and documentation OR you just don’t have the time or budget to custom code the things you need, go for Drupal, there’s always a module for what you need. If, however, you need a powerful scaleable solution AND want lots of flexibility, and have the skills, the time, and the budget to custom code stuff and to learn, go with MODx. This is an over-simplification, and it may not necessarily be 100% accurate, but it’s how I perceive it.  MODx in and of itself is a powerhouse that hasn’t received the exposure it deserves, and I feel like I haven’t even begun to tap into all it’s possibilities.  Additionally, I’ve been using Drupal a lot longer than I have used MODx, and I know I still have a lot of learning to do, and so my thoughts here should be read and understood in that light.

I think when Revo comes along and user and newbie-friendly and end-user documentation becomes more available MODx will be a force to contend with across the spectrum, but right now you may find yourself banging your head against the wall especially with non-developers who would rather use plug-and-play systems that already have the functionality they need in easy to install and configure modules and plugins, with lots of documentation and tutorials a la WordPress and Drupal.  And I say this from the position of being an ardent MODx fan

Thank you Mary for taking the time to answer these questions in such an insightful manner. I think it will generate some great discussion, as well as serve as a good guide for those trying to make an initial CMS decision.

View This Poll

These are not in any particular order, and I can almost guarantee there won’t be 10 things… that just sounded better than “Top Several Things”.  These are just some of the “to-do’s” and “would-be-nice’s” that I’ve identified so far as I’ve mapped out my project plan for the next few months.  Some of them are probably slam-dunks, and others are probably criminally insane.  Any feedback (insight, encouragement, discouragement, whatever) would be greatly appreciated.

1. Integrate “Manage Users” with our company LDAP information. So I can add users by selecting them from a list of all existing employees.  Because I hate typing in employee information that already exists somewhere else on the network.
   (I am fully aware that this will probably take longer for me to figure out than it would to just key in the employee info for the 2-3 dozen people who need accounts… and I’m still hell-bent on doing it).
2. Integrate Manager authentication into our intranet site. In my MODx dreamworld, my users will log in to the company intranet, and, if they are MODx users, will be simultaneously logged in to Manager, with some sort of smart link on the screen to make them aware and take them there. (I’m in various stages of doing the same thing with our web/calendar, our web file storage server, and our helpdesk call tracking system. It just seems like the thing to [attempt to] do).
3. Identify the most logically sound template strategy I possibly can. By which I mean, gain a better understanding of when/how to best use Template Variables (among other things, some of which I’m probably not even aware of yet) to allow the use of one or two primary templates across our entire site.   Our design scheme isn’t too complicated – I’m going to need to customize some background images, probably based on “department” and “parent department” affiliation of the pages.  First I have to figure out the “business logic” (which parts of the design are fixed globally, which parts are fixed based on belonging to a department, and which parts can be overridden at a per-page level).  Then I need to understand TVs & etc.  well enough to transpose those rules into some sexy & ruthlessly efficient template logic.
4. Rock some custom page-specific jQuery.  This is the one I’m most excited about at the moment.  Because jQuery makes life worth living, I want to be able to allow some (read: a carefully vetted elite group of users who WON’T BREAK THE INTERNET) of my MODx editors/page-wranglers to use it on their pages.   I think I have a sound plan mapped out involving the use of TVs and chunks to create an à la carte library of handy pieces of jQuery.  Hopefully I’ll flesh this out and do a full-length post on it someday soon.
5. Implement a revisioning system, or at least a solid backup/recovery plan.  This is CYA territory, plain and simple.  In our current Dreamweaver/FTP-based publishing paradigm, when someone blows away or hopelessly bungles a file or directory, we at least have the option to restore it from tape backups.  I don’t necessarily need something more finely-tuned than that, but I do need to offer at least the equivalent of that.  I’ve been avoiding dealing with this issue, but it isn’t going away on its own.

…and with that, I’m out of gas for today.  Too lazy to re-edit the title, I’ll just leave this as a list of five things.  Perhaps with more to come.