From 5ko at 5ko.fr  Fri Apr  3 02:19:26 2026
From: 5ko at 5ko.fr (Petko Yotov)
Date: Fri, 03 Apr 2026 11:19:26 +0200
Subject: [pmwiki-users] understanding pagelist default parameters
In-Reply-To: <7a9ffff0c364350276bb05e92902151b@5ko.fr>
References: <CAFUSNWMLbtocub_qbch+3FBZdBG7Wyt6-a8wVAz+2C8tNYuViw@mail.gmail.com>
 <e5a97eb8adf729c407ec4d796de7dd44@5ko.fr>
 <CAFUSNWN5SW6pW=AjONhJEPwFZeiPD_wZ7KU2DMquZp2Cpoh04g@mail.gmail.com>
 <7a9ffff0c364350276bb05e92902151b@5ko.fr>
Message-ID: <bebaab12b774f9f59d3535df90ff95b4@5ko.fr>

Nobody replied here or in the PITS entry so I went and added it without 
a switch.

In ParseArgs, unquoted empty arguments will now be ignored rather than 
returned as positional ones.

The documentation already says that if a search string contains "=" or 
":" it should be quoted.

Petko

-- 
If you upgrade :  https://www.pmwiki.org/Upgrades

On 23/03/2026 17:24, Petko Yotov wrote:
> Thank you Simon for opening a PITS entry. Cross-posting to the mailing
> list to give this more visibility.
> 
> Currently, a pagelist argument with no value like:
> 
>    arg_name=  or  arg_name:
>   "arg_name=" or "arg_name:"
> 
> is considered the string "arg_name=", and returned as positional, not
> named, argument. This may cause unexpected behavior for pagelists
> (search string), input elements (value or something unpredictable),
> and wikistyles (unintended class name) and in most core and custom
> directives.
> 
> This is processed in ParseArgs(), a function used very widely in
> various situations in the core and in recipes.
> 
> Simon's suggestion is, if the parsed string has something looking like
> an argument name pattern with no value:
> 
>   arg_name=
>   arg_name:
> 
> and it is NOT quoted, then this should be skipped, considered not set,
> not empty, just null/missing. This would allow for the argument to be
> defined by (:template default:), (:input default:) or in a function by
> SDVA().
> 
> I've prototyped a fix for pagelists, but I wonder if this should
> become standard.
> 
> There could be a switch as a third argument to ParseArgs(), or a
> global variable toggle, or just do it the new way. I did the first one
> but am considering the third one.
> 
> The pagelist/search documentation mentions that if a search term has
> "=" or ":" it should be quoted.
> 
> Would anyone currently use arg_name= without quotes, and need it
> intentionally as a positional argument?
> 
> Do I miss some edge that a change may break?
> 
> Petko
> 
> 
> On 22/03/2026 21:57, Simon wrote:
>> Thankyou, I now see the problem (I think?)
>> 
>> I would have expected, say, in this statement (from a SideBar)
>> (:pagelist name=A* fmt=Songbook.SideBar#listbyletter
>> category={*$:genre} :)
>> the parameter category= NOT to morph into a search string if  the page
>> text variable {*$:genre} is not defined on a page body.
>> 
>> It seems to me that if a user desires a search string of "category="
>> they should quote it.
>> 
>> thanks
>> 
>> Simon
>> 
>> On Fri, 20 Mar 2026 at 20:14, Petko Yotov <5ko at 5ko.fr> wrote:
>> 
>>> The argument category= without anything after the "=" is considered
>>> a
>>> search string and the pagelist shows pages containing the literal
>>> string
>>> "category=" in the page text.
>>> 
>>> You can use category="" but this overrides your template default.
>>> 
>>> If you populate this argument from a page text variable, there are
>>> $DefaultEmptyPageTextVars and $DefaultUnsetPageTextVars:
>>> 
>>> $DefaultUnsetPageTextVars['genre'] = '*';
>>> $DefaultEmptyPageTextVars['genre'] = '*';
>>> 
>>> This should work for the pagelist argument, but may not work well if
>>> you
>>> display the {*$:genre} variable elsewhere.
>>> 
>>> Otherwise you could have a conditional with 2 pagelists, something
>>> like
>>> this:
>>> 
>>> (:if332 empty "{*$:genre}":)
>>> (:pagelist ... category=*:)
>>> (:else332:)
>>> (:pagelist ... category="{*$:genre}":)
>>> (:if332end:)
>>> 
>>> Petko
>>> 
>>> --
>>> If you upgrade :  https://www.pmwiki.org/Upgrades
>>> 
>>> On 20/03/2026 06:27, Simon wrote:
>>>> I have a test here:
>>>> https://www.pmwiki.org/wiki/Test/PagelistWithCategoryParameter
>>>> 
>>>> It has defaults, viz
>>>> 
>>>> (:template defaults group=Cookbook order=name category="*" count=5
>>> :)
>>>> 
>>>> I'm trying to understand why
>>>> (:pagelist name=W* fmt={$FullName}#listbyletter :)
>>>> appears to give a different result from
>>>> 
>>>> (:pagelist name=W* fmt={$FullName}#listbyletter category= :)
>>>> thanks
>>>> 


From 5ko at 5ko.fr  Sun Apr  5 10:45:38 2026
From: 5ko at 5ko.fr (Petko Yotov)
Date: Sun, 05 Apr 2026 19:45:38 +0200
Subject: [pmwiki-users] PmWiki 2.5.9 released
Message-ID: <86aa59aa5a269edc5013b9df4da8dcfa@5ko.fr>

Hello. PmWiki version 2.5.9 was published today, and is available at:

   https://www.pmwiki.org/pub/pmwiki/pmwiki-2.5.9.tgz
   https://www.pmwiki.org/pub/pmwiki/pmwiki-2.5.9.zip
     svn://www.pmwiki.org/pmwiki/tags/latest

This version includes optimizations to the JavaScript helper libraries.

Core syntax highlighting in the edit textarea will now have a 
semi-transparent selection, so selected markup will be highlighted. For 
programming languages, it now allows for language autodetection with 
%hlt%, and the detected language will appear as a tooltip title over the 
highlighted block.

LocalTimes has been refactored, and timestamps on page histories will 
now be wrapped in semantic <time> elements.

A bug was fixed with SaveAttributes, another one with Sortable tables 
when a row had fewer cells than other rows, another one with 
$MessagesFmt appearing multiple times on preview edit.

A new wikistyle %download%[[link]]%% or 
%download=filename.pdf%[[link]]%% was added for links. It instruct the 
browser to show the SaveAs dialog box rather than opening the link. The 
suggested filename can optionally be supplied.

The functions handling $EnableEditAutoText and $EditAutoBrackets were 
refactored. $EditAutoBrackets was removed from 
$EnableCommonEnhancements. Automatically closing brackets can now have 
separate character sets when text is selected from when it is not. A 
number of new keyboard shortcuts for editing were added, see 
Cookbook:EditHelp.
   https://www.pmwiki.org/wiki/Cookbook/EditHelp

The function ParseArgs() will now ignore/drop unquoted empty arguments 
like name=, previously it returned these as positional arguments which 
could cause problems with some pagelists. If a string looks like an 
argument and needs to be returned as positional one, it should be quoted 
like "name=" (this was already documented for pagelist and search).

The FixUrl GuiEdit button has 2 new functions. Clicking on it 
url-encodes some special characters in selected text (for link URLs, 
like before). If Shift is held down, it will encode all special and 
international characters. If Control is held down, it will try to decode 
all encoded characters.

The page SiteAdmin.AuthUser can now have user properties on subsequent 
lines if they end with a backslash.

Some additional debug variables are shown in StopWatch for UpdatePage().

The documentation was updated.

Thanks,
Petko

-- 
If you upgrade :  https://www.pmwiki.org/Upgrades


From nzskiwi at gmail.com  Wed Apr  8 12:10:43 2026
From: nzskiwi at gmail.com (Simon)
Date: Thu, 9 Apr 2026 07:10:43 +1200
Subject: [pmwiki-users] New extension UrlGet
Message-ID: <CAFUSNWMGoat8Vc88SbhVn6v3wd1qFvtpmbctd0TP9gp39fR3Ag@mail.gmail.com>

UrlGet - Cookbook - PmWiki <https://www.pmwiki.org/wiki/Cookbook/UrlGet>


Questions answered by this extension
<https://www.pmwiki.org/wiki/Cookbook/UrlGet#_toc>

I want to use the built in RecipeCheck
<https://www.pmwiki.org/wiki/Cookbook/RecipeCheck> or Blocklist
<https://www.pmwiki.org/wiki/PmWiki/Blocklist> recipes.

   - how do I do this if "allow_url_fopen"
   <https://www.php.net/manual/en/filesystem.configuration.php#ini.allow-url-fopen>
is
   disabled by my webhost?
   - how do I do this in preference to "file_get_contents"
   <https://www.php.net/file_get_contents> used internally by PmWiki?

Description <https://www.pmwiki.org/wiki/Cookbook/UrlGet#_toc>

This extension provides a function UrlGet which uses cURL to retrieve the
contents of the URL.
The global variable $UrlGetFunction is set to UrlGet using the PmWiki
function SDV if it is not already set.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.pmichaud.com/pipermail/pmwiki-users/attachments/20260409/d9b766b2/attachment.html>

From vanes.peter at gmail.com  Wed Apr 22 01:17:59 2026
From: vanes.peter at gmail.com (Peter van Es)
Date: Wed, 22 Apr 2026 10:17:59 +0200
Subject: [pmwiki-users] Argon2ID authentication
Message-ID: <7C0FC060-7DCA-4734-8054-6171864BE35F@gmail.com>


I am setting up a new PMWiki site. 

I have user records in a database table on the same host. It contains username?s and passwords which are Argon2ID salted hashes. They can be verified using the php function: https://www.php.net/manual/en/function.password-verify.php
which just needs the hash, and the password entered by the user.

I?m looking into using recepies:

1. standard authuser.php, which is where the password is checked, if I?m not mistaken
2. AuthUserDB which looks overly complicated given that all user management and password resets are done on another system
3. and the adodb-connect.php script

However, most of these do not appear to have been updated since 2007? 

Should I simplify things and just build my own customised database layer, and modify authuser.php to use the password verify function?
Additionally I want to add groups to the user so that I have more fine-grained access control?

Thanks in advance for your guidance

Peter van Es
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.pmichaud.com/pipermail/pmwiki-users/attachments/20260422/741fc648/attachment.html>

From 5ko at 5ko.fr  Wed Apr 22 03:54:29 2026
From: 5ko at 5ko.fr (Petko Yotov)
Date: Wed, 22 Apr 2026 12:54:29 +0200
Subject: [pmwiki-users] Argon2ID authentication
In-Reply-To: <7C0FC060-7DCA-4734-8054-6171864BE35F@gmail.com>
References: <7C0FC060-7DCA-4734-8054-6171864BE35F@gmail.com>
Message-ID: <534b3302015ad01921afc49d1247f852@5ko.fr>

You should never need to modify core PmWiki files. Everything can be 
configured and your custom functions grafted without changing 
authuser.php. This will ensure your custom functions will continue to 
work when you upgrade your PmWiki core.

If you can't see how, please ask.

Here is some sample code to check passwords from a database. It should 
get you started:

   # before including authuser.php, attach our own function
   $AuthUserFunctions['peters_backend'] = 'AuthUserPetersDB';
   $AuthUser['peters_backend'] = 1;
   function AuthUserPetersDB($pagename, $username, $password, $pwlist, 
&$authlist) {
     global $pdo;
     # Get the hash from the database
     $stmt = $pdo->prepare("SELECT `pass_hash` FROM `users` WHERE 
`username` = ? LIMIT 1");
     $stmt->execute([$username]);
     $passHash = $stmt->fetchColumn();

     # username not found: prevent timing attacks
     if ($passHash === false) $passHash = 'not a valid hash';

     # invalid password
     if (! password_verify($password, $passHash)) return false;

     # success

     # set user groups
     $authlist['@admins'] = 1;
     $authlist['@editors'] = 1;

     return true;
   }
   include_once("scripts/authuser.php");

PDO and prepared statements are very strongly recommended.

This code should go in local/config.php or in a new script under 
cookbook/ included before the including authuser.php.

Let me know if you have questions.

Petko


-- 
If you upgrade :  https://www.pmwiki.org/Upgrades

On 22/04/2026 10:17, Peter van Es wrote:
> I am setting up a new PMWiki site.
> 
> I have user records in a database table on the same host. It contains
> username?s and passwords which are Argon2ID salted hashes. They can
> be verified using the php function:
> https://www.php.net/manual/en/function.password-verify.php
> which just needs the hash, and the password entered by the user.
> 
> I?m looking into using recepies:
> 
> 1. standard authuser.php, which is where the password is checked, if
> I?m not mistaken
> 2. AuthUserDB which looks overly complicated given that all user
> management and password resets are done on another system
> 3. and the adodb-connect.php script
> 
> However, most of these do not appear to have been updated since
> 2007?
> 
> Should I simplify things and just build my own customised database
> layer, and modify authuser.php to use the password verify function?
> Additionally I want to add groups to the user so that I have more
> fine-grained access control?
> 
> Thanks in advance for your guidance


From vanes.peter at gmail.com  Fri Apr 24 11:22:59 2026
From: vanes.peter at gmail.com (Peter van Es)
Date: Fri, 24 Apr 2026 20:22:59 +0200
Subject: [pmwiki-users] Groups and read/edit/write access
In-Reply-To: <7C0FC060-7DCA-4734-8054-6171864BE35F@gmail.com>
References: <7C0FC060-7DCA-4734-8054-6171864BE35F@gmail.com>
Message-ID: <3CFAA8F2-E064-41BE-A466-C0D987401779@gmail.com>

Thanks Petko,

I have the logging in working using a version of the database recipe you provided. Now I?m struggling with the next challenge.
Maybe it is because I do not know how $authlist is meant to look/work...

Most of my wiki will be available only to signed in users. So when people sign in my code (authuser_LB.php) adds:

    # success
    # set user groups: everyone logged in can read
    $authlist['@read'] = 1;

However, for certain users I want to add group rights.. (like for me, admin) (role_in is case insensitive string compare against an array of functions and returns true if any of them match):

    # check role and functions
    $admins = ['Chairperson ICT', 'Administrative Secretary', 'Ambtelijk Secretaris']; 
    # admins are ICT and ASMD
    if (role_in($role, $admins)) {
        $authlist['@admin'] = 1;
    }

This appears to work. Although I?m not entirely sure, as I added my login username to the Site/AuthUser page as an admin:
@admins: xxxx at xxxxx.com <mailto:xxxx at xxxxx.com>  so that might override it?

Now I have a Group on my wiki which I only want members of the group (and me, as admin) to read, edit, upload etc. So I added a statement like:

	$gr = ['District governor', 'MD council chairperson', 'MD general secretary', 'MD treasurer?,
	'MD Opvolgend council chairperson', 'MD vice council chairperson', 'MD Governor council member?];
	if (role_in($role, $gr)) {
		$authlist['@gr'] = 1;
		$authlist['@edit'] = 1;
	}

Then I tried to add to the page Group.Start access restrictions using Group.GroupAttributes?action=attr and adding @gr to all of the access control fields (read, edit, attr and upload). 

After doing that, the group / page became completely inaccessible to me (logged in, and should be at admin level). I tried to add 

		$authlist['@gr'] = 1;

To my own authlist, but even that did not give me access. Where am I misunderstanding the way this is meant to work?

Thanks for your help...

Peter
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.pmichaud.com/pipermail/pmwiki-users/attachments/20260424/0228cd8d/attachment.html>

From 5ko at 5ko.fr  Fri Apr 24 12:15:13 2026
From: 5ko at 5ko.fr (Petko Yotov)
Date: Fri, 24 Apr 2026 21:15:13 +0200
Subject: [pmwiki-users] Groups and read/edit/write access
In-Reply-To: <3CFAA8F2-E064-41BE-A466-C0D987401779@gmail.com>
References: <7C0FC060-7DCA-4734-8054-6171864BE35F@gmail.com>
 <3CFAA8F2-E064-41BE-A466-C0D987401779@gmail.com>
Message-ID: <e0121d221d79e5baf9e7858a46588436@5ko.fr>

On 24/04/2026 20:22, Peter van Es wrote:
>     # success
>     # set user groups: everyone logged in can read
>     $authlist['@read'] = 1;
...
>     # check role and functions
>     $admins = ['Chairperson ICT', 'Administrative Secretary',
> 'Ambtelijk Secretaris'];
>     # admins are ICT and ASMD
>     if (role_in($role, $admins)) {
>         $authlist['@admin'] = 1;
>     }

The user groups like @admins, @read, @gr are entirely up to you (except 
for @nopass and by convention @lock).

So in order for you to be admin, you need to have something like this:

$DefaultPasswords['admin'] = ['@admins'];

Here the first 'admin' are the name of the permission, the name 'admin' 
is not up to you. The list of usergroups in the brackets, their names 
are unrestricted, up to you.

To have the wiki read-protected, add a read password/permission:

$DefaultPasswords['read'] = ['id:*']; # anyone signed in
or:
$DefaultPasswords['read'] = ['@readers', '@guests']; # user groups

Similarly for $DefaultPasswords['edit'], 'upload', and if you enable 
Drafts, 'publish'.


> This appears to work. Although I?m not entirely sure, as I added my
> login username to the Site/AuthUser page as an admin:
> @admins: xxxx at xxxxx.com  so that might override it?

It should merge the access permissions for the listed users.

BTW do you use email addresses as usernames? It should be okay, except 
that any user profile links in recent changes and in signatures may not 
work.


> Then I tried to add to the page Group.Start access restrictions using
> Group.GroupAttributes?action=attr and adding @gr to all of the access
> control fields (read, edit, attr and upload).

Correct, in addition to $DefaultPasswords, you can use per-group or 
per-page permissions on
   Group.GroupAttributes?action=attr

On that form, place the user groups in the fields, space separated.


> After doing that, the group / page became completely inaccessible to
> me (logged in, and should be at admin level).

After you submit the form at ?action=attr, you get logged out 
automatically. This is normal and expected, allows you to sign back in 
to test the new permissions.

If this annoys you, there is a variable to disable it, look it up.


>  I tried to add
>  $authlist['@gr'] = 1;
> 
> To my own authlist, but even that did not give me access. Where am I
> misunderstanding the way this is meant to work?

If you are in a group which is attached to $DefaultPasswords['admin'], 
you can access all groups regardless of the group permissions. You don't 
need to be in both @admins and @gr, if you are in @admins, you can 
access all pages restricted to @gr.

Petko

-- 
If you upgrade :  https://www.pmwiki.org/Upgrades



From 5ko at 5ko.fr  Fri Apr 24 12:32:47 2026
From: 5ko at 5ko.fr (Petko Yotov)
Date: Fri, 24 Apr 2026 21:32:47 +0200
Subject: [pmwiki-users] Groups and read/edit/write access
In-Reply-To: <e0121d221d79e5baf9e7858a46588436@5ko.fr>
References: <7C0FC060-7DCA-4734-8054-6171864BE35F@gmail.com>
 <3CFAA8F2-E064-41BE-A466-C0D987401779@gmail.com>
 <e0121d221d79e5baf9e7858a46588436@5ko.fr>
Message-ID: <41d5d807c51574d5765b7a1d41374cc9@5ko.fr>

Unless your user database has a column with the PmWiki user group, you 
may find it simpler to define and update the user groups in 
SiteAdmin.AuthUser instead of your own function.

Like:

   @admins: peter, yyyy at xxxxx.com

   @gr: petko, xxxx at xxxxx.com, staff at xxxxx.com

Your function will still authenticate if the user signed in correctly, 
and in this case AuthUser will set the user groups from the page.

Petko

-- 
If you upgrade :  https://www.pmwiki.org/Upgrades

On 24/04/2026 21:15, Petko Yotov wrote:
> On 24/04/2026 20:22, Peter van Es wrote:
>>     # success
>>     # set user groups: everyone logged in can read
>>     $authlist['@read'] = 1;
> ...
>>     # check role and functions
>>     $admins = ['Chairperson ICT', 'Administrative Secretary',
>> 'Ambtelijk Secretaris'];
>>     # admins are ICT and ASMD
>>     if (role_in($role, $admins)) {
>>         $authlist['@admin'] = 1;
>>     }
> 
> The user groups like @admins, @read, @gr are entirely up to you
> (except for @nopass and by convention @lock).
> 
> So in order for you to be admin, you need to have something like this:
> 
> $DefaultPasswords['admin'] = ['@admins'];
> 
> Here the first 'admin' are the name of the permission, the name
> 'admin' is not up to you. The list of usergroups in the brackets,
> their names are unrestricted, up to you.
> 
> To have the wiki read-protected, add a read password/permission:
> 
> $DefaultPasswords['read'] = ['id:*']; # anyone signed in
> or:
> $DefaultPasswords['read'] = ['@readers', '@guests']; # user groups
> 
> Similarly for $DefaultPasswords['edit'], 'upload', and if you enable
> Drafts, 'publish'.
> 
> 
>> This appears to work. Although I?m not entirely sure, as I added my
>> login username to the Site/AuthUser page as an admin:
>> @admins: xxxx at xxxxx.com  so that might override it?
> 
> It should merge the access permissions for the listed users.
> 
> BTW do you use email addresses as usernames? It should be okay, except
> that any user profile links in recent changes and in signatures may
> not work.
> 
> 
>> Then I tried to add to the page Group.Start access restrictions using
>> Group.GroupAttributes?action=attr and adding @gr to all of the access
>> control fields (read, edit, attr and upload).
> 
> Correct, in addition to $DefaultPasswords, you can use per-group or
> per-page permissions on
>   Group.GroupAttributes?action=attr
> 
> On that form, place the user groups in the fields, space separated.
> 
> 
>> After doing that, the group / page became completely inaccessible to
>> me (logged in, and should be at admin level).
> 
> After you submit the form at ?action=attr, you get logged out
> automatically. This is normal and expected, allows you to sign back in
> to test the new permissions.
> 
> If this annoys you, there is a variable to disable it, look it up.
> 
> 
>>  I tried to add
>>  $authlist['@gr'] = 1;
>> 
>> To my own authlist, but even that did not give me access. Where am I
>> misunderstanding the way this is meant to work?
> 
> If you are in a group which is attached to $DefaultPasswords['admin'],
> you can access all groups regardless of the group permissions. You
> don't need to be in both @admins and @gr, if you are in @admins, you
> can access all pages restricted to @gr.
> 
> Petko


