I was thinking about a more complex plugin with this theming idea.
We could have code.skin.%skinname%.%themename% page (a real *site* page,
not like code.skin.%skinname%.css), and give reading/writing rights to some
users on these pages. I insist in the {skinname} part because skin variable
names may change from one skin to another...
And then we could call in the header page <(theme %themename% )> or <(theme
{~theme} %defaultcssprefix%)> where BOLTFtheme would be defined by:
function BOLTFtheme($args) {
global $BOLTcssPrefix,$BOLTtheme,$BOLTskin;
$default = BOLTinit(false,$args[2]);
if(BOLTFexists("code.skin.$BOLTskin.$args[1]")) //maybe check also the
user reading rights
$BOLTtheme = $args[1]; //the coexistence of this and of info
vars in code.settings allows users to overwrite default values for a given
prefix
elseif(false !== $default)
$BOLTcssPrefix = $default;
//else do not change the css prefix
}
with of course, on the plugin page:
function myBOLTskinSettings($var) {
global $BOLTcssPrefix,$BOLTskin,$BOLTtheme,$BOLTzone;
$zone = BOLTinit('SKIN', $BOLTzone);
if($var != "sitename" && $var != "slogan" &&
BOLTFexists("code.skin.$BOLTskin.$BOLTtheme"))//maybe check also the user
reading rights, and have a more generic way to select which skinvars can be
replaced by theme pages and which cannot
$out = myBOLTskinVar("code.skin.$BOLTskin.$BOLTtheme",$var);//this
comes before code.settings
if ($out == "default" || $out == '') $out =
myBOLTskinVar("code.settings",$var);
if($out == "default") $out = '';
if ($out != '') return BOLTdomarkup($out, '', $zone);
if (inlist($var, 'skin,script,shared,field,files,domain')) return
BOLTvars($var);
}
function myBOLTskinVar($varPage, $var) {
global $BOLTcssPrefix;
if(BOLTFexists($varPage)) {
$out = BOLTvars("$varPage::{$BOLTcssPrefix}_$var", false);
if ($out == "default" || $out == '') $out =
BOLTvars("$varPage::$var", false);
}
return out;
}
One of my usecases is that I allow the users to change the colors of some
pages, to which is assign very specific prefixes. So they need to be able
to change the values associated with these two prefixes, and not to choose
the css prefix to apply... In that case, I would just put <(theme
%basecssprefix%_{~theme} %basecssprefix%)> and allow users to create pages
like code.skin.%skinname%.%basecssprefix%_%theirtheme% where they can
"overwrite" for example firstprefix_text_color but keep
secondprefix_text_color unchanged (if
code.skin.%skinname%.secondprefix_%theirtheme% does not exist) :-D
This will even let them use themes created by other users, and it would
still be something designed to be applied to the whole site (these *are*
THEMES, not local prefixes). One can still copy some prefixed versions of a
theme page but not all, if one want a theme to be partially applied.
And this plugin could become very powerful if you decided to do <(theme
%basethemename%_{id} %defaultthemename%)> or <(theme {p0}_%basethemename%)>
or even <(theme blue blue)> to enforce blue as a theme (from
"code.skin.%skinname%.blue" does not exist) or at least as a prefix (from
code.settings) if the theme page does not exist. But anyway, should you add
this plugin to your website, I would be glad to maintain it (again, my
member id is maelite).
Cheers,
Tiffany
--
You received this message because you are subscribed to the Google Groups
"BoltWire" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/boltwire.
For more options, visit https://groups.google.com/d/optout.
