Before deploying a plugin in the official WordPress plugins library, you have to make some essential points from this list. Next, your plugin is meticulously checked by people from WordPress Foundation. After approval, you get access to the SVN repository, where you can put the plugin’s source files. During pushing the plugin files there, your code is also auto verifying by Subversion.
However, such an extensive process doesn’t guarantee that everything will work properly. It is good practice to do some basic tests after public our plugin for the plugin library.
It’s never too many tests
The important thing is always solid and reliable tests before your plugin publication. You should check how it works on older versions of WP – minimum 1-2 MINOR versions before. A good practice is also to test plugin on older PHP versions (than your defined in readme.txrt minimal version).
If you need testing at the end, you’re doing it wrong”, would you prefer a Boeing, or are you going Air Icarus?
~ Michael Bolton
Check basic plugin data
Check if all basic data from readme.txt file are visible correctly in the WordPress plugins library, for example, version, description, tags, etc. Remember that these data are important that our product reaches as many people as possible.
Install plugin directly from the WP
Even if you tested the plug well before deployment, you must take the test on the installed plugin directly from the WordPress plugins library. You can do this by the WP admin panel.
For every WordPress update, you should make tests on the new system version and change the “tested up to” information. This is important because if you don’t do it for a long time, the plugin will have a visible deprecation note.
In the same situation if your plugin is integrated with any other plugins – then you have to make tests and updates also for every basic plugin update.
It’s very important, especially if your plugin uses filters, actions, or other advanced WP functions.
Be active on the support forum
All plugins on wordpress.org have a forum where users can report a bug, ask a question or share their thoughts. Plugin developer should follow the forum and respond quickly to threads.
When you are active and you help users, then you increase satisfaction and better ratings for the plugin.
Additionally, very often users find a bug in your code. It’s very helpful because people use different server configurations, versions of WordPress, and plugins. It’s very strange to test your plugin independently on various combinations of environments
A lot of plugin authors don’t pay attention to the support forum – that’s a big mistake.
English is the most important and universal language in The World. Most often this one language is enough for every plugin.
Hover good practice is preparing the translations for some of the most popular languages – especially when the target group of your plugin is people from some specific country. If for example, the plugin is to be used for implementation payments in the Czech “Komerční banka”, it’s advisable that in addition to English, the plugin also has a Czech translation.
WordPress provides a translating service. By using it, every user can add translations for your plugin or theme.
The more languages your plugin has, the more people your plugin will reach – especially non-English speaking people.
This point isn’t necessary, but it has two main advantages. Firstly, of course, the documentation will be helpful for users.
Secondly, creating the documentation allows you to find potential bugs in your code – this is an opportunity for additional testing. If your plugin doesn’t have a lot of features – then the simple documentation in the readme file will be enough. Otherwise, you can use any advanced tools (like for example Docsify).