I’ve been using WordPress as a blogging tool and subsequently as a fully-fledged content management system for over fourteen years. In all that time, I’ve often heard that WordPress isn’t really suited for “serious” use.
If someone really thinks that, then I’m pretty sure they haven’t discussed the possibilities with a WordPress expert. Because these are the kinds of website I’ve been building with WordPress since 2004.
The basic blog has been WordPress’ core strength right from its first release. The famous five-minute installation process usually takes less than two once you’ve done it a couple of times, and if you use a default Theme, you can go from zero to a first published article in under ten minutes. That’s leagues ahead of CMS like TYPO3, which require a more complex process and often a customized server setup.
I trained a client this year who’d never set up a website, and we created a complete new online presence for him, including domain registration and search-machine-optimized content, in a half-day workshop. That workshop proved how quick and easy it is to set up a website for a small business.
Most businesses want a website which matches their own branding or “corporate identity”, which is when a custom Theme comes into play. By building sites with a range of page layouts, each with its own content options, every company can go online with a website which is tailored to their specific requirements.
That’s my bread and butter: building Themes (and associated Plugins) for clients. I developed what developers call a “starter Theme” a few years ago for private projects and continued to develop it for my employer, when the third-party starter theme they’d been using for several years became obsolete. The latest version contains a complete set of code which works as a starting point, and has most commonly been implemented together with the Timber plugin to allow the use of Twig templates.
My starter theme usually gets extended with a block-based system to allow clients to author pages and posts using the multimedia elements of their choice, and I’ll be extending it next year to use the new WordPress editor, code-named “Gutenberg”.
For clients who run several websites, it can be very advantageous to use WordPress’ Multisite capability, so that all the sites are accessible for administration through one interface. I’ve been using this feature for years — first in 2010 and most prominently for SBB when I worked at !frappant, where we set up and managed a 100-site installation with custom plugins, custom themes, and per-site multilingual capability.
Proof of the capabilities of the Multisite technology is that WordPress.com, which contains several million websites, uses WordPress Multisite.
Switzerland is one of the few countries in the world with more than one official language, so most websites I’ve worked on since 2001 have been multilingual. WordPress is set up to work in any one of more than 120 languages, but using several languages concurrently on a single website takes an additional plugin. After several problematic months wrestling with WPML, and needing a huge amount of assistance from their support team, I switched to Polylang when I “returned” to WordPress as my main website development tool and haven’t looked back since. The pro version of their plugin is ridiculously affordable and I’d recommend it to any developer or agency.
Multilingual and international shops
Running a shop with Woocommerce is more of an administrative challenge for the site owner than a technical problem. Since the plugin was taken over by Automattic, the code quality has massively improved and there is a rapidly-increasing number of add-on features available. The sites I’ve helped build taught me a lot about how to make best use of WordPress, Woocommerce, Polylang and the Loco Translate plugin, and one of them even added Multisite to the mix, when a client needed separate shops to be added to an existing website: one for Switzerland and one for the remainder of Europe.
The Headless CMS has been moving like a shadow in the background of CMS development for a very long time, and has only been referred to as such since the advent of advanced front-end development techniques like React. Simply put, the classic backend of the CMS—in this case WordPress—only serves as an interface for editors and administrators to manage the articles and content. The user profits from many years of development and user testing which have produced a simple, yet powerful, editing environment, and the results of their editorial work can be used in a vast range of possible websites or applications.
In a headless CMS environment, the front-end of the website, app or other output device is programmed completely independently of the CMS. This makes huge sense for teams who don’t know the (sometimes complex) range of functions in WordPress. They can focus on their specialist area and leave the “hassle” of the CMS to other people.
Using a front-end technology like React or PHP’s cURL, it’s simple to collect the data from the WordPress REST API and then do whatever needs to be done to convert it into a working website. The data is structured according to standardized, non-WordPress-dependent principles, so if the developer and other interconnected data providers adhere to a common REST principle, it’s easy to get and parse the data from whichever data provider is appropriate.