[pmwiki-users] Custom page specific variable assignment syntax

[Petko Yotov]

This is a good way to learn more about PmWiki variables, and your 
suggestion for the documentation is great.

There are a few other solutions to your specific problem:

1. In a wiki page, you could use the built-in intermap prefix "Path:", I 
use this a lot:
    Path:/Wiki/Main/HomePage
    Path:/Wiki/uploads/Main/document.odt

(or define your own, see https://pmwiki.org/InterMap .)

2. The global variable $UrlScheme contains either http or https, if you 
need this from config.php or from an add-on.

3. In a wiki page, you can probably use either {$ScriptUrl} or 
{OtherPage$PageUrl}.

You could define $ScriptUrl in config.php if PmWiki is unable to detect 
it correctly, possibly with a conditional.


You should bravely edit the documentation, I review all changes before a 
release, and do not worry about the other languages.

If you you have doubts whether what you post is 
correct/safe/appropriate, you can alternatively post it to the Talk 
page.

BTW such a function can be called with a number of wikipage-related or 
global variables as arguments:

   $pn, $group, $name, $page, $GLOBALS["SomeVar"]

You can see the default definitions for $FmtPV from line 123 of 
pmwiki.php.

If you have any questions do not hesitate to ask here on the mailing 
list or on the Talk pages on pmwiki.org.

Petko

On 28/08/2018 18:55, Kevin R. Bulgrien wrote:
> This note regards page specific variables described here:
> 
>   https://www.pmwiki.org/wiki/PmWiki/PageVariables
> 
> It is a suggestion to consider a minor addition to the
> Custom page variables section to add an example of using
> a user-defined function to construct a value to assign to
> a custom page variable.
> 
> My task involved finding a way to keep two (almost) wiki
> sites consistent during a transition period using only
> periodic rsync of the master wiki to a temporary replica.
> Both domain and http vs. https changes occurred.  The
> main challenge was that some wiki content used hard-coded
> http://... URLs to other areas of the web space outside
> the wiki but on the same server.  These links broke when
> rsyncing updates to a different server.  I hoped not to
> change rendered content simply because I was moving the
> wiki to a new platform, and envisioned using computed
> variables that could be used in place of the hard-coded
> URLs.
> 
> Use of custom page variables appeared viable, but I found
> it difficult to gain understanding of syntax rules that
> apply to defining a Page Variable via a moderately
> complex expression.  I tried a number of simple syntax
> structures with intermittent success though each time I
> tried to modify the simple examples, the change would
> invariably break some syntax rule I was not able to
> discern.
> 
> In the end, by looking at various cookbook files, I found
> a function call assignment syntax structure that worked
> immediately and completely removed complexity of syntax.
> 
> So much time was spent trying to get other syntax forms
> to work that it seems a documentation change could help
> others if it showed an example using a user-function to
> assign the FmtPV value.
> 
> Without meaning to imply that the following example is
> without fault, the following illustrates the format:
> 
> function BaseURL()
> {
>   $URLPrefix = "http";
>   if (! empty($_SERVER['HTTPS']))
>   {
>     if($_SERVER['HTTPS'] == 'on')
>     {
>       $URLPrefix .= "s";
>     }
>   }
>   return $URLPrefix .= "://" . $_SERVER['HTTP_HOST'] . "/Wiki";
> }
> $FmtPV['$BaseURL'] = 'BaseURL()';
> 
> It seems it could be helpful if the custom page variable
> documentation mentioned a function call example as it has
> a very simple syntax and allows for complex computation of
> values to assign.  Even if understanding of the existing
> documentation is due to my own issues, perhaps I am not
> alone and there are others who might benefit from adding
> an example like this.
> 
> I placed this code in config.php and made a handful of changes
> to replace hard coded URL text with {$BaseURL} references on a
> few affected wiki pages (though the code could have been placed
> in a cookbook PHP file included by config.php as cookbook files
> normally are).
> 
> I am willing to edit the wiki myself to add a short example
> (probably without full text of the user-function) if it does
> not create a synchronization issue for other language pages
> I cannot edit, or, if this is seen as undesirable, to simply
> let this mailing list note suffice to put the information
> out there for others.