[pmwiki-users] Recommended recipes?

Eemeli Aro eemeli at gmail.com
Fri Aug 28 09:10:08 CDT 2009


Commenting mostly on the recipes I'm responsible for:

2009/8/28 Twylite <twylite at 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 <twylite at 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



More information about the pmwiki-users mailing list