Summary: Instant search in the current page, with highlighting.
Version: 20160219
Prerequisites: JavaScript, recent browser
Status: Experimental
Maintainer: Petko
License: GPLv3+
Categories: Searching, Layout, PHP55, PHP72
Users: (view? / edit)
Discussion: FindInPage-Talk


The recipe provides an input field allowing the readers to search within the contents of the current page.

You can test the recipe here.

The paragraphs, list items, table rows and other elements which DO NOT contain the search terms will be hidden or will appear with less contrast. Those which DO contain the search terms, will appear normally and the search terms will be highlighted.

The recipe will automatically skip section headings (h1-h6) and table rows with headers (tr>th), that is, these elements will not be hidden or blurred if they do not contain the searched text. This is needed for the reader to know in which section of the page the search terms are found.


Place findinpage.js into your pmwiki/pub directory.

Add to config.php such a snippet:

if($action == 'browse') {
  $HTMLStylesFmt['findinpage'] = '.fip_notfound{color: #999;} mark{background-color:yellow;color:black;}';
  $HTMLFooterFmt['findinpage'] = '<script type="text/javascript" src="$FarmPubDirUrl/findinpage.js"></script>';
  $WikiStyle['nofilter'] = array('apply' => 'block', 'class' => 'fip_nofilter');
Markup_e('nofind', 'directives', '/\\(:nofind:\\)/i', 'PZZ($GLOBALS["HTMLFooterFmt"]["findinpage"]="")');

This will install the recipe to all pages; to insall it to individual pages or groups, instead of config.php, use Group.Page.php or Group.php, see Group customizations.


The paragraphs and other block elements that do not contain the search terms, will acquire the CSS class "fip_notfound". You can modify the styles in the above snippet (CSS knowledge recommended, note the initial dot):

  • .fip_notfound{color: #999;} change text color to light gray (adapt this to your site design)
  • .fip_notfound{opacity: 0.5;} reduce contrast/saturation to elements without matches (may require fast processor)
  • .fip_notfound{display:none;} more dramatic, hide completely the elements

The highlighting color, default yellow, can also be modified, eg.:

  • mark{background-color:yellow;color:black;} black letters on yellow background
  • mark{background-color:#afa;font-weight:bold;} bold font on light-green background


As a reader: simply type the search terms. Separate search terms with spaces if you need more than one search term. The matches will appear highlighted.

As a writer: if some block elements need to be always visible, even when they do not contain the search terms, apply the wikistyle %nofilter% or >>nofilter<< to them, eg.:

%nofilter% This paragraph will always be shown.

* filterable list item
* %nofilter% always shown

By default the search form will appear at the top of the "#wikitext" element, right below the page title. If you need to place this element elsewhere in the page, place an element with id=fip_form where it should be:



  • The recipe will not highlight text and may even not work at all for Microsoft Internet Explorer version 8 or earlier.
  • This recipe may be incompatible with recipes using JavaScript to listen to events (clicks...) on elements of the page, like UnToggle, because it rewrites the HTML source of the highlighted elements and this can disable all events.

Change log / Release notes

  • 20160219: fix bug with definition lists.
  • 20160210: major improvement for the highlighting speed; fix for html entities that were not highlighted; prevent form to be submitted to the server.
  • 20160209: add button to start the search.
  • 20160207c,d: fix bug with textarea elements, reported by RandyB.
  • 20160207b: fix bug with finding quotes; reduce CPU usage by adding an interval of 1.5 seconds between scans.
  • 20160207: first public release, ready to be tested.

See also


  • Recipe written and maintained by Petko.


See discussion at FindInPage-Talk

Some additional content here

 Pagelist template
(:div32774 style="border-top: 2px solid red;":)
!! Content from {=$FullName} %block color=red%
(:include {=$FullName}##faq:)

Content from PmWiki.AccessKeys

Access keys (See also Wikipedia:access keys) are keyboard shortcuts for tasks that would otherwise require a mouse click. They are part of markup that may exist on any webpage. On PmWiki steps have been taken to make it easier to use access keys throughout a site, and to make it possible to adjust key assignments to accommodate different languages and preferences.

Using access keys in different operating systems and browsers

Access keys require you to hold down two or more keys.

  • On Windows with Internet Explorer, press ALT + the access key.
  • With Firefox, press SHIFT + ALT + the access key.
  • On a Macintosh with Firefox, Omniweb, Internet Explorer, press Ctrl + the access key.
    • With Safari (Version 4.0.2) press Ctrl + Option + the access key.
  • With Opera press Shift+Esc to enter (or exit) access-key mode.
  • With Konqueror, press Ctrl to enter (or exit) access-key mode.
  • With Chrome, press SHIFT + ALT + the access key

Exceptions exist for specific browsers, and specific versions. For example,

  • Internet Explorer requires that the Enter key be pressed at the end of the sequence for versions 5 and up under Windows, but not under Macintosh (where access keys were not supported until after version 4.5).
  • Firefox versions 1.5 and earlier simply use Alt, while Firefox version 2.0 uses Shift+Alt.

Note, in cases of conflicts between the keyboard shortcuts assigned by browsers and access keys assigned by links and other markup on webpages, many browsers, including Mozilla, Netscape and Internet Explorer, allow access keys to override the browser defaults and require a different sequence to continue using overridden browser assignments (typically, by pressing and releasing the Alt key, instead of holding it down).

Access key assignments in this PmWiki installation

The following is a list of the currently defined access keys for built-in actions. Remember that the letters identified below must be used together with the combination listed above (depending on your operating system and browser). Note that some actions do not have a corresponding access key by default.

Key NameKey ValueFunction
ak_view view
ak_attach attach
ak_print print
ak_backlinks backlinks
ak_logout logout
ak_recentchangescrecent changes
ak_savessave or publish page
ak_saveeditusave and keep editing
ak_savedraftdsave draft
ak_previewppreview page
ak_textedit,jump to edit textarea
ak_em emphasize text
ak_strong strong text
Note: If the 'Key Value' is the same as the 'Key Name', the access key is currently undefined.

When can these access keys be used

  • Access keys ak_view, ak_edit, ak_history, ak_attach, ak_print, ak_backlinks, ak_logout and ak_recentchanges can be used all the time
  • Access keys ak_save, ak_saveedit, ak_savedraft, ak_preview, ak_textedit can only be used in edit mode

Following table explains which button is activated by which access key. Note that the Cancel button has no access key.

Standard Edit modeDraft Edit modeUsed Access Key
 Save draftak_savedraft
Save and editSave draft and editak_saveedit
  • Access keys ak_em and ak_strong work only in edit mode and when the GUIbuttons are enabled in local/config.php.

admins (intermediate)

Customizing access keys

PmWiki uses the same "phrase translation" methods for access key mappings as it does for internationalization. This makes it possible for administrators, skins, language translators, and visitors to all influence the way that specific keys are mapped to actions.

See SitePreferences and Site.Preferences for more information and a template.

Note that some skins (e.g., Lean) don't use the translation mechanism. In this case one must edit the template file itself in order to change the access keys.

By convention, the translation phrases for all of the access key actions start with the characters "ak_", so that the page variable "$[ak_edit]" is replaced by the access key for editing as defined by the current preferences, language, skin default, or site default.

Implementation of access keys

Access keys are implemented in html as optional parameters that can be added to links and many other types of markup.

Example: <a href="" accesskey="x">Example</a> would create a link to that could be triggered by clicking on the linked word "example" or using the access key Akey+x. That same action key link could be created in PmWiki markup by typing %accesskey="x"%[[|Example]]%%, like this: Example. Try it and see if it works. Note that this AKey+x access key only works this way on this page, because it is simply a shortcut for accessing the link that exists only on this page.

The list of access key assignments in default PmWiki installations generally work throughout a site because links have been created in PmWiki skins and editing screens that incorporate access key parameters using the access key translation phrases. One location where those links can be viewed is Site.PageActions. That page contains the links that the default PmWiki skin, and many other skins, use to generate links such as "View" "Edit" and "History" that appear on most pages (other than editing screens). Each of the links in that page also has an %accesskey=$[ak_xxx]% declaration in front of it, which enables a specific access key for that link.

Content from PmWiki.AccessKeys-Talk

  • Discussion moved to PITS:01231 (Allow XLPage entries to have empty values).

Content from PmWiki.AdminTask

PmWiki Administration Tasks

This is a (experimental) list of all PmWiki administration related tasks that is organized in alphabetical order (and delimited by anchors so that it can be reused in other Wiki pages on this site). It is sort of based on core concepts of DITA in which a topic is an archetype for information type. A topic is a unit of information that describes a single task, concept, or reference item. The information category (concept, task, or reference) is its information type (or infotype).

Tasks that are general in nature are on a different page. In DITA terms, AdminTask is a topic specialization of Task (which is a topic). Granted DITA is much more powerful and we cannot get all its benefits with PmWiki yet but perhaps one day, thanks to the genius of Pm, we can try and achieve more with every PmWiki release.

This page (meaning its URL) itself should NOT be linked to from anywhere but the sections should be included by using a syntax such as:

(:include PmWiki.AdminTask#start#end:).

Administering Passwords

You can set passwords on pages and groups exactly as described above for authors. You can also:

  1. set site-wide passwords for pages and groups that do not have passwords
  2. use attr passwords to control who is able to set passwords on pages
  3. use upload passwords to control access to the file upload capabilities (if uploads are enabled)
  4. use an admin password to override the passwords set for any individual page or group

For more information on password options available to administrators, see PasswordsAdmin.


Setting Site Wide Passwords

One of the first things an admin should do is set an admin password for the site. This is done via a line like the following in the local/config.php file:

    $DefaultPasswords['admin'] = pmcrypt('secret_password');

Note that the pmcrypt() call is required for this -- PmWiki stores and processes all passwords internally as encrypted strings. See the crypt section below for details about eliminating the cleartext password from the configuration file.

To set the entire site to be editable only by those who know an "edit" password, add a line like the following to local/config.php:

    $DefaultPasswords['edit'] = pmcrypt('edit_password');

Similarly, you can set $DefaultPasswords['read'], $DefaultPasswords['attr'], and $DefaultPasswords['upload'] to control default read, attr, and upload passwords for the entire site. The default passwords are used only for pages and groups which do not have passwords set. Also, each of the $DefaultPasswords values may be arrays of encrypted passwords:

    $DefaultPasswords['read'] = array(pmcrypt('alpha'), pmcrypt('beta'));
    $DefaultPasswords['edit'] = pmcrypt('beta');

This says that either "alpha" or "beta" can be used to read pages, but only the "beta" password will allow someone to edit a page. Since PmWiki remembers any passwords entered during the current session, the "beta" password will allow both reading and writing of pages, while the "alpha" password allows reading only. A person without either password would be unable to view pages at all.

To generate an encrypted string from your cleartext password so that the cleartext doesn't appear in the config file, go right to


(add that to tail end of your address URL) for a form to use to encrypt the desired cleartext string into an encrypted string. Then simply copy the encrypted string and paste it in the config file where needed. --DP


To upgrade PmWiki:

0. If you're upgrading to a new major release (a release where the second number changes, as in going from 0.5.27 to 0.6.0), then carefully read the PmWiki:ReleaseNotes before performing an upgrade to see if there are any significant changes or preparation tasks that must be handled before performing the upgrade. Upgrading from a beta version of 2.0 is quite easy, but taking a look at the 2.0 PmWiki:ReleaseNotes doesn't hurt.

1. It's always a good idea to have a backup copy of your existing PmWiki installation before starting. You can copy the entire directory containing your existing installation, or you can just make copies of the wiki.d/ directory and any other local customization files you may have created (e.g., config.php, localmap.txt, etc.).

2. Download the version of PmWiki that you want from

3. Extract the tar image using tar -xvfz tgzfile, where tgzfile is the tar file you downloaded above. This will create a pmwiki-x.y.z directory with the new version of the software.

4. Copy the files in pmwiki-x.y.z over the files of your existing PmWiki installation. For example, if your existing PmWiki installation is in a directory called pmwiki, then one way to copy the new files over the existing ones is to enter the command:

cp -a pmwiki-x.y.z/. pmwiki

Note that Mac OS X and other BSD systems will not not have the -a option as a command-line argument for cp, but that's okay, since it's just shorthand for cp -dpR, so use that instead of -a.

On (some) FreeBSD servers you need to use

cp -Rpv pmwiki-.x.y.z/. pmwiki

5. That's it! As long as you didn't make any customizations to the pmwiki.php script or to the files in scripts/, your PmWiki installation should continue to run correctly! (Local customizations should go in local/config.php)

Cleaning Up Deleted Files

When wiki pages are deleted, they leave behind residue as the deleted file isn't exactly deleted, but instead renamed to $FullName,del-TIMESTAMP. If you have a lot of deleted pages laying around, this builds up cruft in you file space. This is one method for cleaning up deleted pages.



Category: Administration

Content from PmWiki.AnalyzeResults

This page contains the instructions and possible responses from using the Site Analyzer.

Instructions for site administrators

  1. Download the analyze.php script and place it in your site's cookbook/ directory.
  2. Add the following lines to local/config.php, changing $AnalyzeKey to a key to use for your site.
    $AnalyzeKey = 'secret';
  3. Fill in the form at the top of the site analyzer page with the url used to access your site and the value of $AnalyzeKey that you set in local/config.php.
  4. Press the "Analyze Site" button.
  5. The PmWiki server will contact your site and report back with information on recommended configuration changes to your site and any vulnerabilities you may need to consider.

Checking the "Allow to save a copy of analysis results" box will save a copy of the analyzer results in a private (web inaccessible) section of the server. Having copies of results from many systems will help us to improve the analyzer and future configuration and security options for the PmWiki distribution.

Obtain site configuration ... no connection

The analyzer was unable to connect to the site. This may be because the url was entered incorrectly, the site is behind a firewall, or is otherwise inaccessible to the server.

Obtain site configuration ... missing analyzer

The analyzer was able to reach the site, but the site did not respond to the ?action=analyze request. You may need to install the analyze.php script. This script should go in the cookbook/ directory, and then be enabled with

$AnalyzeKey = 'secret';

Obtain site configuration ... no key

The analyzer was able to contact the site, but the site does not appear to have an $AnalyzeKey set.

Obtain site configuration ... invalid key

The analyzer reached the ?action=analyze request, but the key entered did not match the $AnalyzeKey on the remote site.

Obtain site configuration ... update

A newer version of the analyze.php script is available -- you may wish to download it and re-run the analysis.

$FarmD register_globals vulnerability ... ok

Your site does not appear to have the $FarmD register globals vulnerability.

$FarmD register_globals vulnerability ... vulnerable

Your site appears to be vulnerable to the $FarmD register globals vulnerability. This vulnerability is being actively exploited in the wild, so you should do one of the following at the earliest opportunity:

  • Upgrade to a version of PmWiki at least 2.1.22 or greater.
  • Turn off register_globals in the php.ini or .htaccess file.

Recipe versions ... ok

All of the cookbook recipes active at this url appear to be up-to-date. Here's a list:


Recipe versions ... check

There appear to be some new versions of cookbook scripts* available. Here's a list:


* Note: Not all scripts reported here are necessarily installed. This list includes all PHP scripts in the cookbook directory, regardless of whether they are included via config.php or not. (PmWiki reports on all scripts in the cookbook directory because they may be conditionally included in certain configurations.)

AuthUser vulnerability ... ok

Your site does not appear to have the AuthUser vulnerability.

AuthUser vulnerability ... upgrade

Your site does not have the AuthUser vulnerability at the moment. You are, however, strongly encouraged to upgrade to PmWiki version 2.2.2 or later, as some future configuration of your hosting server might put you at risk.

AuthUser vulnerability ... probably vulnerable

Your site may be vulnerable to AuthUser vulnerability, if it relies on the core module AuthUser for User:Password authentication. This vulnerability may be actively exploited in the wild, so you should do one of the following at the earliest opportunity:

  • Upgrade to a version of PmWiki at least 2.2.2 or greater.
  • Turn on magic_quotes_gpc in the php.ini or .htaccess file.

?action=diag ... enabled

Your site is running with $EnableDiag set to 1, and others are able to perform ?action=diag on your pages to get diagnostic information about your site. While this isn't necessarily a bad thing ( does it), it can show a lot of configuration information that you might not want to be publicly available.

You may want to change local/config.php to have $EnableDiag=0 (PmWiki's default). A useful alternative to setting $EnableDiag in local/config.php is to set it in a per page customization, so that ?action=diag is enabled only on a single page instead of the entire site. To provide additional security use

if (CondAuth($pagename, 'edit')) $EnableDiag = 1;

$ScriptUrl setting ... relative

Your site has the $ScriptUrl variable set to a relative url -- i.e., without a leading http:// or https:// prefix. While this may appear to work in many situations, some web standards (e.g., web feeds and HTTP redirects) require the use of a fully-qualified (absolute) url. You may want to update your setting of $ScriptUrl to use an absolute url instead of a relative one.

If you want PmWiki to use relative urls for its internal page links, try the $EnableLinkPageRelative setting.

Content from PmWiki.AQ

This page is not a FAQ. It is just a repository for questions about PmWiki that have been answered. If you have asked a question about PmWiki and someone has given you the answer, please put them here. Then the next poor sod who has the same or similar question will at least have a chance of finding the answer on their own.

This page started in response to the following question.

Why don't we use a forum instead of this "AQ" page?

Because the forums (otherwise known as message boards or bulletin boards) are great for holding conversations, but sometimes poor for reaching conclusions. At least here someone can edit my inane comment, sparing future readers the agony of reading it.

Why not post "answers" on a page related to the question?

Because some users, while quite willing to enter the text, can't figure out where to put it. This page at least provides a home for the answer until it can be moved elsewhere. It also means that searchers may find the answer here.

Why doesn't my redirect file work?

When doing test, you probably don't want to use the "index.php" name to don't kill your site at first. But be aware that the redirect line you have to include is a php script and must be pasted in any file with the "php" extension", for example "test.php", not any test.html...

Category: Questions

Content from PmWiki.Audiences

This page contains Patrick Michaud's comments regarding the "audiences" for which PmWiki was designed. As such, many people are reluctant to modify the page, because it is a statement of his opinions and describes some of the thought that went into creating PmWiki. (And we all thank him for that!)

Patrick's comments

I think of PmWiki in terms of two audiences:

  • Authors are the people who generate web content using PmWiki, and
  • wiki administrators are the folks who install, configure, and maintain a PmWiki installation on a web server.

In some senses it could be claimed that as the primary developer of PmWiki I should only have wiki administrators as my target audience, and that authors are the target audience for the administrators. But what really makes PmWiki useful to wiki administrators is that I've put a lot of consideration into creating a tool that is usable by authors, so I have to keep the needs of both audiences in mind as I'm designing and adding new features to PmWiki.

Within the authoring audience I see that there are "naive authors" and "experienced authors".

"Naive authors" are the folks who use wiki to generate content but may know next-to-nothing about HTML, much less style sheets or PHP or the like. Naive authors are easily discouraged from generating web content if they have to wade through markup text that has lots of funny and cryptic symbols in them. So, if we want a site with lots of contributors, we have to be very careful not to do things that will cause this group to exclude themselves from participating.

"Experienced authors" are the folks who know a lot about HTML and could write their content as HTML, but have chosen to use wiki because of its other useful features (ease of linking, collaboration, ease of updates, revision histories, etc.) or because they want to collaborate with naive authors. Experienced authors usually don't have any problem with documents with lots of ugly markup in them; after all, they already know HTML. Experienced authors are sometimes frustrated with wiki because it doesn't have markup that would let them do something they know they can do in HTML (e.g., tables, stylesheets, colored text, etc.). And, they sometimes have difficulty understanding why naive authors would turn away from documents that have lots of markup sequences in them.

For the wiki administrator audience--the folks who install and may want to customize PmWiki--their backgrounds and goals are often quite diverse. PmWiki is designed so that it can be installed and be useful with minimal HTML/PHP knowledge, but it doesn't restrict people who know HTML/PHP from doing some fairly complex things. For one, PmWiki allows a site administrator to build-in markup sequences and features customized to his/her needs (and the needs of his/her audiences).

The separate needs of these audiences are behind most of the PmWikiPhilosophies. The people who develop PmWiki software must continually keep naive authors in mind as new features are requested and proposed by expert authors and Wiki Administrators. Sometimes it may seem to these latter groups that it's okay to implement the complex features because "naive authors don't have to use them", but the truth is that if complex/ugly markup sequences are available then they will eventually be used by someone, and once used they become a barrier to the naive authors. So, if I see that a feature could become a barrier to a naive author I don't include it in the base implementation of PmWiki, but instead find ways to let Wiki Administrators include it as a local customization.

Content from PmWiki.AuthoringPhilosophy

Patrick Michaud on the reasons behind Author variables:

I have trouble with the idea that PmWiki can automatically designate the "original author" -- many times pages are created as simple placeholders, which other authors then come and fill in. So, I think $Creator is probably better name than $Author for this, if we were to add it. But overall I think it's a mistake to try to get PmWiki to automatically determine "primary" authorship. Sometimes pages are completely reworked; and some authors will start deleting and re-posting pages just so they can get a perceived status or ego associated with some "primary author" designation. I think it's better if the appropriate credits for contributions appear in the content (either as prose, signatures, citations, or directives), than to have PmWiki impose a particular model on its authors.

Lastly, PmWikiPhilosophy #1 is "favor writers over readers", and somewhat fundamental to that concept is that any reader can also be an author, thus $Author instead of $User or $Reader. While I recognize this idea of "readers are authors" isn't universally true for many sites that will use PmWiki, as well as an extreme case of wishful thinking, the truth is that in PmWiki the only way someone gets a value into the $Author variable is to actually *be* an author.

(In case any are wondering, "authorship" and "identity" are two different things in PmWiki. The variable used to track the "reader" or login is $AuthId, and it really stands for "authenticated identity", as opposed to "author identity" or "author".)

Radu: The idea of 'readers as authors' is somehow negated by the existence of separate 'read' and 'edit' password sets.

I somewhat disagree. First, the 'read' password has nothing to do with this-- a read password doesn't separate a population into readers and authors, it separates them into readers and non-readers.

So, it's only the edit password that tends to separate things -- but even there, an edit password doesn't have to be site-wide. The edit password can be used (and often is used) simply to say "you can author any page on the site except the ones protected by this password". Generally the edit password is used as a security measure, not as a classification or caste system.

But in the final analysis, just because PmWiki promotes a particular view of the world doesn't mean it has to be totally consistent with it, or enslaved by it. In the "favor writers over readers" case, I'm rebelling against the traditional web maintenance architecture that limits pages to only one author (typically called the "webmaster"), and constrains everyone else to submitting their changes through that author. The philosophy isn't saying that everyone must be an author, it is saying that we should remove the barriers that prevent more people from becoming authors.

See also: Cookbook:PageCreator - recipe allowing to store, access and modify a Creator variable.

Content from PmWiki.AuthorTracking

Deprecated page for 2.0.0. --Pm

PmWiki versions 0.6 and later provide support for tracking authors of edits. By default the edit form provides an "Author:" field where a person editing a page can record his/her name with the edit being performed. Author names are limited to letters, numbers, underscores, and hyphens--basically the same characters allowed in Links. Authorship of edits can then be viewed via the PageHistory command for any page.

Within the RecentChanges pages, author names become links to "profile pages?" where authors can store information about themselves. By default these pages are stored in the "Profiles/" Wiki Group, but this can be changed by a site administrator to be a different group by setting the $AuthorGroup variable in config.php.

One can use the [[~name]] markup to refer to an author's profile page.

As distributed, author names in PmWiki are optional--i.e., a user is not required to supply an author name with an edit. A site administrator can change this behavior via the $EnablePostAuthorRequired variable.

Content from PmWiki.AuthorTracking-Talk

I suggest that the PmWiki.AuthorTracking page and Site.AllRecentChangesPerAuthor be deleted

simon August 03, 2015, at 09:19 PM

Content from PmWiki.AuthUser

AuthUser is PmWiki's identity-based authorization system that allows access to pages to be controlled through the use of usernames and passwords. AuthUser can be used in addition to the password-based scheme that is PmWiki's default configuration.

AuthUser is a very flexible system for managing access control on pages, but flexibility can also bring complexity and increased maintenance overhead to the wiki administrator. This is why PmWiki defaults to the simpler password-based system. For some thoughts about the relative merits of the two approaches, see PmWiki:ThoughtsOnAccessControl.

See also: Cookbook:Quick Start for AuthUser.

Activating AuthUser

To activate PmWiki's identity-based system, add the following line to local/config.php:


Ensure that you have set a site wide admin password, otherwise you will not be able to edit SiteAdmin.AuthUser.

Note: Older versions of PmWiki (before 2.2.0-beta58) use Site.AuthUser.

PmWiki caches some group and page authorization levels when a page is accessed. For this reason, it is better to include authuser.php quite early in config.php, notably

  • after any recipe which inserts some custom writable PageStore class (MySQL, SQLite, Compressed PageStore or other)
  • and after any internationalization (UTF-8 and XLPage).

(If you don't use a custom PageStore class and i18n, include authuser.php first thing in config.php.)

All other recipes should be included after these.

Creating user accounts

Most of AuthUser's configuration is performed via the SiteAdmin.AuthUser page. To change the AuthUser configuration, simply edit this page like any other wiki page (you'll typically need to use the site's admin password for this).

To create a login account, simply add lines to SiteAdmin.AuthUser that look like:

    username: (:encrypt password:)

For example, to create a login account for "alice" with a password of "wonderland", enter:

    alice: (:encrypt wonderland:)

When the page is saved, the "(:encrypt wonderland:)" part of the text will be replaced by an encrypted form of the password "wonderland". This encryption is done so that someone looking at the SiteAdmin.AuthUser page cannot easily determine the passwords stored in the page.

To change or reset an account's password, simply replace the encrypted string with another (:encrypt:) directive.

The password cannot contain spaces, tabs, new lines, columns ":" and equals "="; on some systems it should contain at least 4 characters. Usernames and passwords are case sensitive, eg. "User" is not the same as "user".

Controlling access to pages by login

Pages and groups can be protected based on login account by using "passwords" of the form id:username in the password fields of ?action=attr (see PmWiki.Passwords). For example, to restrict a page to being edited by Alice, one would set the password to "id:alice".

It's possible to use multiple "id:" declarations and passwords in the ?action=attr form, thus the following setting would allow access to Alice, Carol, and anyone who knows the password "quick":

    quick id:alice,carol

To allow access to anyone who has successfully logged in, use "id:*".

One can also perform site-wide restrictions based on identity in the $DefaultPasswords array: e.g.

    # require valid login before viewing pages
    $DefaultPasswords['read'] = 'id:*';
    # Alice and carol may edit
    $DefaultPasswords['edit'] = 'id:alice,carol';
    # All admins and Fred may edit
    $DefaultPasswords['edit'] = array('@admins', 'id:Fred');

You can change the $DefaultPasswords array in local customization files such as:

  • local/config.php (for entire wiki)
  • farmconfig.php (for entire wikifarm)

Organizing accounts into groups

AuthUser also makes it possible to group login accounts together into authorization groups, indicated by a leading "@" sign. As with login accounts, group memberships are maintained by editing the SiteAdmin.AuthUser page. Group memberships can be specified by either listing the groups for a login account (person belongs to groups) or the login accounts for a group (group includes people). You can repeat or mix-and-match the two kinds as desired:

    @writers: alice, bob
    carol: @writers, @editors
    @admins: alice, dave

Then, to restrict page access to a particular group, simply use "@group" as the "password" in ?action=attr or the $DefaultPasswords array, similar to the way that "id:username" is used to restrict access to specific login accounts.

Excluding individuals from password groups

Group password memberships are maintained by editing the SiteAdmin.AuthUser page. To specify a password group that allows access to anyone who is authenticated, you can specify:

    @wholeoffice: *

If you need to keep "Fred" out of this password group :

    @wholeoffice: *,-Fred

To allow all users except Fred to change page attributes, for example, you can add to config.php :

    $DefaultPasswords['attr'] = array('id:*,-Fred');

Getting account names and passwords from external sources

The AuthUser script has the capability of obtaining username/password pairs from places other than the SiteAdmin.AuthUser page, such as passwd-formatted files (usually called '.htpasswd' on Apache servers), LDAP servers, or even the local/config.php file.

Passwd-formatted files (.htpasswd/.htgroup)

Passwd-formatted files, commonly called .htpasswd files in Apache, are text files where each line contains a username and an encrypted password separated by a colon. A typical .htpasswd file might look like:


To get AuthUser to obtain usernames and passwords from a .htaccess file, add the following line to SiteAdmin.AuthUser, replacing "/path/to/.htpasswd" with the filesystem path of the .htpasswd file:

    htpasswd: /path/to/.htpasswd

Creation and maintenance of the .htpasswd file can be performed using a text editor, or any number of other third-party tools available for maintaining .htpasswd files. The Apache web server typically includes an htpasswd command for creating accounts in .htpasswd:

    $ htpasswd /path/to/.htpasswd alice
    New password:
    Re-type new password:
    Adding password for user alice

Similarly, one can use .htgroup formatted files to specify group memberships. Each line has the name of a group (without the "@"), followed by a colon, followed by a space separated list of usernames in the group.

    writers: carol
    editors: alice carol bob
    admins: alice dave

Note that the groups are still "@writers", "@editors", and "@admins" in PmWiki even though the file doesn't specify the @ signs. To get AuthUser to load these groups, use a line in SiteAdmin.AuthUser like:

    htgroup: /path/to/.htgroup

Configuration via local/config.php

AuthUser configuration settings can also be made from the local/config.php file in addition to the SiteAdmin.AuthUser page. Such settings are placed in the $AuthUser array, and must be set prior to including the authuser.php script. Some examples:

    # set a password for alice
    $AuthUser['alice'] = pmcrypt('wonderland');
    # set a password for carol
    $AuthUser['carol'] = '$1$CknC8zAs$dC8z2vu3UvnIXMfOcGDON0';
    # define the @editors group
    $AuthUser['@editors'] = array('alice', 'carol', 'bob');
    # Use local/.htpasswd for usernames/passwords
    $AuthUser['htpasswd'] = 'local/.htpasswd';
    # Use local/.htgroup for group memberships
    $AuthUser['htgroup'] = 'local/.htgroup';

Configuration via LDAP

Authentication can be performed via an external LDAP server -- simply set an entry for "ldap" in either SiteAdmin.AuthUser or the local/config.php file.

    # use for authentication
    $AuthUser['ldap'] = 'ldap://,o=Airius?cn?sub';

Make sure to include AuthUser below the entry for the ldap server:

    # Want to use AuthUser so we can use ldap for passwords

And remember to assign the Security Variables for edit and history (or whatever):

    #Security Variables set login for edit & history page
    # to let anyone edit that has an ldap entry:
    $HandleAuth['diff'] = 'edit';
    $DefaultPasswords['edit'] = 'id:*';
    $Author = $AuthId;

LDAP authentication in AuthUser closely follows the model used by Apache 2.0's mod_auth_ldap module; see especially the documentation for AuthLDAPUrl for a description of the url format.

For servers that don't allow anonymous binds, AuthUser provides $AuthLDAPBindDN and $AuthLDAPBindPassword variables to specify the binding to be used for searching.

See also Cookbook:AuthUser via Microsoft LDAP

Setting the Author Name

By default, PmWiki will use a login name in the Author field of the edit form, but allows the author to change this value prior to saving. To force the login name to always be used as the author name, use the following sequence in config.php to activate AuthUser:

    $Author = $AuthId; # after include_once()

To allow more flexibility, but still enable changes to be linked to the authorized user, one can give the author name a prefix of the $AuthId instead:

    if ($Author) {
	if (strstr($Author, '-') != false) {
	    $Author = "$AuthId-" . preg_replace('/^[^-]*-/', '', $Author);
	} else if ($Author != $AuthId) {
	    $Author = $AuthId . '-' . $Author;
	} else {
	    $Author = $AuthId;
    } else {
	$Author = $AuthId;
    $AuthorLink = "[[~$Author]]";

The above will allow the user to put in the author name of their choice, but that will always be replaced by that name prefixed with "$AuthId-". The reason why $AuthorLink needs to be set is that, if it isn't, the RecentChanges page will have the wrong link in it.

Removing the "Author" edit field

To force users to edit with their AuthID instead of having a field they can place any name in. This enables administration to keep track of who is doing what better. This line also links the Author name to their Profile.
Go to Site.EditForm, remove the line
$[Author]: (:input e_author:)
or replace it with
$[Author]: [[Profiles/{$Author}]]

Authorization, Sessions, and WikiFarms

PmWiki uses PHP sessions to keep track of any user authorization information. By default PHP is configured so that all interactions with the same server (as identified by the server's domain name) are treated as part of the same session.

What this means for PmWiki is that if there are multiple wikis running within the same domain name, PHP will treat a login to one wiki as being valid for all wikis in the same domain. The easiest fix is to tell each wiki to have use a different "session cookie". Near the top of a wiki's local/config.php file, before calling authuser or other recipes, add a line like:


The XYZSESSID can be any unique name (letters only is safest). For the exact naming rules please lookup the description in the PHP manual for the PHP version you use on your server.

Security Reminder: Using different session names in cookies and/or URLs helps against inter-wiki confusion in a browser, but this is not a protection against session injection attacks on the server. See Cookbook:Session Security Advice for that.

See Also

Content from PmWiki.AuthUser-Talk

This is a talk page for improving AuthUser.

Setting single page permission.

Is there a way to set read-only permission to single page, after setting de default $DefaultPasswords['edit'] and $DefaultPasswords['read']?

Yes, follow a link like [[Main.HomePage?action=attr]] and in the form set the read password for the page to @nopass. See Passwords. --Petko September 08, 2016, at 01:01 PM

Can this be done also from config.php and not from browser url and form?

Not in a secure way. --Petko September 08, 2016, at 02:22 PM

Marcus Denning,, 20160202-12:35GMT-06
When using Option: User List on Site.AuthUser
The following pertains to Username, Password, and Profile pages combinations when using AuthUser Wiki pages for group/user Authentications.

If only the password is used for authentication, how can the name assignment be verified or changed appropriately so that there is not an author of name 'blank' or "Profile" showing up and regardless of the login author name a valid profile page can be reached?

This is going to be a bit of an involved one. I have literally just taken snippets of code and figured out how to implement them in this one. I am pretty sure someone can figure out how to do it better. However, this solution seems to work and is letting me display a valid profile page to reach without blanks or the name "Profile" for the AuthorName.

First, I have this little snippet of code in my NavBar header (another CookBook plug-in) that shows the profile selection and login auth selections appropriate to the login.

(:if ! enabled AuthPw:)
* %item rel=nofollow class=login  accesskey='$[ak_login]'%   [-'''%color=#880000%[[{*$FullName}?action=login | $[Login] ]]%%'''-]
(:if enabled AuthPw:)
(:if2 auth admin:)
* [-[[Profiles.{$Author} | %color=#660000%'''''{$Author}'' &nbsp;- '''%%%color=#ff0000% ''Profile''%%]]-]
* %item rel=nofollow class=logout accesskey='$[ak_logout]'% [-'''''%color=#ff0000%[[{*$FullName}?action=logout | $[Logout] ]]%%'''''-]
* [-[[Profiles.{$Author} | %color=#660000%'''''{$Author}'' &nbsp;- '''%%%color=#00ca00% ''Profile'' %%]]-]
* %item rel=nofollow class=logout accesskey='$[ak_logout]'% [-'''''%color=#00ca00%[[{*$FullName}?action=logout | $[Logout] ]]%%'''''-]
(:if auth admin:)
* [-[[Site/Site | %color=red%Site Admin%%]]-]
* [-[[Site.SiteMap | %color=#0000aa%Site Map%%]]-]

Then, in my local/config.sys file, I have done the following.

  • First I made a variable out of the Master Password to make it easier to change if needed.
    • $AdmPass = crypt('MastPass01');
      $DefaultPasswords['admin']   = array($AdmPass,                 # global password
                                          '@admins',                 # +users in these groups
                                          'id:Daniel', 'id:Marcus'); # +users individually
      $DefaultPasswords['upload']  = array($AdmPass, '@admins', '@moderators', '@editors');
      $DefaultPasswords['edit']    = array($AdmPass, '@admins', '@moderators', '@editors', '@writers');
      $DefaultPasswords['publish'] = array($AdmPass, '@admins', '@moderators', '@editors', '@writers');
      $DefaultPasswords['delete']  = '@lock';                        # DeletePage CookBook plug-in addition
      $DefaultPasswords['attr']    = array($AdmPass, '@admins');
  • Then, after all that, I get to my Login Name testing to select the right name.
    • ## Enable authentication based on username.
      if (  $AuthId=='admin' ) {$Author = $AuthId; } # after include_once(authuser)
      if ( !$AuthId=='admin' )
      { if ( (  $AuthId == '' ) || ( $AuthId == 'Profiles' ) )
        { if (  $authpw == $AdmPass ) { $Author = 'admin-X'; }
          if ( !$authpw == $AdmPass )	{ 
            if (  CondAuth($pagename,'admin') ) { $Author = 'admin-X'; }
            if ( !CondAuth($pagename,'admin') ) { 
              if ( CondAuth($pagename,'upload') || CondAuth($pagename,'read') || CondAuth($pagename,'edit') ) { $Author = $AuthId; }
              $Author = 'Rogue-X';

The final result of all of this is that when someone logs in they see their own login name at the top with a link to their own profile page. If they have the incorrect username and the correct password, the system authenticates but strips out any special admin/edit auths per the AuthUser plug-in functionality (goverened from within the AuthUser Wiki page by groups/users auths). If the latter happens, then Rogue-X shows up noting they had the incorrect login name and therefore the username is not a blank or the name "Profile" by default. In addition, the UserName Rogue-X can be assigned any rights desired in the AuthUser Wiki page. By Default, Rogue-X is simply a name and has no rights anyway. The Site Admin username is selected as either admin or admin-X as long as the correct password is entered, however the admin auth status is not stripped. Any edits that happen as admin or admin-X will simply show up as that AuthorName.

I really hope this helps someone. It took me a while to figure out the logic, but it seems solid for now.

Rarely asked questions

I get http error 500 "Internal Server Error" when I try to log in. What's wrong?

This can happen if the encrypted passwords are not created on the web server that hosts the PmWiki. The crypt function changed during the PHP development, e.g. a password encrypted with PHP 5.2 can not be decrypted in PHP 5.1, but PHP 5.2 can decrypt passwords created by PHP 5.1. This situation normally happens if you prepare everything on your local machine with the latest PHP version and you upload the passwords to a webserver which is running an older version. The same error occurs when you add encrypted passwords to local/config.php.

Solution: Create the passwords on the system with the oldest PHP version and use them on all other systems.

if i already specified a group in local/config.php, then i set the same group on SiteAdmin/AuthUser then will it merge all users in that same group?

It is supposed to work this way -- in config.php you set for example:

  $DefaultPasswords['edit'] = '@editors';

then, in the page SiteAdmin/AuthUser you define all users of the @editors group:

  @editors: Alice, Bob

I want to allow anyone to edit my wiki, but don't want anyone else to use my name as the author.

Is there a way to "reserve" and password protect certain usernames? Or basically just require a password when attempting to edit a page with a registered user's name in the author field?

Yes, use such a code in config.php:

  ## Preventing others posting as "Pm" or "Petko"
  if( preg_match('/^(Pm|Petko)$/i', trim(@$_POST['author'])) ){
    $DefaultPasswords['edit'] = '@lock';
    $MessagesFmt[] = "To post as '{$_POST['author']}' please log in.";

This will display the authentication form when a user tries to post as Pm or as Petko. Note that these users need to know the admin password to get through.

Not-answered questions

How can I access the authorization groups that the current user belongs to in order to test using that as a condition of an if statement?

forceflow: Dirty hack I found: create a lone page (DirtyHackPage) somewhere, and only give a certain group (apples, for example), the rights to read it. Then you can use (:if auth read DirtyHackPage:) to identify members of the apples group. It's dirty, but does the trick if you only have limited amount of groups.

Is there any way to have groups inherit other groups (e.g. @fruits: @apples, @oranges, jack)?

See PITS.01232Eemeli Aro

Is it possible to list more than one .htpasswd and .htgroup file to be used?

e.g. if I am running a wikifarm and some users are common across various fields, it would be nice if they only needed to update their password once. Sure I could merge all the passwd & group files, but then I wouldn't be able to support identical user or group names on each independent wikifield..

I'm facing a problem with authentication using MySQL database.

New user registration works but login always fails asking for correct user name and password even though proper values are entered. Where could be the problem?

I have been trying to set site-wide authorizations and getting really frustrated. I have the following lines in my config.php:

 $DefaultPasswords['edit'] = crypt('edit_password');
 $DefaultPasswords['read'] = crypt('read_password');
 $DefaultPasswords['admin'] = crypt('admin_password');

But I can still freely edit many pages. Some not, some yes. I've tried manually "clearing" passwords on pages that I seem to be able to edit.

What gives?

Is there a way that people could self-register through AuthUser?

Chris I'm trying to do this same thing now via phpbb 3.0's authentication and database. If that's an option here's how I plan on doing it. I have the phpbb 3.0 working with an sql database thanks to godaddy. I think all you need are 4 other cookbooks, AuthUserDbase dependent on AuthUser, ADOdb, DatabaseStandard. I'm going to use Cookbook:AuthUserDbase "setting for using another program's database for authentication. Then I'll need to figure out how to set user permissions to their own created content. I'd love to package all 4 of these cookbooks, and some default lines to add to a config.php to enable any new pmwiki hosts to easily connect to an existing database with minimal "dirty work". Best of luck to us both, Mark (reach me at the site I'm building is

Please see Cookbook:AuthUserSignup for a solution to this problem. Peter Bowers October 25, 2008, at 01:45 PM

This is totally true! I've been working with Peter on getting this installed and I can truly say that this is the most complete authentication system for AuthUserSignup. Real Chris November 19, 2008, at 05:15 AM

I use the SiteAdmin.AuthUser page to create user accounts at my wiki. Now, I have three on there now (big site, really). Two I created some time ago (like 2 years ago, or something) that are functioning correctly, but a third that I've recently created, and I can't get this guy working. I have entered and re-entered various times, the same as for the others:

# username: (:encrypt somepassword :)
  1. username: $1$o4iUYvYF$cZh46pfprMsAIDEhRs.kQ1

and the guy can't get in with the assigned username and password.

I am confused by this.

This site is running pmwiki-2.2.27 (VersionNum=2002027).

Please forgive the xpost. I asked this question on another page, but this seems the appropriate place.

tonybaldwin September 25, 2011, at 10:54 AM

Remove the "#" at the beginning of the line before username. --Petko September 25, 2011, at 12:04 PM

Okay, I tried that, but it didn't make a difference. I didn't think it would, since the other users are listed in the same fashion, with a "#". I appreciated the attempt, all the same.

tonybaldwin September 27, 2011, at 06:38 PM

AuthUser ignores lines starting with # so it shouldn't be before any line with username:password. Other things to check: the password cannot contain spaces, tabs, new lines, columns ":" and equals "="; on some systems it should be at least 4 characters long; usernames and passwords are case sensitive. Does another password work with the same username? Does another username work with the same password? --Petko September 27, 2011, at 07:25 PM

Reserving author names - A question like this was asked below, but it doesn't seem to work for me, perhaps it worked with an older version. I have enabled AuthUser and created some accounts. I have one page, however, that I have set the edit password to @nopass to allow for anyone to edit it. I would, however, to not have anon users be able to use specific names as the author (like that of the admin, for example). I've tried adding the recommended lines to my config file with no success. Any suggestions? Thanks!

Here is what we use on this wiki to prevent others posting as Pm or Petko:

  $postauthor = stripmagic(trim(@$_POST['author']));
  if( preg_match('/^(Pm|Petko)$/i', $postauthor) ){
    $DefaultPasswords['edit'] = '@lock';
    $MessagesFmt[] = sprintf("To post as '%s' you need to log in.", $postauthor);

Content from PmWiki.AvailableActions

Page actions are applied to wiki pages, as a query string appended to the URL. Security can be applied to all default actions, and script actions with one exception, but not diag actions, through the use of passwords.

Also documented are all other URL queries.

NOTE: All actions will be disabled if the following is set:

    $EnableActions = 0;

This will initialize PmWiki (along with any configuration/customizations that are being made, e.g. from local/config.php), but won't actually perform any actions. The caller can then call the desired action or other functions as desired. This is available from Version 2.2.0-beta22 on up.

PmWiki Actions

See also site page actions.

displays dialog for setting/changing password of the specified page or group of pages, see passwords, see also $EnablePostAttrClearSession if you do not want to have the session cleared after validating change General use of passwords and login

display the specified page (default action if no ?action= is present)

displays a form for generating hashed passwords out of clear text for usage in your config.php

show a change history of the specified page, see page history History of previous edits to a page

retrieve the page's attachment named file.ext, see $EnableDirectDownload

edit the specified page, see basic editing PmWiki's basic edit syntax

prompt visitor for username/password, by default using Site.AuthForm

remove author, password, and login information

display the specified page using the skin specified by $ActionSkin['print']

bring up the reference count form, which allows the user to generate a list of links (all, missing, existing or orphaned) in or from specified groups. See Ref Count Link references counts on pages . Part of the core distribution but must be enabled by the administrator.

displays searchbox on current page, see search Targeting and customising search results
performs search with searchterm and displays results on current page
performs backlinks search with pagename and displays results on current page

show page source

If web feeds are enabled, returns a syndication feed based on the contents of the page or other options provided by the url, see web feeds Web feed notification of changes

display a form to upload an attachment for the current group, see uploads Uploading and linking to attachments

Query string parameters

?from=page name
use when a page is redirected

?n=page name
display page

sets cookie to custom preferences page. See site preferences Customisable browser setting preferences: Access keys, edit form

Actions enabled by $EnableDiag

The following actions are available only if you set $EnableDiag = 1; in your configuration file. They can be used for debugging and should not be set in a production environment.

displays a list of all markups in 4 columns:
  • column 1 = markup-name (1. parameter of markup() )
  • column 2 = when will rule apply (2. parameter of markup() )
  • column 3 = PmWiki's internal sort key (derived from #2)
  • column 4 = Debug backtrace information for potentially incompatible rules (filename, line number, pattern)
(see Custom Markup Using the Markup() function for custom wiki syntax; migration to PHP 5.5 ).
To see more than what ?action=ruleset gives you, apply the Cookbook:MarkupRulesetDebugging recipe: it can also show the pattern and the replacement strings.
  • doesn't make use of PmWiki's authorization mechanisms.

displays the output of phpinfo() and exits. No page will be processed
  • doesn't make use of PmWiki's authorization mechanisms.

displays a dump of all global vars and exits. No page will be processed
  • doesn't make use of PmWiki's authorization mechanisms.

Actions enabled by PmWiki Scripts

see Site Analyzer and Analyze Results

see Url approvals Require approval of Url links
  • doesn't make use of PmWiki's authorization mechanisms.

Actions enabled by recipes

(more information about Custom Actions)

see Cookbook:UserAuth2 A user-based permission granting and authentication module
see Cookbook:BackupPages Automatically back up the wiki.d directory to a .zip file
see Cookbook:SearchCloud Creates a list of search terms used on a PmWiki site.
see Cookbook:CodeMirror An enhanced page editor for PmWiki
see Cookbook:CommentBox Adds a simple form to post comments
see Cookbook:Comments Comment addon - comments in separate files
see Cookbook:CommentDb Comment recipe - with pagination and RSS feed
see Cookbook:ROEPatterns Replace On Edit
Cookbook:ConvertTable Convert table action
see Cookbook:MovePage Move and copy wiki pages
see CSVAction Adds a ?action=csv capability to pmwiki to output tables as a CSV
Cookbook:Attachtable Actions to rename, delete & restore deleted attachments, as well as an attachlist replacement to use those actions, show file types and list attachment references.
see Cookbook:DeleteAction Use a separate password for deleting pages
see Cookbook:DiscussionTab Provide a skin with a "discussion" tab and "article" tab, etc.
see Cookbook:DownloadManager How can I know how many times a file was downloaded from my wiki?
see Cookbook:ExpireDiff How to remove a page's history
see Cookbook:ImportText Import text files as PmWiki pages
see Cookbook:MultiLanguageViews show language specific content and titles according to user choice
see Cookbook:MultiLanguageViews show language specific content and titles according to user choice
see Cookbook:MovePage Move and copy wiki pages
see Cookbook:CommentBoxPlus Simple styled form to post comments, plus comment counter
see Cookbook:ListCategories use categories as tags
see Cookbook:GeneratePDF Generate PDF versions of pages (?action=pdf) or Cookbook:PmWiki2PDF Generate a PDF; back up all wiki pages in PDF format
see Cookbook:UploadForm Alternative file upload form using (:input file:)
see Cookbook:PublishPDF Typesets wiki page collections into PDF (finalist: New Zealand open source awards 2008)
see Cookbook:ASCIIMath Display MathML rendered ascii formula into PmWiki 2.x pages
see Cookbook:UserAuth2 A user-based permission granting and authentication module
(the imgtpl action is called automatically and should not be called by a link in a wiki page)
(the createthumb action is called automatically and should not be called by a link in a wiki page)
(this action is called automatically and should not be called by a link in a wiki page)
see Cookbook:ThumbList A thumbnail picture gallery for PmWiki
see Cookbook:Mini Simple, lightweight, un-bloated gallery with thumbnail generator
see Cookbook:RecipeCheck Check for new versions of recipes on
see Cookbook:PageRegenerate Make PmWiki regenerate a page, as if someone had done an edit+save sequence.
see Cookbook:Reindex Force re-creation of entire .pageindex
see Cookbook:RenamePage Rename a wiki page from a browser
see Cookbook:SharedPages Share selected pages among several wikis on a common server, as in WikiFarms
see Cookbook:Sitemapper Adds a dynamically generated sitemap to PmWiki.
see Cookbook:TotalCounter A statistic counter - counts page views, users, languages, browsers, operating systems, referers, locations and web bots
see Cookbook:Trash "safely delete" pages so that they can be restored and listed with pagelists
see Cookbook:WebAdmin PHP file manager, works without ftp client
see Cookbook:ZAP The ZAP forms processor handles data and file management, page insertions (forums, blogs), email & newsletters, e-commerce, and more.

Query string parameters enabled by recipes



see Cookbook:ChoiceColorChanger {Cookbook/ChoiceColorChanger $:Summary}
see SkinChange change skin via query or cookie setting

Custom actions

User notes? : If you use, used or reviewed this recipe, you can add your name. These statistics appear in the Cookbook listings and will help newcomers browsing through the wiki.