Serendipity Forums

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

Lux wrote:Move all spam protection related plugins to one antispam plugin.

Move all text formatting plugins to one single plugin.

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.

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

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

garvinhicking wrote:Serendipity follows a modular approach. Combning multipele different text formattings into one plugin will not happen because of more reasons:

Ok, understood.

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"?

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 ...

Dirk

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

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.

Geshi or BBCode must be before any other text formatting plugin, correct?

Cheers

Dirk

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

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...

Same for any other plugin before geshi comes.

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