Improving PmWiki road map
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
The following is intended to prompt discussion on the development of PmWiki. It looks at the following aspects of PmWiki
- PmWiki website
- PmWiki template, styles, and configuration
- PmWiki code base
- PmWiki recipes
- PmWiki features
- PmWiki testing
These are suggestions to spark a conversation from the PmWiki community.
These suggestions are for the PmWiki website, https://pmwiki.org, not necessarily for the release.
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 PmWiki.org 2010-01-26 OliverBetz
- Move to file upload storage to per page directories
- Remove non referenced attachments
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.
- 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
- ... ?
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
$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
$EnablePageIndexexists 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
- ... ?
- remove case sensitivityPITS.00322
- for markup
- for markup directives
- for directive parameters
- for page names
- wysiwyg editorPITS.00421
- 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
- 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
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 gonewiki.redaxo.de, well designed ; and found the way http://www.cef-cfr.ca/ 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