Pmwiki is pretty robust and can automatically adapt to a very wide variety of environments.
However, sometimes things don't go as we expect, so we're cataloging common errors and their fixes here.
Why am I seeing strange errors after upgrading?
Make sure all of the files were updated, in particular pmwiki.php.
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/.)
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 "Warning: Cannot modify header information - headers already sent ..." 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 or spaces before the <?php or after the ?> in a local customization file. Double-check the file and make sure there aren't any blank lines or spaces before the initial <?php. It's often easiest and safest to eliminate any closing ?> altogether. On Windows, it may be necessary to use a hex editor to convert LFCR line endings to LF line endings in the local\config.php file.
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
/some/filesystem/path/to/a/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.
session_save_path('/home/someuser/tmp/sessions');
Why is PmWiki prompting me multiple times for a password I've already entered?
Usually this is 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.
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). Allso 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" errors, "Not Acceptable", 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 error. Common phrases that tend to trigger mod_security include "curl ", "wget", "file(", and "system(", although there are many others.
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.
PmWiki is a wiki-based system for collaborative creation and maintenance of websites.
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.
Key PmWiki Features
Custom look-and-feel: A site administrator can quickly change the appearance and functions of a PmWiki site by using different
skins and HTML templates. If you can't find an appropriate skin
already made, you can easily modify one or create your own.
Access control: PmWiki password protection can be applied to an entire site, to groups of pages, or to individual pages. Password protection controls who can read pages, edit pages, and upload attachments. PmWiki's access control system is completely self-contained, but it can also work in conjunction with existing password databases, such as
.htaccess, LDAP servers, and MySQL databases.
Customization and plugin architecture: One principle of the
PmWikiPhilosophy is to only include essential features in the core engine, but make it easy for administrators to customize and add new markup. Hundreds of features are already available by using extensions (called "recipes") that are available from the PmWiki
Cookbook.
PmWiki is written in PHP and distributed under the General Public License. It is designed to be simple to install, customize, and maintain for a variety of applications. This site is running pmwiki-2.2.11.
PmWiki is a registered trademark of Patrick R. Michaud.
PmWiki's home on the web is at pmwiki.org.