When we were updating our companys demo-site (customer playground), we realized that site development goes a lot quicker when content and structure are already there. It is not like we were just saving the time we normally spent setting up the structure. It's critical to have the structure in place. The result will be that your development team is going to be about 20 times as fast as they would normally be.
In this article we're going to get into a few things that we have done (wrong) in the past, which we are however not going to do again in the future, especially not for big or growing sites.
Developing a MODx site is a delightful job. For several reasons:
- "There's more than one way to do it"
- No restrictive template engine telling you where to put what
- No vulnerable 'popular' plugins that drive you crazy
- No brute-force attempts to crack your password (once you changed the manager address)
- No scenario where you have to tell your customer that "this just can't be done"
We all like our productive freedom in MODx. And more importantly we like how we can customize the manager, rename fileds, add or remove them, disable them, have a very specific permissions layer underneath our software that we can work wih and what not.
However, it is a lot of work to get a site to production-level. And we'd like to share our achievenments over the past few years with anyone starting from scratch - or - which is more likely, with people who have created a few sites and like to improve their skills without having to learn it the hard way.
Prerequisites
This is a best-practice article which addresses developers who know about the following pieces of software:
There are a few more that we require knowledge of/about. It's actually not about knowing about these specific packages, it's about the level of experience you have developing sites in general.
Other things you should know about
- Setting up permissions
- Setting up a separate media-source for your customers
- Setting up manager/form customizations
Why should you know about this? We're addressing those of you who are planning to deliver a 'perfect' product to their customers, that is hard to break and easy to maintain, even if it maintains a complex website.
Doing things in the right order
This is the most important part, where we most often went wrong. Even if it's hard to do so, try to stick with the following order:
- Gather all the information you can get about the site that you are supposed to create
- Create a structure on the site, what it is going to look like, what kind of site you want to have, sample pages, sample collections, etc.
- Add most of the template variables and sample chunks (yes, most of them, you'll miss at least one :) )
After that, you can get to work. You can start templating. Here's how you do this in a fast and elegant way:
- Pick the template with the most elements (very likely the welcome page)
- Start splitting the template into re-usable chunks which you can use on other templates (head, footer, news, members, welcomeSlider, etc.)
- Get this one template up and running, gathering all the information from related resources, etc.
- After that, copy from that template and re-use the work you've already done. It's a lot faster when you already have all of the chunks good to go and derive from that.
- When all is done, you can start setting up manager customizations, permissions and everything else. This is also a job to be done last, because you can duplicate your cusomization sets, which is going to save you a lot of work, too.
Your templates should look clean and simple by now (and so should your forms). Most of the template code should fit on one single window by now. If there are still some huge blocks of HTML, think about if they're something redundant that belongs intWe o a chunl.
Note: we wrote this because doing things in the wrong order will leave you with about three times as much work on your hands, manager customizations alone.
Avoid 'expensive' snippets
We have been using getResources, WayFinder, getPage and several others in almost every site we built in the past, which was alright for medium-sized pages, but once we had several calls for related data on one page, things started to slow down significantly.
Database caching, switching to memcache, lots of other improvements, all of which didn't seem to make a difference. But wait! There were loads of development relics: almost half of our snippet calls were uncached ones. This did some improvement. But still the page took about 2 seconds to load.
Most of these improvements that really do the trick are about little things. Avoid uncached calls, also use the parser properly:
[[[[+var1:is=`1`:then=`$chunk1`:else=`$chunk2`]]]]This might not look like much, but it saves you half the rendering time. Either $chunk1 or $chunk2 will be left, wrapped in the two extra brackets, which will case MODx to only resolve the sesult instead of rendering every single chunk.
If you're not already doing the above, you might still be using the "If" snippet. Delete it and use output filters instead. If is really slow.
getResources, getPage, WayFinder
...can all be replaced by a package called "pdoTools". Using the pdoTools-equivalents for the snippets mentioned above will speed up your page by a factor of 10 on average.
The reason for this is the avoidance of unnecessary calls. So this approach also has some drawbacks. Since pdoTools uses xpdo directly instead of using getCollection, this also means that it circumvents MODx security, so permissions and anything that needs them (which is not the case on most sites, because most sites don't have a lot of logic or different user-groups) would need to be activated manually. There's a flag called &checkPermissions though, to switch them on in case you need them.
In most cases however this is not needed, so you can safely use pdoTools as drop-in replacements for your calls.
Other differences:
includeTVs: is not a 0 or 1 flag in pdoResources, but a list of specific TVs to grab, which makes it slimmer and faster than getResources
parents: is finally consistent. pdoMenu doesn't use startId instead of parents, and the tpl flags differ a little. Other than that, it's a drop-in replacement for Wayfinder. Since you very likely render a menu on ALL of your pages, including the footer and other menus, changing this will affect your sites performance massively.
pdoPage is also more convenient and doesn't need that unorthodox syntax anymore.
Instead of reading this you should probably read up on the pdoTools documentation and give it a shot.
pThumb, resizer, getCache, MinifyX, autoFixImageSize
There are also loads of other snippets that replace 'expensive' ones, wrap things up that increase page-load and that are just misconfigured (or missing) in most cases. Many people forget to resize backround images, slider images and general content, and more importantly, have pthumb render them at 85% quality and force-format them to jpg, to avoid bmps, tiffs and pngs for huge images. This will decrease the size of your page a lot. Just read up on what the other snippets do.
General improvements
This doesn't actually belong into MODx improvements, but it doesn't change the fact that these factors improve performance - a lot.
MinifyX can't concatenate all Javascript and CSS, sometimes it messes things up. But you can. Once a site is finished, you can use the Google Closure Compiler to only load ONE minified javascript file instead of loading tons of separate files.
Reduce image sizes, reduce the size of the CSS files and try to stick with the above rules.
Developing a site should not take you more than two days, if no custom development is needed. But sticking to the right order and getting things done the first time should save you a lot of time.
Bottom line
Avoid getResources, avoid WayFinder, replace phpThumbof with pthumb, set up database caching, replace most of the stuff you use with the pdoTools equivalent and start doing things in the right order.
As Monk would say:
You'll thank me later.
Appendix
For your personal amusement, here are a few things where we went wrong:
#1 After planning a site for our customer, we started developing a site, added a lot of data to it, set up fancy pages for references and team members, set up manager customizations for all of them and presented the work that we already had to them so they can see how easy it is to maintain their information.
-- Turns out, employee fluctuation is way too high to name any member of the team, pictures do not exist and references/portfolio is not needed because they do not want anybody to know who their customers are. Most of them are competitors. We might have had a chance to plan the structure of the site first. We kind of missed it.
#2 Same customer provides us with a lot of input. We derive from the templates we already have and start fixing stuff up. Along with it most of the manager customizations, because the customers wanted to start maintaining their products while we are dealing with templates.
-- every two weeks, we ended up adding another field, and another field, and an additional picture, and a PDF file attached to it. Then the PDF file needed to be a picture of the first page of the PDF and it needed to be clickable. After that the downloads of the file needed to be counted.
After around six weeks the customers asks: "Is it at all possible to just maintain a list of generic information instead of what we just added." - at this point, you might want to kill your customer. But on the other hand it's our fault. We should have gathered all that information first and we should have made a suggestion on how to maintain and present that information.
Hours wasted on manager customizations, missing fields in manager customizations, missing MIGX, broken MIGX, different labels, etc. etc. - This could have all been avoided if we had just done everything in the right order.
There's a lot more and we're certain there's also more to come. But you see where we're getting with this.