WordPress is the most popular Content Management System.
We love it not only because it’s easy to use, but because it’s easy to build upon as well.
We’ve built over 25 plugins on WordPress, which we own, and several others for our clients.
Our approach to plugin development has matured over the years.
For those starting out with plugin development, the Plugin Handbook should be your coding bible. It teaches you the ‘how’ of building a plugin on WordPress. It contains everything you need to know when coding a plugin.
But of course beyond coding, there’s more.
To make your WordPress plugin user-friendly, bug free, maintainable, extendable, there are a few processes you need to follow!
These include employing suitable design, following coding conventions, optimizing the code, testing it and so on.
Some of you might already be aware of these.
But for those of you who aren’t and are looking to improve your current plugin development process, this article can be a great start. 😀
Few of the basics mentioned here, are present in the plugin developer handbook; the others- we’ve accumulated from our coding experience over the years.
So, without further ado, sit back, turn zen mode on, and read away!
#1 Coding Standards Do Not End at Naming Conventions
I can’t stress enough on the importance of coding standards during plugin development, or development of any code for that matter. The reason for following guidelines is simple, they prevent silly errors from being made and makes code easy to maintain.
Whether you adhere to predefined standards, or have company specific guidelines here are a few conventions you need to follow:
Naming Conventions
Naming conventions are aimed to make the code readable, maintainable and secure. They are needed to prevent clashes with other plugins. You need to add a prefix for all functions, classes, file names and namespaces to ensure that compatibility issues don’t creep up.
Folder Structure
Separating out JS, CSS, admin files, media, should be part of your design process. When working on a project remember to separate out these files even if it is a one page solution.
Formatting Code
Formatting your code should be a matter of habit.
If not, there are editors which help.
Formatting your code makes it readable. In attempt to minify JS, CSS and HTML files, we tend to remove the white spaces and code comments. While, this might be needed for large files, try to keep it to a minimum.
Data Validation
Always validate data that’s being received or sent. Begin by checking the format or casting it to the right data type. Sanitize the values based on the type of data being output or input. Based on your scenario, you could also check data being input against trusted values.
At WisdmLabs, we follow PSR-2 coding standards.
Remember, following coding conventions should be the way you code and not an additional step.
#2 Make Code Modular
Modular programming is the process of subdividing a computer program into separate sub-programs.
To facilitate the development of large-scale applications, object oriented programming is preferred. It makes the software modular by decomposing it into smaller pieces.
It makes the code maintainable, since testing changes and fixes can be limited to a module and do not need to affect the entire system.
#2.1 Use Design Patterns (if Needed)
Image Source: Pinterest
Design patterns are cool!
They truly are.
They make the development process simple, and make your code. Based on the problem at hand, you need to design a pattern that fits. For example abstract factory, observer, template method, MVC, are popularly employed.
Now, I agree not all plugins might need you to implement a design pattern. But plugins with large amounts of code need a proper design in place.
#3 Design Scalable Code
Your plugin’s going to grow.
The functionality is going to improve, the user base will increase.
When architecting a plugin you have to plan the code for now, and for the features you will be implementing in the future.
Optimize Your Database Queries
Database queries are expensive.
When performing an operation that retrieves data from the database, try to get as much information as possible using minimum number of queries.
The more optimized the queries and database tables, the more scalable is your application, because it can handle a lot of data. You can have your own file structure to maintain your plugin’s files. But the communication with the database should always be smooth and optimized… Depending on how scalable your application can be, you should decide whether to go with a standalone plugin or with an add-on architecture.
– Sumit Pore, on architecting a plugin. (Read the entire interview here)
Build a Scalable Database Architecture
Say your plugin needs to save values in the database. In such a scenario, there’s always the question of whether to use WordPress tables or to create your own.
In case a few options have to be saved, or meta information needs to be saved, you could consider using WordPress tables.
But, if multiple interlinked values need to be saved, then you should consider building your own table (or tables).
Limit the Use of Expensive Operations
Similar to database queries several other operations are expensive and can affect the performance of your plugin, and in effect the website it will be added to.
For example, when you need to connect to remote servers, store large data, load large files. In this case, optimize the use of these operations to improve the system’s overall performance.
#4 There is no such thing as ‘Too Secure’ Code
We all know this. Security is a serious concern.
When building your WordPress plugin make sure you take care of security measures. Some of these are:
- Check for user capabilities when displaying/saving settings
- Using nonce verification for form submissions
- Sanitizing inputs before executing database queries
- Properly escaping outputs to prevent cross-site scripting (XSS) attacks
- Preventing direct file access to plugin files by checking the existence of ABSPATH constant
- Preventing direct listing of files in your plugin’s directory, by adding a blank ‘index.php’ file in the main plugin file (and under every sub-directory)
Always consider security factors when writing database queries. For example, you have to ensure that your SQL queries are injection free… Use nonce for form submissions to avoid cross site scripting… All inputs should be sanitized and the output should be secured by escaping user data.
– Praveen Chauhan, when asked about coding practices (here’s Praveen’s complete interview)
#5 No Code is 100% Bug Free
Image Source: Google
Testing the code is as important as building it.
Honestly, there’s no point toiling for hundreds of hours, to build a plugin that’s buggy. It’s just going to hurt your users and affect your brand.
For simple functionality, manual or user testing can suffice.
A complex plugin demands more. You could add unit-testing, stress testing, integration testing, acceptance testing and so on, to your process.
Simple checks include:
- Checking for warnings and errors, in debug mode (you could use a plugin like Debug Bar to log information)
- Use plugins such as Query Monitor and P3 to test slow queries/HTTP requests and plugin performance
#5.1 Code Reviews Help
See the thing about code reviews is that you get to see your code through the mind of a fellow developer. Apart from identifying bugs, new ideas, optimization techniques might spring up.
Do add code reviews to your development process, if you have the liberty to do so.
#6 Make the Code Contribution Friendly
Now, most of us build code keeping the end user in mind.
But developers are going to work with your plugin too, and there is a possibility they might want to build upon it.
Encourage contribution by making your code extensible- add custom actions and filters in your plugin’s code.
Having the needed hooks in place makes it easy for fellow developers to extend your code, and makes it simple for you to customize the functionality for certain users or build add-ons.
All of this without touching the core!
Think about the times when you’ve worked with other plugins and found it easier to customize when there was an appropriate hook in place.
Custom hooks = Extensible code = Good development 🙂
#6.1 Make the Plugin Multisite & Localization Ready
To grow your user base, make sure you follow simple coding techniques to make your plugin’s code multisite compatible (well, at least error free when installed on multisite), and localization ready.
#7 Maintainability trumps Optimization
Plugin maintenance is not just about bug fixes, it’s about providing updates, and optimizing your code.
Optimization is good. It is. I support it.
But sometimes developers tend to go overboard with code optimization.
Remember, the mantra is, optimize the code, don’t complicate it.
If I were in a situation where I had to choose between writing code that’s maintainable or optimizing it, I’d choose the prior.
This is because, we work in a team. When you’re part of a team, more than one person might be working on the plugin. You don’t want to sit and explain the code to different people all the time.
You might not remember code you had written a few months ago.
Comment all the things – well commented code is happy code.
– Hugh Lashbrooke, on must-follow coding practices
#7.1 Handling Major Updates
Recently, we completely re-wrote the entire Edwiser Bridge plugin and its extensions.
When we wanted to roll-out the update, we realized we needed to add an ‘update warning notification’ to existing users, just to be on the safer side.
But then again, this could only be possible if we had provided support to display a warning notification in the current version of the plugin.
We hadn’t! 😮
Lesson learnt- Add support for Update Notices! (## Upgrade Notice ## in readme files)
The next task was about safely strip out legacy code.
Marking options/code depreciated is one way of ensuring that users/developers move to new settings/hooks. But there isn’t a thumb rule on when to completely get rid of code that’s no longer being supported.
You need to make sure that the least number of users are affected when code is re-factored.
#8 Documentation. Documentation. Documentation.
The main thing is to document your code, both for your benefit and the benefit of other developers who look at your code. A year from now you won’t remember what a bit of code you wrote was supposed to do, but if it’s nicely documented, your future self will thank you!
– Carrie Dils, on coding practices.
Your plugin’s not ready until you’ve documented it.
And trust me, no amount of documentation is enough. So go all out; create a user guide, add FAQs, create videos, help your users every way you can.
But at the least, create a readme.txt file.
#9 Using Intelligence to Improve Options
Well, you can always take things a step further, and improve your plugin with data you receive from users.
Learn how users interact with the settings, which options are not used; send out feedback forms to gain intelligence on features users are looking forward too and more 🙂
The Secret Ingredients for a Great Plugin
- A user interface that fits in naturally with the WordPress dashboard
- An experience that is intuitive and takes little to learn
- Proper sanitization, validation, and security of data that it manages
- Properly sets itself up and cleans up after itself upon installation and uninstallation
- Solves a problem that the end-user is experiencing with their WordPress-based site.
– Tom McFarlin, on ingredients for a great plugin.
Remember, this article is not a be all and end all guide for the plugin development process. It’s aimed towards helping you refine your development process.
So the benefit of readers, you are invited to join me and contribute to this list 🙂
Please note, some of the links in this blog post might be affiliate links. This means if you go on to purchase a product using such a link, we receive a small commission (at no additional cost to you). This helps us support the blog and produce free content. We only recommend products we work with or love. Thank you for your support!
Leave a Reply