[pmwiki-devel] Ideas for discussion related to Extensions

[Petko Yotov]

Sorry for the delay, lately I've been under a lot of pressure at work 
and I haven't had the time and peace to think about the extensions 
architecture. But maybe the dev list can help me with advice.

Before we advertise this widely and ask people to create their own 
extensions, we have to decide these questions:

1. How to prevent PHP and CGI scripts in the pmwiki/extensions 
subdirectories from being reachable by a browser and executed by the 
server, bypassing pmwiki.php or hub.php. This includes recipe page/form 
files.

The file extensions/hub.php needs to be browser-accessible in order to 
serve resources from compressed extensions, so we need configuration 
options for .htaccess  widely-available across many hosting providers to 
allow one PHP file but block all others. RewriteEngine may not be 
enabled everywhere. I haven't found one. This only applies to 
uncompressed extensions. I see a few possible solutions:

- Mandate that extensions ship with a .htaccess file that disables 
direct browser access to scripts when the extension is uncompressed. If 
there is no such file or it is not correct, the hub can refuse to enable 
the extension.

- Move individual extensions to a subdirectory like "extensions/exts", 
so for example Filterable will be "extensions/exts/Filterable" instead 
of "extensions/Filterable". This will make it easier  to deny direct 
access to PHP files via .htaccess.

- Deny direct browser access to hub.php and use a special pmwiki.php 
action. This may be more secure but will potentially be much slower than 
hub.php as pmwiki.php is large, and loads a large number of other large 
scripts before it processes actions.

OTOH, I may be overthinking this; a rogue script in an extension could 
simply configure a PmWiki action, it doesn't need direct browser access. 
(Like the current skins and cookbook recipes.)  The cookbook directory 
is protected by a .htaccess file, and could even be placed outside of 
the document root, but this is only to prevent unintentional errors, not 
evil code. And the current skins have similar structure and are in 
browser-reachable locations, without reported problems.

Also, while Apache is very popular, there are other web servers, and 
.htaccess wouldn't work on them.

What do you think?


2. It makes sense to allow PmWiki skins to be managed by the hub, and 
for admins to place them in this common directory, maybe under 
extensions/skins instead of or in addition to pmwiki/pub. Like 
extensions, skins could be uncompressed or left compressed.

In this case, should the main directory be "extensions"? Skins are a 
kind of extension extending layout and colors. Or should there be a 
different parent directory and have both extensions and skins as 
subdirectories?

This decision may change the directory structure, the code, and the 
documentation, and should be made before other people start adding 
extensions.

BTW unlike recipes, the current skins should not need to be modified for 
the hub, existing skins should work.


3. There is a recent request on PITS:01501 to make the core PmWiki 
installation "no-touch", without any custom files (local files, skins, 
cookbook recipes, pub resources including pub/css and from recipes), so 
people can more easily upgrade to new PmWiki versions and revert to 
older ones.

This is very sensible and will help people who update manually instead 
of using version control or scripting - and shared hosting providers 
rarely allow version control or even shell access with open network.

The Extensions concept is a step in the right direction, but there is a 
lot of documentation and recipes that assume the default way of 
interspersing custom files into the core directories. And the Extensions 
documentation also instructs to place the extensions directory inside 
the core distribution, as a sibling to scripts/. This is not required 
for the hub to work though.

BTW it is now possible to run the whole PmWiki directly from the zip 
archive, this is an even more extreme variant of a "no-touch" 
installation but probably not very efficient because of the 
decompression overhead. Or not, I haven't found the time to benchmark 
this, and to document it.


4. I'd like to figure out an easy way for recipes to ship with UI 
translations in different languages, i.e. easier than the current 
XLPages, or via XLSDV() in the PHP code.

I'm thinking about having the translations in the extension 
configuration form page, something like this:

[[#i18n]]
en: Some label in English
fr: Translation of the above in French
de: German this is in.
----
en: Another label in English
fr: L'étiquette en français
----
[[#i18nend]]

When the extension is enabled, its translations are parsed and added to 
different XLPage configuration pages, so when a wiki group loads another 
language, only its configuration array would be loaded.

Not sure what happens if some label is modified or removed, or when an 
extension is disabled or removed, and how will the XLPage array be 
updated. Also, how can a user add a new language translation to their 
own wikis? They should be able without having to ask the extension 
maintainer.

See also below:

On 27/04/2024 06:42, Simon wrote:
> First perhaps adding:
> 
> Extension:  https://www.pmwiki.org/wiki/Cookbook/
> Profile:    https://www.pmwiki.org/wiki/Profiles/
> 
> to intermap.txt or better to PmWiki | Site / InterMap

Not sure about that, what if people have defined these on their own 
wikis to point to something else? We discussed this when we added 
Skins:, let me think about it.


> Second,
> while it is early days I'd like to suggest that extensions go in their
> own group, viz https://www.pmwiki.org/wiki/Extensions/
> 
> I see this having the benefit of clearly separating the new direction
> of extensions from the Cookbook, perhaps encouraging people to look in
> extensions first.

This is possible, but we can also stay within the Cookbook group and use 
categories.

What do other people think of that?

Extensions will potentially have the same categories as the Cookbook 
(Administration, Images...). People should be able to see both classic 
recipes and extensions in the same listings.

What should we do if an existing recipe is ported to the extension 
format? It may be best to use the same Cookbook page, and while leaving 
the old version available for download, make it clear that the new 
version is different, how to install it, and how to uninstall the old 
one.

This - migrating classic recipes to extensions, when people have 
existing local configuration in he old format - is something I haven't 
figured out yet.

Petko