Improving PmWiki road map

Current discussion

Allow trail= option to pagelist to accept wildcards. What does this mean exactly? I assume specifying a pattern or a list of pages like "Main.HomePage,Category.*,-Category.Private". Then should all pages be opened and the trail built from trails in all of them, or should that be only the first page found (like for IncludeOtherPages)? What happens if there is an anchor like "Main.HomePage,Category.*,-Category.Private#trail#trailend", should this apply to all pages or just to the last one? --Petko September 09, 2019, at 12:53 PM

Pre-2019 discussion

The following is intended to prompt discussion on the development of PmWiki. It looks at the following aspects of PmWiki

These are suggestions to spark a conversation from the PmWiki community.

PmWiki website

These suggestions are for the PmWiki website,, not necessarily for the release.

01135  Compare cookbook recipes (Open)
01137  Key PmWiki Features on the front page (Open)
01233  Cleanup the Cookbook (Open)
01265  New homepage and default skin ideas (Confirmed)

Add new group for Developer

Add new group for developer and internals (merge these categories) There is a significant amount of developer documention in the PmWiki and Coookbook groups. It makes sense to separate this from the "user" oriented groups and combine in its own area.

I would like to see a book developed with the developer documentation.

Encourage use of the website

While the email news groups are a mine of information, there is a lack of transfer of that information to the website. Encouraging the use of the website through more use of questions and other? means pages would be beneficial. The provision of "section edit" and "page toc" might be of benefit.

  • more intensive use of talk pages
  • DaveG 5-Jan-2011: Persoanlly I don't find wiki pages convenient for length discussions, and prefer the email lists. What we should encourage though is for people receiving an answer to a question, to update the wiki appropriately. Perhaps a gentle reminder to update pages after a discussion end.
    • I agree 100% with DaveG. The mailing list is much better (efficient) for discussion but results should be kept at 2010-01-26 OliverBetz


PmWiki Configuration

This section covers the configutation handled by /local/config.php, group, and page config files, and the pages provided in the Site and SiteAdmin groups.

Template content

  • make all content maintainable from the front end, eg logo, header (top bar), footer (bottom bar), page actions
  • move more configuration from config file to wiki, for example
    • ... ?

Code base

There is a tension between keeping the wiki simple (steady as she goes) and adding features (and complexity). Favour an incremental evolution of new features and improvements.

  • improve support/API for recipes
  • improve support/API for skins
  • consider moving some core candidates into the PmSiki base code
  • ... ?
  • can we vote to remove some features out of the core?CarlosAB January 05, 2011, at 12:59 PM
    why not make the suggestions here simon March 27, 2011, at 09:54 PM
    • remove $EnablePageIndex, I asked for it and I admit it was a bad thing to ask for, as it slows down pmwiki a lot, when you have many pages to be searched. AFAIK what it does can be done better and faster, out of PmWiki code.CarlosAB
      • $EnablePageIndex exists specifically to speed up searches and pagelists. In most cases, especially in wikis with many pages, it should be very useful. I don't see a case where it should be switched off, but you can switch it off if needed. --Petko August 06, 2012, at 12:35 PM
      • It slows down searchs considerably, I've tested, but yes you can always turn it off at any time. CarlosAB August 06, 2012, at 01:41 PM
    • Don't remove vspace, now I understand it fully.CarlosAB


  • add support/documentation/APIs for recipes so there is a basic framework
  • isolate recipes more from the core allowing PmWiki's evolution to continue with less risk of breaking recipes
  • ... ?


I just gave a presentation about PmWiki at a Texas science teacher convention. I prefer the present system but not having wysiwyg is a sticking point for new users.
17-May-2011: A fund drive has been setup to cover the costs of creating a WYSIWYG capability for PmWiki.
  • increase and improve markup consistency
    • expressions the same whether in all directives (eg if, pagelist) or as parameters
    • css and style to work the same in all span and block directives
  • improve accessibility support
    • font resizing in core
  • support skinning for different media out of box
    • pda
    • phones
  • search
    • incorporate context snippets with results returned
  • blogging (strongly supported)
  • built in table of contents
  • automatic generation of anchors for headings (also see PITS.01224)
  • lightweight user registration (cf wikimedia)PITS.00010
    • self registration (Id, email, password)
    • self recovery of password using email
    • integrated into AuthUser and login


Can we develop some units tests for PmWiki, and for recipes, perhaps using HtmlUnit and PHPUnit


There is value in PmWiki being widely used, this encourages and supports development. To do this requires the community to support it widely, eg Wiki Matrix, Wikipedia:PmWiki, Wikipedia:Comparison_of_wiki_software

  • get PmWiki added to Fantastico
  • list some nice (well designed or pmwiki engine best usages) installations (a limited showcase)?
    I have discovered, well designed ; and found the way is working very interesting. In my case, I would like some « case studies » (cf. drupal) to know how skilled users succeeded doing their project with pmwiki. gb November 21, 2010, at 02:43 PM

This is a talk page for improving PmWiki.RoadMap.