Why I use ProcessWire

March 2, 2014

Let me say that first up that although it might seem so, this isn’t a post about slagging off your chosen CMS. If that works for you then great. This post is about some of the reasons why I’ve been put off by some CMSs I’ve used in the past and why I’ve chosen ProcessWire and why it works for me and the kinds of clients I have.

Lately I’ve been getting requests to either build websites in various CMSs or make changes to a website already running a particular CMS. In both instances my response is usually:

“I’d love to help you with your site but I don’t work in the CMS ‘C’ space. But if you’re looking for an alternative CMS that’s easy to use, has a good security track-record, a doddle to update, then we can suggest a system that would fit the site your currently have: ProcessWire (http://www.processwire.com). Here are some recent sites we’ve built, similar to yours, that run it and if you need a demo I’d be more than happy to send you a video walk-through of one of them.”

Sometimes a reply isn’t forthcoming. CMS ‘C’ runs a lot of the world’s websites. It’s part of most web hosts control panels by way of a one-click-install system. There’s momentum there for sure as well as brand recognition. “Oh, I can install it on my site with one click!?”. Click, instant website or blog. Need a different theme to alter the look? Boom. There are thousands of them as there are plugins to do pretty much anything. This is all well and good but I’ve always wondered how you control the markup output by all these plugins let alone picking through theme code to work out how an element is displayed. As someone who usually builds websites from scratch it seems like a good way to create bloat. I can also see that changing systems can potentially be confusing and disruptive. It requires trust in your developer to go with something new.

When I started learning ProcessWire I realised that I was free from obscure PHP and limp tags systems. I’d bought books on other CMSs, studied countless websites on how to get certain features working etc, but none of it sunk in or I ended the session frustrated and feeling hopeless and stupid. After getting over the initial learning curve I quickly decided that I wasn’t going to use anything else except ProcessWire.

My past CMS choices (yes, that I’ve actually used in production) have been frustrating and any mention of them will cause fanboi uproar. To keep it generic and inoffensive I struggled with them all in different ways. CMS ‘A’ assumed your site was a blog (and fair enough it had been created for that purpose) and had a maddening way of editing templates via the admin. Certain functions were so locked down that it took a plugin to do anything different with it. CMS ‘B’ came with a good set of tools out of the box but assumed the site you were creating was a news system or blog too. The concept that you would like any static pages (like an About page) was a poorly implemented after-thought and the idea that you might like to change the display order of an entry to something other than by date was left to a third-party developer. I haven’t used CMS ‘B’ in over two years and I’d go so far as to say it’s become a platform for developers to sell plugins and modules because the core is so inflexible and lacks generality.

So coming from these tagged-based CMSs to ProcessWire was initially a bit of a shock - it’s API is PHP-based. As a self-confessed PHP noob it took me quite a lot of fumbling around to understand it. I don’t pretend to know the entire ProcessWire API but the penny has slowly been dropping on a lot of it’s potential. It requires a different mindset to CMSs ‘A’, ‘B’ & ‘C’ but once that hurdle was jumped the curtains opened and the show began. There wasn’t any site I’d done in the past that I couldn’t do in a simpler fashion, quicker and with less abstracted tag code than I could using ProcessWire. Seemingly complicated sites with multiple hierarchies and mixes of static pages and lists became simple to construct.

In this mythical About section sits Updates (with several pages underneath it) and a static page underneath that. The ‘About’ and ‘Other’ pages are static whereas the update 1,2 & 3 pages are ordered by newest first (or by manually sorting them if you wanted). The only way for me to build that in ‘A’ or ‘B’ is via a third-party module. (Actually I’m not even sure that setup would be possible using CMS ‘A’.) My point with this is to illustrate that with ProcessWire it doesn’t assume anything about the site you’re creating. You need to mix static and dynamic pages within a section? Sure! Go right ahead.

I’ve heard some criticisms of ProcessWire’s UI. Something along the lines of “pfff, look at the UI, I couldn’t use it” or “hey, those colours look like they’re from our CMS. Humfph!” I’m all for judging a product on it usability but if you’re bagging out a product that you haven’t used (let along installed or tried) based on it’s colour scheme you’re wasting everyone’s time including the brainpower you used to compose that tweet. Another criticism floating around was that of the PW page tree yet CMS ‘B’s most popular add-on was one that allowed you to edit your site in a page tree. Go figure. One of the major strengths of ProcessWire is the way in which your site is presented as a hierarchy. It makes pages easier to find and you know exactly where you are and what you’re editing. What’s more there’s no setup involved to get it working like that. And if you need to change it it’s not difficult.

The concept of Pages has confused many and put quite a few off I would say. Don’t be scared of them, they can do a lot. It’s a generic term and best summarised thusly by fellow PW user Joss:

“Pages in Processwire are used for all kinds of things. They can be used as a marker in your pages list. They can be used as a group parent for other pages. They can be used as categories, tags or lists or users. And they can even be used for simple drop-down selects - just to supply a label and value.”

At the time of writing I’ve developed nearly 50 websites with ProcessWire. Clients vary from never-seen-a-cms-before to seasoned CMS users. Some sites have been simple blog/gallery work, others contain news/blogs with product lists and various static pages and forms. When I’ve presented ProcessWire as an alternative to their current setup - if there was one in the first place - the reaction has almost always been "Wow, that looks easy." And it is.

If I’ve learnt anything from using various CMSs over the years (Textpattern, ExpressionEngine, CMS Made Simple, Joomla!, WordPress and ModX) it’s how fast can I get from a finished design to a finished website? How easy is it for the end-user to add, edit and manipulate content? How easy is it for me to update the core system? These are questions I ask myself with each and every website build.

There are many more reasons why ProcessWire is good fit for the type of sites I build:

I like to work locally on my Mac, using MAMP Pro, AMPPS or similar. It lets me work faster to get that first draft of your site ready to show you. When I push that site to a development server (or use a tool like pagekite which can pipe your local site to a public address) the URLs need to work relative to the base URL. With some CMSs the base URLs are all fixed when it was initially set up. ProcessWire doesn’t do that. It doesn’t care what the website’s base URL is. So if I start developing locally like this: yoursite.local and the destination URL is yoursite.com.au or yoursite.net.au or yourbrandnewsite.org.au, ProcessWire couldn’t care less.

And what about installing ProcessWire in the first place? It goes like most CMS installs I suppose: unload your zip file, extract, create a database, run the install and you’re done.(Like with most things ProcessWire there’s a quicker way to do that too: https://github.com/somatonic/PWOnlineInstaller

If for whatever reason I need to develop on a sub-domain moving the ProcessWire install when it’s time to go live is simple too. I just move the site files and directories up a level. Done. Some (most?) CMSs would have a panic as all the path names will have change. By having relative URLs out of the box it makes the choice of where you develop with PW a no-brainer. That it doesn’t care what URL it lives on takes a big chunk of stress away from deploying a ProcessWire site.

Upgrading ProcessWire is a cinch. All you need to do it replace one directory and two files. There’s no mash of system files with site templates and modules. They’re totally separate. This tweet sums it up perfectly:

Poured cup of coffee, backed up processwire site, had a sip, upgraded site to version 2.4, had another sip, tested site. Upgrade finished.

I could go on with a few more detailed examples why I love and keep using ProcessWire. The last one I’ll leave you with is the ProcessWire forums. If you’re a PHP noob jumping in with basic questions don’t be at all intimidated or feel like you shouldn’t. Every single participant is there is there to help and encourage you. I can honestly say there has been no elitist scoffing at my questions, only positive answers and a willingness to help.

There’s so much more to ProcessWire than what I’ve touched on here. I haven’t even gone into any detail about the API which is a pleasure to use as well.

ProcessWire is just one piece of the jigsaw that is a modern website. For managing content I can imagine using anything else.