[pmwiki-devel] Hub Q?

[Petko Yotov]

On 12/08/2024 23:14, Simon wrote:
> On the topic of
> $conf = extGetConfig($MyDefaultValues);
> 
> I believe that $conf should only make visible to the recipes values
> that are related to the recipe itself (i.e. all other recipe variables
> should not be visible)

Thank you for the review and feedback.

Indeed this function returns the full configuration and is used by the 
extension but the full array is needed by the hub when editing and 
saving configurations.

We can refactor it so the hub uses a different function to get the full 
configuration, and this function to only return values for the recipe 
valid for the current page.

> I am starting to understand this include:
> * calculated variables for the current page (from recipe's form)
> * saved config variables (from recipe's form)
> * x variables for the recipe (e.g. xAction)

Which are also saved from the recipe's form. I agree these can be safely 
omitted here, and will make it simpler for extension authors.

> * = variables for the recipe (e.g. =url)
> 
> Some feedback - i find the access to the configuration variable the
> most confusing part.
> For example what is it with the [0] part of $conf['=conf'][0] ?

An extension can have different "configurations" per pagename pattern. 
These are added with a drop-down on the main ExtensionHub listing.

Not sure of the word "configuration", we may find a better one.

You can have for example "configurations" like:
[0] = * (applies to all pages)
[1] = Main.* (applies to Main group)
[2] = Site.*,SiteAdmin.* (applies to Site and SiteAdmin groups)
[3] = (existed once, now deleted, ignored)
[4] = Category.* (applies to Category group)

A "configuration" can be enabled or disabled (checkbox in the hub form).

The [0] part is the number of the "configuration". If the pagename 
patterns of different configurations match the current page, the enabled 
ones will be merged with array_merge, and later values override previous 
ones.

This merging needs some additional work from me, as it currently merges 
in the order of creation, but it should start with the more wildcard 
one(s).

For example, if we have 3 different configurations say for: "*", 
"Main.*" and "*.RecentChanges", and the page is Main.RecentChanges, in 
what order should these be merged?

It becomes more complex with a pattern like 
"Main.*,PmWiki.*,-*.HomePage,Group.Name*", how should this be sorted 
before merging the values?

I need to think about it.


> Its probably too late to change things, but perhaps something like
> this would be clearer

Today is not too late: the only people having published extensions are 
you and I. :-)

Although someone else said on a talk page they are making a custom 
extension.

> $conf = extGetConfig($MyDefaultValues); # returns the following
> arrays:
> 
>  $conf['=']['VarName'] ; #
>  $conf['x']['Varname'] ; #
>  $conf['f']['FieldName'] ; # form configuration values for current
> page
>  $conf['sc']['FieldName'] ;# saved form configuration values as
> entered on Extension hub

I feel $conf should return only 'FieldName' type values for the current 
page, plus '=dir'. Values that are needed for the hub like '=url', 
'=conf', 'xAction' can be excluded here, and a different function called 
by the hub can return those.

> Also, please consider making the "Applies to pages:" text box two or
> three times wider, or deeper by allowing it to have multiple lines (so
> a list of pages can extend over several lines)

Good idea.

> I can't wait for ExtensionHub to be included in the PmWiki releases

Not sure about that. The extensions/hub.php script needs to be 
browser-reachable, and the PmWiki core may be outside of the document 
root (with pmwiki/pub symlinked).

I'm still considering this very attractive idea:

   PITS/01501: make release software tree "no-need-to-touch"

For people who don't use version control to upgrade, it would be much 
easier to install a new version or revert to a previous one, without 
local customization files and recipes intermingled within the core 
directories.

Unlike what is written in the documentation, extensions don't need to be 
placed in pmwiki/extensions or $FarmD/extensions, it could be somewhere 
else like $_SERVER['DOCUMENT_ROOT']/extensions.

Petko

> On Tue, 13 Aug 2024 at 00:47, Petko Yotov <5ko at 5ko.fr> wrote:
>> ExtensionHub shouldn't truncate the field names. However, while
>> working
>> on an extension, if you modify a field name, and a value with a
>> different name was previously saved, the old value will appear in
>> $conf.
>> 
>> In such a case, just repost the configuration form, and the old
>> value
>> will be cleared.
>> 
>> BTW note the difference between $conf['FieldName'] and
>> $conf['=conf'][0]['FieldName']. The former is the one calculated for
>> the
>> current page; the latter is one of the saved configurations.