|KCHUNG wiki||PmWiki »
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.
Troubleshooting Frequently Asked Questions
Note: This page on pmwiki.org is probably not the best place to post questions. Consider seeking assistance from the pmwiki-users mailing list, or post your question on the PmWiki:Questions page.
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.
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 recipe causes them:
In config.php disable all recipes: included files from the cookbook directory, or a custom skin, or any line containing "Markup(" or "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, each 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:
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/.)
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
I'm suddenly getting messages like "
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]]).
Why am I seeing "
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
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
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:
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
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 "
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.
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
I get the following message when attempting to upload an image, what do I do?
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:
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
|Page last modified on March 17, 2014|