3 Tactics Your WordPress Developer Should Avoid

3 Tactics Your WordPress Developer Should Avoid

 

As an internet marketer, you often want to customise your site to match user expectation. In fact it’s more important than most niches to stand out. Naturally you’ll want to hire somebody to make this happen.

But beware.

As a WordPress developer myself, I have seen the trail of destruction left by those new to the WordPress development game. The problem is not their abilities and mastery over programming and styling but rather their implementation of it when applied to WordPress.

Long story short: they don’t yet understand the rules of WordPress.

Here are 3 common no-nos I’ve seen developers do:

• Make direct changes to a WordPress theme
• Tweak a plugin’s code
• Data entry of information into the themes templates

Okay, so this all sounds innocent. But to reach the desired goal, there is a better way. First let’s see why these are no nos.

Make changes to a WordPress theme

Let’s say your developer downloads a theme from wordpress.org. You decide you overall like the theme and functionality but you want to change the colour from red to blue and you want to add your own copyright information to the footer.

Fair enough right? Of course!

But here’s the problem. The theme maker decides to put out a new update to the theme. So your developer upgrades and suddenly, without warning (but I did warn you), all changes are lost. Bummer!

 

Tweaking a Plugin’s code

Same deal as above. Your developer downloads a plugin from wordpress.org and makes a change to the code so that it does something you want it to do. But when you update the plugin, it’s all lost.

 

Data entry of information such as copyright into the theme’s templates

You ask your developer to place your copyright notice in the footer. What the developer does is type it into the template file. Templates are simply the parts that make up the theme such as header, index, footer.

Then you realise a mistake was made. They spelled your company name wrong. You can’t change this without going into the source code. What a nightmare!

 

So what are the solutions?

 

For theme manipulation

Create a child theme. Child themes inherit the pieces from the parent and only change what you tell them to change. So if you have a header.php in your child theme it will use that. Otherwise it will revert to the parent. The beauty of this is that if the parent is updated, the child will not be affected.

 

For Plugin Manipulation

This can be trickier. Some plugins are not open to extension. You have a few options. Have your developer search for hooks. Do a search for do_action and apply_filters within the scope of the plugin files. These may allow the developer to intercept the code without changing it. Your developer will do this manipulation via another plugin (what I call an adapter plugin).

If the plugin uses classes or an object oriented approach, have your developer see if he can extend these classes. You could also see if you can manipulate global variables the plugin defines.

In other words, if you can touch the plugin without touching it, go for it. Most of the time you’ll have an uphill battle but plugins from wordpress.org must come under the GPLv2 license meaning you can take pieces of their code (free to share/modify) and create your own version.

 

Data entry of information into the themes templates

The easiest approach, combined with the child theme, is to copy the footer from the parent and add a piece of php that allows you to define this area as a widget. If your developer does this, you can change the text anytime via the widget.

 

So there we have it. Three mistakes your developer might make and some workarounds. Being proactive and asking your developer if they are using child themes vs direct manipulation is the best approach. Even better is to specify these no nos in your project management plan.

If your changes suddenly disappear after an update, long after your developer has moved on, you’ll be tearing your hair out so make sure it’s done properly! Please share in the comments below if you’ve had any experiences with loss resulting from poor development work.