If you have developed a plugin or are planning to develop a plugin I think you should consider the following situation.
When you are developing your plugin you usually need PHP classes, functions, global variables (hopefully not... it is 2014!), as well as CSS classes and identifiers, HTML name and id attributes or even JavaScript functions and variables. It is almost impossible to write a useful plugin that doesn't need at least one of them. And things usually work the way they should. Particularly, if you are using a clean (without any plugins) core in the development process.
As time goes by, you have your big-button CSS class, your nice-button id attribute, your PHP function in the qa-plugin.php file named userid_to_userhandle, your element JavaScript variable and your toggle JavaScript function. And, of course, everything works. So you release your plugin... not knowing it is a matter of time for things to stop working.
Things work until any other developer (or maybe yourself) write a different plugin that uses the big-button CSS class, the nice-button id attribute, etc. If 2 plugins use the same identifier and happen to be in the same scope then that only means things will break. So how can this issue be prevented?
Without asking core developers to do magic in the core, we can solve this by just communicating and being proactive. This issue can be easily addressed by prefixing each element that is part of a shared scope with a string. In order for that string to work as PHP class names, PHP functions, PHP varaibles, CSS class names, CSS identifiers, HTML name attribute values, HTML id attribute values, JavaScript function names and JavaScript variable names they can all contain letters, numbers and underscores (_) but should all start with a letter. There are also other identifiers that can be added to the list such as the plugin folder name and the title of your plugin settings stored in the ^options table.
I thought on the following guideliness to be applied. Prefixes should:
- Be unique and not re-used between different plugins
- Be applied to all shared scope elements including, but not limited, to the aforementioned ones
- Be at least 4 characters long
- Not use underscores
- Be separated from the rest of the element identifier by an underscore
- Be case-insensitive
This way these could be some valid names for elements prefixed with the myplugin prefix:
- PHP class: MYPLUGIN_User
- PHP function: myplugin_show_profile()
- CSS class: .myplugin_big_button
- CSS id: #myplugin_save_button
- HTML name attribute: myplugin_user_input
- HTML id attribute: myplugin_terms_agreed_checkbox
- JavaScript function: myplugin_toggleVisibility(e)
- JavaScript variable: myplugin_countryArray
- Table name: myplugin_countryArray
- Plugin folder (note it could only be the identifier itself): myplugin
- Title of element in ^options table: myplugin_enable_user_feature
An approach that is actually included in the previous guideliness is adding a developer prefix, so to speak. So you could have plugins with the prefix MyDevId and, on your own, avoid plugin duplication by adding the second level of identification with the plugin id MyPluginId. This would result in elements identified by MyDevId_MyPluginId_identifier.
I think getting to a certain degree of agreement is needed and, as time goes by, this is becoming more necessary. Please, let me know your thoughts on this.
Now, in order to be able to satisfy guideline #1 it is needed to let others know what plugin ids you have used. Even if you don't want to follow this convention at least refer to this list to know which plugin prefixes not to use if you want to make a fully compatible plugin.
Note that while writing this, I've decided to use the developer prefix approach in the future. I'm planning to use the prefix pupi.
If you like the idea, feel free to add yours in order to centralize future lookups.
