Feb 19

The Unconventional Guide to WordPress

Posted by

Published in , , ,

Similar to other web companies in the modern age, we use WordPress quite a fair bit. We’ve transferred most of our news management systems over to WordPress from custom built legacy systems and we also use it to power other more interesting stuff. We’ve found it just works and gives us the power and flexibility needed for the things we need to do.

That isn’t to say we haven’t run into problems and hurdles along the way. As a company built on high standards and quality, I don’t think any CMS is completely immune. For example, we found that WordPress wasn’t removing non-alphanumeric characters from URLs at all but just replacing them with ugly URL encoded equivalents, to our shock and horror. However, instead of deprecating 99% of all our WordPress installs with completely different content management systems, as a lot of people would do, we just simply wrote a plugin to fix this.

With all that said and done, as much as this is a guide about WordPress development, it’s also a guide showing that you don’t have to find a new CMS when the problems mount, a guide showing how you can really leverage the power of it. With a bit of PHP knowledge, I will show you solutions to things that annoyed us and could have annoyed you too.

Using a Custom Backend

I’m pretty certain there will be people reading this thinking “WHAT THE” followed by an expletive. When I first noticed this being done, I did the same so I’m not surprised. However, what I’m going to talk about will justify my actions in continuing with this method.

It seems very unconventional and quite stupid really but honestly it’s not as stupid as it sounds. You may also think we’ve reinvented the wheel. However, a better analogy would be that we invented our own axle to make the wheel fit our needs to a greater degree. Here’s why I think this:

Do We Really Need It?

WordPress is, as we all know, a fully-featured CMS. It has a lot of stuff for people to use and take advantage of but seriously, we didn’t need it for this part of the system. If we wanted to cut it down to the size we wanted it, we’d have to hack the core and I’m vehemently opposed to this for obvious reasons.

We also had people using the system with minimal experience with computers in general and we didn’t want to confuse them with anything we couldn’t remove from WordPress. In fact, the interface only needed to be as simple as a list of things to amend and a text box to write amendments to. No WYSIWYG, no drafts and definitely none of the extra baggage WordPress has.

Ah, but We will Need That

There are also loads of WordPress features we really wanted as well. For one, being able to use the plugins we currently use is one, along with making our little quick fixes for small WordPress quirks. Another is presenting us with an extensible, regularly-updated and fully-featured frontend without actually having to build it. Another is tree-structure categories, multiple categories, tags and comments (coupled with an awesome spam guard). Everything.

We got it all right out of the box when we went with WordPress for the frontend and it shaved a massive amount of time off development. Not only that but it also saves in maintenance time too since the only thing I need to do to maintain that aspect is upgrading the core and the various plugins.

A Hypothetical Advantage: Different Languages

You could actually use a completely different programming language. Want to use Ruby, Python or, gasp, C++? You can and still have an awesome frontend.

So if you’re a PHP hater, you can reduce the amount of stress this induces by being forced to write the necessary and extensive amount of plugins you would require for your custom functionality. Also, as stated as above, you wouldn’t have to re-implement every single feature of WordPress you want to make use of.

Now, this one is completely hypothetical and we didn’t actually do this but logic dictates that this will also work. I’ll have to test it one day!

Okay, so how?

Doing things this way does require some skill on your part. You must be prepared to dive in and learn the ins and outs of the WordPress database schema but this is quite simple. A few diagrams and you’ll completely understand.

You must also have the skill to write the backend in the first place but again, it’s quite simple.

In a later post, I will introduce you to the bare essentials for interacting with the WordPress DB schema. Not only will this help you write a customised backend but it would probably make you a better plugin developer. If you want to contribute to the WordPress core at some stage in your life, this could also be helpful.

WP Super Cache

Every morning I listen out for the daily traffic reports on Cosmetic Dentistry Guide and for the past few weeks, it has consistently risen. I have two emotions growing inside me simultaneously. On one hand, I’m overwhelmed with pride that so many people are using a website that I’ve made technical contributions to – it’s an unbeatable feeling. There is also anxiety. A very rational and justified anxiety. Questions race through my head “Will these systems hold up?” and “How much can they actually handle?”.

One thing we’ve needed to do to relieve a lot of the stress is to install a caching plugin and it didn’t come without problems. We gave the renown W3 Total Cache a try and we found that posts were disappearing from the blog index. Of course, this is probably not due to the simple page caching but the other things. Having decided the page caching was fine, we switched to WP Super Cache, which has less caching features. Again, it had its issues.

WP Super Cache works on time-based and also WP action-based clearance. In my opinion, I prefer action-based clearance so that a cached page is only updated when it really needs to be updated and the website’s traffic warrants this.

However, since one of our systems relies on a custom backend, this also means that Super Cache won’t notice when we’ve published a new post.

The solution is, obviously, to manually delete those files and this is quite obvious. So we did that and everything seems to working now.

So What’s Next?

In the following weeks, I will be outlining many, many more interesting things from theme development for backend developers, plugin development made easy, interacting with the WordPress database and many more interesting things you may need to do.

I plan to introduce a system I’m building which is especially useful if you have multiple WordPress installations across many different domains and servers and how you can use it to significantly reduce your WordPress maintenance time.

Stay tuned.