SideBar (edit)Associated Sites |
(redirected from PmWiki.TroubleShooting) administrators 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.
How to track errors and know if they come from the PmWiki core or from a local configuration or addon/recipe? The PHP programming language has recently deprecated or removed a number of functions that were heavily used in the past by PmWiki and many addons/recipes/skins. The PmWiki core no longer relies on these functions but some addons still do -- here is how to track these. The PmWiki architecture allows addons (recipes, skins) and local configuration to register actions to be performed by PmWiki at a later point of the process. That's why the PHP warning may indicate a line in It is recommended to get the latest versions of PmWiki and of all your addons -- known bugs would have been fixed. This assumes the errors are fixed in the latest versions. (1) First disable or comment out all addons and local configuration ( (2) Enable one local configuration or one addon and test your wiki to see if the error appears. (3) If the error doesn't appear, the problem is likely elsewhere. If you have more addons to enable, go back to (2). (4) If the error appears, it was likely caused by the last configuration or addon that you enabled. Search the documentation and the cookbook for more recent versions, or contact the addon maintainer, or leave a message on the talk page. If that doesn't work, contact us at our issue tracking system. Developers can find documentation on how to update old addons at CustomMarkup and Functions. (5) Disable again the faulty addon and if you have more addons to enable, go back to (2). PmWiki has a friendly and reactive community and we may be able to quickly provide fixes. After some upgrades to website, hosting, or browser, some skin styles/colors and possibly local styles, recipes, and embedded pictures, have stopped working. In your local configuration, if you have the variables After a PHP upgrade, some of my markup rules have been disabled, and a tooltip title says (in English) "Markup rule ... is obsolete and has been disabled. See pmwiki.org/Troubleshooting". The obsolete markup rule should appear on the tooltip title and should make it easy to identify which custom configuration or addon/recipe caused it. If it is not obvious, follow the steps in the first section. Developers can find documentation on how to update old addons at CustomMarkup and Functions. My wiki displays warnings " 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 PHP 7.2 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 PmWiki:CustomPagelistSortOrder. The recipe Cookbook: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 How to track down the addons that cause the warnings, see the first section. My wiki displays warnings " 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 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 If the 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 See categories: . My wiki displays warnings " You probably have configuration settings that worked on older PHP versions. Here is how to hunt and try to fix this. In your (farm) Additionally, if there are locked passwords with a star The Some of your page files may still have the old star Edit the file and replace the star My wiki displays warnings " A character class range in a regular expression is something in brackets like If you want to match an actual dash (minus) rather than identify a character range, you need to place it first or last thing, like: To track the error, see the first question on this page, and check the variables 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. Sometimes this may be caused by insufficient file permissions on the server. The PHP process needs "read/write (rw)" access to all files in the directories " Alternatively, this may be caused by a change in PHP 5.4 which affects the function The easiest temporary fix would be in your Or, this may sometimes work in 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 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 Very long pages with thousands of lines may appear blank after adding a few additional lines. This may be preformatted text, table, or text inside conditional markup, or text in a custom markup directive. This may be caused by the PHP limits on how far to look forward, and loop back, when searching for matches of regular expressions. You may want to split the very long page into several pages, or the very long markup into separate sections/blocks, or you can increase the PHP limits by adding this to Why am I seeing strange errors after upgrading? Make sure all of the files were updated, in particular 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
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 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 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 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, spaces, or other characters before the When you save the file, the encoding/charset should be either 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 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:
session_save_path('/home/someuser/tmp/sessions'); # unix-type OS
session_save_path('C:/server/tmp/sessions'); # Windows
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 You've made a mistake in writing the PHP that goes into the 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 Some of my posts are coming back with "403 Forbidden", "406 Not Acceptable", or "418 I'm a teapot" 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 Alternatively, you may try the recipe Cookbook:EncodePost. I get the following message when attempting to upload an image, what do I do?
Your server is configured with PHP Safe Mode enabled (removed as of PHP 5.4.0). 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 " 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 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 It could happen if (farm) The order of 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 I get the error " 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. This page may have a more recent version on pmwiki.org: PmWiki:Troubleshooting, and a talk page: PmWiki:Troubleshooting-Talk. |