Should we create one large plugin or lots of small ones?

Question

We are looking at a project where we have lots of plugins.

I was thinking if it would be better to merge them into one, preventing plugin conflicts, or keep lots of small ones, which makes maintenance easier?

Is there good practice for this and do people have any thoughts on this?

Answer 1

Good question.

1. Core control processing about plugin is heavy. System performance deteriorates according to the number of plugins. Therefore, when emphasizing performance, plugins should be fewer. Naturally, system with no plugins is fastest.

2. Override mechanism of Q2A is daisy chain system. If each feature overrides same core function, we can minimize conflict problems by aggregating features in one plugin. When all override functions call *_base (), it might work correctly. However, if an override function on the way does not call *_base (), subsequent override functions will not be processed. This is common conflict problem of override feature.

http://docs.question2answer.org/plugins/overrides/

3. If core has a plugin switch feature (to turn on/off plugins), maintenance will be easy if you divide the feature into small parts. If there is no switch, you will need to make switch (Enable/Disable toggle) for each small feature in your plugin.

http://www.powerqa.org/documents/core/new-features/plugin-switch/

These are my opinion based on my development experience.

Comments

Good question to which you've provided a very good answer

---

We started work on a plugin switch for 1.8 but hit a lot of problems.

@sama55 how are you storing which plugins are enabled/disabled? In the database? Does it work with database function overrides?

---

@Scott, How about, have a file on the server which lists disabled plugins, and ensure it is editable by the web directory. That file can be read and modified without any access to the database.

Otherwise, a special connection to the database is required to be made, without all of the usual error handling stuff that can be affected by plugins.  This can be done during initialization, after qa_initialize_constants_2().