• HomePage
• WikiSandbox

PmWiki

• Initial Setup Tasks
• Basic Editing
• Documentation Index
• PmWiki FAQ
• PmWikiPhilosophy
• Release Notes
• ChangeLog

pmwiki.org

• Cookbook (addons)
• Skins (themes)
• PITS (issue tracking)
• Mailing Lists

edit SideBar

• View
• Edit
• History
• Print
• Backlinks

PmWiki Administration Tasks

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

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

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

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

Administering Passwords

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

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

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

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:

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

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

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

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

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

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

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

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

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

Upgrading

To upgrade PmWiki:

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

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

2. Download the version of PmWiki that you want from http://www.pmwiki.org/pub/pmwiki.

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

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

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?