Basic PmWiki editing rules

(:pagelist group=PmWiki fmt=#test1 count=20:)

!! {$$PageCount} {=$FullName}
(:include {=$FullName} lines=2..:)
# {=$FullName}

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 Konqueror, press Ctrl to enter (or exit) access-key mode.
  • With Chrome, press SHIFT + ALT + the access key
  • access keys in Vivaldi

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.

How can I change the keyboard shortcuts for editing and saving a page?

See Customizing access keys.

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 Darwin Information Typing Architecture (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:

  • 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.
  • 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.).
  • Download the version of PmWiki that you want from
  • Read the Installation instructions
  • 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.
  • 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

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.

5 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

6 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.

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.

simon August 03, 2015, at 09:19 PM

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

(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 "restaurant", enter:

alice: (:encrypt restaurant:)

When the page is saved, the "(:encrypt restaurant:)" part of the text will be replaced by an encrypted form of the password "restaurant". 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, colon ":" 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 (in local/config.php): 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 other PmWiki pages

If you want PmWiki to get account names and passwords from other pages than SiteAdmin.AuthUser, you can set the variable $AuthUserPageFmt in config.php.

$AuthUserPageFmt must be set before including authuser.php.

Before PmWiki version 2.2.108, you can point PmWiki to an other page than SiteAdmin.AuthUser, like this:

    $AuthUserPageFmt = 'SomeOtherGroup.SomeOtherPage?';

From PmWiki version 2.2.108 forward $AuthUserPageFmt can be an array of page names:

    $AuthUserPageFmt = array('SomeOtherGroup.SomeOtherPage?', 'SomeThirdGroup.SomeThirdPage?');

This will have AuthUser check in all listed pages, with the same expected format as documented. If there are repetitions, later values will replace previous ones.

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('restaurant');
# 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_authnz_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


Can I specify authorization group memberships from with local/config.php?

Yes -- put the group definition into the $AuthUser array (in config.php):

$AuthUser['@editors'] = array('alice', 'carol', 'bob');

Can I have multiple admin groups?

Yes, define the groups with array('@admins', '@moderators'); like this:

$DefaultPasswords['admin'] = array( pmcrypt('masterpass'), # global password
    '@admins', '@moderators', # +users in these groups
    'id:Fred', 'id:Barney');  # +users Fred and Barney

I'm running multiple wikis under the same domain name, and logins from one wiki are appearing on other wikis. Shouldn't they be independent?

This is caused by the way that PHP treats sessions. See PmWiki.AuthUser#sessions for more details.

Is there any way to record the time of the last login for each user when using AuthUser? I need a way to look for stale accounts.

See Cookbook:UserLastAction.

Though every setting seems correct, authentication against LDAP is not working. There is nothing in ldap log, what's wrong?

Be sure ldap php module is installed ( on debian apt-get install php(4|5)-ldap ; apache(2)ctl graceful )

The login form asks for username and password, but only password matters.

Username can be left blank and it still signs in under the account. Is this intentional and if so, can I change it so that the username and password must both be entered? - X 1/18/07 Never mind I think this has something to do with using the admin password. I created a test account and it's working ok.

Make sure you are not entering the admin password when testing the account because, if the password is equal to the admin password, it will authenticate directly through the config.php file and skip any other system.

Do note that even with AuthUser activated you can still log in with a blank username and only entering the password. In that case any password you enter will be "accepted" but only passwords which authenticate in the given context will actually give you any authorization rights. Using this capability AuthUser comfortably coexists with the default password-based system.

If you want to require both username and password, then you need to set an admin id before including authuser.php:

## Define usernames and passwords.
$AuthUser['carol'] = '$1$CknC8zAs$dC8z2vu3UvnIXMfOcGDON0';

## Enable authentication based on username.

# $DefaultPasswords['admin'] = pmcrypt('secret');
$DefaultPasswords['admin'] = 'id:carol';

A username and password will then be required before login is successful.

Is there any way to hide IP addresses once someone has logged in so that registered users can keep their IP addresses invisible to everyone except administrators? - X 1/18/07

Yes, see solution provided at PITS:00400.

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

You can see HtpasswdForm or UserAdmin for recipes providing this feature.

I would like it that after I have AuthUser turned and a user is authenticated to get on my site, that if I have a password put on a particular page or group that they don't get the AuthUser form to show up (username and password), but only the typical field for password?

See this thread of the mailing list (authuser vs passwords).

How to allow a group or a page for reading or editing, only to signed-in users?

You can set the password fields to id:*. Navigate to Group.Page?action=attr (for a single page) or to Group.GroupAttributes??action=attr (for the whole group) and fill the fields "New read password" and "New edit password" with id:* then save the form.

10 PmWiki.AuthUser-Talk

This is a talk page for improving AuthUser.

AuthUser & Farm-Wikis

I need a bit more concrete hints for handling AuthUser within wikis in a farm, if wiki1 should be readable for all visitors, while wiki2 only should be readable for login-users. Especially I’m not sure, where to place the include of authuser.php. But – after very long searching, I’d wish I could have found such a hint clearly and directly at AuthUser – I bet it could work like this:

$AuthUser['htpasswd'] = 'path/to/.htpasswd';
$AuthUser['htgroup'] =  'path/to/.htgroup';
$DefaultPasswords['edit'] = '@wiki-editors';
#NO include of authuser.php here, while it will destroy all settings – correct?

$DefaultPasswords['read'] = '';

$DefaultPasswords['read'] = '@wiki2-readers';

Am I right: The include of authuser.php must NOT be placed in the farmconfig.php, but should be included in every local/config.php ?

Thanks for all helpful hints and answers!

Yes, this looks good. --Petko November 07, 2017, at 02:40 AM

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 (open for everyone), @lock (locked for everyone except admins) or any actual password. 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, HouseOfDenning?.com, 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 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 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.

-> Q: but how to do this for groups of users? - BlacK? June 14, 2018, at 10:49 PM

If you set in config.php include_once("$FarmD/scripts/authuser.php"); $Author = $AuthId; then any username typed by unregistered users will be ignored, the page histories will simply store the IP addresses. Registered users before editing will need to first go to ?action=login to log in; you may want to add a warning wrapped in a (:if authid:) conditional in Site.EditForm. --Petko June 15, 2018, at 09:31 AM

not working? got this:

 $AuthUser['htpasswd'] = '.htpasswd';
 $AuthUser['htgroup'] = '.htgroup';
 $Author = $AuthId;
 $DefaultPasswords['admin'] = 'id:Admin';

+captcha set up. +default edit password is not set.

still writing any written name+ip into page history - BlacK? June 15, 2018, at 04:28 PM

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);

Error message when logging in

I have set up a new wiki installation with AuthUser enabled. When I log in via ?action=login, everything works as expected. When I then log out again on a read protected page, I am redirected to a login prompt. Logging in via that prompt works, but causes the error messages "Deprecated: crypt(): Supplied salt is not valid for DES. Possible bug in provided salt format. in [redacted]/pmwiki.php on line 519". I have already found the explanation that this is most likely due to the use of the crypt function instead of pmcrypt, but I have not found the error anywhere. This seems like a bug in AuthUser to me. Can someone help? Thanks! Mierk? March 27, 2018, at 02:21 AM

See Troubleshooting#crypt on how to track down some old pages that may need updates. --Petko March 27, 2018, at 05:01 AM

Yes, thanks for answering. I know this page and have looked for the problems described there. So can you confirm that this is a problem unique to my installation? Then I will continue looking. Thanks! Mierk? March 27, 2018, at 09:42 AM

It is also possible, in rare cases, that specific (older, Windows) PHP versions created hashes that are not compatible with more recent PHP versions (especially if the passwords are too short, eg 4 characters or less IIRC). If this is the case and you re-type your password in the ?action=attr prompt, your hash should be updated to something that is recognizable. If this is a PmWiki bug you are unlikely to be the only one experiencing it, so more people will come forward. (I assume you don't have any addons or customizations that call the pmcrypt() function, or we should review those.) --Petko March 27, 2018, at 02:01 PM

Unfortunately that's not it either. These are all new passwords that I generated a few days ago using Ubuntu. Just to be sure I just tested setting a new password for a user on the AuthUser site via (:encrypt newpassword:), as well as for a specific page with ?action=attr, still the same error. I tried disabling all recipes except AuthUser, no change. I wonder why this error does not occur when logging in via ?action=login. Mierk? March 28, 2018, at 02:36 AM

I am using Ubuntu daily, and tried to reproduce the bug you have, without success. When I open pmwiki.php?action=phpinfo, my PHP version is "", with the latest PmWiki version. The only error I get (not the one you reported) is when I place a colon ":" in the page password -- this is not allowed and no password is stored. If I had access to your server I'd do a backtrace and print the hash that is compared. Can you confirm your wiki doesn't contain "page files" (in wiki.d or wikilib.d) that contain among their first few lines the lines passwdread=* and/or passwdedit=*? I'm not sure what else to try. --Petko March 28, 2018, at 01:36 PM

Thanks for your help, Petko! I think I narrowed down the error pretty well now. I did a completely new install with just the following changes:

  • move sample-config from docs to local, rename to config.php, change the wiki title (for clarity) $WikiTitle= 'TestWiki?';
  • set passwords: $DefaultPasswords['admin'] = array(pmcrypt('secret'), '@admins');
  • include_once("$FarmD/scripts/authuser.php");
  • (also set the right permissions for wiki.d and config.php)
  • go to SiteAdmin.AuthUser, replace the page content by
   !!Login accounts
   mierk: $1$8XR6Uzui$3pQn6AaB0nSaDldQ11Sjd1
   !!Authorization groups
   @admins: mierk
  • logout, login with username mierk -> everything works as expected, I have admin rights, no error messages
  • replace the content of SiteAdmin.AuthUser by
   !!Authorization groups
   @admins: mierk
   !!Login accounts
   mierk: $1$izeCyGE7$N7ZDdxfyI8jf/ZDoh?/
  • log out, log in as mierk -> error message! (still logs in successfully)
  • reversing the order to the group and the account name gets rid of the error :) Did I miss somewhere in the instructions that the order should be this way?
  • also, the error message appears when a wrong password is entered whatever the order of the content of SiteAdmin.AuthUser. But this is less bad in a way because in that case, error messages are expected.

Could you try to replicate this error, Petko? For me, this problem is now ok, I will just leave the content of SiteAdmin.AuthUser in the correct order. Thanks again! Mierk? April 03, 2018, at 06:11 AM edit: my php version is PHP Version 7.0.28-0ubuntu0.16.04.1 Mierk? April 03, 2018, at 06:37 AM

Sorry for the late reply. Yay I was able to see the error message! There are at least 2 things to note here.

  1. The ?action=login function (HandleLoginA?) for some reason discards the $DefaultPasswords['admin'] entries, so when you use that action for an admin account it never logs you in Edit: I was wrong, as authuser.php is loaded before that function gets called, the $AuthList array is populated and the admin should be logged in correctly. I'm unsure why this is so, it was done by Pm before I took over and I found no discussion or explanation in the archives -- my guess is this should somewhat prevent automated bots trying to break in -- at any rate if it was done for a reason and people are using it I wouldn't modify it now. This should probably be documented somewhere ("Administrator cannot login via the "?action=login" url.")
  2. The functions that check the passwords will check the password hash, but sometimes also the user groups as if they were password hashes. When your encrypted password is defined before the user group and you type the correct password, you are logged in and the user group is not checked as if it were a hash, so you see no error message. When the @group is defined before the password, it is checked as if it were a hash, and it would be an invalid hash, so there is an error message. (In the past PHP just returned false, so it worked fine.) This will certainly concern many installations and we should fix it in the core -- still considering the implementation.

So thank you for discovering and raising this issue -- great work Mierk! --Petko April 06, 2018, at 05:16 AM

Is there a possibility to cascade different user-groups in a .htgroups file?

Background: I'm using AuthUser via files .htpasswd / .htgroup in a wiki-farm (compare with first post on top of this page). In htgroup I'd like to write something like that:

wiki1-admins: tom petko peter 
wiki1-editors: garry mary sandy

wiki2-admins: @wiki1-admins rosie missie chrissie

Should this usually work? If so, the malfunction of my wiki's got other causes 🙈

Again - thanks for all wailking aids, I'm just crawling around several days :-) Matthias D? May 07, 2020, at 08:00 PM

I don't think nested authentications are implemented. --Petko

Oh, that's the explanation, but it's pritty pity!!! Although that would be a great feature! BUT - thanks for stopping my life in the dark cellar :-) Matthias D? May 08, 2020, at 08:49 AM

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 customizing 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

creates a link that will open the NewPage? using the contents of OldPage?, see Cookbook:Edit Templates Specify a wiki page or pages to use as a template when a new page is created.

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:Attachman Attachman[ager] shows attaches as a rich sortable table, works also via AJAX
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 Cookbook: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:DeletePage Use a "delete" action and 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:HideDiff Hide specific edits from page histories
see Cookbook:ExtensionHub Configuration panel for extensions
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:RenamePage Rename a wiki page from a browser
see Cookbook:Flipbox Flippable checkboxes and checklists
see Cookbook:Flipbox Flippable checkboxes and checklists
see Cookbook:MovePage Move and copy wiki pages
see Cookbook:ListCategories use categories as tags
see Cookbook:CommentBoxPlus Simple styled form to post comments, plus comment counter
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:PPDonate - Create links to accept donations via PayPal?
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:ReindexCategories Update link targets and page index for PmWiki 2.3.0
see Cookbook:RenamePage Rename a wiki page from a browser
see Test.PageIndex This page exists to test and benchmark the page indexing facilities.
see Cookbook:SharedPages Share selected pages among several wikis on a common server, as in WikiFarms
see Cookbook:GoogleSiteMap Create an XML sitemap in the root of the website which is suitable for submission to Google (and other) search engines.
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 Provide a way of setting persistent skin color and theme choices when using the Choice skin.
see SkinChange change skin via query or cookie setting

Custom actions

Here are the actions using the full linkage markup:

This page has some background information on making backups and explains some basic *nix backup and restore procedures.


Your wiki installation contains some unique data in the following directories:

    local/         Local configuration scripts
    cookbook/      Recipes obtained from the Cookbook
    pub/           Publicly accessible files
    wiki.d/        Wiki pages
    uploads/       Uploaded files (attachments)

A good backup plan will include periodically archiving these directories — or at bare minimum local/ and wiki.d/. Good practice dictates keeping your backup archives on a separate machine.

Simple Backup and Restore (*nix)

When it comes to backup, simpler is better. Since the pmwiki distribution is very small (about 1/4 megabyte), it's simplest to just archive the distribution files along with the data.

Making a Backup Archive

The following *nix command, executed from the parent directory of your wiki's directory, will put a complete backup archive of your site in your home directory.

tar -zcvf  ~/wiki-backup-`date +%Y%m`.tar.gz  wiki/

Restoring the Backup Archive

Simple Method

Your site can be restored and running in under 30 seconds with

tar -zxvf ~/wiki-backup-200512.tar.gz
find wiki/uploads/ -type d |xargs chmod 777
find wiki/wiki.d/ -type d |xargs chmod 777

A Slightly-More-Secure Method

The simple restore commands above will give you world-writable files and directories. You can avoid world-writable permissions by letting PmWiki create directories with the proper attributes (ownership and permissions) for you.

Start with

tar -zxvf ~/wiki-backup-200512.tar.gz
rm -rf wiki/wiki.d
rm -rf uploads
chmod 2777 wiki/

Now upload a file in each group that had uploads. If your site doesn't have uploads, just visit your site once so the wiki.d/ directory will be created.

Finish your installation with

chmod 755 wiki/
tar -zxvf ~/wiki-backup-200512.tar.gz


The commands on this page assume your site is in a directory called "wiki/". The test backup was made in December, 2005 so it's named accordingly.

Your site will only have an uploads/ directory if uploads are enabled.

The backup command uses a date stamp (YYYYMM) in the filename. If you automate the command via cron you'll wind up with monthly snapshots of your site. You can get a daily snapshot by appending %d to the date command (`date +%Y%m%d` will get you YYYYMMDD). Be wary of space limitations if you have a large uploads/ directory.


Backup via FTP

Download and install a ftp client like Filezilla

  1. Using the ftp client connect to the server where you host PmWiki using
    1. the IP address (ex: or the ftp name (ex:
    2. supply your account name (ex: mylogin) and password (ex: myp4ssw0rd)
  2. Move to your pmWiki directory (ex: /usr/mylogin/web/wiki/ or /tahi/public_html/pmwiki )
  3. Select the folder you want to backup as explained before (probably either only the data or the whole wiki directory)
    • for data you will want to backup both the directories
      • wiki.d for user page data
      • pmwikiuploads (or uploads) for your attachments (uploads)
    • for system you will want, at a minimum, to backup both the directories
      • local for configuration data
      • pub for local CSS and skins customisations
  4. Download them to a local folder
  5. Use 7zip or a similar software to build an archive of this backup

You can also very easily sync your FTP directories with your hard disc via this command line:

wget -nv -np -m

Download Wget for Windows (other systems normally have it installed).

Alternatively, you can also mirror your FTP directories with lftp:

lftp -u your_user_name,your_password -e "mirror --verbose /wiki.d /path/to/local/folder" ftp://your_host

(this will mirror only the /wiki.d folder, replace with / to mirror everything)

Using rsync

See Cookbook:BackupWithRsync and Cookbook:TwoWayMirroringWithRsync.

See Also

The pages on this site are wiki-based pages, which means that pages can be created and edited by multiple authors. To edit a page, click the Edit link that exists somewhere on the page, usually in the header or footer. Some pages may be password-protected, depending on the system's security policies, but many systems allow open editing of pages.

PmWiki is not WYSIWYG - When editing a page, you see the markup text that describes the content of the page. The basic rules for page markup are simple:

  1. Use a blank line to start a new paragraph more.
  2. To make a list, start each line with # for numbered (ordered) lists or * for bulleted (unordered) lists more.
  3. To make a heading, start a line with two or more ! marks; !! is a subheading, and !!! is a sub-subheading more.
  4. To emphasize text, enclose it in 2 or 3 single quotes; ''text'' for italics or '''text''' for bold more.
  5. To make a link to another page, enclose the page's name in double brackets; for example [[basic editing]] links to this page.
  6. To make a link to another site, type its address, such as [[]]. Email links must have "mailto:" before such as

If you want to experiment with editing a page, try it on the Wiki Sandbox. You can edit the Wiki Sandbox without affecting anything important on this site. On talk pages and discussions, it's courteous to sign your contribution; using ~~~ effectively 'signs' the name that you provide in the Author field on the Page Edit form.

Examples of common markups

The tables below demonstrate many of the common markups used to format pages. The left column shows what to write to achieve the effect, the right column shows the effect of the markup. More details are available from the text formatting rules and other documentation pages. An exhaustive list of default markup is available as the markup master index.

Paragraphs and line breaks

What to type

What it looks like

Consecutive lines
will be merged together
as part of the same paragraph.

One or more empty lines will start a new paragraph.

Consecutive lines will be merged together as part of the same paragraph.

One or more empty lines will start a new paragraph.

Two backslashes at the end of a line \\
force a line break.

Or use this markup: [[<<]] to force a break.

Two backslashes at the end of a line
force a line break.

Or use this markup:
to force a break.

Further reading:

  • text formatting rules for more information on linebreaks, indented or hanging paragraphs.
  • wiki styles for centered or right justified paragraphs and "floating" text (boxes), borders and much more.


Start each line with # for numbered (ordered) lists or * for bulleted (unordered) lists:

* Bullet list
* Another item
** More asterisks produce sub-items
** etc.
  • Bullet list
  • Another item
    • More asterisks produce sub-items
    • etc.
# Numbered lists
# Another item
## more hashes produce sub-items
  1. Numbered lists
  2. Another item
    1. more hashes produce sub-items
# List types
# can be mixed
** numbered list with unordered sub-list
  1. List types
  2. can be mixed
    • numbered list with unordered sub-list

Learn more about lists (including definition lists) and list styles.


Headings are useful for creating a "well-structured" page. They're not just for making big text.

What to type

What it looks like

!! Major Subheading
!!! Minor Subheading
!!!! And More
!!!!! Subheadings

Major Subheading

Minor Subheading

And More


Text emphasis

To emphasize, enclose text in apostrophes (single-quote marks), not double-quotes.

What to type

What it looks like

''Emphasize'' (italics),
'''strong''' (bold), 
'''''very strong''''' (bold italics).

Emphasize (italics), strong (bold), very strong (bold italics).


To make a link to another page, enclose the page's name in double square brackets.

What to type

What it looks like

Practice editing in the [[PmWiki/wiki sandbox]]

Practice editing in the wiki sandbox

Note that words are automatically capitalized in page titles. The link above links to the page WikiSandbox.

Text after a pipe (|) is used as the link text:

Practice editing in the
[[PmWiki/WikiSandbox | practice area]].

Practice editing in the practice area.

Endings become part of the link text, parentheses hide parts of the link name:

[[PmWiki/wiki sandbox]]es.

[[PmWiki/(wiki) sandbox]].

wiki sandboxes.


When linking to a page in a different WikiGroup, provide the group name, followed by a separator, and then the page name:

[[Main.Wiki Sandbox]] shows group + name

[[Main/Wiki Sandbox]] shows only name

Main.Wiki Sandbox shows group + name

Wiki Sandbox shows only name

Links to external sites

bare url:

link text: [[ | PmWiki home]]

bare url:

link text: PmWiki home

Links as reference to external sites

bare url:

link text: [[ | #]]

bare url:

link text: [1]

To add a tooltip title to a link, add it in quotes after the page name or the URL:

Hover your mouse cursor over the links to see the tooltip.
* [[Documentation Index"Return to our help center"]]
* [["Collaborative Wiki-based CMS" | PmWiki]]

Hover your mouse cursor over the links to see the tooltip.

Colons make InterMap (also called InterWiki?) links to other wikis:

What's an [[Wikipedia:aardvark]], anyway?

What's an Wikipedia:aardvark, anyway?

Links to nonexistent pages? are displayed specially, to invite others to create the page.

PmWiki supports more link types and a lot of display options, see Links to learn more.

Escape sequence

If you don't want Wiki markup to be processed, but lines reformatted use [= =]. Can also be used inline.

markup is ''not'' processed
but lines are reformatted

markup is ''not'' processed but lines are reformatted

Preformatted text

Preformatted text is displayed using a monospace font and not generating linebreaks except where explicitly indicated in the markup.

Note that very long lines of preformatted text can cause the whole page to be wide.

For preformatted text with markup (e.g. emphasis) being processed, start each line with a space:

 Lines that begin with a space
 are formatted    exactly    as typed
 in a '''fixed-width''' font.
 Lines that begin with a space
 are formatted    exactly    as typed
 in a fixed-width font.

If you don't want Wiki markup to be processed, use [@ @]. Can also be used inline.

Text escaped this way has
the HTML ''code'' style
Text escaped this way has
the HTML ''code'' style

You can also use the escape sequence preceded with a space on the first line.

 [=The   '''escape sequence''',
preceded by space(s) on the first line,
is    rendered          preformatted.=]
 The   '''escape sequence''',
preceded by space(s) on the first line,
is    rendered          preformatted.

You can enable code highlighting for preformatted blocks with recent PmWiki versions.

Horizontal line

Four or more dashes at
the beginning of a line
produce a "horizontal rule"

Four or more dashes at the beginning of a line

produce a "horizontal rule"


Simple tables use double pipe characters to separate cells:

|| border=1
||! head 1 ||! head 2 ||! head 3 ||
|| cell 1  ||  cell 2 ||  cell 3 ||
head 1head 2head 3
cell 1cell 2cell 3

See simple tables and advanced tables to learn more about the rich feature set of PmWiki tables.


See Images

Character formatting

What to type

What it looks like

* @@Monospaced text@@
* Text with '^superscripts^'
* Text with '_subscripts_'
* deleted {-strikethrough-} text
* inserted {+underline+} text
* [+big+], [++bigger++] text
* [-small-], [--smaller--] text
  • Monospaced text
  • Text with superscripts
  • Text with subscripts
  • deleted strikethrough text
  • inserted underline text
  • big, bigger text
  • small, smaller text

Use WikiStyles to change the text color .

Page titles

The (:title:) directive sets the page's title to something other than its page name.

(:Title Basic PmWiki editing rules:)
The name of this page is "{PmWiki.BasicEditing$Name}", and its title is "{PmWiki.BasicEditing$Title}".

The name of this page is "BasicEditing", and its title is "Basic PmWiki editing rules".

Page description

  • The (:Description Page description here:) directive sets the page description. The description is used by search engines, and can be displayed in search results and in page lists.
(:Description PmWiki's basic editing rules:)
The summary description of this page is "{PmWiki.BasicEditing$Description}".

The summary description of this page is "PmWiki's basic editing rules".

Page summary

(:Summary:PmWiki's basic edit syntax:)
The summary of this page is "{PmWiki.BasicEditing$:Summary}".

The summary of this page is "PmWiki's basic edit syntax".

I'm new to PmWiki, where can I find some basic help for getting started?

The Basic Editing page is a good start. From there, you can just follow the navigational links at the top or the bottom of the page (they are called Wiki Trails) to the next pages, or to the Documentation Index page, which provides an outline style index of essential documentation pages, organized from basic to advanced.

How do I include special characters such as Copyright (©) and Trademark (® or ™) on my wiki pages?

See special characters on how to insert special characters that don't appear on your keyboard.

How can I preserve line-breaks from the source text?

PmWiki normally treats consecutive lines of text as being a paragraph, and merges and wraps lines together on output. This is consistent with most other wiki packages. An author can use the (:linebreaks:) directive to cause the following lines of markup text in the page to be kept as separate lines in the output. Or a wiki administrator can set in config.php $HTMLPNewline = '<br/>'; to force literal new lines for the whole site.

Can I just enter HTML directly?

By default (and by design), PmWiki does not support the use of HTML elements in the editable markup for wiki pages. There are a number of reasons for this described in the PmWiki Philosophy and Audiences. Enabling HTML markup within wiki pages in a collaborative environment may exclude some potential authors from being able to edit pages, and pose a number of display and security issues. However, a site administrator can use the Cookbook:Enable HTML recipe to enable the use of HTML markup directly in pages.

Where can I find more documentation?

See the documentation index and the markup master index pages.

The title attribute also works as a tooltip.

Examples show the title attribute set in image links in double quotes adjacent to the right side of the image file reference.

[[URL|image"title attribute text"]]


This will not work for a text link. I had an extremely difficult time finding that this works for a text link by putting the title attribute text in double quotes adjacent to the left side of the URL

[["title attribute text"|PMWiki]]

This works - mouse over the link and see the tooltip:

[["title attribute text is here"|PMWiki with HTML title attribute set]]

PMWiki with HTML title attribute set

This will not work:

[[|PMWiki with HTML title attribute set"no title attribute text is here"]]

PMWiki with HTML title attribute set"no title attribute text is here"

I also found the title/tooltip being adjacent to the URL appears to work too.


Someone didn't consider this to be "basic", so it is documented in Links#tooltiptitle. In fact, Attach: with a picture was implemented by Pm, then later I added it for external links, and even later for page links. The "Attach:" prefix is an InterMap prefix for PmWiki (like "https:") so these use the same logic. --Petko

Where the variables are available as wiki markup they are shown as Variable value "{$VariableName}".

%apply=item id=AsSpacedFunction?%$AsSpacedFunction
The name of the function used to convert WikiWords? into normal, spaced strings. Defaults to 'AsSpaced?'.
$AsSpacedFunction = 'MyAsSpaced';

$Author is currently ""

Set to the current reader, who is potentially an author (see discussion). See also $EnablePostAuthorRequired.
%apply=item id=AuthorGroup?%$AuthorGroup
The WikiGroup? for user profiles. Defaults to 'Profiles'. This variable is implicit in the markup [[~AuthorName]]
$AuthorGroup = 'Users';
%apply=item id=AuthId?%$AuthId
For sites using user-based authorization, tracks the "reader" or login name.
if( isset($AuthId) ) { // this person has been authenticated
%apply=item id=AuthPw%$AuthPw
Request for documentation, meanwhile see AuthId vs AuthPw.
if( isset($AuthPw) ) { // this person has entered a password

$BaseName is currently "PmWiki.BasicVariables"

%apply=item id=BaseName%$BaseName
%apply=item id=BaseNamePatterns?%$BaseNamePatterns
Allows population of the {$BaseName} PageVariable. The key to the hash is the pattern to be replaced and the value is the replacement string.
# If {$FullName} is 'Group.Page-Draft' then {$BaseName} is 'Group.Page'
$BaseNamePatterns['/-Draft$/'] = '';
# If {$FullName} is 'Comments-Group.Page' then {$BaseName} is 'Group.Page'
$BaseNamePatterns['/^Comments-/'] = '';
%apply=item id=CategoryGroup?%$CategoryGroup
The WikiGroup? used for categories. Defaults to 'Category'. (See Categories). This variable is implicit in the markup [[!CategoryName]]
%apply=item id=CookiePrefix?%$CookiePrefix
A string prefix to be prepended to cookies set from PmWiki scripts. It defaults to '', but can be set to a different value to avoid conflicts with similar-named cookies from other applications, or to allow multiple wikis from the same domain to store separate cookies.
$CookiePrefix = 'pmwiki_'; # set cookie prefix to 'pmwiki_'
If you have a WikiFarm, use the following in each field's config.php to get a unique prefix for each field in the farm, thus isolating each field's cookies.
$CookiePrefix = substr($tmp = md5(__FILE__), 0, 5).'_';

$DefaultGroup is currently "PmWiki"

%apply=item id=DefaultGroup?%$DefaultGroup
WikiGroup used by default (on startup) when no group is specified in the URL.

$DefaultName is currently "HomePage"

%apply=item id=DefaultName?%$DefaultName
Name of the default HomePage of each WikiGroup?. Used when the group doesn't have a page with the same name as the group.
Note that the behavior will differ based on whether the page exists or not. Probably you want to alter $PagePathFmt in addition to $DefaultName if you really want it to take effect.
Note: See comment below under $DefaultPage re the order how this must be defined within your (farm)config.php scripts - this must be set prior to any call of ResolvePageName().
%apply=item id=DefaultPage?%$DefaultPage
Startup page when PmWiki is called without a specified page, normally $DefaultGroup.$DefaultName.
Note: for $DefaultGroup, $DefaultName and $DefaultPage variables to work, they should be defined in the beginning of (farm)config.php, before any call to the function ResolvePageName?(). This means, before any script from PmWiki and before any recipe that might be using this function. This also means it cannot be set in a per-page or per-group customization script - ResolvePageName?() is called before these are loaded.
Please note that this variable is intended to be set in (farm)config.php, not in individual groups. Trying to use different $DefaultName, $DefaultPage or $PagePathFmt settings in different groups will cause cross-group linking anomalies.
%apply=item id=EnableLocalConfig?%$EnableLocalConfig
Allows/disables local/config.php customizations (usually for a farm's wikis). Can be set to zero in local/farmconfig.php to prevent the farm's wikis' local/config.php from being loaded.
$EnableLocalConfig = 0; # disable PmWiki's local/config
%apply=item id=EnableStdConfig?%$EnableStdConfig
Disables scripts/stdconfig.php and a large part of the core functionalities provided by the scripts in the pmwiki/scripts directory and outlined in the core documentation, unless included by your own local configuration (notably core markup rules, page history, skins, uploads). Allows you to completely reshape the way PmWiki behaves, if you need to.
$EnableStdConfig = 0; # disable many standard features
%apply=item id=EnablePGCust?%$EnablePGCust
Allows/disables per-page and per-group customizations. Can be set to zero in any local customization file to prevent remaining page/group customizations from being loaded.
$EnablePGCust = 0; # turn off per-page/group configs
%apply=item id=EnableBaseNameConfig?%$EnableBaseNameConfig
When enabled, and if the page has a different base page (per $BaseNamePatterns), will include the local configuration for the base page. For example, if the page is "Group.Page-Draft", this would try to include the file local/Group.Page.php in addition to local/Group.Page-Draft.php.
$EnableBaseNameConfig = 1; # include basename configuration
%apply=item id=EnableRedirect?%$EnableRedirect
When enabled (default), causes page redirects to automatically be performed by the browser. Setting $EnableRedirect to zero causes PmWiki to pause and issue a "Redirect to link" message instead. This is sometimes useful when debugging recipes to be able to see the results of actions before page redirections occur. Not to be confused with $EnableRedirectQuiet.
%apply=item id=EnableWikiWords?%$EnableWikiWords
Enable WikiWord processing.
%apply=item id=EnableWSPre?%$EnableWSPre
Enables a markup rule that causes lines with leading spaces to be treated as sections of preformatted text. If set to a value greater than 1, indicates the minimum number of leading spaces required for this treatment.
$EnableWSPre = 1; # leading spaces are preformatted text
$EnableWSPre = 0; # leading spaces are normal lines of text
$EnableWSPre = 4; # 4+ spaces are preformatted text
%apply=item id=FTimeFmt?%$FTimeFmt
Can be used to override the default date format used by the "ftime" function. The default $FTimeFmt is $TimeFmt. (See Markup Expressions.)
%apply=item id=GroupPattern?%$GroupPattern
The regular expression pattern used for valid WikiGroup name specifications. Defaults to allowing any group name beginning with an uppercase letter, but can be set to limit the valid group names (see Cookbook:LimitWikiGroups).
# limit groups to Site, SiteAdmin, PmWiki, and MyGroup
$GroupPattern = '(?:Site|SiteAdmin|PmWiki|MyGroup)';
#for case-sensitive group names, note the ?-i switch:
$GroupPattern = '(?-i:Site|SiteAdmin|PmWiki|MyGroup)';
%apply=item id=LinkWikiWords?%$LinkWikiWords
If set, then bare WikiWords? in a page are automatically linked to pages of the same name. Note that this value can also be affected by the (:linkwikiwords:) and (:nolinkwikiwords:) directives.
$LinkWikiWords = 1; # turn on WikiWord links
$LinkWikiWords = 0; # disable WikiWord links
Note, this setting requires WikiWords? to be enabled, see $EnableWikiWords.
%apply=item id=LogoutRedirectFmt?%$LogoutRedirectFmt
Identifies the page to which the visitor should be sent after an ?action=logout. Defaults to the current page.
$LogoutRedirectFmt = 'Site.Logout'; # ?action=logout target
%apply=item id=LogoutCookies?%$LogoutCookies
An array of cookie names to be removed when ?action=logout is invoked.
%apply=item id=NamePattern?%$NamePattern
The regular expression pattern used for valid page names. Defaults to allowing pages beginning with an uppercase letter or digit, followed by sequences of alphanumeric characters, hyphens, and underscores.
A variable that gives the name of the current page.
To access inside a Markup callback function, use
It is also accessible via
global $pagename; # if you use it inside a function
$pagename = ResolvePageName($pagename);
See LocalCustomizations for more information, including when it's possible to use this variable.
Once you have $pagename, page variables become accessible:
$page = PageVar($pagename, '$FullName'); # =$pagename
$group = PageVar($pagename, '$Group');
$name = PageVar($pagename, '$Name');
%apply=item id=PagePathFmt?%$PagePathFmt
An array controlling how the default group home-page name will be determined.
Please note that this variable is intended to be set in (farm)config.php, not in individual groups. Trying to use different $DefaultName, $DefaultPage or $PagePathFmt settings in different groups will cause cross-group linking anomalies.
Default Setting:
$PagePathFmt = array('{$Group}.$1','$1.$1','$1.{$DefaultName}');
Setting to use if you wish $DefaultName to actually be the name of your group home-pages:
$PagePathFmt = array('{$Group}.$1','$1.{$DefaultName}','$1.$1');
Do note that if the Groupname.Groupname page does exist but Groupname.Defaultname does not exist, then Groupname.Groupname will still take precedence. You may remove the '$1.$1' entirely to require Groupname.Defaultname to be the group homepage - that would look like this:
$PagePathFmt = array('{$Group}.$1','$1.{$DefaultName}');

$SiteGroup is currently "Site"

%apply=item id=SiteGroup?%$SiteGroup
Default group for storing configuration and utility pages such as Site.Search, Site.EditForm, Site.PageNotFound, etc.
%apply=item id=SiteAdminGroup?%$SiteAdminGroup
Default group for locked administrative pages such as SiteAdmin.AuthList, SiteAdmin.AuthUser, SiteAdmin.ApprovedUrls, etc, defaults to 'SiteAdmin'.
The name of the directory containing the skin (theme) files, default "pmwiki". See Skins.
%apply=item id=SpaceWikiWords%$SpaceWikiWords
If set, then WikiWords? in pages are automatically spaced according to $AsSpacedFunction. Note that this value can also be affected by the (:spacewikiwords:) and (:nospacewikiwords:) directives.
$SpaceWikiWords = 1; # turn on WikiWord spacing
$SpaceWikiWords = 0; # turn off WikiWord spacing
%apply=item id=TimeFmt?%$TimeFmt
The format to use for dates and times, in strftime() format. The default value is '%B %d, %Y at %I:%M %p', which gives dates of the form "September 8, 2005 at 10:57 PM". Formats $CurrentTime variable.
$TimeFmt = '%B %d, %Y'; # dates as "September 8, 2005"
$TimeFmt = '%Y-%m-%d'; # dates as "2005-09-08"
%apply=item id=EnableFTimeNew?%$EnableFTimeNew
If set to 1, enables the new functions to format dates and times for PHP before 8.1. This allows you to preview the outputs of dates and times, for example in the page footer, in Recent Changes and page histories, or with the {(ftime)} markup expression. See explanation at Functions#PSFT. (For PHP 8.1, strftime() is deprecated, and the new functions are enabled by default.)

$Version is currently "pmwiki-2.3.34"

A string representing the release version of PmWiki.

$VersionNum is currently "2003034"

%apply=item id=VersionNum?%$VersionNum
A number representing the release version of PmWiki, with the major and minor release components padded with zeroes to produce three digits. Thus, release "pmwiki-2.1.40" will have $VersionNum set to 2001040.
The first digit is a 2, the next three digits are the major release number, and the last three digits are the minor release number. Beta releases use 900-999 for the minor release number. Thus:
2.1.0          2001000
2.1.1          2001001
2.1.27         2001027
2.2.0-beta1    2001901
2.2.0-beta2    2001902
2.2.0-beta18   2001918
2.2.0          2002000
%apply=item id=WikiWordPattern?%$WikiWordPattern
The pattern that describes a WikiWord.
%apply=item id=EnableRelativePageVars?%$EnableRelativePageVars
This setting controls how Page variables in included pages are understood by PmWiki.
$EnableRelativePageVars = 1; # PmWiki current default
In this case
{$Name} displays the name of the physical page where it written. If {$Name} is in an included page, it will display the name of the included page. (This is currently PmWiki's default.)
$EnableRelativePageVars = 0; # revert to previous default
In this case
{$Name} displays the name of the currently browsed page. Even if {$Name} is in an included page, it will display the name of the browsed page. This was PmWiki's default in versions 2.2.8 and earlier, and changed in 2.2.9, but you can revert it back with this line in config.php.
{*$Name} with an asterisk always displays the name of the currently browsed page, regardless of $EnableRelativePageVars.

Categories: PmWiki Developer

17 PmWiki.Blocklist

The block list is one of a number of security measures that can be taken to protect your wiki from spam and other unwelcome postings.

Unfortunately, the open-editability of many wiki systems often makes them attractive targets for "link spam" or "wikispam", in which links are added to pages in an effort to increase search engine rankings or drive traffic to other sites. Also, many link spammers have developed automated systems to locate sites that accept visitor input and attempt to flood the site with unwanted links. Also, and harder to deal with, is just plain wiki vandalism where nonsense changes are made, often replacing entire pages.

By far the best countermeasure against wikispam is to restrict editing through the use of passwords (see Passwords and Passwords Admin). Experience has shown that passwords can be effective even if the password is widely known, and even if the password is publicly available on the site itself. However, there are many cases where passwording may be an impediment, so these will generally want to use some form of blocklist.

Blocklist basics

A blocklist is a list of IP addresses, phrases, and expressions which are prevented from being added into pages on the website. PmWiki is distributed with a built-in blocklisting capability; blocklists can be enabled by adding the following line to local/config.php:

$EnableBlocklist = 1;

This tells PmWiki to scan the SiteAdmin.Blocklist page and the "SiteAdmin.Blocklist-Farm" page (and possibly other pages -- see below) looking for phrases and IP addresses to be excluded from posting to the site.

Blocking by word or phrase

The simplest form of block is simply a line containing "block:" followed by a word or phrase to be excluded from postings. For example, a line like

in SiteAdmin.Blocklist will block any posts containing the string "" (case-insensitive) anywhere in the post.

Blocking by IP address

Sometimes we wish to restrict posts coming from particular addresses or address ranges that are known as sources of wikispam. If a blocklist page contains IP addresses of the form "a.b.c.d" or "a.b.c.*", then any posts coming from that address or range will be blocked.

To find an author's IP address, try hovering the mouse over the author name in the page history for a page.

Blocking by regular expression or pattern

Blocking on simple words can sometimes pose difficulties; for example, a simple "block:cial" entry will also block the word "specialist". For these cases it's often helpful to use a regular expression, as in:


This says to block "cial" only if it doesn't occur in the middle of a larger word. The leading slash (/) after "block:" tells PmWiki to use a regular expression match instead of a simple string match. (Blocklist uses PCRE or "Perl Compatible Regular Expressions"; see PCRE functions for more information.)

Regular expression to block 'href'

If you want to block 'href', you can use the following markup:


which blocks 'href', but neither '\href' nor 'toughref'.

The regular expression can be interpreted as follows: Match any character that is neither a word character nor a '\', followed by href which ends in a word boundary.

Letting authors know why they've been blocked

By default, blocklist only tells an author that a particular edit has been blocked, but doesn't give a specific reason for the blocking (e.g., the offending phrase). Setting the following in a local customization file will also provide the reasons for the block:

$EnableWhyBlocked = 1;

Managing multiple blocklists

PmWiki allows blocklist entries to come from multiple pages by setting the $BlocklistPages variable. By default $BlocklistPages is set to "SiteAdmin.Blocklist", as well as any automatically downloaded blocklists as described below. PmWiki will use all entries in all the blocklists for filtering wikispam. Setting a value of $BlocklistPages changes the default:

$BlocklistPages = array('Main.Blocklist', '{$Group}.Blocklist');

The order of blocklists really doesn't matter -- all of the blocklist pages ultimately get used, and the unblock: entries are processed after all of the blocklist pages have been loaded.

Automatically downloaded blocklists

Maintaining blocklists is relatively easy to do, but can become tedious over time. Several groups have formed and maintain "shared blocklists", where a common blocklist is made available to all. PmWiki's blocklist capability has built-in features for automatically downloading and updating such shared blocklists.

If you're just in a hurry to make use of some standard blocklists, make the following setting in local/config.php:

$EnableBlocklist = 10;

This tells PmWiki to not only enable blocklists on the site, but to also configure itself to automatically retrieve and maintain local copies of well-known blocklists such as MoinMaster. These local copies will be saved in SiteAdmin.Blocklist-MoinMaster? and refreshed once per day (as determined by the value of $BlocklistDownloadRefresh).

To automatically retrieve the SiteAdmin.Blocklist page used at, add the following setting in local/config.php:

$BlocklistDownload["$SiteAdminGroup.Blocklist-PmWiki"] = array('format' => 'pmwiki');

The blocklist from which we used in the past is no longer available as of 2013.

Ignoring specific entries in a blocklist (unblock)

When using a large master blocklist or blocklists automatically refreshed from external sites, it may be that some entries in the blocklists are inappropriate or overeager and block legitimate content. In this case a wikiadministrator can use "unblock" in a blocklist page to ignore an entry from the blocklist. For example, to allow "" even if another blocklist has a block entry for it:

In order for unblocking to work the phrase or pattern following "unblock:" must be exactly the same as the original.

Permissions on blocklist pages

In general, an administrator will want to edit-protect the SiteAdmin.Blocklist and any other blocklist pages to prevent arbitrary changes to the blocklist (see Passwords). Since most pages in the SiteAdmin.* group are edit-protected by default anyway, this usually isn't a problem.

Administrators may also wish to read-protect the various blocklist pages so that others do not know the exact phrases and/or IP addresses that are being blocked. (By their nature blocklists tend to contain phrases or terms that may be offensive or inappropriate to some.)

Any pages created via automatic download (see above) are automatically locked against viewing except by administrators.

administrators (intermediate)

Detailed configuration of automatically downloaded blocklists

Automatic downloading of blocklist information is controlled by the $BlocklistDownload array. An entry for MoinMaster? might look like:

$BlocklistDownload["$SiteAdminGroup.Blocklist-MoinMaster"] = array(
    'url' => '',
    'format' => 'regex',
    'refresh' => 86400);

This says to download the blocklist data from the given url into the SiteAdmin.Blocklist-MoinMaster? page, that the entries in the blocklist are regular expressions, and to refresh the information every 86,400 seconds (one day).

If 'refresh' is omitted, then the page will be refreshed at the time interval given by $BlocklistDownloadRefresh (default one day). If 'format' is omitted, the page is assumed to have PmWiki-formatted entries as described above. If 'url' is omitted, then the blocklist information is downloaded from a standard location on the site.

To force a refresh of an automatically downloaded blocklist, simply delete the existing page -- a new version will be installed upon the next blocklist scan. Blocklist pages are checked for download in response to any ?action=edit request.

If you are specifying your Blocklist-Pages in the config.php you have to specify the automatically updated pages too, else they won't be updated or created even if you use $EnableBlocklist = 10; .

Farm-wide blocklist

A blocklist can be applied farm-wide (see SharedPages). After these pages are created they can be moved into the farm shared.d/ directory:

Blocklist Variables

The following variables help control the configuration and operation of blocklists:

If set to a non-zero value, then blocklists are enabled on the site. If set to a value of ten or higher, then add entries for automatic downloads of standard blocklists.
$EnableBlocklist = 1; # enable blocklists
$EnableBlocklist = 10; # auto-configure standard blocklists
By default, authors are not told which particular phrases or IP addresses are causing a particular post to be blocked; setting $EnableWhyBlocked to 1 provides this information.
$EnableWhyBlocked = 1; # give reasons for blocking
An array of pages to be checked for blocklist entries. The elements of the array may contain page variables. Defaults to "SiteAdmin.Blocklist", plus any other automatically downloaded blocklist pages.
The message to provide the author whenever a post has been blocked.
If $EnableWhyBlocked is set, defines the text to use for each type of block being performed. Currently only 'ip' and 'text' are recognized.
$BlockedMessagesFmt['ip'] = "IP address blocked from posting: ";
$BlockedMessagesFmt['text'] = "Text blocked from posting: ";
An array of automatically-downloaded blocklists. The keys of the array are the pages in which the blocklists should be stored, the values contain the url, format, and refresh interval for the downloaded blocklist.
  # Download the MoinMaster blocklist every twelve hours
  $BlocklistDownload["$SiteAdminGroup.Blocklist-MoinMaster"] = array(
    'url' => '', 
    'format' => 'regex',
    'refresh' => 43200);
  # Download a shared blocklist from every day
  $BlocklistDownload["$SiteAdminGroup.Blocklist-Shared"] = array(
    'format' => 'pmwiki');
The default refresh interval for any $BlocklistDownload entries that don't explicitly specify a 'refresh' value.
# perform automatic downloads once per week by default
$BlocklistDownloadRefresh = 86400 * 7;
The format to use when saving automatically downloaded blocklists.
Some cookbook recipes update pages with author input but don't use the built-in data posting routines. If $EnableBlocklistImmediate is set (default) and the current action is listed in $BlocklistActions (below), then an immediate blocklist scan is performed on the incoming text.
A list of actions for which immediate blocklist checks should be performed (see $EnableBlocklistImmediate above).
# perform immediate checks for ?action=comment
$BlocklistActions['comment'] = 1;
# perform immediate checks for ?action=postdata
$BlocklistActions['postdata'] = 1;

18 PmWiki.Blocklist-Talk

This is a talk page for improving Blocklist.

How do i configure the blocklist to also check third party cookbook scripts, in my case Cookbook.Guestbook? This scripts posts to pmwiki using the hidden field action=guestbook in the form.

So i have tried putting in tho local config:

$BlocklistActions['guestbook'] = 1;

But that does not get it working. If i try it manually by calling the blocklist from within the guestbook-script

global $Enablepost;
if ($Enablepost)

Bas? May 05, 2008, at 03:52 PM

blocklist bug! I create SiteAdmin.Blocklist




  • $EnableBlocklist = 1;

When I edit a page, the script "scripts / blocklist.php" is played ... but is added to the page ...

Help please!

the script never gets in the if clause as Enablepost is not set?

$EnablePost is set to 1 early in pmwiki.php. Do you have a standard pmwiki installation or there are some recipes which use a different mechanism for editing pages? --Petko February 15, 2012, at 01:58 AM

EDIT ! Thanks ! My problem is with the translation ;)

Vous pouvez m'écrire en français. Le Blocklist fonctionne sur plusieurs wikis. Je ne sais pas si Fox est compatible avec Blocklist, si vous modifiez des pages avec des formulaires Fox, je suppose qu'il faut demander au développeur HansB (en anglais ou en allemand). --Petko February 15, 2012, at 03:55 PM

Pour les activer Blocklist avec Fox je viens de faire $BlocklistActions['foxpost'] = 1; et ça marche !(dans config.php)

How do I temporarily disable the blocklist. I have a password-edit only site with HTML enabled and want(!) to be able to add javascript <script> tags etc. on my sidebar. I can re-enable it when my edit (add a searchbox) is done. $EnableBlocklist = 0; is not working. XES July 05, 2013, at 07:44 AM

Nevermind -- it was also enabled in a recipe.

I do not manage to get the automatic blocklist download working (pmwiki blocklist) A file SiteAdmin.Blocklist-pmwiki is created, but it is empty.

Any hints? Klonk November 06, 2013, at 01:25 PM

It should be SiteAdmin.Blocklist-PmWiki with proper capital letters, not all lowercase pmwiki. Use the following in config.php to download it. --Petko November 06, 2013, at 06:16 PM

  $EnableBlocklist = 10; # not 1
  $BlocklistDownload["$SiteAdminGroup.Blocklist-PmWiki"] = array('format' => 'pmwiki');

Sorry, a misspelling from my side. But see yourself how it looks like:

Maybe I forgot some configuration? Or are there some special rights I have to give? Or modules to load/activate? Klonk November 07, 2013, at 01:24 AM

That group is password-protected so I cannot see the page and even if there is a page Blocklist-PmWiki. Do you have $EnableBlocklist = 10; and not 1? --Petko November 07, 2013, at 02:22 PM

Yes I have $EnableBlocklist = 10; And the only content of that created page is:

## blocklist-note:   NOTE: This page is automatically generated by blocklist.php
## blocklist-note:   NOTE: Any edits to this page may be lost!
## blocklist-url:    listDownloadUrl
## blocklist-when:   2013-11-09T08:13:10
#  blocklist-format: listFormat

Klonk November 09, 2013, at 01:57 AM

Do you have a custom markup or a custom PageVariable called {$Block} in (farm)config.php, in a recipe or in a skin? It may get evaluated before the blocklist functions get to save the data. Disable that markup/variable and try again. --Petko November 09, 2013, at 03:57 AM

I haven't found anything. Disabled all recipes and skins - still does not work! After some more testing: For whatever reason sometimes it is loaded, sometimes not.... I have no idea. I use the fox cookbook reciepe and I don't know wheter blocklist works there anyways... Klonk November 10, 2013, at 06:06 AM

I haven't had the opportunity to review Fox. You should test if it works with the normal PmWiki editing mecanism. In the page content you posted above, instead of listDownloadUrl, listFormat and listData, PmWiki has $BlocklistDownloadUrl, $BlocklistFormat and $BlocklistData just before the downloaded list is saved to the page. Upon saving, these variables are replaced with their values, "", "pmwiki" and the content of SiteAdmin.Blocklist. The fact that you see listFormat means that in some of your *.php file(s) there is a variable $Block or {$Block} which is defined and is empty, so the "$Block" part from "$BlocklistFormat" is replaced with nothing, before the replacement of the full $BlocklistFormat which never happens. The fact that you see the time means that the $CurrentTimeISO variable is correctly replaced with the time. So the replacement works but there is a variable $Block that breaks some of the other variables. I would scan all *.php files looking for "$Block" in order to find it and deactivate it - eventually renaming it to something different. --Petko November 10, 2013, at 09:03 AM

Also note that PmWiki waits at least 24 hours before trying to download the data again. While testing you may want to set in config.php $BlocklistDownloadRefresh = -1; so that it will try to download the data at every save. When it works, remove this line. --Petko November 10, 2013, at 09:15 AM

It took me some time, but I guess, I found it. Seems to be bug in PmWiki!

The only position I found $Block was in pmwiki.php line 1483, in function FormatTableRow?. There a global variable $Block was defined but nowhere used. Can you confirm that? If so, should I open a PITS issue or will you?

Earliest this evening I have access to my server to check whether removing the global variable $Block helps.

Thanks for your patience and help! Klonk November 21, 2013, at 05:27 AM

This is a nice catch, thanks. (I wonder how that function is triggered on your wiki and not on others.) No need to open a PITS entry, I just removed the variable for the next version. I hope that it will fix your blocklist problems. --Petko November 21, 2013, at 02:15 PM

"Block markup" is a term used in the sources of PmWiki indicating all markups resulting in HTML block elements[1] or in other words multiple paragraphs and other content.

WikiStyles can be applied to blocks, else you don't need to bother about "blockmarkup" as a PmWiki user.

Division blocks

Division <div> HTML blocks are inserted with the (:div:)...(:divend:) markup. You can have the HTML id= and class= attributes like (:div id=id1 class="class1 class2":). A (:div:) markup automatically closes a previously open such tag. To have nested tags, you need to number the tag, and the matching tag end:
Outer block
Inner block

Semantic HTML5? elements

Since version 2.2.75, PmWiki allows the inclusion of a few semantic HTML5? elements. Note that an opening semantic markup automatically closes any previously opened tag of the same type, but does not verify or tidy the structure for you, so make sure you use closing tags when needed.

Inserts an <article> tag. You can have the HTML id= and class= attributes like (:article id=id1 class="class1 class2":). An (:article:) markup automatically closes a previously open such tag. To have nested tags, you need to number the tag, and the matching tag end:
Outer article
Inner article
Inserts a <section> tag. You can have the HTML id= and class= attributes like (:section id=id1 class="class1 class2":). A (:section:) markup automatically closes a previously open such tag. To have nested tags, you need to number the tag, and the matching tag end, like the (:article:) markup.
Inserts a <header> tag. You can have the HTML id= and class= attributes like (:header id=id1 class="class1 class2":). A (:header:) markup automatically closes a previously open such tag, and it is not possible to nest such tags.
Inserts a <footer> tag. You can have the HTML id= and class= attributes like (:footer id=id1 class="class1 class2":). A (:footer:) markup automatically closes a previously open such tag, and it is not possible to nest such tags.
Inserts an <aside> tag. You can have the HTML id= and class= attributes like (:aside id=id1 class="class1 class2":). An (:aside:) markup automatically closes a previously open such tag, and it is not possible to nest such tags.
Inserts an <address> tag. You can have the HTML id= and class= attributes like (:address id=id1 class="class1 class2":). An (:address:) markup automatically closes a previously open such tag, and it is not possible to nest such tags.
Inserts a <nav> tag. You can have the HTML id= and class= attributes like (:nav id=id1 class="class1 class2":). A (:nav:) markup automatically closes a previously open such tag, and it is not possible to nest such tags.
(:details summary="Summary":)...(:detailsend:)
Inserts a <details> and embedded <summary> section. Standard-compliant browsers will only show the summary, and the user can click on it to open the full section, without a need for JavaScript?. A (:details:) markup automatically closes a previously open such tag. To have nested tags, you need to number the tag, and the matching tag end, like the (:article:) markup. This is a recent addition to the HTML5? standard, see for current browser support (browsers that do not support it show the section open).
(:details summary="Click for more information...":)
Here is the content of the <details> section.
Click for more information...

Here is the content of the <details> section.

To have a details section open by default, add the attribute open=open like (:details open=open summary="Summary":)

See also

This is a talk page for improving BlockMarkup.

Block marking

>>X Y<< is a shortcut for "(:div:)%div X Y apply=div%" [2].

A block can be marked as follows

>>wiki style<<
>>change in wiki style<<

and continues until the wiki style changes or empty brackets are encountered. A block cannot be nested using this markup, but a block can contain a table or the following markup.

A block can be marked as follows

(:div class="c1 c2" style="atr1:z;atr2:y;":)

Blocks can be nested by naming (with numbers) the blocks, viz

(:div5 class="c1 c2" style="atr1:z;atr2:y;":)
(:div2 class="c1 c2" style="atr1:z;atr2:y;":)
(:div2:) %div rframe%
How do I use rframe in a block?

(:div class="rfloat frame":)
How do I use rframe in a block?

How do I use rframe in a block?

How do I use rframe in a block?

A block can also be a table.

Text wraps, joins and breaks

Text on two lines in a row will wrap and fill as needed (the normal HTML behavior).

Text on two lines in a row 
will wrap and fill as needed 
(the normal HTML behavior).

Text on two lines in a row will wrap and fill as needed (the normal HTML behavior).

To turn off automatic text filling, use the (:linebreaks:) directive above the paragraph.

Text on two lines in a row 
will wrap and fill as needed 
(the normal HTML behavior).

Text on two lines in a row
will wrap and fill as needed
(the normal HTML behavior).

Use \ (backslash) at the end of a line to join the current line to the next one.

Use \ (backslash) at the end of a line \
to join the current line to the next one.

Use \ (backslash) at the end of a line to join the current line to the next one.

Use \\ (2 backslashes) at the end of a line to force a line break.

Use \\ (2 backslashes) at the end of a line \\
to force a line break.

Use \\ (2 backslashes) at the end of a line
to force a line break.

Use \\\ (3 backslashes) at the end of a line to force 2 line breaks.

Use \\\ (3 backslashes) at the end of a line \\\
to force 2 line breaks.

Use \\\ (3 backslashes) at the end of a line

to force 2 line breaks.

Use [[<<]] to force a line break that will clear floating elements.

Use [[<<]] to force a line break that will clear floating elements.

to force a line break that will clear floating elements.

Preformatted blocks

The [= and =] markup can be applied to multiple input lines, including empty lines. This makes it useful for displaying lines of code, which will be shown as monospaced font and not interpreted by PmWiki. Just leave an empty space in front of the opening [=, and finish with a closing =]. If there are [=...=] pairs in the code, put a =][= after each =]. For example:

Code goes here like [[PmWiki.PmWiki]]
$CurrentTime $[by] $AuthorLink:  [=$ChangeSummary=]=][='; #just some code
Code goes here like [[PmWiki.PmWiki]]
$CurrentTime $[by] $AuthorLink:  [=$ChangeSummary=]'; #just some code

The same effect can be achieved using the [@...@] syntax; in this case you don't need a leading space or the extra =][= markup.

Code goes here like [[PmWiki.PmWiki]]
$CurrentTime $[by] $AuthorLink:  [=$ChangeSummary=]'; #just some code
Code goes here like [[PmWiki.PmWiki]]
$CurrentTime $[by] $AuthorLink:  [=$ChangeSummary=]'; #just some code

It is also possible to use [= ... =] within other wiki structures, which enables the inclusion of new lines in text values. The example below shows how to include a multi-line value in a hidden form field.

(:input hidden message "[=Line1

The "pre" style can also be applied

This style preserves white    space, and 

This style preserves white space, and newlines.

Note that it does not cause the text to be displayed in a monospaced font.

See also

More advanced formatting can be achieved with wiki styles and page directives.

Headings in summary

The detail's summary allows heading content, but !! etc do not appear to work. Is it possible to permit headings in the detail summary in PmWiki?

simon June 23, 2020, at 10:49 AM

Not at this point, see PmWiki philosophy #2 "PmWiki doesn't make any attempt to do everything that can be done in HTML." --Petko June 23, 2020, at 11:11 AM

Is BlockMarkups finalized, DocumentationIndex does not have a link to it ?

!! {$$PageCount} {=$FullName}
(:include {=$FullName} lines=2..:)
# {=$FullName}
  0: 00.00 00.00 config start
  1: 00.01 00.01 config end
  2: 00.21 00.20 MarkupToHTML begin
  3: 00.21 00.20 MarkupToHTML begin
  4: 00.21 00.20 FPLTemplate: Chain begin
  5: 00.21 00.20 FPLTemplate: FPLTemplateLoad
  6: 00.21 00.21 FPLTemplate: FPLTemplateDefaults
  7: 00.21 00.21 FPLTemplate: FPLTemplatePageList
  8: 00.21 00.21 MakePageList pre
  9: 00.21 00.21 PageListSources begin
 10: 00.21 00.21 PageStore::ls begin wiki.d/{$FullName}
 11: 00.22 00.21 PageStore::ls merge wiki.d/{$FullName}
 12: 00.22 00.21 PageStore::ls end wiki.d/{$FullName}
 13: 00.22 00.21 PageStore::ls begin $FarmD/wikilib.d/{$FullName}
 14: 00.22 00.21 PageStore::ls merge $FarmD/wikilib.d/{$FullName}
 15: 00.22 00.21 PageStore::ls end $FarmD/wikilib.d/{$FullName}
 16: 00.22 00.21 PageListSources end count=315
 17: 00.22 00.21 PageListSort pre ret=4 order=name
 18: 00.22 00.21 MakePageList items count=315, filters=
 19: 00.22 00.21 MakePageList post count=315, readc=0
 20: 00.22 00.21 PageListSort begin
 21: 00.22 00.21 PageListSort sort
 22: 00.22 00.21 PageListSort end
 23: 00.22 00.21 MakePageList end
 24: 00.22 00.22 FPLTemplate: FPLTemplatePmWikiOrg
 25: 00.22 00.22 MarkupToHTML begin
 26: 00.23 00.22 MarkupToHTML end
 27: 00.23 00.22 FPLTemplate: FPLTemplateSliceList
 28: 00.23 00.22 FPLTemplate: FPLTemplateFormat
 29: 00.23 00.22 MarkupToHTML begin
 30: 00.24 00.23 MarkupToHTML begin
 31: 00.24 00.23 MarkupToHTML end
 32: 00.24 00.23 MarkupToHTML begin
 33: 00.24 00.23 MarkupToHTML end
 34: 00.24 00.23 MarkupToHTML begin
 35: 00.24 00.23 MarkupToHTML end
 36: 00.24 00.23 MarkupToHTML begin
 37: 00.24 00.24 MarkupToHTML end
 38: 00.24 00.24 MarkupToHTML begin
 39: 00.25 00.24 MarkupToHTML end
 40: 00.25 00.24 MarkupToHTML begin
 41: 00.25 00.24 MarkupToHTML end
 42: 00.25 00.24 MarkupToHTML begin
 43: 00.25 00.24 MarkupToHTML end
 44: 00.25 00.24 MarkupToHTML begin
 45: 00.25 00.24 MarkupToHTML end
 46: 00.25 00.24 MarkupToHTML begin
 47: 00.25 00.24 MarkupToHTML end
 48: 00.25 00.24 MarkupToHTML begin
 49: 00.25 00.24 MarkupToHTML end
 50: 00.25 00.24 MarkupToHTML begin
 51: 00.25 00.24 MarkupToHTML end
 52: 00.25 00.24 MarkupToHTML begin
 53: 00.25 00.24 MarkupToHTML end
 54: 00.25 00.24 MarkupToHTML begin
 55: 00.25 00.24 ReadApprovedUrls SiteAdmin.ApprovedUrls begin
 56: 00.26 00.25 ReadApprovedUrls SiteAdmin.ApprovedUrls end
 57: 00.26 00.25 MarkupToHTML end
 58: 00.26 00.25 MarkupToHTML begin
 59: 00.26 00.25 MarkupToHTML end
 60: 00.26 00.25 MarkupToHTML begin
 61: 00.26 00.25 MarkupToHTML end
 62: 00.26 00.25 MarkupToHTML begin
 63: 00.26 00.25 MarkupToHTML end
 64: 00.26 00.25 MarkupToHTML begin
 65: 00.26 00.25 MarkupToHTML end
 66: 00.26 00.25 MarkupToHTML begin
 67: 00.26 00.25 MarkupToHTML end
 68: 00.26 00.25 MarkupToHTML begin
 69: 00.26 00.25 MarkupToHTML end
 70: 00.26 00.25 MarkupToHTML begin
 71: 00.26 00.25 MarkupToHTML end
 72: 00.26 00.25 MarkupToHTML begin
 73: 00.27 00.25 MarkupToHTML end
 74: 00.27 00.25 MarkupToHTML begin
 75: 00.27 00.26 MarkupToHTML end
 76: 00.27 00.26 MarkupToHTML begin
 77: 00.27 00.26 MarkupToHTML end
 78: 00.27 00.26 MarkupToHTML begin
 79: 00.27 00.26 MarkupToHTML end
 80: 00.27 00.26 MarkupToHTML begin
 81: 00.27 00.26 MarkupToHTML end
 82: 00.27 00.26 MarkupToHTML begin
 83: 00.27 00.26 MarkupToHTML end
 84: 00.27 00.26 MarkupToHTML begin
 85: 00.27 00.26 MarkupToHTML end
 86: 00.27 00.26 MarkupToHTML begin
 87: 00.27 00.26 MarkupToHTML end
 88: 00.27 00.26 MarkupToHTML begin
 89: 00.28 00.26 MarkupToHTML end
 90: 00.28 00.26 MarkupToHTML begin
 91: 00.28 00.27 MarkupToHTML end
 92: 00.28 00.27 MarkupToHTML begin
 93: 00.28 00.27 MarkupToHTML end
 94: 00.28 00.27 MarkupToHTML begin
 95: 00.28 00.27 MarkupToHTML end
 96: 00.28 00.27 MarkupToHTML begin
 97: 00.28 00.27 MarkupToHTML end
 98: 00.28 00.27 MarkupToHTML begin
 99: 00.28 00.27 MarkupToHTML end
100: 00.28 00.27 MarkupToHTML begin
101: 00.28 00.27 MarkupToHTML end
102: 00.28 00.27 MarkupToHTML begin
103: 00.28 00.27 MarkupToHTML end
104: 00.28 00.27 MarkupToHTML begin
105: 00.28 00.27 MarkupToHTML end
106: 00.28 00.27 MarkupToHTML begin
107: 00.28 00.27 MarkupToHTML end
108: 00.28 00.27 MarkupToHTML begin
109: 00.28 00.27 MarkupToHTML end
110: 01.13 01.10 FPLTemplate: Chain begin
111: 01.13 01.10 FPLTemplate: FPLTemplateLoad
112: 01.14 01.11 FPLTemplate: FPLTemplateDefaults
113: 01.14 01.11 FPLTemplate: FPLTemplatePageList
114: 01.14 01.11 MakePageList pre
115: 01.14 01.11 PageListSources begin
116: 01.14 01.11 PageStore::ls begin wiki.d/{$FullName}
117: 01.14 01.11 PageStore::ls merge wiki.d/{$FullName}
118: 01.14 01.11 PageStore::ls end wiki.d/{$FullName}
119: 01.14 01.12 PageStore::ls begin $FarmD/wikilib.d/{$FullName}
120: 01.15 01.12 PageStore::ls merge $FarmD/wikilib.d/{$FullName}
121: 01.15 01.12 PageStore::ls end $FarmD/wikilib.d/{$FullName}
122: 01.15 01.12 PageListSources end count=1
123: 01.15 01.12 PageListSort pre ret=4 order=name
124: 01.15 01.12 MakePageList items count=1, filters=
125: 01.15 01.12 MakePageList post count=1, readc=0
126: 01.15 01.12 PageListSort begin
127: 01.15 01.12 PageListSort sort
128: 01.15 01.12 PageListSort end
129: 01.15 01.12 MakePageList end
130: 01.15 01.12 FPLTemplate: FPLTemplatePmWikiOrg
131: 01.15 01.12 MarkupToHTML begin
132: 01.15 01.12 MarkupToHTML end
133: 01.15 01.12 FPLTemplate: FPLTemplateSliceList
134: 01.15 01.12 FPLTemplate: FPLTemplateFormat
135: 01.15 01.12 MarkupToHTML begin
136: 01.15 01.12 MarkupToHTML end
137: 01.15 01.12 FPLTemplate: FPLTemplatePmWikiOrgPostFormat
138: 01.15 01.12 FPLTemplate: Chain end
139: 01.15 01.12 FPLTemplate: Chain begin
140: 01.15 01.12 FPLTemplate: FPLTemplateLoad
141: 01.15 01.12 FPLTemplate: FPLTemplateDefaults
142: 01.15 01.12 FPLTemplate: FPLTemplatePageList
143: 01.15 01.12 MakePageList pre
144: 01.15 01.12 PageListSources begin
145: 01.15 01.12 PageStore::ls begin wiki.d/{$FullName}
146: 01.16 01.12 PageStore::ls merge wiki.d/{$FullName}
147: 01.16 01.13 PageStore::ls end wiki.d/{$FullName}
148: 01.16 01.13 PageStore::ls begin $FarmD/wikilib.d/{$FullName}
149: 01.16 01.13 PageStore::ls merge $FarmD/wikilib.d/{$FullName}
150: 01.16 01.13 PageStore::ls end $FarmD/wikilib.d/{$FullName}
151: 01.16 01.13 PageListSources end count=12
152: 01.16 01.13 PageListSort pre ret=4 order=name
153: 01.16 01.13 MakePageList items count=12, filters=
154: 01.16 01.13 MakePageList post count=12, readc=0
155: 01.16 01.13 PageListSort begin
156: 01.16 01.13 PageListSort sort
157: 01.16 01.13 PageListSort end
158: 01.16 01.13 MakePageList end
159: 01.16 01.13 FPLTemplate: FPLTemplatePmWikiOrg
160: 01.16 01.13 MarkupToHTML begin
161: 01.16 01.13 MarkupToHTML end
162: 01.16 01.13 FPLTemplate: FPLTemplateSliceList
163: 01.16 01.13 FPLTemplate: FPLTemplateFormat
164: 01.17 01.13 MarkupToHTML begin
165: 01.17 01.14 MarkupToHTML end
166: 01.17 01.14 FPLTemplate: FPLTemplatePmWikiOrgPostFormat
167: 01.17 01.14 FPLTemplate: Chain end
168: 01.19 01.16 MarkupToHTML end
169: 01.20 01.16 FPLTemplate: FPLTemplatePmWikiOrgPostFormat
170: 01.20 01.16 FPLTemplate: Chain end
171: 01.20 01.16 MarkupToHTML end
172: 01.20 01.17 MarkupToHTML end
173: 01.21 01.17 MarkupToHTML begin
174: 01.22 01.18 MarkupToHTML end
175: 01.22 01.18 MarkupToHTML begin
176: 01.22 01.19 MarkupToHTML end
177: 01.27 01.19 now
Peak memory: 6,650,560 bytes