FAQ

What is PmWiki?

PmWiki is a wiki-based system for collaborative creation and maintenance of websites. See PmWiki.

What can I do with it?

PmWiki pages look and act like normal web pages, except they have an "Edit" link that makes it easy to modify existing pages and add new pages into the website, using basic editing rules. You do not need to know or use any HTML or CSS. Page editing can be left open to the public or restricted to small groups of authors. Feel free to experiment with the Text Formatting Rules in the "Wiki sandbox". The website you're currently viewing is built and maintained with PmWiki.

What are the requirements?

See the PmWiki requirements page.

Where can I find documentation?

See the documentation index page.

How can I download PmWiki?

See the download page.

How do I install PmWiki?

Instructions for installation are on the installation page.

How do I get help with PmWiki?

See Mailing lists and How to get assistance.

How do you pronounce "Michaud"?

"Michaud" is french pronounced "mee show", the trailing D is silent.

How do I create a new page?

Typing [[my new page]] will create a link to the new page. There's a lot you can do with double bracket links.

Why do some new pages have a title with spaces like "Creating New Pages" and others end up with a WikiWord-like title like "CreatingNewPages"?

The default page title is simply the name of page, which is normally stored as "CreatingNewPages." However, you can override a page's title by using the (:title Creating New Pages:) directive. This is especially useful when there are special characters or capitalization that you want in the title that cannot be used in the page name.

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

See Customizing access keys.

Is there a variable like $LastModified, but which shows me the creation time?

No, but you can create one in config.php. For instance:

# add page variable {$PageCreationDate} in format yyyy-mm-dd
$FmtPV['$PageCreationDate'] = 'strftime("%Y-%m-%d", $page["ctime"])';

If you like the same format that you define in config.php with $TimeFmt use

 $FmtPV['$Created'] = "strftime(\$GLOBALS['TimeFmt'], \$page['ctime'])";

How can I test if a variable is set and/or not empty?

Use (:if ! equal "{$Variable}" "":) $Variable is not empty. (:ifend:). Note that undefined/inexistent variables appear as empty ones.

Categories: PmWiki Developer

How do I set the same header or footer for all pages/groups?

The header and footer for each page are controlled by the variables $GroupHeaderFmt and $GroupFooterFmt. If your site-wide header and footer pages are Site.SiteHeader and Site.SiteFooter, you can add this in config.php:

### If you use Site.SiteHeader and Group.GroupHeader
$GroupHeaderFmt = '(:include {$SiteGroup}.SiteHeader'
  . ' basepage={*$FullName}:)(:nl:)' . $GroupHeaderFmt;

### If you use Site.SiteHeader instead of Group.GroupHeader
$GroupHeaderFmt = '(:include {$SiteGroup}.SiteHeader'
  . ' basepage={*$FullName}:)(:nl:)';

### If you use Site.SiteFooter and Group.GroupFooter
$GroupFooterFmt .= '(:nl:)(:include {$SiteGroup}.SiteFooter'
  . ' basepage={*$FullName}:)';

### If you use Site.SiteFooter instead of Group.GroupFooter
$GroupFooterFmt = '(:nl:)(:include {$SiteGroup}.SiteFooter'
  . ' basepage={*$FullName}:)';

Note that single quotes must be used in the lines above.

See also the Cookbook:AllGroupHeader recipe.

Instead of using an additional page, you could set any wiki text in $GroupHeaderFmt, for example:

Is there a way to remove page history from page files?

1. Administrators can clean page histories using the Cookbook:ExpireDiff recipe.

2. Administrators with FTP file access can download individual pages from the wiki.d directory, open them in a text editor, manually remove history, and re-upload the files to wiki.d/ directory. Care must be exercised, when manually editing a page file, to preserve the minimum required elements of the page and avoid corrupting its contents. See PageFileFormat#creating.

3. Edit the page. Select all the contents of the edit text area and cut them to the clipboard. Enter delete into the text area and click on the save and edit button. Select all the contents of the edit text area and paste the contents of the clipboard over them. Click on the save button. This will remove all of the page's history up to the final save in which the pasted material is re-added.

How can I restrict viewing the page history (?action=diff) to people with edit permission?

In the local/config.php file, set

In case of this restriction is set up on a farm, and you want to allow it on a particular wiki, set in your local/config.php :

How do I disable uploading of a certain type of file?

Here's an example of what to add to your local/config.php file to disable uploading of .zip files, or of files with no extension:

$UploadExtSize['zip'] = 0;  # Disallow uploading .zip files
$UploadExtSize[''] = 0;     # Disallow files with no extension

How do I attach uploads to individual pages or the entire site, instead of organizing them by wiki group?

Use the $UploadPrefixFmt variable (see also the Cookbook:UploadGroups recipe).

For $UploadDirQuota - can you provide some units and numbers? Is the specification in bytes or bits? What is the number for 100K? 1 Meg? 1 Gig? 1 Terabyte?

Units are in bytes.

   $UploadDirQuota = 100*1024;         # limit uploads to 100KiB
   $UploadDirQuota = 1000*1024;        # limit uploads to 1000KiB
   $UploadDirQuota = 1024*1024;        # limit uploads to 1MiB
   $UploadDirQuota = 25*1024*1024;     # limit uploads to 25MiB
   $UploadDirQuota = 2*1024*1024*1024; # limit uploads to 2GiB

Is there a way to allow file names with Unicode or additional characters?

Yes, see $UploadNameChars

Where is the list of attachments stored?

It is generated on the fly by the

There's no "config.php"; it's not even clear what a "local customisation file" is!

The "sample-config.php" file in the "docs" folder, is given as an example. Copy it to the "local" folder and rename it to "config.php". You can then remove the "#" symbols or add other commands shown in the documentation. See also Group Customizations.

Can I change the default page something other than Main.HomePage ($DefaultPage)?

Yes, just set the $DefaultPage variable to the name of the page you want to be the default. You might also look at the $DefaultGroup and $DefaultName configuration variables.

Note the recommendations in $DefaultName and the need to set $PagePathFmt as well if you are changing the default startup page for groups.

How do I get the group / page name in a local configuration file (e.g. local/config.php)?

Use the following markup in pmwiki-2.1.beta21 or newer:

## Get the group and page name
$pagename = ResolvePageName($pagename);
$page = PageVar($pagename, '$FullName');
$group = PageVar($pagename, '$Group');
$name = PageVar($pagename, '$Name');

Note the importance of the order of customizations in config.php above to avoid caching problems.

If you need the verbatim group and page name (from the request) early in config.php, $pagename is guaranteed to be set to

1. Any value of ?n= if it's set, or
2. Any value of ?pagename= if it's set, or
3. The "path info" information from REQUEST_URI (whatever follows SCRIPT_NAME), or
4. Blank otherwise

according to this posting

Can I remove items from the wikilib.d folder on my site?

The files named Site.* and SiteAdmin.* contain parts of the interface and the configuration and they should not be removed. The other files named PmWiki* contain the documentation and could be removed.

How do I customize my own 404 error page for non-existent pages?

To change the text of the message, try editing the Site.PageNotFound page.

Is the order of customizations in config.php important? Are there certain things that should come before or after others in that file?

Yes, see Order of the commands in config.php.

How can I apply CSS styles to a particular group or page?

Simply create a pub/css/Group.css or pub/css/Group.Page.css file containing the custom CSS styles for that group or page. See also Cookbook:LocalCSS.

Why shouldn't passwords be set in group (or page) customization files? Why shouldn't group or page passwords be set in config.php?

The reason for this advice is that per-group customization files are only loaded for the current page. So, if $DefaultPasswords['read'] is set in local/GroupA.php, then someone could use a page in another group to view the contents of pages in GroupA. For example, Main.WikiSandbox could contain:

(:include GroupA.SomePage:)

and because the GroupA.php file wasn't loaded (we're looking at Main.WikiSandbox --> local/Main.php), there's no read password set.

The same is true for page customization files.

Isn't that processing order strange? Why not load per page configuration last (that is after global configuration an per group configuration)?

Many times what we want to do is to enable a certain capability for a group of pages, but disable it on a specific page, as if it was never enabled. If the per-group config file is processed first, then it becomes very difficult/tedious for the per-page one to "undo" the effects of the per-group page. So, we load the per-page file before the per-group.

If a per-page customization wants the per-group customizations to be performed first, it can use the techniques given above (using include_once() or setting $EnablePGCust = 0;).

How do I change the Wiki's default name in the upper left corner of the Main Page?

Put the following config.php

The docs/sample-config.php file has an example of changing the title.

How can I embed PmWiki pages inside a web page?

Source them through a PHP page, or place them in a frame.

How do I change the font or background color of the hints block on the Edit Page?

Add a CSS style to pub/css/local.css: .quickref {background:...; color:... }. The hints are provided by the Site.EditQuickReference page, which is in the PmWiki or Site wikigroup. Edit that page, and change the "bgcolor" or specify the font "color" to get the contrast you need.

How do I customize the CSS styling of my PmWiki layout?

See Skins for how to change the default PmWiki skin. See also Skins, where you will find pre-made templates you can use to customize the appearance of your site. You can also create a file called local.css in the pub/css/ directory and add CSS selectors there (this file gets automatically loaded if it exists). Or, styles can be added directly into a local customization file by using something like:

Where can the mentioned "translation table" be found for adding translated phrases?

See Internationalizations.

Is it possible to have the edit form in full page width, with no sidebar?

If the sidebar is marked with <!--PageLeftFmt-->, adding (:noleft:) to Site.EditForm will hide it when a page is edited.

Can I easily hide the Home Page title from the homepage?

Yes, you can use in the wiki page either (:title Some other title:) to change it or (:notitle:) to hide it.

Is it possible to hide the Search-Bar in the default PmWiki Skin?

Yes, please see Cookbook:HideSearchBar.

How do I include text from the page (whole page, or first X characters) in the feed body? (note: markup NOT digested)

    function MarkupExcerpt($pagename) {
      $page = RetrieveAuthPage($pagename, 'read', false);
      return substr(@$page['text'], 0, 200);
    }

    $FmtPV['$MarkupExcerpt'] = 'MarkupExcerpt($pn)';
    $FeedFmt['rss']['item']['description'] = '$MarkupExcerpt';

Does this mean if I want to include the time in the rss title and "summary" to rss body I call $FeedFmt twice like so:

$FeedFmt['rss']['item']['description'] = '$LastSummary'; 
$FeedFmt['rss']['item']['title'] = '{$Group} / {$Title} @ $ItemISOTime';

How can I use the RSS <enclosure> tag for podcasting?

For podcasting of mp3 files, simply attach an mp3 file to the page with the same name as the page (i.e., for a page named Podcast.Episode4, one would attach to that page a file named "Episode4.mp3"). The file is automatically picked up by ?action=rss and used as an enclosure.

The set of potential enclosures is given by the $RSSEnclosureFmt array, thus

allows podcasting in mp3, wma, and ogg formats.

How to add "summary" to the title in a rss feed (ie. with ?action=rss)?

Add this line in you local/config.php

How to add "description" to the title in an rss feed, and summary to the body?

Add these lines to your local/config.php

NOTES:

• you need to replicate these lines for each type (atom, rdf, dc) of feed you provide.
• the RSS description-tag is not equivalent to the pmWiki $Description variable, despite the confusing similarity.

Some of my password-protected pages aren't appearing in the feed... how do I work around this?

From a similar question on the newsgroup, Pm's reply:

The last time I checked, RSS and other syndication protocols didn't really have a well-established interface or mechanism for performing access control (i.e., authentication). As far as I know this is still the case.

PmWiki's WebFeeds capability is built on top of pagelists, so it could simply be that the $EnablePageListProtect option is preventing the updated pages from appearing in the feed. You might try setting $EnablePageListProtect=0; and see if the password-protected pages start appearing in the RSS feed.

The "downside" to setting $EnablePageListProtect to zero is that anyone doing a search on your site will see the existence of the pages in the locked section. They won't be able to read any of them, but they'll know they are there!

You could also set $EnablePageListProtect to zero only if ?action=rss:

    if ($action == 'rss') $EnablePageListProtect = 0;

This limits the ability to see the protected pages to RSS feeds; normal pagelists and searches wouldn't see them.

Lastly, it's also possible to configure the webfeeds to obtain the authentication information from the url directly, as in:

    .../Site/AllRecentChanges?action=rss&authpw=secret

The big downside to this is that the cleartext password will end up traveling across the net with every RSS request, and may end up being recorded in Apache's access logs.

How to add feed image?

Add the following to local/config.php (this example is for ?action=rss):

$FeedFmt['rss']['feed']['image'] =
" <title>Logo title</title>
 <link>http://example.com/</link>
 <url>http://example.com/images/logo.gif</url>
 <width>120</width>
 <height>60</height>";

How do I insert RSS news feeds into PmWiki pages?

See Cookbook:RssFeedDisplay.

How can I specify default feed options in a configuration file instead of always placing them in the url?

For example, if you want ?action=rss to default to ?action=rss&group=News&order=-time&count=10, try the following in a local customization file:

   if ($action == 'rss')
     SDVA($_REQUEST, array(
       'group' => 'News',
       'order' => '-time',
       'count' => 10));

Are there ways to let people easily subscribe to a feed?

On some browsers (Mozilla Firefox), the visitor can see an orange RSS icon in the address bar, and subscribe to the feed by clicking on it. To enable the RSS icon, add this to config.php :

$HTMLHeaderFmt['feedlinks'] = '<link rel="alternate" type="application/rss+xml" 
  title="$WikiTitle" href="$ScriptUrl?n=Site.AllRecentChanges&amp;action=rss" />
<link rel="alternate" type="application/atom+xml" title="$WikiTitle"
  href="$ScriptUrl?n=Site.AllRecentChanges&amp;action=atom" />';

You can also add such a link, for example in your SideBar, [[Site.AllRecentChanges?action=atom | Subscribe to feed]].

Can I create an RSS feed for individual page histories?

See Cookbook:PageFeed.

How do I create a custom FeedPage similar to RecentChanges or AllRecentChanges, but with only certain groups or pages recorded?

See Cookbook:CustomRecentChanges. In a nutshell, you'll declare a $RecentChangesFmt variable with your dedicated FeedPage, and then wrap it in a condition of your choice. For example:

   if (PageVar($pagename, '$Group')!='ForbiddenGroup') {
     $RecentChangesFmt['Site.MyFeedPage'] =
       '* [[{$FullName}]]  . . . $CurrentTime $[by] $AuthorLink: [=$ChangeSummary=]';
   }

How can I update my RSS feed to show every edit for pages on that feed, not just new pages added to the feed?

Add unique guid links for each edit to your to config.php file (see PITS entry):

   $FeedFmt['rss']['item']['guid'] = '{$PageUrl}?guid=$ItemISOTime';

Alternatively, you can create the option for edit monitoring by adding a qualifier for RSS links. This allows the user to choose between default new pages RSS feeds and new edits RSS feeds (pmwiki.org has this option enabled).

   ## For new pages updates: http://example.com/wiki/HomePage?action=rss
   ## For edits updates: http://example.com/wiki/HomePage?action=rss&edits=1
   if(@$_REQUEST['edits'] && $action == 'rss')
     $FeedFmt['rss']['item']['guid'] = '{$PageUrl}?guid=$ItemISOTime';

My wiki displays warnings "Deprecated: Function create_function() is deprecated".

PHP version 7.2 deprecated a function which PmWiki used for markup definitions and pattern replacements. It is recommended to upgrade to the latest PmWiki version and update all addons and skins from the Cookbook?. Addons in the PHP72? category are reported to be compatible with PHP 7.2. If you need a specific addon that has not yet been updated please contact us. To update your own addons, you probably need to update your calls to Markup(), see the pages Custom markup, Functions and CustomPagelistSortOrder.

The recipe PccfToPcfOverride may provide a temporary solution until you can update all your add-ons.

Note that PmWiki itself doesn't use that function, but (older) addons can register instructions to be processed at a later point. That's why the warning reports a line in pmwiki.php, even if it was requested by a local configuration or an addon.

How to track down the addons that cause the warnings, see the next section.

My wiki displays warnings "Deprecated: preg_replace(): The /e modifier is deprecated, use preg_replace_callback instead".

This is caused by a change in PHP version 5.5 for the preg_replace() function. PmWiki no longer relies on the deprecated feature since version 2.2.56 (it is recommended to upgrade to the latest version) but many recipes do.

Note that PmWiki itself doesn't use that function, but (older) addons can register instructions to be processed at a later point. That's why the warning reports a line in pmwiki.php, even if it was requested by a local configuration or an addon.

Recipes and Skins are currently being updated for PHP 5.5. Check if there are more recent versions published by their maintainers on the Cookbook. If you update your PmWiki and recipes, and still see the warnings, here is how to find out which recipes cause them:

For PmWiki version 2.2.71 or newer, in config.php, enable diagnostic tools:
$EnableDiag = 1;
Then visit your wiki with the action 'ruleset', for example http://www.pmwiki.org/wiki/PmWiki/PmWiki?action=ruleset or follow a link like [[HomePage?action=ruleset]]. This page will list all markup rules; those potentially incompatible with PHP 5.5 will be flagged with filenames, line numbers and search patterns triggering the warning.

If the ?action=ruleset page shows no flagged rules, it is possible that either your recipes call the preg_replace() function directly, or they define various search-replace patterns in incompatible ways. In these cases, your warning should display the file name and line number causing problems, if not, here is how to track it. In config.php disable all recipes: included files from the cookbook directory, or a custom skin, or any line containing "Patterns". You can insert # at the beginning of a line to disable it. Then test the wiki: if you have disabled everything, the warning message should disappear.

Next, re-enable your customizations one after another, every time testing the wiki. If at some point the warnings re-appear, you'll know that the customization you just enabled is not compatible with PHP 5.5.

You can contact the authors of the broken recipes and (kindly) ask them to update their recipes for PHP 5.5 - recent PmWiki versions add new helper functions which make it easy, see CustomMarkup. If you cannot have the recipes fixed by their authors, tell us and we'll try to fix them.

Note that many hosting providers allow you to run different versions of PHP. See the documentation of your hosting plan to learn how to enable a PHP version earlier than 5.5.

Finally, it is possible to suppress these warnings in PHP 5.5, by setting this line at the beginning of config.php:
error_reporting(E_ALL & ~E_NOTICE & ~E_DEPRECATED);
This should be a temporary solution, left only until your recipes are fixed.

My wiki displays warnings "PHP Deprecated: crypt(): Supplied salt is not valid for DES. Possible bug in provided salt format".

You probably have configuration settings that worked on older PHP versions. Here is how to hunt and try to fix this.

In your (farm)config.php or other local or cookbook files, any call to crypt can be replaced with pmcrypt, eg
$DefaultPasswords['edit'] = crypt("my_password"); # DEPRECATED
$DefaultPasswords['edit'] = pmcrypt("my_password"); # OK
$DefaultPasswords['edit'] = array(pmcrypt("pass1"), pmcrypt("pass2")); # OK

Additionally, if there are locked passwords with a star *, you should replace those with @lock:
$DefaultPasswords['edit'] = '*'; # DEPRECATED
$DefaultPasswords['edit'] = '@lock'; # OK (and no pmcrypt)

The $DefaultPasswords variables usually have keys like 'edit', 'attr', 'read', 'upload', 'publish'.

Some of your page files may still have the old star * locking. Files that in the past shipped with the star lock were Site.GroupAttributes, SiteAdmin.GroupAttributes, Site.AuthUser and/or PmWiki.GroupAttributes in the directories wikilib.d and/or wiki.d. You need to edit them in a text editor and replace any line among these:
passwdedit=*
passwdattr=*
passwdread=*
passwdpublish=*
passwdupload=*

Edit the file and replace the star * with the word @lock on every existing line. Do not add these lines if they are not already in the file, and do not change the lines if there is something other than a single star after the = equals sign. Save the file, upload it back to your wiki and the warnings should disappear. (If you run a wiki farm, you may have such files in several wiki.d directories.)

After a PHP upgrade, some of the pages on my wiki are completely blank, empty, some have blank or missing sections, but the sidebar and the action links are visible.

This can be caused by a change in PHP 5.4 which affects the function htmlspecialchars().

The easiest temporary fix would be in your php.ini, or in .user.ini to change the default_charset directive to an 8-bit charset, for example cp1252:

    default_charset = "Windows-1252"

Or, this may sometimes work in pmwiki/local/config.php:

    ini_set("default_charset", "Windows-1252");

A more permanent fix would be to upgrade your installation to a more recent PmWiki version, your recipes, and in your own recipes or modules replace all calls to htmlspecialchars() with PHSC(), a PmWiki helper function for such cases.

The "blank" pages come from the fact that in PHP 5.4 the default encoding switched from an 8-bit encoding to variable-bit validated UTF-8, and that an incorrect UTF-8 string will be rejected. If your wiki uses an 8-bit encoding, it is virtually certain that it is not valid UTF-8. Worse, even if you do use UTF-8 some browsers may submit invalid bits. So the PHSC() function always pretends that it converts an 8-bit encoding where all bits are allowed.

Why am I seeing strange errors after upgrading?

Make sure all of the files were updated, in particular pmwiki.php and all files in the scripts/ directory.

This question sometimes arises when an administrator hasn't followed the advice, which used to be less prominent, on the installation and initial setup tasks pages and has renamed pmwiki.php instead of creating an index.php wrapper script. If you have renamed pmwiki.php to index.php, then the upgrade procedure won't have updated your index.php file. Delete the old version and create a wrapper script so it won't happen again.

Sometimes an FTP or other copy program will fail to transfer all of the files properly. One way to check for this is by comparing file sizes.

Be sure all of the files in the wikilib.d/ directory were also upgraded. Sometimes it's a good idea to simply delete the wikilib.d/ directory before upgrading. (Local copies of pages are stored in wiki.d/ and not wikilib.d/.)

Make sure that the file permissions are correct. The official files have a restricted set of permissions that might not match your site's needs.

If you use a custom pattern for $GroupPattern make sure that it includes Site ($SiteGroup) and since PMWiki 2.2 also SiteAdmin ($SiteAdminGroup). Otherwise migration may fail (e.g. missing SiteAdmin for PMWiki 2.2 and later) and/or login does not work.
Additionally Main ($DefaultGroup) should be included too.

I'm suddenly getting messages like "Warning: fopen(wiki.d/.flock): failed to open stream: Permission denied..." and "Cannot acquire lockfile"... what's wrong?

Something (or someone) has changed the permissions on the wiki.d/.flock file or the wiki.d/ directory such that the webserver is no longer able to write the lockfile. The normal solution is to simply delete the .flock file from the wiki.d/ directory -- PmWiki will then create a new one. Also be sure to check the permissions on the wiki.d/ directory itself. (One can easily check and modify permissions of the wiki.d/ directory in FileZilla (open-source FTP app) by right-clicking on the file > File attributes)

My links in the sidebar seem to be pointing to non-existent pages, even though I know I created the pages. Where are the pages?

Links in the sidebar normally need to be qualified by a WikiGroup in order to work properly (use [[Group.Page]] instead of [[Page]]).
Also: Make sure you type SideBar with a capital B.

Why am I seeing "PHP Warning: Cannot modify header information - headers already sent by ..." messages at the top of my page.

If this is the first or only error message you're seeing, it's usually an indication that there are blank lines, spaces, or other characters before the <?php or after the ?> in a local customization files such as config.php. Double-check the file and make sure there is nothing before the initial <?php. It's often easiest and safest to eliminate any closing ?> altogether. On Windows, it may be, but shouldn't be, necessary to use a hex editor to convert LFCR line endings to LF line endings in the local\config.php file.

When you save the file, the encoding/charset should be either cp1252/Windows1252 or UTF-8 without Byte Order Mark. NotePad++ is an editor that can do this.

When you transfer the files, tell your FTP manager to use text mode transfer, or, if that doesn't help, binary mode transfer.

If the warning is appearing after some other warning or error message, then resolve the other error and this warning may go away.

How do I make a PHP Warning about function.session-write-close go away?

If you are seeing an error similar to this

Warning: session_write_close() [function.session-write-close]:
open(/some/filesystem/path/to/a/directory/sess_[...]) failed: No such file
or directory (2) in /your/filesystem/path/to/pmwiki.php on line NNN

PmWiki sometimes does session-tracking using PHP's session-handling functions. For session-tracking to work, some information needs to be written in a directory on the server. That directory needs to exist and be writable by the webserver software. For this example, the webserver software is configured to write sessions in this directory

but the directory doesn't exist. The solution is to do at least one of these:

• Create the directory and make sure it's writable by the webserver software
• Provide a session_save_path value that points to a directory that is writable by the server, e.g. in config.php:

Why is PmWiki prompting me multiple times for a password I've already entered?

This could happen like out of nowhere if your hosting provider upgrades to PHP version 5.3, and you run an older PmWiki release. Recent PmWiki releases fix this problem.

Alternatively, this may be an indication that the browser isn't accepting cookies, or that PHP's session handling functions on the server aren't properly configured. If the browser is accepting cookies, then try setting $EnableDiag=1; in local/config.php, run PmWiki using ?action=phpinfo, and verify that sessions are enabled and that the session.save_path has a reasonable value. Note that several versions of PHP under Windows require that a session_save_path be explicitly set (this can be done in the local/config.php file). You might also try setting session.auto_start to 1 in your php.ini.

See also the question I have to log in twice below.

I edited config.php, but when I look at my wiki pages, all I see is "Parse error: parse error, unexpected T_VARIABLE in somefile on line number."

You've made a mistake in writing the PHP that goes into the config.php file. The most common mistake that causes the T_VARIABLE error is forgetting the semi-colon (;) at the end of a line that you added. The line number and file named are where you should look for the mistake.

Searches and pagelists stopped working after I upgraded -- no errors are reported, but links to other pages do not appear (or do not appear as they should) -- what gives?

Be sure all of the files in the wikilib.d/ directory were also upgraded. In particular, it sounds as if the Site.PageListTemplates page is either missing (if no links are displayed) or is an old version (if the links do not appear as they should). Also make sure that read-permissions (attr) are set for the pages Site.PageListTemplates and Site.Search.

Some of my posts are coming back with "403 Forbidden" or "406 Not Acceptable" errors, or "Internal Server Error". This happens with some posts but not others.

Your webserver probably has mod_security enabled. The mod_security "feature" scans all incoming posts for forbidden words or phrases that might indicate someone is trying to hack the system, and if any of them are present then Apache returns the 403 Forbidden or 406 Not Acceptable error. Common phrases that tend to trigger mod_security include "curl ", "wget", "file(", and "system(", although there are many others (depending on the configuration, percent signs, html tags, international characters).

Since mod_security intercepts the requests and sends the "forbidden" message before PmWiki ever gets a chance to run, it's not a bug in PmWiki, and there's little that PmWiki can do about it. Instead, one has to alter the webserver configuration to disable mod_security or reconfigure it to allow whatever word it is forbidding. Some sites may be able to disable mod_security by placing SecFilterEngine off in a .htaccess file.

I get the following message when attempting to upload an image, what do I do?

Warning: move_uploaded_file(): SAFE MODE Restriction in effect. The script whose uid is 1929 is not allowed to access /home/onscolre/public_html/pmwikiuploads/Photos owned by uid 33 in /home/onscolre/public_html/pmwiki/scripts/upload.php on line 198

PmWiki can't process your request

?cannot move uploaded file to /home/onscolre/public_html/pmwikiuploads/Photos/FoundationPupilsIn1958.jpeg

We are sorry for any inconvenience.

Your server is configured with PHP Safe Mode enabled. Configure your wiki to use a site-wide uploads prefix, then create the uploads/ directory manually and set 777 permissions on it (rather than letting PmWiki create the directory).

I'm starting to see "Division by zero error in pmwiki.php..." on my site. What's wrong?

It's a bug in PmWiki that occurs only with the tables markup and only for versions of PHP >= 4.4.6 or >= 5.2.0. Often it seems to occur "out of nowhere" because the server administrator has upgraded PHP. Try upgrading to a later version of PmWiki to remove the error, or try setting the following in local/config.php:

    $TableRowIndexMax = 1;

I have to log in twice (two times) (2 times). -or- My password is not being required even though it should. -or- I changed the password but the old password is still active. -or- My config.php password is not over-riding my farmconfig.php password.

It could happen if (farm)config.php, or an included recipe, directly calls the functions CondAuth(), or RetrieveAuthPage(), PageTextVar(), PageVar() and possibly others, before defining all passwords and before including AuthUser (if required).

The order of config.php is very significant.

When editing an existing page, The "Save" causes a no-response of your server (not a blank page, no response at all, an endless connexion try). To get back the hand, it is necessary to request for another page (by clicking on its link in the menu for instance). And horror!, the ...?action=edit is then inhibited, it becomes impossible to edit any page.

When the editing of a page is initiated a file names .flock is created in the wiki.d repository. As long as this file exists it is impossible to edit any page. This file denotes an edition in progress and is automatically destroyed when leaving successfully an edit action by "Save". In case of a crash of the editing, this file is not destroyed. The remedy is, with an FTP client parameterized to show hidden files, to remove the .flock file. And all get back OK. This behavior is typically caused by a bug which provokes (directly or indirectly), an endless loop in a recipe concerned by the edited page.

I get the error "Data Mismatch - Locking FAILED!"

This is probably not a PmWiki error. PmWiki cannot create a lock file due to an underlying file system problem. For example the disk quota has been exceeded (e.g. by an error log file or file uploads), or there are problems with file system permissions.

Why doesn't PmWiki use hierarchical / nested groups?

It essentially comes down to figuring out how to handle page links between nested groups; if someone can figure out an obvious, intuitive way for authors to do that, then nested groups become plausible. See Design Notes and PmWiki:Hierarchical Groups.

Why don't PmWiki's scripts have a closing ?> tag?

All of PmWiki's scripts now omit the closing ?> tag. The tag is not required, and it avoids problems with unnoticed spaces or blank lines at the end of the file. Also, some file transfer protocols may change the newline character(s) in the file, which can also cause problems. See also the Instruction separation page in the PHP manual.

Does PmWiki support WYSIWYG editing (or something like the FCKEditor)?

Short answer: PmWiki provides GUI buttons in a toolbar for common markups, but otherwise does not have WYSIWYG editing. For the reasons why, see PmWiki:WYSIWYG.

Categories: PmWiki Developer