Loaded question I know but I can't find a real difinitive answer.
I have some 'extensions' I need to make (or have made), such as importing users, family connections, etc.
I have successfully made both a plugin and integrated my own script into the modcp so this isn't a how-do-I. It's a which-should-I.
I've read a number of posts in the past that suggest turning off plugins when having performance issues, and several that talk about how many hooks are used and others that say people complain about performance when they have 100's of plugins.
So does this mean that they should be avoided whenever possible? What is a good example of when to make a plugin over a system modification/addition?
Plugins just seem so much easier to use for the administrators and owners who aren't developers.
Sorry if this has been covered. If so, just point me to the topic and I'll disappear
Thanks.
Plugins essentially are system modifications/additions. When you add hundreds of them, especially shoutboxes, you are going to hit some bumps. Plugins are better than core file edits because when you upgrade, your changes are gone.
(2012-08-17, 08:57 PM)Paul H. Wrote: [ -> ]when you upgrade, your changes are gone.
That was also a concern of mine.
Thank you, that was very clear and difinitive.
I actually prefer no plugins when the solution to the problem is simple.
For example, plugins that add a UID to the profile page or insert Analytics or VigLink code in the footer, or even a plugin that inserts bad words into the filter. These can all be accomplished directly with template or DB edits.
Now, some plugins don't manipulate data or there are no hooks for, etc. These I prefer to use the Patches plugin and make core edits with that. Since the changes are tracked, upgrading MyBB versions is simple and there is no overhead for the plugins that would otherwise be present.
Data manipulation and the output of dynmaic data almost always needs to be a plugin. Inserting ads, tweaking output based on UID/GID, etc are okay. Just be smart and minimize performance impact by skipping the code if it does not apply to the page the user is on in case of using global hooks (global_start, global_end, pre_output_page, etc)
(2012-08-17, 09:06 PM)pavemen Wrote: [ -> ]Patches plugin
I'll have to check that plugin out. Although on the face of it, you're using a plugin to not use a plugin :p That's just my sense of humor, sorry. Not a dig by any means
(2012-08-17, 09:06 PM)pavemen Wrote: [ -> ]Data manipulation and the output of dynmaic data almost always needs to be a plugin.
Why is that? It makes sense in my mind, but I would like to hear your reasoning to re-affirm mine.
(2012-08-17, 09:06 PM)pavemen Wrote: [ -> ]Inserting ads, tweaking output based on UID/GID, etc are okay. Just be smart and minimize performance impact by skipping the code if it does not apply to the page the user is on in case of using global hooks (global_start, global_end, pre_output_page, etc)
A good point.
(2012-08-17, 09:13 PM)TOA Wrote: [ -> ] (2012-08-17, 09:06 PM)pavemen Wrote: [ -> ]Patches plugin
I'll have to check that plugin out. Although on the face of it, you're using a plugin to not use a plugin :p That's just my sense of humor, sorry. Not a dig by any means
Patches plugin only has code that runs while in the ACP, there is no real overhead in the main forum space
(2012-08-17, 09:13 PM)TOA Wrote: [ -> ] (2012-08-17, 09:06 PM)pavemen Wrote: [ -> ]Data manipulation and the output of dynmaic data almost always needs to be a plugin.
Why is that? It makes sense in my mind, but I would like to hear your reasoning to re-affirm mine.
If the data is dynamic then you can't always make a simple core edit to handle the manipulation of it. There can also be new templates or template modifications, DB queries, etc, that need to be made based on the data currently being processed.
I personally limit my Patches edits to a few lines only per change. If it is much larger, then I use a plugin or go without.
(2012-08-17, 09:13 PM)TOA Wrote: [ -> ] (2012-08-17, 09:06 PM)pavemen Wrote: [ -> ]Inserting ads, tweaking output based on UID/GID, etc are okay. Just be smart and minimize performance impact by skipping the code if it does not apply to the page the user is on in case of using global hooks (global_start, global_end, pre_output_page, etc)
A good point.
It can make a large difference, especially since every active plugin file in included with each page view. If you can run do something like
if(THIS_SCRIPT == "the file I want the plugin to run on.php")
{
//all my plugin code outside the _info, _activate, etc functions
}
then you save a little overhead