Commenting mostly on the recipes I'm responsible for: 2009/8/28 Twylite <twyl...@crypt.co.za>: > So basically if I don't know it exists, I'm not going to look for it > unless I have a specific problem that needs to be solved. Which means > that short of browsing through all the recipes I won't find ones that > could be enhancements rather than just solutions.
Random inspiration from this: in addition to recipe +/- voting and download counts, how about a "featured recipe" for each week or month, that could get some visibility on the front page and/or <http://www.pmwiki.org/wiki/Cookbook/Cookbook>? This could require a nomination and short recommendations from, say, three or four different people. > * Rename pages > http://www.pmwiki.org/wiki/Cookbook/MovePage is an alternative, and > suggests that RenamePage has problems. RenamePage doesn't update the page history when you move a page, so reverting a move is tricky. I also never quite felt comfortable with its interface for determining the new page name, and the link renaming options and functionality confused more than helped me. Finally, MovePage is less than a third the size of RenamePage, and (hopefully) has none of its problems. > RenamePage hints at consequences to moving between Groups (unqualified > attachments may go astray), but I don't see any discussion on any recipe > page of the interaction between page renaming and > http://www.pmwiki.org/wiki/Cookbook/UploadPlus. Are there situations > (similar to page renaming) that may affect the choice to use a > CustomPageStore or to group uploads? There's some discussion on <http://www.pmwiki.org/wiki/Cookbook/MovePage-Talk>, but your question isn't actually very simple to answer, as there are multiple levels at which stuff happens regarding uploads. UploadsPlus does a number of different things, of which only its $UploadPrefix array might be significant here. And to answer your question, integrating that with eg. MovePage once it handles attachments as well would require some custom code in the recipe since UploadsPlus changes the default way of mapping a string (eg. "Attach:Main./file.ext") to a file path... probably by abusing the way $UploadPrefixFmt gets by default passed through FmtPageName, which means that you could define a page variable that does a lookup from $UploadPrefix array, which means that you've essentially re-implemented most of UploadsPlus with about ten lines of code. Perhaps I should check this and post it to the recipe page itself. > * Restricted delete > Recovering deleted pages is often not straightforward (sometimes not > possible at all, sometimes not possible through the web interface), so > it can be desirable to restrict page deleting to some set of authorised > users. In PmWiki, it is possible but requires shell or FTP access to the server. "Deleted" pages are renamed with a suffix that makes them impossible to find as normal pages via PmWiki. > * Diff between arbitrary revisions > Most Wikis have this functionality; PmWiki seems to lack it. > http://www.pmwiki.org/wiki/Cookbook/ViewDiff appears to do this > http://www.pmwiki.org/wiki/Cookbook/InlineDiff also looks like a > popular/useful enhancement, but doesn't appear to diff arbitrary > revisions. Are these two compatible? Also InlineDiff has a "modified > version" attached to the bottom of the page; is that a separate > (unnamed) recipe? ViewDiff defines a new action (viewdiff) that lets you see the state of a page at a specific time, while InlineDiff modifies the output of a default action (diff), so they should not conflict. As for integrating InlineDiff-type diff display to ViewDiff, I don't know enough about ViewDiff to comment on that. As for InlineDiff's modified version, I should probably clarify in the comment that it does require also a download of the pagerevinline zip file. It's not really a separate recipe ass I've just cleaned up the code a bit. 2009/8/28 Twylite <twyl...@crypt.co.za>: > * Changing the linking scheme of the Wiki to an > http://www.pmwiki.org/wiki/Cookbook/AlternateNamingScheme or even to > disable CamelCaseLinks needs to be done from the start. CamelCaseLinks > could be enabled later, but not disabled without a significant > probability of destroying existing links. I believe CamelCase is now disabled by default. > * Getting rid of Main (http://www.pmwiki.org/wiki/Cookbook/GetRidOfMain) > or changing the group home page name > (http://www.pmwiki.org/wiki/Cookbook/GroupHomePageChange) would involve > renaming pages and altering links, and may not be straightforward > depending on the size of the Wiki. For a public Wiki this would also > destroy URLs that may have been bookmarked. This should actually be do-able without any disruption, as old URLs should still resolve to the same pages. Actually, I'd recommend against either of these choices. What I've done instead is reconfigure group main pages to not contain the page name, such that the URL for Cookbook.Cookbook on pmwiki.org would be <http://www.pmwiki.org/wiki/Cookbook> instead of <http://www.pmwiki.org/wiki/Cookbook/Cookbook>. > * If I introduce say > http://www.pmwiki.org/wiki/Cookbook/PageTableOfContents to create ToCs, > but later find that it is buggy or doesn't interact well with some > common/useful recipes, then I may need to change the markup on many > pages in order to migrate to another ToC recipe. If you're afraid of something like that, then you probably ought to put the TOC into a GroupHeader and make its inclusion on a page be enablable using a page text variable. eemeli _______________________________________________ pmwiki-users mailing list pmwiki-users@pmichaud.com http://www.pmichaud.com/mailman/listinfo/pmwiki-users