Reini Urban wrote:
>>I know some of these things can be easily turned off via the config
>>file, but they all add to the complexity of the codebase and increase
>>the maintainability workload.
>>The more we can work to separate them into plugins the better in my
>>opinion. Anyway, I'm not trying to moan or anything :) We'll do our best
>>to help out where we can too.
>I do what I can.
>The next step is to seperate the mailer functions into an extra
>library, with minimal dependencies from main.
Comments and thoughts on this, as someone who has extended PhpWiki a
lot, and wishes he could do it without forking.
1) There is plenty of functionality we have that could not be separated
into plugins in the current architecture. I wish I could neatly
summarize those changes, but I don't know how. My faulty memory says:
+ WikiDB changes for sure (adding queries, adding tables). We could not
separate that into plugins or make it easily updatable because the "LOCK
TABLE" statement would break if the tables didn't exist.
- Example: we changed the RateIt plugin so you could put multiple of
them on a page to rate urns instead of pages, and we needed to add a urn
and page_urn table.
+ User changes, since it was broken enough that we had to patch it up
+ other things??
2) It would be nice to have an easy way to extend the wiki grammar.
Right now, here is a typical ratings plugin for a thing on a page:
- <?plugin RateIt caption="*inky*" urn="grouplens:printernames:*inky*"
stats="true" expandable="true" ?>
This is way too huge. Most typical users won't do it, and it would be
great if we could define a short-hand or a macro to make it easier.
3) We believe WYSIWIKI is the wave of the future, but does all this
plugin stuff break that?