If you have developed a plugin or are planning to develop a plugin I think you should consider the following situation.
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?
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
- 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.