For whatever reason, sometimes it's seems complicated to get a working tabbed window that is also a form using ExtJS/modExt. And then when you do, the height of the shadow doesn't resize when the window does when you change tabs. Here's one way to pull all of that off and how I got this working in the bdListings component.

All of the below assumes you know the basics of ExtJS, and that all you need is a gentle push in the right direction to get this working in your own custom manager pages in MODX. If you're not yet at that level, I suggest reading up on stuff.

By default, the MODx.window includes a FormPanel, meaning that it is expecting fields. So while it may sounds more logical to actually use an items or components config option, the window will be expecting fields.

So let's give that to the window, shall we? I've included some default options you probably want here as well.

So what you're seeing there is a few things.

1. We're passing a title, connector URL and action, closeAction (which in this case destroys the window on close), and the arguement to use autoheight. Note that autoHeight only seems to affect the first load.
2. We add a field with xtype modx-tabs, which is how we would normally be using the tabs in MODX anyway.
3. The modx-tabs is given some config options (not all would be neccessary):
• Use autoHeight
• Do not defer (=delay) rendering until we open the tab, and force a layout. These options make sure the markup is always avialable, which is essential when you are going to be posting the form and using validation.
• Give it a 98% width and some padding, as well as a border for looks.
• Tell the underlying items (the individual tabs) to use the following defaults:
• Use no border, automatic height and some padding for looks.
• Use the "form" type layout, this is crucial to display labels and fields correctly.
• Do not defer rendering & force layout.

Now, not all of those options should be neccessary but I haven't had the motivation to figure out which ones or what combination get the right effect. Maybe someone can add to that in the comments? Thanks!

Now that we've got the basic tabpanel set up, we should add the tabs and some forms. Here's an example of that (which starts off where the last code block ended):

So we're using the known items object here, and we also give this individual tab a title from our Lexicon file. Then we add two items to this tab, namely an "id" statictextfield and a "title" textfield. The statictextfield can be used to just display text that cannot be modified by the average user (of course us web devs could just use Firebug to go in and change the field to a textfield should we want to :) ), and we also tell that to submit the value in it to make sure our processor has access to the ID when saving.

We can repeat the above block for more tabs, more items, etc etc. Just finish off the rest of the configuration like usual, making sure all brackets are closed properly. I personally use PhpStorm and that's pretty awesome at figuring out if something is missing or wrong.

Making sure the window resizes when changing tabs

Now that we've got working tabs in our window you will notice that if they are different in height, you will see the background shade doesn't resize along. For this we can use the syncSize function on the window. Whenever you change a tab, the "tabchange" event fires on the tabpanel which is what we'll need.

Add this code to the tabpanel configuration, ie the modx-tabs xtype we loaded.

What this does is that it listens for the tabchange event, and if that happens we fire the syncSize function. But as that is a function on the window object, and not the tab object, we will need to specify the scope:this to the listener option which makes sure that if we reference "this" it's actually the window object.

You can find a complete example with all these different parts in the bdListings repository.

In some languages (the Dutch one for sure) on smaller monitors/ browsers (1024px), the top menu in the MODX Manager overflows, pushing the last two or three items down a row, rendering it useless.

I've created a simple plugin to fix that called TopMenuFix, and has been added to the Extras repository

And with simple, I mean really simple. As the menu is simply styled with CSS, all it has to do is override those styles on manager pages. We'll be using the onManagerPageInit event to put some style definitions on the page automatically.

This two line plugin calls the modX::regClientStartupHTMLBlock method, which sounds really complicated but just injects some html into the header of the page. In this case, that is simply this:

And that's all there is to it.

Want this too? No problem! I've wrapped it up in a package using the PackMan addon and it is available from the Package Manager It's called "TopMenuFix". You can also find it on the MODX Website.

The source is on Github and with any bugs or feature requests (I don't expect them.. but.. okay) please also post on the TopMenuFix Repository Issues section.

The manager on my site handles a couple of site. First of all it is, obviously, where I write these articles. Then there was a Dutch translation in the works in a seperate context, as well as another one for the HandyMan website. Every now and then there's somebody who helps me out with these. There's someone translating for me, there's some people who help out on the HandyMan website and then a few more that need access to my main site.

At first I just gave them all full out access, but to provide a little more customization and security for myself I decided to set up a couple of user groups with just the permissions people will need. One of these involved the elements such as chunks and templates. Users working on the HandyMan site don't need access to my main site template or the other way around.

So I set up some access levels. I decided to do it quickly, and set up one "MH Admin" group which has access to the main site context and its elements. That would mean any other user groups (minus the main Administrator one which already had access to everything) only has access to the others. This is, in case you don't know yet, because the security system locks out user groups that do not have the permission in case you set it explicitely. So first everyone's allowed - but when you give one user group explicitely access to it, it will block all the rest. No problem! That's exactly what we want.

Fast forward a month.

It is now June, and a week ago I updated MODX to 2.1.1-pl, and set up a new context related to the development of a new website - this one! Fresh content, fresh layout etc. All good. But suddenly, a week after setting that up, while browsing the site it seems some pages have eaten their template! Nothing shows up, but just the content.

Theory 1: corrupted cache

Okay... odd. Now let's think. What could've caused this? Let's just refresh the cache to make sure we're not just dealing with an incidental corrupt cache or anything. Cache cleared, back to the website, all good. Alright then - back to work!

Theory 2: context settings

Now about an hour later I end up watching my website again, and guess what? Same problem all over again! I didn't settle with clearing the cache this time, but instead kept browsing around in order to see if I can replicate it on the website. At one point I just totally couldn't find it and decided to make a note about it on my homepage just in case it would happen again. So I make the modifications and press the "View" button to check how it looks. But wait! The "View" button doesn't work, but attempts to open a javascript code as webpage. So I went to check the site_url setting in the context, to find it wasn't there.

I never set them on the "web" context for the simple reason that it wasn't needed. The web context runs just like it would be the only one. But, or so I guessed, the fact that I recently added a development context for my new site without settings either (did not want it public yet) might have been the problem. Let's set some settings such as site_url and try again. Yay, it's back up!

... or is it?

What actually was the problem

The problem was that it would not be parsing my templates, chunks and so on. My elements. The same ones that I protected a month earlier in the back-end to make sure only the people I want to be able of accessing could actually see them. After receiving another text message asking if I made my website "Mobile friendly" (yes, that's you Taco!!) it seemed the problem was still there. Aaargh!

Figured it out yet? If you didn't, don't worry - at this stage I didn't either. If you did, where were you when I needed you?! :P

If you remember (or scroll back up) you'll see how I explicitely set my MH Admin user group to be able of accessing these specific categories. What that meant is that any other user groups would not. But that's what we want right? Actually - there's one flaw in there, which may stem from still being used to the Evolution security systems in which you had the division between web and manager users. In Revolution, you do not but instead they can be used for both or just one of them. The user group that caused this was the (anonymous) one - a user group representing people that are not logged in. Site visitors. People who will want to see my templates and other elements.

So because I only explicitely allowed my MH Admin user group to access these elements, they were automatically hidden from other user groups.

Including valuable visitors.

The fix was easy - just give the (anonymous) user group access to these elements as well, using the access control of "Load, list and view". Flush permissions, clear cache and back to the site. Test in three browsers and ask three other people from all over the country to do the same. I am now confident to say the problem has been fixed.

So that's all?

Now there's one more thing that I didn't explain yet, which has seriously made this fault hard to track down. I know this system quite well, and this had me puzzled for days.

One word: Caching.

My site is cached as much as possible, which includes complete resource caching. So whenever a page is requested (by anyone) it is cached. This anyone is often me - whenever I change something I check it out, and click around a bit to check out comments etc. All the resources I visited were added to the cache, and these often were the ones that were most visited as well. So whenever I visit a resource while being logged in, it gets cached with my permissions.

But, and this was the problem, when a resource was not cached it would use the anonymous user group permission and MODX would refuse to display the templates and other elements. As a result it would just dump the content with no errors (it's intended behavior, not something failing) or any clues.

 

So that's what kept me busy over the past period. And I hope this article can prevent you from having to do the same. :)

It's possible that you don't know what the MODX Partner Program is, though it has been getting more and more attention lately. There's not a simple explanation to that as it becomes as much as you put into it, and much of it is constantly in development to offer more benefits to the Partners as well as MODX.

In general it can (and has been) said that it is aimed at developing MODX and your own business by offering resources, a private discussion board and closer contact with the core developers. Depending on the size of your company, there are three levels you can choose from: Professional, Agency and Premier. Where Professional is the cheapest (at $ 500 per year at launch, but as of June $ 50 per month) level, it does come with the advantages mentioned above and also includes a complimentary license for PhpStorm and New Relic, a Partner Listing valued at $ 100 per month and of course access to the partner board. Moving up the levels, the price increases (to $ 5 000 and $ 10 000 for Agency and Premier partners respectively) as well as the benefits such as 5/10 hours of core consults, a MODX integrated helpdesk suite, sales leads and much, much more.

In April I decided to take the plunge, and sign up to become a Professional Partner and see if it is worth it. As you may know, I am a freelance developer and even though the business is running well, at that point $ 500 was still a lot of cash and making the decision to try it out didn't come easy.

Taking the plunge

The first few hours of being an official Professional MODX Partner were mainly spent visiting the private forums, which are packed with other skilled MODXers discussing topics varying from favorite development IDE, development and quality assurance workflows, what they were working on and so on and so on. While the public forums are amazing as it is, there is something about the Partner boards that the public ones just don't have. For example when looking at help requests, it is easier to share bespoke code as the forums are not indexed or otherwise publicized, there is a less demanding atmosphere and they don't just deal with how to use basic MODX properties, but go more into depth challanging the system and the people using it.

Furthermore - there's the scoop. Lots of it. Think about a first look & test run at the new forums, a topic explaining what has changed in 2.1 before the public launch and more. It may be hard to put the value of such forums into money, but for me personally there is a great wealth of information there and lots of dense-packed knowledge from the core team as well as other partners.

A second point that has really attracted me to take the plunge was the MODX Certification. At time of writing this has not yet been fully developed, but it is expected in the third quarter of this year and will provide a huge advantage to show credibility and knowledge. Especially for the smaller companies or freelancers like myself, credibility is often one of the bigger challanges in doing business, and this will be a huge help to get that obstacle out of the way.

Three months later - was it worth it?

Short story: yes.

In the past months I have not only learned a lot about MODX, but also about different tools for development and email marketing, read about the differences between MODX and another system in detail and my business is running like crazy. Joining and actively participating in the program has introduced me to new people and has led to new inquiries - a big bunch of them from other Partners looking for people with my speciality. In June I was also contacted for a promotional activity, which you can see the result from on the Partner Program page.

Everyone will have a different idea of the partner program, and different benefits attract different people. There's designers, developers and decision makers involved but they have one thing in common: they support MODX and have been willing to contribute towards further development of it as a system as well as a company. 

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.

There is something, well, maybe not magical, but certainly productive about using xPDO queries within MODX as opposed to using plain SQL. I've created a really simple snippet which fetches children of a resource (if any) and outputs them in an unordered list. And this took no more than a few minutes to pull off.

Before getting started

You may be wondering what xPDO is. If you've not wrote custom code in MODX Revolution yourself yet, I can imagine the term might not sound familiar. xPDO stands for "open eXtensions to PDO" and it has been developed by part of the MODX Core Development team to provide an Object Oriented Programming approach to relational databases built upon PDO - a core function of PHP > 5.1. At the same time, it also provides (although slightly limited) support for PHP versions under that.

Anyway - that's not what I wanted to explain in this article. This article is about how you can use xPDO within MODX to easily create custom snippets which are very easy to read, fast to execute and can be customized at will without spending years learning a special language - it's all PHP.

getChildren

I designed this snippet cause I needed a simple way to output an unordered list of children of the current resource, but where using an existing addon (like getResources or Wayfinder) would feel like overkill. Of course they both have their own advantages compared to using this custom approach, but I'm being given the power to use this by MODX, it's probably faster (I didn't test it - but just have a look at the lines of code getResources uses and what my snippet uses) and I wont be touching it often after developing it anyway.

This is the actual snippet I'm using:

It's commented line by line, and those familiar with PHP will see what it does in an instant. There's a few things I'd like to point out in this case though:

1. The script starts off with calling the $modx->resource->getMany('Children') method. What this does is tell MODX to use the current resource, and find associated children based on that resource.
2. On line 6 shows the modX::getOption (inherited from xPDO:getOption) method, which is considered best practice to get settings and properties from in MODX Revolution. It accepts three parameters:
   1. (string) name of the option (setting, property) you want to retrieve. In this case I'm looking for the tpl parameter.
   2. (options array) variable name you want to get it from. Within snippets you'll use $scriptProperties.
   3. (string) default value if there's no value found for the option name. In this case I set it to an empty string.
3. When it starts going through each of the children found, it first sets an array with the different resource fields I want to have available in my template chunk, and get the value using the ->get('fieldname') method. When it has all the data in the $out array, it will take those fields and use $modx->getChunk($chunkname,$placeholders) to populate the template with the placeholders, and in turn add that output to the $o variable.
4. Lastly, it finishes the outer markup and returns the output to the snippet call.

Now let's look at the tpl chunk.

The chunk is really straight forward. It creates a list item element, adds in an anchor (hyperlink) tag and uses the placeholders that are set. It also uses the link tag syntax to create a link and the "default" output filter, which sets the value of the placeholder to what's included in the `` quotes if the placeholder value is empty. So in this case, that acts as a backup in case I didn't set a menu or a longtitle (assuming there will always be a pagetitle).

What remains now is showing you how to call it (assuming you named your Snippet getChildren, and your chunk getChildrenTpl):

Conclusion

Don't be hesistant to coding your own snippets - xPDO and the MODX api makes the most common tasks ridiculously easy. This snippet took a couple of minutes to make and by spending a couple more minutes you could improve it easily to also use an outer template instead of mixing PHP and HTML... but it suited my needs as it is :)

What do you think about using custom coding in your development?