Basic PmWiki editing rules

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.

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.

• 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="https://example.com" accesskey="x">Example</a> would create a link to example.com 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"%[[https://example.com|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.

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

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:

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.

Installation

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:

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:

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

Upgrading

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 https://www.pmwiki.org/pub/pmwiki.
• 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:

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

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.

Contributors:

BJayaram
tamouse

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.

   include_once("$FarmD/cookbook/analyze.php");
   $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 pmwiki.org to save a copy of analysis results" box will save a copy of the analyzer results in a private (web inaccessible) section of the pmwiki.org 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 pmwiki.org 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

include_once("$FarmD/cookbook/analyze.php");
$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:

(:recipetable:)

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 (pmwiki.org 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

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

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.

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.

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.

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

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

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

All other recipes should be included after these.

Creating user accounts

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

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

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

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 :

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:

    alice:vK99sgDV1an6I
    carol:Q1kSeNcTfwqjs?

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

include_once("$FarmD/scripts/authuser.php");

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 ldap.airius.com for authentication
$AuthUser['ldap'] = 'ldap://ldap.airius.com/ou=People,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
include_once("$FarmD/scripts/authuser.php");

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:

include_once("$FarmD/scripts/authuser.php");
$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:

    include_once("$FarmD/scripts/author.php");
    include_once("$FarmD/scripts/authuser.php");
    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

or replace it with

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:

session_name('XYZSESSID');

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

• PmWiki.Passwords
• PmWiki.PasswordsAdmin
• Cookbook:AuthUser for tips and tricks
• SiteAdmin.AuthUser

FAQ

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

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

## Enable authentication based on username.
include_once('scripts/authuser.php');

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

This is a talk page for improving AuthUser.

farmconfig.php:
$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?

wiki1/local/config.php:
$DefaultPasswords['read'] = '';
include_once("$FarmD/scripts/authuser.php");

wiki2/local/config.php:
$DefaultPasswords['read'] = '@wiki2-readers';
include_once("$FarmD/scripts/authuser.php");

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

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

  @editors: Alice, Bob

  ## 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.";
  }

 $AuthUser['htpasswd'] = '.htpasswd';
 $AuthUser['htgroup'] = '.htgroup';
 include_once('scripts/authuser.php');
 $Author = $AuthId;
 $DefaultPasswords['admin'] = 'id:Admin';

 $DefaultPasswords['edit'] = crypt('edit_password');
 $DefaultPasswords['read'] = crypt('read_password');
 $DefaultPasswords['admin'] = crypt('admin_password');
 $include_once("scripts/authuser.php");

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

   !!Login accounts
   mierk: $1$8XR6Uzui$3pQn6AaB0nSaDldQ11Sjd1
   !!Authorization groups
   @admins: mierk

   !!Authorization groups
   @admins: mierk
   !!Login accounts
   mierk: $1$izeCyGE7$N7ZDdxfyI8jf/ZDoh?/

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

wiki2-admins: @wiki1-admins rosie missie chrissie

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;
    include('pmwiki.php');

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.

?action=attr

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

?action=browse

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

?action=crypt

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

?action=diff

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

?action=download&upname=file.ext

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

?action=edit

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

?action=login

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

?action=logout

remove author, password, and login information

?action=print

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

?action=refcount

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.

?action=search

displays searchbox on current page, see search Targeting and customizing search results

?action=search&q=searchterm

performs search with searchterm and displays results on current page

?action=search&q=link=pagename

performs backlinks search with pagename and displays results on current page

?action=source

show page source

?action=template

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.

?action=atom

?action=rdf

?action=rss

?action=dc

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

?action=upload

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

?setprefs=SomeGroup.CustomPreferences?

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.

?action=ruleset

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)

?action=phpinfo

displays the output of phpinfo() and exits. No page will be processed

• doesn't make use of PmWiki's authorization mechanisms.

?action=diag

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

?action=analyze

see Site Analyzer and Analyze Results

?action=approvesites

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)

?action=admin

see Cookbook:UserAuth2 A user-based permission granting and authentication module

?action=attachman

see Cookbook:Attachman Attachman[ager] shows attaches as a rich sortable table, works also via AJAX

?action=backup

see Cookbook:BackupPages Automatically back up the wiki.d directory to a .zip file

?action=clearsky

see Cookbook:SearchCloud Creates a list of search terms used on a PmWiki site.

?action=cm-dependencies

see Cookbook:CodeMirror An enhanced page editor for PmWiki

?action=comment

see Cookbook:CommentBox Adds a simple form to post comments

?action=comments

see Cookbook:Comments Comment addon - comments in separate files

?action=comment-rss

see Cookbook:CommentDb Comment recipe - with pagination and RSS feed

?action=convert

see Cookbook:ROEPatterns Replace On Edit

?action=converttable

Cookbook:ConvertTable Convert table action

?action=copy

see Cookbook:MovePage Move and copy wiki pages

?action=csv

see Cookbook:CSVAction Adds a ?action=csv capability to pmwiki to output tables as a CSV

?action=downloaddeleted

?action=delattach

?action=deldelattach

?action=fileinfo

?action=thumbnail

?action=undelattach

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.

?action=delete

see Cookbook:DeletePage Use a "delete" action and a separate password for deleting pages

?action=discuss

see Cookbook:DiscussionTab Provide a skin with a "discussion" tab and "article" tab, etc.

?action=downloadman

see Cookbook:DownloadManager How can I know how many times a file was downloaded from my wiki?

?action=expirediff

see Cookbook:ExpireDiff How to remove a page's history

?action=hidediff

see Cookbook:HideDiff Hide specific edits from page histories

?action=hub

see Cookbook:ExtensionHub Configuration panel for extensions

?action=import

see Cookbook:ImportText Import text files as PmWiki pages

?action=lang

see Cookbook:MultiLanguageViews show language specific content and titles according to user choice

?action=setlang

see Cookbook:MultiLanguageViews show language specific content and titles according to user choice

?action=links

see Cookbook:RenamePage Rename a wiki page from a browser

?action=lockflipbox

see Cookbook:Flipbox Flippable checkboxes and checklists

?action=unlockflipbox

see Cookbook:Flipbox Flippable checkboxes and checklists

?action=move

see Cookbook:MovePage Move and copy wiki pages

?action=pageindex

see Cookbook:ListCategories use categories as tags

?action=PageUrl?

see Cookbook:CommentBoxPlus Simple styled form to post comments, plus comment counter

?action=pdf

see Cookbook:GeneratePDF Generate PDF versions of pages (?action=pdf)

or Cookbook:PmWiki2PDF Generate a PDF; back up all wiki pages in PDF format

?action=postupload2

see Cookbook:UploadForm Alternative file upload form using (:input file:)

?action=ppdonate

see Cookbook:PPDonate - Create links to accept donations via PayPal?

?action=publish

see Cookbook:PublishPDF Typesets wiki page collections into PDF (finalist: New Zealand open source awards 2008)

?action=purgeqns

see Cookbook:ASCIIMath Display MathML? rendered ascii formula into PmWiki 2.x pages

?action=pwchange

see Cookbook:UserAuth2 A user-based permission granting and authentication module

?action=imgtpl

(the imgtpl action is called automatically and should not be called by a link in a wiki page)

?action=createthumb

(the createthumb action is called automatically and should not be called by a link in a wiki page)

?action=mini

(this action is called automatically and should not be called by a link in a wiki page)

?action=purgethumbs

see Cookbook:ThumbList A thumbnail picture gallery for PmWiki
see Cookbook:Mini Simple, lightweight, un-bloated gallery with thumbnail generator

?action=recipecheck

see Cookbook:RecipeCheck Check for new versions of recipes on pmwiki.org

?action=regen

see Cookbook:PageRegenerate Make PmWiki regenerate a page, as if someone had done an edit+save sequence.

?action=reindex

see Cookbook:Reindex Force re-creation of entire .pageindex

?action=reindexcat

See Cookbook:ReindexCategories Update link targets and page index for PmWiki 2.3.0

?action=rename

?action=links

see Cookbook:RenamePage Rename a wiki page from a browser

?action=rmpi

see Test.PageIndex This page exists to test and benchmark the page indexing facilities.

?action=share

?action=unshare

see Cookbook:SharedPages Share selected pages among several wikis on a common server, as in WikiFarms

?action=sitemap

see Cookbook:GoogleSiteMap Create an XML sitemap in the root of the website which is suitable for submission to Google (and other) search engines.

?action=sitemapaddgroups

?action=sitemapupdate

see Cookbook:Sitemapper Adds a dynamically generated sitemap to PmWiki.

?action=totalcounter

see Cookbook:TotalCounter A statistic counter - counts page views, users, languages, browsers, operating systems, referers, locations and web bots

?action=trash

?action=untrash

see Cookbook:Trash "safely delete" pages so that they can be restored and listed with pagelists

?action=webadmin

see Cookbook:WebAdmin PHP file manager, works without ftp client

?action=zap

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

?color=colorscheme

:?setcolor=colorscheme

?skintheme=theme

?setskintheme=theme

see Cookbook:ChoiceColorChanger Provide a way of setting persistent skin color and theme choices when using the Choice skin.

?skin=skinname

?setskin=skinname

see SkinChange change skin via query or cookie setting

Custom actions

• See CustomActions.

Here are the actions using the full linkage markup:

• Csv
• Downloaddeleted
• Delattach
• Deldelattach
• Fileinfo
• Thumbnail
• Undelattach
• Delete
• Discuss
• Downloadman
• Expirediff
• Import
• Move
• %item rel=nofollow class=PageUrl? accesskey='ak_PageUrl'% Pageurl
• Pageindex
• Pdf
• Postupload2
• Publish
• Purgeqns
• Pwchange
• Imgtpl
• Createthumb
• Mini
• Purgethumbs
• Recipecheck
• Regen
• Rename
• Links
• Share
• Unshare
• Sitemapaddgroups
• Sitemapupdate
• Totalcounter
• Trash
• Untrash
• Webadmin
• Zap

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

Introduction

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

Details

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.

Miscellaneous

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: 123.234.56.67) or the ftp name (ex: ftp.myhost.com)
   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:

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

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

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

Using rsync

See Cookbook:BackupWithRsync and Cookbook:TwoWayMirroringWithRsync.

See Also

• A backups thread on the pmwiki-users mailing list.
• A Backup Pages recipe in the cookbook.
• A Backup HTML Zip recipe in the cookbook.

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 [[https://example.com/]]. Email links must have "mailto:" before such as mailto:xyz@example.com

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

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.

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.

Lists

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

* Bullet list
* Another item
** More asterisks produce sub-items
** etc.

# Numbered lists
# Another item
## more hashes produce sub-items

# List types
# can be mixed
** numbered list with unordered sub-list

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

Headings

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

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

Text emphasis

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

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

Links

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

Practice editing in the [[PmWiki/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]].

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

[[PmWiki/wiki sandbox]]es.

[[PmWiki/(wiki) sandbox]].

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

Links to external sites

bare url:  https://www.pmwiki.org

link text: [[https://www.pmwiki.org | PmWiki home]]

Links as reference to external sites

bare url: https://www.pmwiki.org

link text: [[https://www.pmwiki.org | #]]

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"]]
* [[https://www.pmwiki.org"Collaborative Wiki-based CMS" | PmWiki]]

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

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
=]

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"

Tables

Simple tables use double pipe characters to separate cells:

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

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

Images

See Images

Character formatting

* @@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}".

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}".

Page summary

• (:Summary:Page summary here:) is a PageTextVariable that is used in some of the default PageList templates.

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

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"]]

see: https://www.pmwiki.org/wiki/PmWiki/Images#links

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

[[https://pmwiki.org"title attribute text"|PMWiki]]

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

[[https://pmwiki.org"title attribute text is here"|PMWiki with HTML title attribute set]]

This will not work:

[[https://pmwiki.org|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.

gnuzoo February 28, 2024, at 09:44 PM

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 February 29, 2024, at 08:54 AM

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

$Author

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.

SessionAuth($pagename);

if( isset($AuthId) ) { // this person has been authenticated

%apply=item id=AuthPw%$AuthPw

Request for documentation, meanwhile see AuthId vs AuthPw.

SessionAuth($pagename);

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.

%apply=item id=DefaultPage?%$DefaultPage

Startup page when PmWiki is called without a specified page, normally $DefaultGroup.$DefaultName.

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.

$pagename

A variable that gives the name of the current page.

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

$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'.

$Skin

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.32"

$Version

A string representing the release version of PmWiki.

$VersionNum is currently "2003032"

%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

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:

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 "spam.com" (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.

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:

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:

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:

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 pmwiki.org, add the following setting in local/config.php:

The blocklist from chongqed.org 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 "spam.com" 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' => 'http://moinmo.in/BadContent?action=raw',
    '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 pmwiki.org 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:

$EnableBlocklist

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

$EnableWhyBlocked

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

$BlocklistPages

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.

$BlocklistMessageFmt

The message to provide the author whenever a post has been blocked.

$BlockedMessagesFmt

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: ";

$BlocklistDownload

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' => 'http://moinmo.in/BadContent?action=raw', 
    'format' => 'regex',
    'refresh' => 43200);
  # Download a shared blocklist from pmwiki.org every day
  $BlocklistDownload["$SiteAdminGroup.Blocklist-Shared"] = array(
    'format' => 'pmwiki');

$BlocklistDownloadRefresh

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;

$BlocklistDownloadFmt

The format to use when saving automatically downloaded blocklists.

$EnableBlocklistImmediate

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.

$BlocklistActions

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;

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;
Blocklist($pagename,$some_text_string);
if ($Enablepost)
{
WritePage($datapagename,$rcpage);
}

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

blocklist bug! I create SiteAdmin.Blocklist

SiteAdmin.Blocklist

• block:caca.com

config.php

• $EnableBlocklist = 1;

When I edit a page, the script "scripts / blocklist.php" is played ... caca.com 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

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: http://www.loncarek.de/pages/SiteAdmin/Blocklist-PmWiki

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
listData

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, "https://www.pmwiki.org/blocklists/SiteAdmin.Blocklist-PmWiki", "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.

• Forms
• paragraphs
• indent/outdent
• lists
• list items
• headings
• divisions and semantic HTML5 elements
• images
• pre
• tables

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

Division blocks

(:div:)
Outer block
(:div2:)
Inner block
(:div2end:)
(:divend:)

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.

(:article:)...(:articleend:)

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:

(:article:)
Outer article
(:article2:)
Inner article
(:article2end:)
(:articleend:)

(:section:)...(:sectionend:)

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.

(:header:)...(:headerend:)

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.

(:footer:)...(:footerend:)

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.

(:aside:)...(:asideend:)

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.

(:address:)...(:addressend:)

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.

(:nav:)...(:navend:)

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 https://caniuse.com/#feat=details 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.
(:detailsend:)

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

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

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

(:div2:) %div rframe%
How do I use rframe in a block?
(:div2end:)
[[<<]]

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

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

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

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

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 \\\ (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.

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
Line2=]":)

The "pre" style can also be applied

>>pre<<
This style preserves white    space, and 
[[(Wikipedia:)newline]]s.
>><<

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?

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 ?
VKrishn February 09, 2023, at 10:23 PM