WordPress plugins: which strategy for data?

WordPress is a very popular platform, which has a big amount of plugins (around 4,000 plugins). This choice is an advantage, of course, but also a disadvantage: for a given function, we can have dozens of plugins. How to choose the right?
One of my criteria is to see if plugins use non-standard WordPress tables: To keep some consistency, I prefer that the plugin uses only the existing structure and does not create additional tables.
When I develop my own plugins, I follow the same principle. But is this strategy relevant? Is it really good?

This post is an english translation of the post Plugins WordPress: quelle stratégie pour les données?


During plugin development, we have generally three kind of data to handle:

  1. Options,
  2. WordPress objects (posts, pages, categories, tags, …),
  3. New objects or new attributes of existing objects.

The first two cases are obvious: just use the database and functions of WordPress. For the third case, we have two distinct strategies:

  • Using existing tables, what I call Internal solution,
  • Creating new tables, what I call External solution.

I exclude the solution of modifying existing tables. The dangers are obvious: updates of WordPress may crash, or plugins can be systematically affected by these changes.

I am going now to compare the internal and external methods.

Users point of view

Initially, the first solution (internal solution) seemed more suitable, for a main reason, sustainability: In fact, WordPress is more sustainable (I think) than its plugins. Plugins depend on the availability of their(s) author(s). We have so many plugins that are no longer maintained, or not compliant with the latest versions of WordPress. The recent case of All in one SEO pack is quite significant: if the plugin wasn’t popular, its development would be stopped today. In this context it is important to be as independent as possible of plugins, and therefore to choose the plugins that do not manage their own data.

Suppose that, a plugin like NextGen Gallery is no longer maintained. With the next version of WordPress, this plugin will certainly not work properly. NextGen is so complex that it would take weeks to a generous developer to find the faulty elements. And if nobody wants to take over, the users will have all of their posts without galleries!

But the internal solution also has drawbacks: what happens when you uninstall the plugin? I see two possibilities:

  • Information generated by the plugin are no longer used. The database will contain unused data that impact the performances,
  • These information become visible (if they were not with the plugin), and thus make the blog unreadable.

The view of the developer

If we now take the developers point of view, we can give two arguments to choose the external solution: store additional data in standard WordPress tables can impact performances, and what happens if a big changes occurs on this?

I get the first argument (performances), during the development of a plugin that I certainly will publish in the coming weeks. This plugin is based on « custom fields ». When checking that everything is going well at the database level, I have seen how the wp_postmeta table could be « crowded » of various objects such as attachments, custom fields, and other elements. Overall, if you use 1 or 2 fields and an average of 3 attachments per post, you will reach quickly, a table that size, in number of records, will be 6 to 8 times the size of the posts table itself (wp_posts).

Overall, in the WordPress database, a developer does not have a lot of possibilities for storage: we have the wp_postmeta, whose records are connected only to the posts, and we have tables wp_terms, wp_terms_taxonomy and wp_terms_relationships, which give more flexibility in creating objects that are still mainly related to the posts. Potential problems raised above for the wp_postmeta table, are the same for tables wp_term ....

Use specific table (external solution) would limit the impact on performance, by optimizing the database for the function we want to add.

The second argument for an external solution, is also sustainability: a plugin with using specific tables is independent of WordPress changes. In theory these changes are smooth, and it is recommended to query the base through dedicated functions, rather than directly. With these two conditions changes are transparent.
In the real world, we don’t know if, in the future, we won’t have the same changes than those made between versions 1.5 and 2.0, and in many cases the functions provided by WordPress are not enough and require us to access directly to the database.

Internal or External

This small study shows that each method has its advantages and disadvantages. The internal solution is still interesting, but less than initially.

But how to choose? Internal / external, External / internal?

To answer this question, I think that we have to follow the user point of view, by analyzing the plugin impact:

  • Does the blog run properly after deactivation or uninstallation,
  • Are the information handled by the plugin, always accessible, clearly displayed?
  • Is the blog readable?

The right solution is one whose impact is lower.

Taking the case of NextGen Gallery, uninstall the plugin doesn’t lead to a shutdown of the blog, but all posts will display only [ nggallery ...] instead of images expected. The user loose all its galleries.

To limit the impact of the plugin, the author could:

  • Store part of information in the standards table wp_postmeta, and the rest in dedicated tables, so that the standard shortcode [ gallery] continues working after uninstallation,
  • Or provide the PHP code to run the NGG shortcode, in order to allow removal without effect on the public part of the blog. All existing posts would be displayed as before, the user will be free to install another solution for future posts.

The case of this plugin, and the proposed solutions are only examples / illustrations. We can take examples with all plugins that enhance WordPress standard shortcodes or features.

If we look at multilingual plugins, arguments are reversed. Plugins of the Polyglot family, are fully integrated with the WordPress, but are making the blog completely unreadable after uninstallation. Visitors will see all the translations of posts on the same page. Inversely, uninstalling plugins like QTranslate or ZDMultilang, which uses external tables, won’t generate any problem. Translations will just disappear. And with ZDMultilang, these translations are easily accessible in a single table (if the author has the skills to get them).

This approach, allowing plugins removal or migration to another, is the opposite of a « marketing » standard. It corresponds more or less to my idea of what should be a « free » software (I will write something about that in a next post).

Conclusion

I haven’t the definitive answer for the question Should we or should we not create additional tables for my plugin. But I have now, a way to decide case by case: the chosen method must be one that will minimize the consequences of an uninstallation.

Partager cet article