New MODx Blog


My new MODx Revolution blog is now live at this address:

http://www.cmslesstraveled.com/

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

Publishing a resource from a draft copy (revised – now with TVs)


Lots of feedback on yesterday’s post, much of it to the effect of “call me back when you’ve got it working with Template Variables!”

Alright then. Continue reading

Updating a published resource from a draft copy


[[UPDATE:  A slightly updated version of the plugin code, with Template Variable syncing, has been posted here]]

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.

Continue reading

Its all happening…


Nothing remotely technical in this post… I’m taking a step back from that stuff, while I get ready to relocate this blog and settle on some long-term specific themes/topics that will keep my interest and serve the MODx community as well as the “trying to decide on a CMS” community. Stay tuned.

Continue reading

Managing CSS and Javascript/JQuery in MODx templates and pages – Part One


An interesting bit of discussion on Twitter today about jQuery rotating image galleries for MODx got me thinking about the way I’ve designed my templates to handle custom jQuery at the per-page level.  Long-time readers from back-in-the-day (by which I mean February) will recall that this was one of my high-priority issues for using MODx Revolution.  While I don’t quite have it all sorted out yet, I think I’m on the right track.

Continue reading

Thoughts on developing a template strategy… and my new template click-through utility


I’m keeping the sarcasm and clever wit to a minimum today, and putting out a request for comments.

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”&gt;
<html xmlns=”http://www.w3.org/1999/xhtml”&gt;
<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”&gt;
<html xmlns=”http://www.w3.org/1999/xhtml”&gt;
<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.

Up to my eyeballs in MODx Revolution Permissions


The above title is the answer to the question, “where has the author of this blog been for the past six weeks?”

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

Continue reading

Follow

Get every new post delivered to your Inbox.

Join 33 other followers