Hi,
it would be a great idea to consolidate plugins that work in the same field. Following "one plugin per task", there would be Room for improvement.
Move all spam protection related plugins to one antispam plugin.
Move all text formatting plugins to one single plugin.
Please take this as a starting point for discussions.
The big advantage (among others) would be that settings that influence each other in a bad way can be made impossible.
Cheers
Dirk
Consolidation of Plugins
-
- Regular
- Posts: 764
- Joined: Fri Aug 12, 2005 4:36 pm
- Location: Grüt, Zürich, Switzerland
- Contact:
Consolidation of Plugins
Last edited by Lux on Wed Jan 19, 2011 8:27 pm, edited 1 time in total.
Re: [2.0] Consolidation of Plugins
I guess this is a "philosophical" question. On the one hand, we have a modular approach, which enables people to add functionality bit by bit as they need it. On the other hand, we tend to add functionality to existing plugins in order to keep the number of plugins altogether small. Both is valid in my humble opinion.Lux wrote:Move all spam protection related plugins to one antispam plugin.
Move all text formatting plugins to one single plugin.
In terms of spamblock, I think at least spamblock and bayes should be kept seperate. Bayes is awesome, but I'm not sure it's for everyone. Same for RBL etc. It would also blow up the "normal" spamblock plugin.
I'm also not sure combining all the markup plugins is a good idea, although I did already suggest to
a) move markdown and textile from the core to spartacus since not many people seem to use them anyway
b) try to expand Serendipity markup to a full-featured markup plugin which could eventually replace a WYSIWYG editor (which is a huge task)
YL
-
- Core Developer
- Posts: 30022
- Joined: Tue Sep 16, 2003 9:45 pm
- Location: Cologne, Germany
- Contact:
Re: [2.0] Consolidation of Plugins
Hi!
Serendipity follows a modular approach. Combning multipele different text formattings into one plugin will not happen because of more reasons:
- too large to maintain
- too easy to screw things up for other text formattings, even if only one was to be updated
- takes up too much RAM
- errors and bugs are too hard to isolate
- configuration gets bloated
- you cannot easily search for the plugin that you exactly look for
- New experimental things would affect the stability of other plugins
- People would need to often upgrade plugins even though it might not affect the part of the plugin that they are using
- For markup plugins, it's actually a big plus that they are seperate so that a user can choose due to his own requirements in which order different markups are applied. This is often not a general statement where a global "fix" is possible because it disturbs other users requirements. nl2br vs. nl2p is a different kind of core problem, though.
I initially read your idea to better group plugins through the filtering dropdown - and I think this is a place where similar plugins could better be grouped to let the user see "similar ones"?
Regards,
Garvin
Serendipity follows a modular approach. Combning multipele different text formattings into one plugin will not happen because of more reasons:
- too large to maintain
- too easy to screw things up for other text formattings, even if only one was to be updated
- takes up too much RAM
- errors and bugs are too hard to isolate
- configuration gets bloated
- you cannot easily search for the plugin that you exactly look for
- New experimental things would affect the stability of other plugins
- People would need to often upgrade plugins even though it might not affect the part of the plugin that they are using
- For markup plugins, it's actually a big plus that they are seperate so that a user can choose due to his own requirements in which order different markups are applied. This is often not a general statement where a global "fix" is possible because it disturbs other users requirements. nl2br vs. nl2p is a different kind of core problem, though.
I initially read your idea to better group plugins through the filtering dropdown - and I think this is a place where similar plugins could better be grouped to let the user see "similar ones"?
Regards,
Garvin
# Garvin Hicking (s9y Developer)
# Did I help you? Consider making me happy: http://wishes.garv.in/
# or use my PayPal account "paypal {at} supergarv (dot) de"
# My "other" hobby: http://flickr.garv.in/
# Did I help you? Consider making me happy: http://wishes.garv.in/
# or use my PayPal account "paypal {at} supergarv (dot) de"
# My "other" hobby: http://flickr.garv.in/
-
- Regular
- Posts: 764
- Joined: Fri Aug 12, 2005 4:36 pm
- Location: Grüt, Zürich, Switzerland
- Contact:
Re: [2.0] Consolidation of Plugins
Ok, understood.garvinhicking wrote:Serendipity follows a modular approach. Combning multipele different text formattings into one plugin will not happen because of more reasons:
No, not exactly. There are some plugins that cause unwanted side effects, if placed in a wrong order. Maybe ordering plugins in the right way can be supported by a plugin offering an example text and showing the results. Just thinking loudly ...garvinhicking wrote:I initially read your idea to better group plugins through the filtering dropdown - and I think this is a place where similar plugins could better be grouped to let the user see "similar ones"?
Dirk
-
- Core Developer
- Posts: 30022
- Joined: Tue Sep 16, 2003 9:45 pm
- Location: Cologne, Germany
- Contact:
Re: [2.0] Consolidation of Plugins
Hi!
Your thinking is greatly appreciated. Sadly, we have sooo many plugins and the mathematical combination methods are so high. The only plugins that come to my mind that have positioning trouble, I think the plugins mentions "Must be placed at the end/before/after X". However, of course there must be plugins missing this description, and I'd love to fill those out.
If anyone knows of exact plugin collisions, please post here or on a new thread so that we can either document it, or see if the special combination problem can somehow be better circumvented.
Best regards,
Garvin
Your thinking is greatly appreciated. Sadly, we have sooo many plugins and the mathematical combination methods are so high. The only plugins that come to my mind that have positioning trouble, I think the plugins mentions "Must be placed at the end/before/after X". However, of course there must be plugins missing this description, and I'd love to fill those out.
If anyone knows of exact plugin collisions, please post here or on a new thread so that we can either document it, or see if the special combination problem can somehow be better circumvented.
Best regards,
Garvin
# Garvin Hicking (s9y Developer)
# Did I help you? Consider making me happy: http://wishes.garv.in/
# or use my PayPal account "paypal {at} supergarv (dot) de"
# My "other" hobby: http://flickr.garv.in/
# Did I help you? Consider making me happy: http://wishes.garv.in/
# or use my PayPal account "paypal {at} supergarv (dot) de"
# My "other" hobby: http://flickr.garv.in/
-
- Regular
- Posts: 764
- Joined: Fri Aug 12, 2005 4:36 pm
- Location: Grüt, Zürich, Switzerland
- Contact:
Re: [2.0] Consolidation of Plugins
Geshi or BBCode must be before any other text formatting plugin, correct?garvinhicking wrote:If anyone knows of exact plugin collisions, please post here or on a new thread so that we can either document it, or see if the special combination problem can somehow be better circumvented.
Cheers
Dirk
-
- Core Developer
- Posts: 30022
- Joined: Tue Sep 16, 2003 9:45 pm
- Location: Cologne, Germany
- Contact:
Re: [2.0] Consolidation of Plugins
Hi!
I think Geshi has it's own special syntax that should not interfere with other ones.
As for textformatting plugins, one simply has to think of it like this. The text starts with what you entered, and then gets handed down to each text formatting plugin in the order they are sorted.
That means that any plugin which relies on specific input, you need to make sure that the actually required input gets through to the plugin - and you need to know what output a specific text formatting applies, to judge if another transformation needs to occur before or after.
As long as transformations rules to not overlap, the order should not vary. Geshi for example only listens on (geshi)...(/geshi) (I think) and BBCode does not transform any tags in square brackets it does not recognize.
A good example would be if you have the emoticate plugin installed that transfers a smilie like ": - )", and you post a code example where you want to have the actual string ": - )" to appear, you'll have a problem because no matter if the emoticate plugin is posted first or last in queue, it will always replace that string with a smilie...
Regards,
Garvin
I think Geshi has it's own special syntax that should not interfere with other ones.
As for textformatting plugins, one simply has to think of it like this. The text starts with what you entered, and then gets handed down to each text formatting plugin in the order they are sorted.
That means that any plugin which relies on specific input, you need to make sure that the actually required input gets through to the plugin - and you need to know what output a specific text formatting applies, to judge if another transformation needs to occur before or after.
As long as transformations rules to not overlap, the order should not vary. Geshi for example only listens on (geshi)...(/geshi) (I think) and BBCode does not transform any tags in square brackets it does not recognize.
A good example would be if you have the emoticate plugin installed that transfers a smilie like ": - )", and you post a code example where you want to have the actual string ": - )" to appear, you'll have a problem because no matter if the emoticate plugin is posted first or last in queue, it will always replace that string with a smilie...
Regards,
Garvin
# Garvin Hicking (s9y Developer)
# Did I help you? Consider making me happy: http://wishes.garv.in/
# or use my PayPal account "paypal {at} supergarv (dot) de"
# My "other" hobby: http://flickr.garv.in/
# Did I help you? Consider making me happy: http://wishes.garv.in/
# or use my PayPal account "paypal {at} supergarv (dot) de"
# My "other" hobby: http://flickr.garv.in/
-
- Regular
- Posts: 764
- Joined: Fri Aug 12, 2005 4:36 pm
- Location: Grüt, Zürich, Switzerland
- Contact:
Re: [2.0] Consolidation of Plugins
Same for any other plugin before geshi comes.garvinhicking wrote:A good example would be if you have the emoticate plugin installed that transfers a smilie like ": - )", and you post a code example where you want to have the actual string ": - )" to appear, you'll have a problem because no matter if the emoticate plugin is posted first or last in queue, it will always replace that string with a smilie...
Take nlbr, it has a field where I can set it shall not occur in geshi-tagged "paragraphs". Maybe it is a good idea to have this exclusion for every plugin. In this case the order of the plugins is not important.
And, maybe it is better to have it the other way round. You have to include tags, where the formatting should be done.
Cheers
Dirk