This interview is certainly a special one. Today, I had the privilege to interview an expert WordPress developer, an open source enthusiast, a dedicated employee and truly a humble guy- Sumit Pore, a senior developer at WisdmLabs and my dear friend.
At WisdmLabs, Sumit is the ‘go-to’ guy for any WordPress related issues, PHP or JS related issues or any networking related problems- basically when you have a doubt- Sumit is the guy you go-to. And he’ll always hear you out and accommodate your queries, no matter how silly they are or how busy he may be.
Sumit plays a strategic role in the company’s hiring and training process, is the principal architect of our plugins, and regularly contributes to the WisdmLabs’ blog.
It wouldn’t be wrong to say that Sumit’s views on development are in-line with the companies views, and today he shares a few of them with us.
Let’s take a look.
What factors do you take into account when architecting a plugin? Is there any difference when building add-on plugins as opposed to standalone ones?
The primary factors I think about while architecting solutions are- design of the database, and user-friendliness of the interface. I believe these two factors play a vital role in the long run.
The speed of your plugins or applications are primarily based on two things- coding practices followed and the database queries being fired on each refresh. 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.
User friendly applications or games always work. If applications you build can not be understood by your users, you will end up spending a lot of time in support, and your sales will be affected as well.
Depending on how scalable your application can be, you should decide whether to go with a standalone plugin or with an add-on architecture. To give you an example, if your plugin is going to support Payment Gateways, then going with an add-on architecture is a good idea, because not every client is going to use same payment gateway. If users receive code which allows them to use only desired payment gateways, they’ll be happy. Because, in this case they will have less things to setup in your plugin. The overall footprinting of your code will be less as well which would make your plugin work faster. On the other hand, if you think all of your plugin’s features would be used by every user, then creating a standalone plugin is a good idea. I always prefer code with minimalist footprint as it allows me to manage the code easily.
With several plugins being identified with vulnerabilities, how do you ensure that your WordPress website is secure?
A rule of thumb to keep a WordPress website secure is- install only the required plugins and themes and update the WordPress core, your plugins and themes regularly.
I always suggest the following things to clients:
- Remove a user with the username ‘admin’
- Remove a user with id 1
- Change the login url from wp-admin to something else
- Always keep strong passwords and change them often
- Change the database prefix to something other than wp_
- Install Sucuri plugin and subscribe for Sucuri Firewall
- Do not allow automatic posting of comments
- Put 644 permissions on files and 755 on folders
Install SSL certificate on the site and enable it for the whole site if possible. It keeps the communication encrypted.
For development sites, we have put up a basic authentication on the server which blocks bots and unwanted user traffic.
What security measures should WordPress developers undertake when building themes or plugins?
- First and foremost, all the forms included in plugins and themes MUST have nonce verification.
- Before inserting anything in the database, values MUST be sanitized and escaped.
- After fetching values from the database and before using them, values should be escaped.
- Minimize the usage of global variables
- Check the existence of ABSPATH constant in all files right at the beginning so that direct execution of all files will be prevented.
- Every directory in the plugin should contain a blank index.php file. This will prevent listing of all files in the directory if someone visits the directory via a URL.
- If your plugin allows the upload of files, prevent uploads of PHP files as far as possible.
- Do server side as well as client side validations.
- If your plugins or themes provide a functionality on front-end which allow changes to be made to the database, then test it multiple times. Test that functionality with gibberish inputs and make sure that it does not make any unwanted changes in the database in any case.
- It is also necessary to make sure that your plugin and themes are not throwing any errors/warnings when WP_DEBUG is enabled.
List must-follow coding practices you teach junior developers.
These are a few must-follow practices I always encourage junior developers to follow:
- Always access the database using $wpdb variable and to not hard-code database names
- Use readable variable names, and avoid the usage of extract() function
- Before beginning with the development process, add the below lines in wp-config.php
// Enable WP_DEBUG mode define('WP_DEBUG', true); // Enable Debug logging to the /wp-content/debug.log file define('WP_DEBUG_LOG', true); // The SAVEQUERIES definition saves the database queries to an array. This array can be displayed to help analyze the queries. define('SAVEQUERIES', true);
- Add the below plugins on your staging site before beginning with the development and check the output provided by them regularly:
- Debug Bar
- Debug Bar Console
- Query Monitor
- Log Deprecated Notices
- WordPress Reset (Once development is done, Reset your WordPress installation using this plugin and test it again)
- Before accessing any array element including $_GET or $_POST, perform isset on that element
- Always add CSS and JS using wp_enqueue_scripts and wp_enqueue_styles
- Dig into WordPress (or plugins and themes) code until you find the desired hook or filter to complete a task instead of hacking it.
- If you are writing your own plugin/theme, then make sure that you write the code in such a way that APIgen of PHPDoc can create readable documentation of your code.
- And most importantly commit code in SVN regularly!
How important is it for developers to be updated with the latest developments in WordPress?
If you are developing a WordPress based product for a community, it is very important to follow the way WordPress is being developed. It gives you an insight into new functionality being developed, teaches you development best practices and the precautions which should be taken care of while developing.
I would suggest WordPress developers to subscribe to blogs of known personalities in WordPress community and follow their blog regularly. You’ll get to learn a lot. To give you an example, recently Yoast published an update for his plugins. The issue was in the implementation of add_query_arg and remove_query_arg functions. It was notified to the WordPress guys and then they made appropriate changes in their documentation. If you do not follow WordPress development or blogs of known people, you won’t be aware of such issues.
What are your views on the WordPress REST API and its impact on the future of WordPress development?
WordPress REST API is going to open the door for many opportunities. It is going to make it easier for developers to create scalable and portable applications. Developing an IOS app or android app will become simpler. If you are an entrepreneur and want to build SaaS applications, you can have a single WordPress website to host multiple applications. The time to develop an API for such applications will be reduced to great extent.
To give you a simple example, let’s suppose you have a restaurant site, with a custom post type food and add all available menu items added in the custom post type. Now, using the REST API, you can create a native app which could list all available items and add all incoming orders as comments besides the respective item. So, when an end user clicks the order button for an item, an invisible comment will be posted on that item from that native application via the REST API and restaurant will be notified about it.
If you could change one aspect about the WordPress CMS, what would it be? And why?
From a developer’s point of view, WordPress should have an inbuilt profiling system which should help us find bottlenecks in the system, or there should be a way to display the source file of the content being shown on the front-end. A search functionality in the dashboard which would instantly search for any settings, would be great too.
From a user’s point of view, I would like to see an option for live edit on the front-end.
Sumit, thank-you for taking the time out of your busy schedule and sharing this valuable piece of information with us. We really appreciate it.
And just so you know, we’ll not stop bugging you with our silly questions. We do that, because we trust you always have the right answers. 🙂