Built using ProcessWire

Ancient World Magazine is built using the open-source content management framework ProcessWire, created by Ryan Cramer.

Written by Josho Brouwers on

Since 1996, I’ve had a website in one form or another. I taught myself HTML, then switched to make websites using server-side includes (briefly), then perl, and finally taught myself PHP. I picked up CSS and JavaScript (mainly jQuery) along the way.

Being dissatisfied with existing content management systems, it wasn’t long before I started building my own using PHP. For example, back in 2009, when I worked for the VU University in Amsterdam, I built a digital learning environment from scratch (which I called “CitiVU”) to accompany a class about the city of Athens.

When I did my postdoctoral work at the University of Thessaly in Volos, Greece, I built a complete content management system (dubbed “Helo”) to make the W.D.E. Coulson Archives available online. That system’s still up and running, based on a flat file database exported from Access.

Existing content management systems

Aside from my own projects, I’ve also been building websites for clients for half a decade or so, mostly working with designer Sebastiaan Guliker, who owns and operates Het Ontwerp Departement. As building custom solutions isn’t generally an option when doing work for regular clients (small businesses and the like), I had to work with existing content management systems. The most popular of these is, for better or for worse, WordPress.

Don’t get me wrong: WordPress is fine if all you want is a blog with some static pages. Anything more complex and you’ll be forced to try to bend WordPress to your will: creating custom templates for specific pages, creating custom functions and hooks, and creating your own plugins (or downloading other people’s plugins and hope that they managed to fix all security holes and the like).

WordPress has a peculiar way of doing things, too: the code is – not to put too fine a point on it – quite a mess. A lot of it is entirely procedural rather than object-oriented, which means that many of the variables and functions aren’t exactly consistently named or implemented.

For example, this:

get_the_permalink()

works differently from this:

the_permalink()

And it’s not obvious from the way these things are named what does what precisely: functions that start with “get” usually don’t immediately output anything, so you have to tell PHP to actually store the data in a variable or output it directly. And that’s exactly what you would want sometimes; just the way it’s phrased in WordPress makes things confusing at times. It also doesn’t help that this scheme isn’t used consistently.

Of course, other content management systems have similar problems: either they were made – like WordPress – to fulfill a very specific role, or they have their own peculiar way of doing things. Drupal, for example, has a particular terminology (nodes and the such) and a particular structure (with content blocks) that requires some getting used to. One of my previous employers originally had a website that ran on Joomla: my experience with that was so bad that I never want to work with that system ever again.

In fact, none of the content management systems I have tried over the years I’ve ever actually enjoyed working with. None, that is, until I ran into ProcessWire back in 2012.

Enter ProcessWire

Technically speaking, ProcessWire is not a content management system so much as it’s a content management framework. Downloading and installing ProcessWire is simple – much easier even than WordPress’s vaunted “5-minute installation” – but if you want to make the most of it, you will need to actually code your own website in PHP.

ProcessWire makes no assumptions about the kind of data you want to store in the system or the way that you want to structure and layout your website. That is great, and a distinct advantage over almost all other content management systems, but that does mean that it’s not ideal for people who just want to get a website up and running as quickly as possible.

Crucially, there are (almost) no themes to download for ProcessWire to easily re-skin your website. All of the different “profiles” offered as options during installation will create a basic website structure that only serves as the starting point for actually building your own website. There’s a “beginner” profile for when you just want to get the hang of working with ProcessWire and an “intermediate” one if you want a more developed structure to expand upon. But if you don’t know how to code in PHP then ProcessWire is not for you.

As far as files are concerned, ProcessWire is split into basically two folders. The first, “core”, contains all the files necessary to run ProcessWire, which you can update via a module (ProcessWire’s version of plugins – most of them come standard with the system). The second, “site”, contains all the files specific to your website, including your template files, assets (uploaded pictures, documents, and the like, as well as session data, etc.), and site-specific modules. Creating your website, such as outputting HTML, is all done by editing the PHP, CSS, and JavaScript files in your site/template/ folder.

Nevertheless, the backend is very easy to work with and I’ve had no trouble to convince people to switch from whatever CMS they were using before to using ProcessWire (since I handled all the code anyway). The reason for that is simple: the way that ProcessWire is structured and functions is very simple and accessible.

In ProcessWire, everything is essentially a page: users, actual pages, bits of information you want stored but not necessarily passed directly to the frontend. When you sign in to the backend, you’re greeted by a tree structure consisting of pages eminating from your website’s homepage. You’ll have the “About” page here, your blog index, but also “Admin”, underneath which are all of the pages used in your backend, such as the module overview page, your user directory, and so forth.

Each page has a template. A template is essentially nothing more than a collection of fields. Fields can be regular text fields (e.g. for titles), textareas (for longer bits of text), image fields, and so on. If there’s a PHP file with the same name as the template in your site/template/ directory, the system will assume that this file must be used to output any page with this template. (You can change this via settings if that’s not the behaviour you want; if, for example, you want a particular template only accessible to a subset of your users.)

Coding the actual PHP template files is also a lot easier than coding anything for e.g. WordPress, as ProcessWire is entirely object-oriented and uses a jQuery-like syntax. For example, to output the title of a particular page, all you have to do is this:

echo $page->title;

Want to output the page’s URL? Just type this:

echo $page->url;

But note that the above only gives the relative URL. What if you want to output the full URL, for example when you want to include a canonical URL in your webpage’s header? Simple, use this:

echo $page->httpUrl;

Basically, the part after the object operator (i.e. the “arrow”) is usually either the name of the field in the template (which you control entirely) or a method that is part of a class (in this case, it’s the page class, with this instance defined as $page, a protected variable name). So let’s say that you have a field called “author”. To output whatever data is contained in that field, you’d simply type the following:

echo $page->author;

Unlike in WordPress, where you need to install a plugin to add custom fields, you can define whatever fields you want in ProcessWire directly from the backend. Adding them to a template is as easy as selecting them from a list and then dragging them to where you want them to appear. You can hide fields from view if they’re empty, indicate what fields are required, and so forth, all directly from the backend.

Working with templates

When I do a fresh install of ProcessWire, I always start out with the “intermediate” profile. It does a few things that help me speed things up, even though I usually do end up rewriting almost everything from scratch.

As far as the templates are concerned, I tell the system, in config.php (located in the “site” directory), to first load a template file called init.inc.php, which contains all of the base variables that I want to use throughout the website. It also loads my functions.inc.php file, which contains all necessary functions, such as a truncating functions to shorten texts in summaries, and some functions used to render specific data.

The system will then load whatever template has been requested: for example, if the user is accessing the homepage, it will load the template home.php. Templates like this usually populate particular variables, such as $title or $content, which have been defined earlier in init.inc.php.

Next, the system queries config.php to see if it has to append a particular file: in my case, I usually specify that the system has to load main.inc.php, which is the main template file: it features most of the HTML, including the webpage header and footer, and it populates areas defined by the individual templates. (You can also define prepended and appended files on a per-template basis in the backend, which is very convenient.)

The biggest advantage of ProcessWire is that the system itself mostly gets out of the way. The template files are all straightforward PHP. You don’t have to mess around with content blocks like e.g. in Magento (for webshops), nor do you have to name and structure the PHP files in a particular way (e.g. WordPress needs files to have specific names for files, like index.php or footer.php). You can essentially arrange the files however you like, which offers exactly the kind of freedom that I want.

Closing thoughts

This website would have been a great deal more difficult to create if it hadn’t been for ProcessWire. I know I’ve been gushing about ProcessWire so much now that you probably think I’m getting paid to write this! I’m not, but I shudder to think how complex it would have been to build this website in something like WordPress, what with its different types of content (articles, podcasts, the museum pages, the links to external resources, the FAQ, this dev blog, etc.), each with subtle or not-so-subtle differences with regards to layout.

At the same time, I hasten to add that ProcessWire is definitely not for everyone. As I wrote earlier, you cannot just grab a ZIP archive from the ProcessWire website, install it on your server, and expect to have a website that is ready to use.

ProcessWire requires extensive coding to create the website that you want. As such, it’s great for developers like me, but a poor fit for people who don’t know how to code in PHP and cannot afford to hire someone else to do it for them. In those instances, you’re better off sticking with something like WordPress, as long as you don’t mind being entirely dependent on other people’s code.

For myself, an avowed control freak, I cannot imagine ever wanting to use another system to build websites with. For my current employer, for example, I have rebuilt the old ZenCart-based website using ProcessWire, adding my own solution to create a simple, but fully functional webshop, including user registration, an address book, order overviews, and so forth. With Sebastiaan Guliker, I have developed a range of other websites, from simple one-page websites to far more complex business sites with secure sections accessible only to authorized users.

And, of course, Ancient World Magazine serves as a good example of a website built using ProcessWire, with many different parts. I have lots of cool stuff planned for the future, including a timeline, that will further showcase just how robust and versatile ProcessWire is.

In any event, I hope that you have found this blog post useful. If you have any questions, feel free to get in touch.