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.

For the most part, sending emails using PHP is one of the simplest things one could possibly do, using the mail() function. We usually just use a rudimentary script which can easily be ported around and used where ever it calls for, with minimal amount of hacking.

However, today an issue arose and caused quite some confusion. For some reason, for certain hosting providers, if you try sending an email using an address that doesn’t exist (in the From part of the header), it will discard the whole From: section and use something a lot uglier.

For example:

$header = 'From: Dude <my-non-existent-email@lol.com>'

All of that information above would be simply be ignored and replaced! The solution is to create the email address so that it does exist and it should be perfectly fine. This seems so obvious but you may not know initially, as we didn’t, that the email does actually need to exist.

I’m not sure if this is intentional or accidental on hosting provider’s part and I can see the benefits from an anti-spammer point of view. However, this is easily forgotten since this behaviour seems quite sporadic from host to host. To be honest, there probably are many other hosting providers that do this so when in doubt: create the email address.

PHP is known to be a very ugly language. In fact, PHP makes it almost effortless to write really ugly code. There are certain methodologies and patterns that try to alleviate this problem but even then, it’s still a piece of cake writing horrid code.

If we look at almost any other high level language, there are clean and elegant ways of initialising arrays, assoc. arrays and/or objects. In PHP, there is no support to initialise objects in a clean way. Consider this in JavaScript:

var my_obj = {first_name: 'James', last_name: 'Dunne'}

That will initialise an object, with ‘first_name’ and ‘last_name’ as properties of my_obj. The equivalent in PHP is this:

$my_obj = (object) array('first_name' => 'James', 'last_name' => 'Dunne');

We have to go around all the houses, declare an associative array and then cast it as an object, completely disregarding the ugly way that the array is initialised. I don’t have tell you which one looks cleaner, especially when you have a function that takes a stdClass object as a parameter and you’re using it all over the place. I’d hate to think what phpQuery would look like. Scratch that, PHP isn’t JavaScript (and definitely not as cool). There are always going to be certain awkward points about a language, but PHP has  many of these.

Then there are the massive inconsistencies in style that we have to remember. Was that str_to_lower or strtolower? Is it strreplace or str_replace? Okay, every PHP developer knows these ones by now but it’s besides the point.

PHP has been accumulating extensions over the many years, so this sort of thing is expected. It can’t easily be cleaned up either but it does make PHP look like what it is: a language that has been cobbled together. If you look closely enough, you can notice the transition from plain structured, to procedural to OO, with each phase leaving parts of its old self behind.

But then they added something that’s meant to be really cool…

Closures

And like usual, they butchered the concept. PHP 5.3 has closures and, due to the daft scoping rules, we also have to declare the variables we want to use. Personally, this is a bit stupid and just clutters up the number of keywords in use. However, I believe closures, on the whole, are a great addition. Just like polymorphism,  they can massively help reduce the need for switch statements, but are definitely not limited to just this use-case. In fact, this article should serve to demonstrate the large range of possibilities.

For example:

function my_func($some_var, $my_var)
{
    switch ($some_var)
    {
        case 1:
            some_func($my_var());
        break;

        case 2:
            some_other_func($my_var);
        break;

        case 3:
            omg();
            many($my_var);
            funcs();
        break;
    }
}

This sort of thing is GREAT for simple usage, but it’s very rigid and is a serious pain when you want to do something a very similar many times over. Now, with closures (disregard the danger in this example):

function my_func($some_var, $my_var)
{
    $callbacks = array(
                        function () use ($my_var) { some_func($my_var); },
                        function () use ($my_var) { some_other_func($my_var); },
                        function () use ($my_var)
                        {
                            omg();
                            many($my_var);
                            funcs();
                        }
                      );

    $callbacks[$some_var]();
}

In real, production use, we’d have bounds checking but what’s one more function definition for the obvious power this gives us? Now we have an alternative to a static, rigid control structure that:

• Can be passed around as any other data structure.
• Can be changed on the fly.
• And based on the above statements, can reduce duplication a hell of a lot.

And, in true sales man style: many more!

In object context

Closures are a bit iffy in object context, which stops us using $this-> inside a closure’s body.  However, there is a work around. You would have to assign $this to a local variable and then use that local variable in the closure. For example:

class My_class
{
    private $my_var;

    public function __construct($my_var)
    {
        $this->my_var = $my_var;
    }

    public function get_var()
    {
        return $this->my_var;
    }

    public function my_func()
    {
        $self = $this;

        return function () use ($self)
        {
            return $self->get_var();
        };
    }
}

Even with this solution, you either have to expose certain member variable (breaking your encapsulation), make a getter (like I’ve done above) or you could use magic methods. Again, not really an ideal solution. The good news is that this has been fixed in the next release of PHP.

Cleaning up

For most of this week, I’ve been cleaning up the code on Cosmetic Dentistry Guide and I used closures to handle the bitmasks passed to interface functions. In the beginning, I was simply experimenting with them before I had the chance to really stretch and pull what I could do with the new handler. It turns out they have helped me massively and I’ll definitely be  on the look out for new opportunities to use them in my PHP code and you should too.

As time’s passed, I’ve really begun to appreciate the short and sweet things in life. Short bus rides, instant payments and the time between a Google search and what ever it is I’m looking for.

Naturally, this appreciation has extended to the code I read and write. Short arguments, short methods and short classes. Can’t beat it.

Foot-long Functions

Looking back on other people’s, and certainly my own, old code, I’m disgusted by what I call ‘foot-long functions’. These abominations are like reading chapters in a novel without paragraphs. Ideally, functions should do one thing and one thing only and, usually, when they do more it’s just plain wrong.

“James, why is it so wrong?” you might ask. Well, the list is potentially endless but here are my main gripes:

• Longer functions that handle more than one thing are harder to comprehend, thus harder to maintain.
• Limits the usage of the function.
• Disables my right to move the function to a new home.

You’re probably into web development so you probably also know that serving all your content into one, long block of text wouldn’t do your conversion rate any favours. This concept similarly applies to code.

Functions were introduced, in an imperative sense, as a means to split a program into smaller, commonly-used tasks. You may find you only need to use half a function. Don’t you dare add in that if conditional. Just split it into two functions!

Chances are, during a refactoring session, I may want to move a piece of code to a different class where it rightfully belongs. This process is made a lot smoother and more manageable when I can actually understand the code.

An argument against long function arguments.

I think everybody has been guilty of this in the past before realising their horrendous mistake. Without proper consideration, this kind of thing can really build up on you and it’s never pretty. Here’s why:

• Adding a new argument to a much used function makes any argument before it harder to remove later on.
• It is a sign that there is either:
  1. A lack of structure to the data and/or
  2. Your function is doing far too much

This problem is solved quite easily earlier on by using even the simplest of data structures. You can use arrays, hashmaps and objects. If the abstraction called for it, a parameter object would be beneficial. However, since I keep my functions short, they really only need 1 or 2 basic data types, with the second being an array.

In PHP, the above 3 data structures are available built right in and are used EVERYWHERE. Chances are your configuration file uses hashmaps.

Ever found a majority of those arguments are booleans? Use a bitmask. For example:

function get_listings($is_published, $is_featured, $is_frontpage)

Although that argument list isn’t THAT bad, it can easily be made shorter like so:

function get_listings($options)

Where options has 1 bit per boolean option you wish to pass. You can then use bit-wise operators on these variables to set and get the individual booleans:

$options & 1 == $is_published
$options & 2 == $is_featured
$options & 4 == $is_front_page

And to set them:

$options = $options | 1;
$options = $options | 2;
$options = $options | 4;

As you can see, it’s quite simple to use. The integers you can use are in a 2ⁿ sequence. You probably know why this is but I’ll explain why anyway: bits are represented in binary. In the above example, there are a total of 3 bits being used and we are using each of those 3 bits as 3 booleans independent of each other rather than as a decimal value as a whole. 1 is 001, 2 is 010 and 4 is 100 and that same pattern continues as you progress up the sequence. It’s best to look past the literal value of 5 and think of the number as a series of switches when working with this.

As a quick note, I wouldn’t use literal integers with, I strongly recommend you define constants for this.

What about classes?

I’m beginning to notice that my code, along with a lot of other people’s, is not using the full power of object-oriented programming. I can see that a lot of libraries and applications, written on the CodeIgniter framework, only use classes as a means of organising procedural code. It makes for cleaner PHP but it’s still not quite OOP.

Who cares if you’re using instance variables? That’s just like using static global variables in C, which are limited to a source file in scope.

Who cares if you’re using stdClass? That’s the equivalent of a struct in C.

Who cares if you’re using an MVC framework? Yes, the framework is OO but the code written for it is definitely not.

Maybe CodeIgniter encourages this sort of coding. It’s not very often you see a class defined as a type of object, rather just a group of related methods. Not once in my time working with CodeIgniter have I seen an object being used the way objects were intended to be used.

I’m guessing the above won’t change soon though and shows more my concern at what I’m becoming and what other CodeIgniters are currently doing.