[pmwiki-devel] Ideas for discussion related to Extensions

[Petko Yotov]

For people who wonder what "Extensions" are, these are a new family of 
recipes that are easy to install, configure and update with a 
configuration panel I call "hub". Check these pages:

   https://www.pmwiki.org/wiki/Cookbook/ExtensionHub
   https://www.pmwiki.org/wiki/Cookbook/ExtensionDesign
   https://www.pmwiki.org/wiki/Cookbook/Extensions

Petko


On 17/05/2024 22:01, Petko Yotov wrote:
> 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