[Pmwiki-users] local/Main.php...

Patrick R. Michaud pmichaud
Thu Jan 29 13:11:34 CST 2004


On Wed, Jan 28, 2004 at 05:19:24PM +0100, Thomas -Balu- Walter wrote:
> 
> I've found a minor thing though which I don't like (so far ;) - the way
> Pmwiki loads the local configuration files.
> 
> I wanted to have a global layout for all pages, so I've edited
> local.php. In addition I wanted to modify the Main-group so that it
> looks a little different. But now it loads the Main.php for all other
> groups too - yes, it's documented that way, but...:
> 
> "For all LocalCustomizations, PmWiki first processes the local.php file,
> and then looks for a per-page customization file in the local/
> subdirectory to process. If there is no per-page customization file then
> PmWiki looks for a per-group customization, and if that doesn't exist it
> looks for a per-group customization file for the group given by the
> $DefaultGroup (usually "Main"). "
> [...]
> IMHO local.php is the global configuration that should be used for all
> groups. One should be able to override that using a page or group
> specific configuration. Using local/Main.php as an additional "global
> config" simply makes it impossible to override settings just for the
> Main group. 

Well...yes and no.  The problem I was trying to resolve for my own site
was that I wanted to have configuration settings for "all groups and pages
that don't already have a specific customization file".  The local.php
file can't do this easily, because it's loaded for all pages.  And
I didn't want to have to create per-group files to "disable" features and
settings I've made in the global file, because it's often harder to
disable included features than it is to simply not include them in the
first place.

Fortunately, there *are* some relatively simple workarounds.  The first
is that the default group config file (e.g., Main.php) can easily be 
written such that it only works for pages in the default group, just add:

   $group = FmtPageName('$Group',$pagename);
   if ($group!=$DefaultGroup) return;

Second, the script that controls the per-page and per-group customization 
file loading is scripts/pgcust.php, and the default behavior can be
disabled by adding $EnablePerGroupCust=0 to local.php.  You can then have
local.php process the per-page and per-group customization files in whatever
sequence you wish--use the code from scripts/pgcust.php as a starting point.

> I'd also load the files in a different order: 
> local.php -> local/Group.php -> local/Group.PageName.php
> (if file_exists() && is_readable() of course ;)
> 
> This way you'd avoid having duplicate code in local/Group.PageNameX.php
> as all "page configs" would share a common "group config" (plus a global
> "site config").

I thought about this as well, and again it was a case of I didn't want
a per-page config file to have to try to "undo" the effects of
a per-group config file.  So, it's done either-or, and you can easily
get the effect that you want by simply adding an "include" to the
top of the per-page config file.  For example, just do

   @include_once("local/Group.php");

as the first line of local/Group.PageNameX.php and you get the same effect.
Again, I figured that on the whole it was easier for an admin to add one 
line to the per-page config to load in the group settings than it was
to be adding many lines to the per-page configs to "take out"
the unwanted settings of the per-group configs.

However, the ability to easily disable the pgcust.php script and replace
it with your own logic means you can have whatever config processing you
wish.  :-)

> Another that just came into my crazy mind:
> Using single quotes to define strings in PHP would help a lot to
> avoid escaping special characters (the only char that needs to be
> escaped in single quotes is of course the single quote itself.
> IIRC in XHTML you should (must?) use double quotes for the arguments.

There's nothing in the XHTML spec that says double quotes must or should 
be used for arguments.  It simply says that arguments must be quoted, 
and HTML explicitly recognizes that attributes may be either single or 
double quotes (http://www.w3.org/TR/html4/intro/sgmltut.html#h-3.2.2).

I decided I wanted to be consistent in my attribute quoting, and I
went with single quotes because there are some strings in the PHP
code where variable substitution *is* supposed to take place at
the PHP level.  Thus, for these strings I had to use double quotes, and
it made more sense to use single-quotes for the attributes, and to be
consistent I generally followed that convention everywhere.  Also,
in statements such as

  $PageDiffFmt = "<h1><a href='\$PageUrl'>\$PageName</a> $[Revisions]</h1>";

I think it's worthwhile for the escapes to call the programmer's 
attention to the fact that the substitutions for $PageUrl and $PageName 
are going to be done when the string is output (by FmtPageName()), 
and *not* by PHP when the assignment is executed.  But I agree it's a 
close call and I simply went the other way because it seemed more 
consistent to me overall.

Pm



More information about the pmwiki-users mailing list