So you decided to build a WordPress website for your business. Now is time for business evaluation
WordPress is one of the most versatile tools for web development. It allows you to make incredible websites with ease, saving time, money and server resources. But, is it good for your specific needs? Have you ever thought about how your website will be ten years from now or how many visitors it will have?
If you didn’t, you should.
It is very likely that you’ll have to do some maintenance work in your website once in a while, and that should never happen in the production environment, aka your live site. I mean, you could, so long you accept the risk involved in reckless behavior. The best way is to try it all out in a development environment first, to assure your business will be fine when changes are implemented.
And there you go clone your site, but you noticed something strange: there are 100GB worth of files which your WordPress installation rely on, most of them being media file from your ten years of website use, making the cloning process very, very painful at least.
This is a very common issue when dealing with long term marketplaces and news websites. Because the nature of their business, this kinds of system generally needs constant updates, scaling database and overall storage use at impressive rates.
Avoiding that involves adopting an array of good practices, which I’ll be talking about bellow.
Scale evaluation
What kind of business you or your client intend to run on the web? Is it a e-commerce, news website, personal blog, professional or presentational? Depending on the answer, you can build a work plan that will fit you and the client in the short and long run.
E-commerce, news sites and personal blogs needs constant updates and image uploading, which will turn the monolith structure of WordPress a real nightmare in a few years. If that is the nature of the business and if the client intends to make heavy use of it, consider breaking the monolith in smaller parts.
And what is considered “heavy use”? Well, I have no scientific base for that, but for me is more than two posts a week. Anything higher than that justifies system detachment, dividing all the work between various system and services. Serving your images from a 3rd party service and your static assets through CDN should do the trick.
But keep in mind, systems scale fast, demanding more server resources. Only detaching the system may not be enough, even more if your website have to handle heavy user activity that generates writing operations in your database.
Do your best interviewing the client about his model of business, aspirations and marketing methods. Think of how many users, pages and overall assets it will have in five or ten years. How much power the server will need in terms of RAM, database capacity, requests handling and so on.
Take notes of everything you can, research needed plugins and build a solid development plan before start coding. That is a important note, because coding without a plan leads to refactoring, rebuilding and even planing everything all over again. A fool works twice! Don’t be one.
Police your client: set user roles
Can you picture your client installing and testing a random plugin on the production environment? Because he will, if you let him.
Let’s talk a little about user roles, which are set on user registration. Not only WordPress, but any given system that handles numerous users must implement user roles for defining the privileges and access policies for users. You may see this as a hierarchical system where the administrator have all privileges and reigns over all, being the the sole role capable of making system changes, as implementing new functionalities, changing the permalinks structure, and so on. Other roles, as editor, author and subscriber, for instance, will have access to limited functionalities – and your client’s role also should, unless he/she has some solid knowledge about WordPress.
The “editor” role is a good starting point for your client, but don’t feel chained to it. You can create custom roles through PHP or, most commonly and recommended, the Advanced Custom Fields plugin. ACF makes the process easy and is one of the most used plugins of all WordPress repository for a reason. Use it to create and define your client’s privileges according to his/hers needs.
Be one step ahead of the client
Every developer should be some steps ahead of the users of his/hers systems. Take the image storage matter, for instance. The developer will not worry that much at the beginning because he is sure that it will take the user at least half a decade for growing a meaningful image volume on the server side.
This silly developer thinks the user will deal with images like he/she does, optimizing all that is possible to optimize. And then the user starts uploading 35MB files, divided in four dimensions by the wp-core, resulting in about 70MB uploaded with one file. If the user keeps such an horrendous behavior, not only the installation will be pornographically huge, the website’s performance will drop dramatically, resulting in bad indexing in search engines, which will impact in the client’s overall traffic by the end of the day. Oh! And don’t forget about cloning the thing to development. Yikes!
For our luck, the solution for this problem is quite simple. As long you have made a good system scaling evaluation as mentioned before, you already know that image files should live elsewhere, and that the user PROBABLY DOES NOT KNOW A THING ABOUT IMAGE HANDLING.
So, if that is the case, make sure to integrate WordPress with 3rd party image hosting services, like Dropbox, AWS S3, and many others. There are several plugins that will help you with the integration process, but the go to option still is WP Offload Media. Even tough it is not perfect, it works very nice in the lite version if you still in development stage. Migrating images is possible, but only in the premium version, which offers various plans and a nice 60 days refund policy.
And that is ONE user generated problem solved, and it is not the most troublesome. Pay close attention about how the client uses the system and keep him in the appropriate role. Take note of the most commonly mistakes that a user can make and plan ahead of it. If the client intends to use various embeds, make sure that is done in a way that won’t impact performance that much – 3rd party requests tends to lower your score on webpage test tools.
Always be ahead of him/her and of his/hers needs. Study the possibility of making minimal interventions to attend the client, be it avoiding plugins for silly tasks as queuing scripts or for creating custom frontend features. Consider if the client’s request will introduce new database operations or complex programming involving too much javascript and, mostly important, if the feature will return the desired result.
With a little elbow grease you can control system scaling and be ahead of the client all the time.
Test everything before deploying
If you feel tempted to try a new miraculous plugin that will solve all your life problems, do it in development or staging environments. Certain things should be done only behind closed doors, have some decency, please.
Users experiencing inconsistencies while browsing your website is only one of the problems generated by this behavior. You should be aware that lots of plugins doesn’t remove their data from your system upon deactivation or exclusion, leaving you with a messy and polluted database. That can cause complete random problems for you in the future if you use the production environment for testing.
So, make sure to try it all on development first, then on staging and, after approved, in production. That way you’ll keep your database tight, efficient and easier do handle – I can’t stress enough how important this is, because WordPress is basically your database and vice-versa.
In case you have used a plugin for a long time and now want to remove it from your site, make sure to check if all data is wiped out.
You may understand all those issues better when you face a longstanding wp website containing all the problems cited above. I hope you don’t, but if you do, come back to this post to have some minor guidance.
Wrapping up
All of what was said in here are basic software development knowledge for most developers. But among WordPress developers it may not be the case. WordPress is a low code solution based on user interaction with the wp-admin panel, making it possible to work with the CMS without all that knowledge, justifying most of the WP popularity. For those people, specially beginners, this is not so obvious.
So, for the ones who these tips applies, just remember: build a solid plan, beware of user behavior and police him as needed, and finally, only deploy when you are sure that your work won’t result in a critical error.