Howdy! Welcome to my humble web presence. I'm Mark Hamstra, the CEA at my latest venture modmore, where I spend most of my time developing and providing support for awesome tools and extras for MODX Revolution.

This website is where I share my thoughts, cool projects and other oddities related to MODX, xPDO and ExtJS. Sometimes I post three blogs in a day, sometimes there's no update in a year. Read a random article.

MODX Revolution features a number of very powerful features that are hidden under the surface, but when discovered are hard to live without. Two of these are Element Properties and Output Modifiers. This short article will give you a quick introduction on what they are, and how they could be used.

What we will want to achieve

Do you have some kind of breadcrumbs trail in your page's  title, which should display the parent of the resource you are in? Great - but we don't want that on regular pages. Our regular pages and blog pages (where we want the parents title in our page title) are in two different templates, but they share the same header chunk. We'll want to use  the same header chunk, but make it output different contents.

So how do we do this?

We will tell the chunk in the blog template to output the parent (using an element property), and in the chunk we will add some conditional logic (with output modifiers).

Let's assume the following to be your template.

What we can do there is assign a property. Assigning a property can be seen as adding a variable or telling it to do something. When we put snippet calls in our template, we tell the snippet what to do using properties. For example, a Wayfinder call could have a startId and level property telling it how to process your menu.

Those properties we assign to snippets is something we can also assign to other elements (chunks and template variables are most applicable in this case). Knowing that, we can use the following to tell the core.header chunk to show the parent:

Just doing that wont do much... we will need to adjust our core.header chunk to make use of the property we pass to it (showParent), and based on that output the parent's title or not. When using properties with chunks, they will be added as placeholders so we can access that with the placeholder syntax. Let's use that, and throw in the conditional logic we need.

Let's say this is the relevant part of the core.header chunk:

After making the changes, it will look along the lines of this:

Okay. Let's break down what we did there.

  • First it simply fetches the pagetitle.
  • Then it fetches the placeholder we just set with the &showParent parameter on the chunk call, and do some magic with it:
    • It first checks if the placeholder is not empty (or: does it have a value?) using the output modifier "notempty". If it does, it outputs ":: [[*parent:getPagetitle]]". If it is empty it will return the placeholder's value (which is then nothing).
    • [[*parent:getPagetitle]] is where we use another output modifier, a custom one (snippet) this time, which fetches the parent's ID and parses it with a small snippet to get the pagetitle.
  • Then it simply sets the rest of the title.

By checking if the parameter showParent is empty, you're creating a way to conditionally control the value being outputted by the chunk. Throw in a custom output filter to parse the value further, and you've created a dynamic(-ish) title.

By the way, this is the custom getPagetitle snippet we use as output filter:

Due to recursive parsing of tags, it is needed to check the $input variable for a valid value, and stop doing things if it aint. After that, simply fetch the resource with the ID given, and return it's pagetitle.


Read 4 comments and share your own thoughts!

The getResources snippet is actually quite easy when you know how to start. As everything though, it can be convenient to have someone point you in the right direction when starting something new.

What is getResources?

Some people call getResources the replacement for Ditto, and frankly, it is listed as an equivalent in the docs. But getResources is probably more flexible then that, especially when combined with other snippets such as getPage. This article will help you get started with a quick example of how to use getResources.

New for MODX 2.2: Articles!

As of MODX Revolution 2.2, you can also use the Articles plugin which is pretty much a one-click Blog install for MODX. Read more about Articles.

Requirements

Let's get going!

The getResources snippet takes a lot of different parameters as the documentation shows, but for now we'll only use a few of them. These are &tpl, &parents, &depth and &limit. MODX veterans (or at least anyone who has worked with snippets like Ditto and Wayfinder) will probably recognize what they do. In order, they specify a chunk to use as a template, the IDs of parent resources, the depth to search in and the number of resources to return.

This is my getResources call I place in the content of my category container page:

By doing this, you get all resources from within the resource it is being called from, only one level deep with a maximum of 10 resources being visible. The blogTpl chunk is as follows:

You can see we put each item in its own div with class blogPost, and create a link to our resource with the link tag. We're also using some output filters, for example "strtotime" and "date" to make nicely presented published dates. We also use a custom output filter, which is parsetags - one could just as easily use the toLinks snippet (part of tagLister) to create links to the tag detail pages. Furthermore we're also showing the count of comments, based on a thread identified by the parentid-resourceid - make sure that matches how you set up your comment threads in the Quip and QuipReply snippets!

Now, this was a real brief article - however there's many, many, many more to know about getResources - all of which you can find in the docs, and possible future follow-ups to this post.


Read 0 comments and share your own thoughts!