Pmwiki usage:

for scientific documentation/correspondence
as a CMS for personal pages

Pmwiki devel interests:

Cookbook.UserAuth2, improvement of Cookbook.UserAuth
Cookbook.LinuxTex (improving latex support, see wishlist on LinuxTex.Devel and LinuxTex.PureLatex)
addressing attachments "issue", see below, and PITS.00904
wiki security
improving user interaction, e.g.
- better upload facility (use something like Fireflix extension?)
- editing using a usual editor extended by a wiki interfacing unit talking to a WikiEdit API, details below
improving interoperatibility with other data sources, e.g.
- conversion to and from standard office documents
- PITS.00468 Post to PmWiki by email
towards making an AJAX version of pmwiki (possible advantages lie at: login, edit, upload, and possibly better integrated plugins)
to say it in one word: user interface! user interface! user interface!

Contributions/files

Cookbook.UserAuth2 - a user-based authorization module with delegation capabilities (kind of reimplementation of UserAuth)
Cookbook.IncludeFile - a full-fledged (:includefile:) markup
Cookbook.FootnotesExtended
Cookbook.NotifyOnUpload
Cookbook.UploadsMarkup - e.g. Uploads:/MyGroup/MyPage/myfile.txt
Some other extensions that I have in personal use (contact me)
- improved attachlist (related to Cookbook.AttachDelete)

Personal feature wishlist / todo list

(:permissioninfo:) markup that displays all the users that have a right granted on the current or the given page. (One can restrict this to display only permission levels that the caller is itself authorized to inflict, thus displaying only users on the same "level" (list of peers).)
edit skin (if (action=='edit') $Skin = 'mySpecialEditSkin'; else $Skin = 'myNormalSkin'; )
better latex support
exclude own posts from notify mechanism ( done, see 00867)
extend my includefile markup to be able to edit the referenced text file (related to Cookbook.IncludeWithEdit but that edits wiki pages)
Revise pmwiki security: is it sensible and how would it be easily possible to separate executed scripts from files accessed? Using "check docroot" and "open_basedir" options on webserver and PHP level one could elevate the burden to create and execute malicious code, and thus dampen the effect of unnoted security holes in pmwiki code. (stalled, since open_basedir does not have semantics as expected)

Firefox extensions useful in connection with wiki development/production

FireBug: debug and alter html/css/javascript code, obtain timing information for rendering the page
HTML-Validator: this is an extension that checks on client side every page on loading for HTML syntax errors and provides even hints for their solution - just gorgeous
BBComposer: WYSIWYG editor on top of textarea fields supporting MediaWiki (and maybe some day PmWiki?) syntax
"It's All Text": lets user edit textarea fields in external editor; nice for not sacrificing general wiki layout for the edit situation
various picture upload helpers

Some code fragments

These are some code fragments that I found useful. Feel free to copy them around in the wiki, or add some new features etc. (Leave me a notice of what you did.)

Debugging

I use the following code (could evolve to cookbook/debug.php) to debug my pmwiki:

<?php if (!defined('PmWiki')) exit();

SDV($EnableDebug, false);

$dbgAlreadyCalled = false;
$repetitionLock = false;

function debugMsg($label, $text) {
  global $debugfile;
  global $debugEvents;
  global $debugLastMsg;
  global $dbgAlreadyCalled;
  global $repetitionLock;
  global $EnableDebug;

  if (!$EnableDebug) return;

  if (strlen($text) == 0) return;

  if (in_array($label, $debugEvents)) {
    if (!$dbgAlreadyCalled) {
      $debugfile = @fopen("cookbook/debugout.txt", "a");
      fwrite($debugfile, str_pad('', 80, '-') . "\n");
      $dbgAlreadyCalled = true;
    }
    if ("$label$text" == $debugLastMsg) {
      if ($repetitionLock) return;
      $text = 'Last message repeated at least once.';
      $repetitionLock = true;
    } else {
      $debugLastMsg = "$label$text";
      $repetitionLock = false;
    }
    $labelLength = 4;
    $label = str_pad(substr($label, 0, $labelLength), $labelLength, ' ');
    $textArr = explode("\n", trim($text));
    $outtext = '';
    foreach($textArr as $textLine) {
      $outtext .= strftime("%Y-%m-%d %H:%M:%S %Z") . "  $label  $textLine\n";
    }
    fwrite($debugfile, $outtext);
  }
}

To install, place include_once("cookbook/debug.php") as usual in the config.php, and define an array of event labels like

$debugEvents = array(
  # add further event labels here:
  'LOGN', # login
  'LOGT', # logout
  #'LTEX', # linuxtex.php
  #'NOTY', # notification
  #'UPLD', # upload
  ''      # dummy
);

also there. (You can customize the "label table" to your needs.) Further, set $EnableDebug to true. Then, to log events, just place

  debugMsg('xxxx', "myfile.php: My text.\n");

in the code, where xxxx is just one of the defined labels. Selecting certain events can be done by uncommenting some fields in the array. Enjoy.

Special features:

automatically adds time header for multi line messages
surpresses repeating messages

Pmwiki references

PmWiki.AvailableActions
Cookbook.SkinGuidelines
PmWiki.Audiences
PmWiki.DesignNotes
PmWiki.Functions (a page that I have looked for already very long)
PmWiki.CustomMarkup
Cookbook.JavaScript
HansB

Roadmap for the WikiEdit API

Become clear which data flow will be necessary between editor and wiki for all common scenarios
(For example, what exactly should happen if you press "Save" in the editor. Page refresh as well? How?)
Hammer out the details of the API (which actions, how to do authentication, etc.)
Preferably one will want to use HTTP for transferring the data as usual, and authentication could be done by either sending username and password with every request or by accepting a session cookie to the lean browser component working internally.
Find a suitable editor to code a proof of concept
("Where is it easiest to include a HTTP component and pop up some authentication dialogs?")
Do the work
Ask for comments about the API in other wiki communities
Make a standard of it
Convince some editor "manufacturers" to include this component (supporting the standard) into their usual releases
Wait for other manufacturers to catch up

Stuff

{$ClientIP}
(:visitorslist:) limit days author actions
Cookbook/SysDiff.php

Old stuff

Reasoning for solving certain pmwiki interna

Naming scheme for paths to uploaded files

This has been more or less realized in the "Uploads:" markup, see UploadsMarkup. ThomasP December 17, 2007, at 05:09 AM

Concerns every module that has interaction with local (uploaded) files, e.g. (:attachlist:), ..., upload functions, etc.

I propose to let path names be meant as absolute starting from below the upload directory, i.e. /Main/HomePage/file.txt would address a file located in the directory upload/Main/HomePage/ belonging to page Main.HomePage. (The directory structure is thus fixed to look like /Group/Page.) The variable $UploadPrefixFmt should - instead of indicating a prefix under which the files should be stored - rather mean the default directory where to look for a file if no path is given in the markup, as is the case e.g. in

  (:includefile file.txt:)

Actually there is no reason against having just two config variables, one for specifying where files go by default, and one from where they are read by default (like the $UploadPrefixPathFmt variable proposed by Dominique). This could leave the current $UploadPrefixFmt variable intact.

Assume in a wiki $UploadPrefixFmt is set to '/$Group', then in this case the engine would look for the file uploads/Group/file.txt, where Group is the group of the page where the markup is placed.

The following syntax would - using this strategy - be well defined:

  (:newattachlist /:)
  (:newattachlist /Home:)
  (:newattachlist /Home/MyPage:)
  (:newattachlist:)

meaning that the engine should show the list of files

in the upload root dir (= uploads/),
in the group dir of group Home (= uploads/Home/),
in the page dir of page Home.MyPage (= uploads/Home/MyPage). or
in the page dir of the current group ($UploadPrefixFmt='/$Group') or the current page ($UploadPrefixFmt='/$Group/$Page').

Note that this leads to a common file structure for everyone using pmwiki, but still retains the possibility of storing the files grouped wherever you want. When uploading files for example (especially when using the "upload" button), one should be allowed to specify where the file is put. (The field "Save as" should take also path names to this end, that are meant (consequently) as absolute starting below the upload root dir.)

Usually one would only allow path specification using slashes. Considering the current way of addressing attachments in directories different from the current one (using Attach:Group.Page/file.txt etc.), it shows that the new strategy can coexist with that way, so it would not disrupt the workings of already deployed wikis.

Some extra implementation would be necessary besides changing every single module: currently permission checking is done using the current page (where the markup is placed) as reference. With the new strategy, that page should only do the job of handling the action, while permission checking is done using the path specified. (E.g. when uploading a file with

  Attach:/OtherGroup/file.txt

or displaying files with

  (:newattachlist /OtherGroup:)

(where we assume that this markup is placed in group Home, = different from OtherGroup), the group OtherGroup should be taken as reference for the "upload" permission check.) This means that these checks also have to be possible for groups or the root dir, and this is a really new thing that needs to be implemented then (though it would be not much work, as I estimate from the UserAuth module).