[pmwiki-users] user-customisation of edit form

Patrick R. Michaud pmichaud at pobox.com
Fri Jul 22 14:02:35 CDT 2005


On Thu, Jul 21, 2005 at 07:05:01PM +0100, Hans wrote:
> I like to persue this further for the selfish reason to get my custom
> edit form back on pmwiki.org, which I used in gemini skin via
> $PageEditFmt, but abandoned for the sake of EditForm customisation.

Note that there are really a bunch of ways to do this... and it
ultimately gets into the topic of packaging customizations in skins
in general.  I now have lots of ideas about this, so let me answer
your specific requests first and then get to the bigger picture...

> So I wonder if we can experiment on pmwiki.org with user customised edit
> forms, and like to ask Patrick to add to config.php
>     $PageEditForm = '$[Site.EditForm]'

Now done on pmwiki.org; I still haven't decided if this should be
the distribution default.

> after which we can include in a user copy of
> Site.Preferences our personal EditForm location, like:
> 
>     'Site.EditForm' => 'Site.EditFormJoe',

I think the general case ought to be one of 

    'Site.EditForm' => 'Joe.EditForm'
    'Site.EditForm' => 'Profiles.Joe-EditForm'

since most people don't have write permissions into the 'Site' group.

Now back to the issue of edit forms, and more generally, let's
look at the ways in which skins can provide custom settings.
First, skins like the GeminiSkin and FixFlow want to provide 
custom default pages such as Site.PageTopMenu and Site.PageFootMenu.  
Eventually some of these pages will likely be adopted as standard
conventions in PmWiki skins, but I think there will always be
some pages that end up being specific to one or a very few skins. 

At the moment, skin-specific pages are typically distributed with the 
skin, and have instructions to the wikiadmin to "copy these pages 
into wiki.d".  Unfortunately, this has the potential to overwrite existing
customized pages, especially when the skin is upgraded and needs to
be reinstalled.  So perhaps a better solution is for the skin to 
follow PmWiki's update model, by creating a PageStore specifically
for the skin's distributed pages and placing that store into 
$WikiLibDirs.  A brute-force approach to this would be to do 
something like the following in skin.php:

    global $WikiLibDirs, $WikiDir, $SkinDir;
    $WikiLibDirs = array(&$WikiDir,
      new PageStore("$SkinDir/wiki.d/\$FullName"),
      new PageStore("$FarmD/wikilib.d/\$FullName"));

Essentially this is saying to use the skin distribution's pages in 
addition to (and in preference to) the ones in the PmWiki distribution
in wikilib.d/, but locally edited versions of the page still have
priority.  

Unfortunately, the code above disrespects any wikiadmin customizations
of $WikiLibDirs, so the better approach is to do something like

   global $WikiLibDirs, $SkinDir;
   $where = count($WikiLibDirs)
   if ($where>1) $where--;
   array_splice($WikiLibDirs, $where, 0, 
     new PageStore("$SkinDir/wiki.d/\$FullName"));

which will insert the skin's pages just before the last entry in
the list (usually wikilib.d/) but never before the first entry 
(usually wiki.d/).  

Okay, so now we have an easy way to get a skin's pages into the
system, but what about skin defaults for access keys and other
user-preference settings?  Well, just like user preferences and
internationalization, a skin can make use of the translation tables
in PmWiki.  Thus, in skin.php the skin author can do

   global $XLLangs;
   XLPage('gemini', 'Site.GeminiXLPage');
   array_splice($XLLangs, -1, 0, array_shift($XLLangs));

Here, the array_splice line is giving the skin's preferences
lower priority than any languages or user-prefs that might've been
loaded.  Thus, the Site.XLPageGemini page (in the skin's wiki.d/) 
can contain new or changed accesskey bindings and phrase
preferences (and even $[Site.EditForm]) beyond what PmWiki 
distributes, but not clobber any language, admin, or user 
preferences in the process.  

And if a skin wants to put defaults somewhere other than wiki pages,
it can always choose to add things to the translation table arrays
directly using XLSDV().

Of course, this all makes for somewhat advanced skinning beyond simply
creating template files.  But it seems that skin authors are always
pushing PmWiki's boundaries in this respect anyway.  (I'm not
complaining!)  So, perhaps something along the lines above
can allow skins to provide additional features while still 
integrating well with other customizations.

Comments, questions, suggestions?

Pm




More information about the pmwiki-users mailing list