Description: There's a better way of doing script and cookbook initialisations than the current dependency on including files in the correct order.

Proof of concept: setup.php

For example, I'm putting together a new PmWiki blog package, but I'm running into some rather thorny issues manipulating the $EditFunctions array in a sane manner.

More specifically, at the moment I'm looking to overload the EditDraft function, without having to duplicate the contents of scripts/draft.php and other script files. The simple thing to do would be something like this:

if (IsEnabled($EnableDrafts, 0)) {
 include_once("my_draft.php");
 $EnableDrafts = 0;
}

But that won't play nice, since drafts should come after simuledit + prefs, and hence those too would have to be included before my_draft.php, and those in turn might be influenced by stuff in per-page customisations, etc. So the chance of screwing up and/or interfering with other recipes gets pretty high.

The reason it's so difficult is because much of the initialisation code for scripts as well as cookbook recipes happens right when they're included, which means that the order in which you put things in your config file(s) is important. I think this isn't the best way of doing things.

For a fix, I suggest a new table of initialisation functions that could get called from pmwiki.php at the very end of initialisation, just before HandleDispatch. The format for this table should be something similar to the MarkupTable, which handles the exact same problem, just for a different context (the order in which markup rules get implemented).

Regarding my original issue, this table would let me eg. add a function near its end that would safely replace the appropriate $EditFunctions entry with my own function.

A proof of concept implementation of this SetupTable is attached. To see it in action, include it in a config file and use ?action=setuprules on a wiki page.

  $EditFunctions = array(
    'EditTemplate'  => 100, 
    'RestorePage'   => 200,
    'ReplaceOnSave' => 300,
  # etc.
  );

$Setup = array(
  'SetCurrentTime' => 100,
  'ResolvePageName' => 200,
  "$FarmD/scripts/stdconfig.php" => 300,
  'ReadInterMapFiles' => 400
);

asort($Setup);
foreach($Setup as $k => $v) {
  if (!$k || !$v) continue;
  if (substr($k,-4) == '.php') include_once($k);
  else $k();
}

I would love to see greater control over when config code gets executed. In addition to being able to specify an order for initialization with normal config.php I think there should be some capability for executing code after stdconfig, at the very end of producing a page, etc. --Peter Bowers August 06, 2009, at 03:15 PM

Here are a couple of actual use cases where I'd find it very useful to be able to get a function to run near the end of the setup phase. —Eemeli Aro August 17, 2009, at 05:06 AM

• EditAttributes adds two entries to $EditFunctions, one of which is meant to run as early as possible as it'll modify the page text and attributes, which other $EditFunctions may depend on (such as the Bloge new post naming). At the moment, Bloge needs to specifically look for EditAttrBeforePost and add itself after it, if it exists.

• A second difficulty exists with EditAttributes, as it needs to set $EditFields before HandleEdit is run: the added text fields need to be set before the $EditFunctions are executed. This means that easy configuration of the recipe requires the $EditAttrFields to be defined before including editattr.php, which isn't possible is you want to have eg. per-group customizations to edit fields. To fix this, currently you need to execute the following after you've finally set $EditAttrFields:
  $EditFields = array_merge($EditFields, array_keys($EditAttrFields));

• draft.php renames a page when a draft version is published, by removing the -Draft suffix from the name. This is fine, provided that you're not creating a new page or that you know when starting the draft what the page's eventual name will be. This is not necessarily the case with Bloge when creating a new blog post, which has a name that includes the post's publication date. The difficulty here comes from the rather precise positioning of EditDraft in $EditFunctions in relation to at least MergeSimulEdits. Hence overloading EditDraft is very difficult at the moment.

$Setup['PageStore'] = array('wiki.d'=>100, 'wikilib.d' => 200, /*etc*/);
$Setup['EditFunctions'] = array(
  'EditTemplate' => 100, 
  'RestorePage'  => 200, /*etc*/);
$Setup['UploadFunctions'] = array( 'UploadVerify'=>100, /*etc*/);
$Setup['FmtTemplateFunctions'] = array( /*etc*/);
$Setup['init'] = array(
  'SetCurrentTime' => 100,
  'ResolvePageName' => 200,
  "$FarmD/scripts/stdconfig.php" => 300, /*etc*/);

A simple $PostConfig array processed after stdconfig.php was added to subversion, for 2.2.17, unless we discover some problems (speak up). --Petko June 05, 2010, at 07:18 PM

Any possibility it could be moved down a few more lines? If it occurred immediately after this line:

SDV($LinkPageCreateSpaceFmt,$LinkPageCreateFmt);

or even just before this line:

if (IsEnabled($EnableActions, 1)) HandleDispatch($pagename, $action);

then functions can call MarkupToHTML() successfully... Also the later it is the less likely we will run into caching issues...

If there's an advantage to having it in its current location then perhaps there could be some mechanism where functions with sort values less than 100 go in the current location but functions with sort values greater than 100 go in the later location?

Or maybe ...

$PostConfig['A']['myfunc'] = 100;   // this will run right after stdconfig is loaded
$PostConfig['B']['mylatefunc'] = 200; // this will run after links are defined

with certain predefined values for the index. ( --Peter Bowers June 21, 2010, at 04:20 AM

I'm not sure that functions should call MarkupToHTML() directly from the config files: at the moment, I can't decide if we should try to support this and to keep fixing it every time someone's code breaks it. :-) If someone requires link variables to be defined, they could define them in the script, however direct calling of MarkupToHTML() might work but is still utterly unsupported. PITS:01214. --Petko September 04, 2010, at 11:50 AM

I don't know if I understood the problem completely, but about this:

if (IsEnabled($EnableDrafts, 0)) {

 include_once("my_draft.php");
 $EnableDrafts = 0;

}

I believe this could be solved by setting a variable called $DraftsScript, that when changed will run the Draft Script you want instead of PmWiki's Draft Script.

Also, to change, remove or substitute an entry in EditFunctions more easily we could create a recipe that does that.

I did a really tiny recipe that does just that as it was a MarkupFrame manipulator, it just doesn't replace or remove, it just ads in front or after an already placed EditFunction and also at the beginig or at the end.

I will change the recipe to do replaces and removes as well.

CarlosAB March 17, 2018, at 01:34 AM