[dokuwiki] Re: Plugin and Theme integration
- From: "Martin Gill" <martin@xxxxxxxxxxxxxxxxx>
- To: dokuwiki@xxxxxxxxxxxxx
- Date: Wed, 28 Feb 2007 10:12:41 -0000 (UTC)
On Wed, February 28, 2007 09:16, Michael Klier wrote:
>
> in an ideal world all the plugin authors would use the set of default
> style.ini replacements (__text__, __text_alt_, a.s.o.) in their plugin CSS
> to make the plugin fit into any template, and all the template authors
> would a least use this default set in their template, that`s what the
> style.ini is for. But that`s, not yet, the case for all plugins/templates.
>
Actually, the problem here is that some plugins (e.g. notes) define their
own colours and there's no easy central way to deal with those changes.
If all colours were stored in the same manner (e.g. a php array/map) then
it would be possible to edit this map via the wiki, or even just have a
"final" config file in the config folder that would override values.
E.g. Notes has a bright red colour defined as colors['note1']. I want a
dark red, so all i need to do is read up in notes what colours it sets,
and then add colors['note1'] to my override config and change the value
before it's used. And yes, a local.style.ini could be used here for this.
No need to edit or merge files, hunt around for the files. Just replace
the value with a new one.
I agree with you though that all plugins / themes etc should use the
default replaces where possible.
>
>> There are two things I would like to suggest for discussion.
>>
>>
>> The first is to allow plugins to have their own style.ini which is
>> appended to the theme's style.ini. I suspect the style.ini replacement
>> code is actually fairly slow though (not sure, as I've not looked at
>> how it's parsed).
>
> I doubt this would safe you from clashing colors, I think it would
> rather lead to a more complicated situation as the plugin authors may
> introduce their own substitutions. Also, since the CSS is cached after
> it`s parsed the method is IMO fast enough.
>
Speed was a minor issue, and I agree that colour clashes would not be
avoided, hence this wasn't my preferred solution, see my answer above.
>> The ultimate aim would be to have a colour config plugin that would
>> allow a each user (or just the admin) to actually completely customise
>> the colours without having to edit a single file, and consequently
>> without having to know anything about CSS or PHP.
>
> If we would have the ideal situation mentioned earlier, it would be only
> a matter of editing the style.ini to define personalized color scheme,
> which doesn`t require any knowledge about CSS and PHP. I don`t know if it
> would make sense to introduce some kind of admin plugin to do that as you
> don`t change your template colors every day.
>
You don't change your main wiki settings everyday either, yet we use a
plugin. The reason being it's easier for the user, just another step in
setting up the wiki that the user can use or not, depending on their
tastes.
>> It would read the merged colours array from the theme, adn all the
>> plugins adn would allow the user to change the vales, then either store
>> the overried as part of the cookie or in the main config file. That way
>> even updates to plugins and themes would retain the users colour
>> selections.
>
> In regards to upgrade safeness - what about just checking for the
> existence of another file local.style.ini in the template directory before
> the CSS gets parsed, just like with all the other config files? But we
> have to keep in mind that template authors may introduce or drop
> replacements from time to time, which then must be handled by
> lib/exe/css.php in some way.
>
The reason I suggested using php array is that you can just set the value
again. Regardless of what the theme or plugin sets it to.
Granted with a local.style.ini you can probably do the same, it'd just be
an extra step to read the value out of the file first, then set the
variable, instead of having the file set the variable directly.
In my suggestion you'd end up with a file like:
<?php
$color['1'] = "#123456";
$color['2'] = "#123456";
//etc
?>
The need for parsing the file, and the extra complexity that introduces,
falls away, all you need to do is include the file and you've got your
settings.
I'd imagine something like this:
include default colors
include plugin colors
include theme colors
include local override colors
parse css files.
Ragards,
Martin
--
DokuWiki mailing list - more info at
http://wiki.splitbrain.org/wiki:mailinglist
Other related posts:
