For Developers of WordPress plug-ins and templates. 
WordPress Developers Manifest
Problems encountered by our team are often caused by third-party plug-ins or pure coded templates for WordPress on users sites. Thereby all developers, who are somehow connected with the development for WordPress environment – plug-ins creators or templates coders – we call you to ad here a few simple rules in your work that will help to improve the overall picture of the development for WordPress. Here they are:
- Do not connect external jquery libraries. Very often in the source code of the site we can see something like:
And here are a few problems. Firstly – the version of library here can be any, and differs from the version that is supported by WordPress – and hence other plug-ins. Secondly, there is no
jQuery.noConflict()
If you use jquery in your work – connect the library solely from within:
wp_enqueue_script ('jquery');Moreover, in the arsenal of WordPress there are already quite a lot of libraries. And before connecting required library from outside of WordPress – it is better to check, is there anything you need inside WordPress? We try to do this all the time, for example – we use “native” libraries like jquery-ui-dialog, jquery-ui-slider, etc.
- Do not connect javascript and / or css styles wherever your plugin is not used. This applies to both the admin part and the output to the frontend. Firstly, you overload user’s pages by including there unnecessary scripts. For example, your template supports the output of a Google map on the contacts page – and that’s good. But why do you need to connect Google’s scripts to all pages in general? Connect them only for the page where the output of google maps is used – the site will work faster and users will only say “
- Thank you” for it. Secondly, you lead to undesirable conflicts with other plug-ins / templates. For example, you are using modified jquery ui styles in admin area, but this is a popular library, and it can be used in the admin area parts not only by you, but also by other developers. As a result – if you include such styles / scripts everywhere – other plugins in the admin area will stop working correctly.
- If you use modified css / javascript libraries – make them a unique handle for the wp_enqueue_script and wp_enqueue_style, and enclose the content in the special parent shell html tag. For example, you modified Bootstrap styles completely for yourself – removing half of all it’s styles, and redefining other part. But you still call
wp_enqueue_style ('bootstrap', your path)All other developers, who also want to use this popular library, will see only your modified styles, and as a consequence – their code will not work correctly (i.e. “nothing will work on the user’s site”). It is better to connect it as
wp_enqueue_style ('custom.modified, bootstrap', your path)and the contents of the modified styles – enclose in the special shell – like the parent
– and in your modified css all styles of this library will only be applied for child elements of #bsCustomContent – so you will be sure that you will not damage anything else on this site.
- If you connect popular PHP libraries – make sure that the library was not connected before your script. For example, the Mobile_Detect library is frequently used to determine the user’s device on the server side – and many developers, without hesitation, connect it as:
require_once ('Mobile_Detect.php');At the same time the same library could have already been connected earlier with another plug-in or template. Therefore, before connecting external libraries, make sure that it was not connected before:
If (!class_exists ('Mobile_Detect')) require_once ('Mobile_Detect.php');Again, it is best to connect any libraries only when they are actually used (same as p.2 – but for PHP). For example, in the code it is often possible to see the connection of all libraries at once – when loading the plug-in, but their use in the future in the plug-in is determined by a number of conditions – and it is not always necessary. It is best to use the Lazy Load pattern to connect your libraries: you will not overload the server memory, and make your application faster and more stable.
- Make the names of all global variables (if such is used by your code), function names, classes and Ajax events unique. Remember – if you made a class with the name for example ‘user’, ‘database’, ’email’ – there is a high probability that you will have conflicts with another plugin – which will have the same name – simply because it is very simple and popular. Try to use unique names for your events – just in the code, and for Ajax events. For example, Ajax events with the name “contact” – will most likely be used not only by you. In our plugins we track not only the name of the Ajax event, but also the module name – in which this event should work, plus we also pass the unique code of our plug-in – which helps us unambiguously determine – that the event should be executed only by our plug-in. Do not override global variables of WordPress – you can disrupt the work of other plug-ins or a whole site. For example, as for JavaScript – on the frontend there is a global variable ajaxurl – which contains URLs for Ajax requests. We had cases when the third-party plug-in just redefined this variable – and, of course, all Ajax requests just stopped working for this reason. Do not do this.
- Test your applications. Enable Debug mode – and test. Pay attention to all warnings and notice in PHP, test everything you do – with an open debug console in the browser – that would prevent errors in JavaScript. Often we see a situation when another plug-in causes a client-side JavaScript error, and as a result, execution of all scripts (including ours) stops working completely, and we have to look for an error in other people’s plug-ins or templates.
And lastly – remember that WordPress is a huge platform with a huge number of plug-ins and templates for it. Write your code so that it does not interfere with other developers, respect each other. Contact Form Plugin – Lifetime
