version=pmwiki-2.2.90 ordered=1 urlencoded=1 author=Petko charset=UTF-8 csum=#blank_sections name=PmWiki.Troubleshooting rev=130 targets=PmWiki.HowToGetAssistance,PmWiki.MailingLists,PmWiki.Questions,Cookbook.Cookbook,PITS.01319,PmWiki.CustomMarkup,PmWiki.Upgrades,PmWiki.Functions,PmWiki.Installation,PmWiki.InitialSetupTasks,PmWiki.FilePermissions,PmWiki.WikiGroup,PmWiki.LocalCustomizations,PmWiki.UploadsAdmin,PmWiki.Tables text=(:Summary:Advice for troubleshooting an installation:)%0a(:Audience: administrators :)%0a%0aPmWiki is pretty robust and can automatically adapt to a very wide variety of environments. %0aHowever, sometimes things don't go as we expect, so we're cataloging common errors and their fixes here.%0a%0a!! Troubleshooting Frequently Asked Questions%0a%0a->%25note%25 Note: This page on pmwiki.org is probably not the best place to post questions. Consider [[PmWiki:HowToGetAssistance | seeking assistance]] from the pmwiki-users [[mailing list(s)]], or post your question on the [[PmWiki:Questions]] page.%0a%0a>>faq%3c%3c [[#faq]]%0aQ: [[#deprecated]] My wiki displays warnings "Deprecated: preg_replace(): The /e modifier is deprecated, use preg_replace_callback instead".%0aA: This is caused by a change in PHP version 5.5 for the [[http://php.net/preg_replace|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 even if the warning points to a line in pmwiki.php, the problem comes from a local configuration or recipe.%0a%0aA: 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:)Cookbook]]. If you update your PmWiki and recipes, and still see the warnings, here is how to find out which recipes cause them:%0a%0aA: For PmWiki version 2.2.71 or newer, in config.php, enable diagnostic tools: \\%0a@@$EnableDiag = 1;@@\\%0aThen 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.%0a%0aA: 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.%0a%0aA: 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.%0a%0aA: 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, [[PITS:01319|tell us]] and we'll try to fix them.%0a%0aA: 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.%0a%0aA: Finally, it is possible to suppress these warnings in PHP 5.5, by setting this line at the beginning of config.php: \\%0a@@error_reporting(E_ALL & ~E_NOTICE & ~E_DEPRECATED);@@\\%0aThis should be a temporary solution, left only until your recipes are fixed.%0a%0a[[#blank_sections]]%0aQ: 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.%0aA: This can be caused by a change in PHP 5.4 which affects the function @@htmlspecialchars()@@.%0a%0aA: 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:%0a%0a default_charset = "Windows-1252"%0a%0aA: Or, this may sometimes work in @@pmwiki/local/config.php@@:%0a%0a ini_set("default_charset", "Windows-1252");%0a%0aA: A more permanent fix would be to [[Upgrades|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.%0a%0aA: 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 [[Functions#PHSC|PHSC() function]] always pretends that it converts an 8-bit encoding where all bits are allowed.%0a%0aQ: Why am I seeing strange errors after [[(PmWiki.)upgrad(es)]]ing?%0aA: Make sure all of the files were updated, in particular ''pmwiki.php''.%0a%0aA: This question sometimes arises when an administrator hasn't%0afollowed the advice, which used to be less prominent, on the%0a[[(PmWiki.)installation(#notes)]] and%0a[[(PmWiki.)initial setup tasks(#dontmodify)]] pages and has renamed%0a''pmwiki.php'' instead of creating an ''index.php'' wrapper script.%0aIf you have renamed ''pmwiki.php'' to ''index.php'', then the upgrade procedure%0awon't have updated your ''index.php'' file. Delete the old version and%0acreate a wrapper script so it won't happen again.%0a%0aA: Sometimes an FTP or other copy program will fail to transfer all of the%0afiles properly. One way to check for this is by comparing file sizes.%0a%0aA: Be sure all of the files in the ''wikilib.d/'' directory%0awere also upgraded. Sometimes it's a good idea to simply delete the ''wikilib.d/''%0adirectory before upgrading. (Local copies of pages are stored in ''wiki.d/'' and not ''wikilib.d/''.)%0a%0aA: Make sure that the [[(PmWiki.)file permissions]] are correct. The official files have a restricted set of permissions that might not match your site's needs.%0a%0aA: If you use a custom pattern for $GroupPattern make sure that it includes Site ($SiteGroup) and since PMWiki 2.2 also SiteAdmin ($SiteAdminGroup).%0aOtherwise migration may fail (e.g. missing SiteAdmin for PMWiki 2.2 and later) and/or login does not work.\\%0aAdditionally Main ($DefaultGroup) should be included too.%0a%0a[[#flock]]%0aQ: I'm suddenly getting messages like "@@Warning: fopen(wiki.d/.flock): failed to open stream: Permission denied...@@" and "@@Cannot acquire lockfile@@"... what's wrong?%0a%0aA: Something (or someone) has changed the [[PmWiki/FilePermissions | 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 %25newwin%25[[http://filezilla-project.org/ | FileZilla]] (open-source FTP app) by right-clicking on the file > File attributes)%0a%0a[[#sidebar]]%0aQ: 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?%0a%0aA: Links in the sidebar normally need to be qualified by a [[WikiGroup]] in order to work properly (use [=[[Group.Page]] instead of [[Page]]=]).\\%0aAlso: Make sure you type Side'''B'''ar with a capital B.%0a%0a[[#headers]]%0aQ: Why am I seeing "@@PHP Warning: Cannot modify header information - headers already sent by ...@@" messages at the top of my page.%0a%0aA: 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 [@%3c?php@] or after the [@?>@] in a [[local customization(s)]] files such as @@config.php@@. Double-check the file and make sure there is nothing before the initial [@%3c?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.%0a%0aA: When you save the file, the encoding/charset should be either cp1252/Windows1252 or UTF-8 without Byte Order Mark. [[https://notepad-plus-plus.org/ | NotePad++]] is an editor that can do this.%0a%0aA: When you transfer the files, tell your FTP manager to use text mode transfer, or, if that doesn't help, binary mode transfer.%0a%0a%0aA: If the warning is appearing after some other warning or error message, then resolve the other error and this warning may go away.%0a%0a[[#session_write_close_error]]%0aQ: How do I make a PHP Warning about @@function.session-write-close@@ go away?%0a%0aA: If you are seeing an error similar to this%0a%0a->[@%0aWarning: session_write_close() [function.session-write-close]:%0aopen(/some/filesystem/path/to/a/directory/sess_[...]) failed: No such file%0aor directory (2) in /your/filesystem/path/to/pmwiki.php on line NNN%0a@]%0a%0aPmWiki sometimes does session-tracking using PHP's%0a[[http://php.net/session | session-handling functions ]].%0aFor session-tracking to work, some information needs to be written%0ain a directory on the server. That directory needs to exist and%0abe writable by the webserver software. For this example, the%0awebserver software is configured to write sessions in this%0adirectory%0a%0a->[@/some/filesystem/path/to/a/directory/@]%0a%0abut the directory doesn't exist. The solution is to do at least one%0aof these:%0a* '''Create the directory''' and make sure it's writable by the webserver software%0a* Provide a session_save_path value that points to a directory that is writable by the server, e.g. in config.php:%0a%0a->[@session_save_path('/home/someuser/tmp/sessions');@] # unix-type OS%0a->[@session_save_path('C:/server/tmp/sessions');@] # Windows%0a%0a%0a[[#multiplepwprompts]]%0aQ: Why is PmWiki prompting me multiple times for a password I've already entered?%0a%0aA: 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.%0a%0aA: 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.%0a%0aA: See also the question [[#configphp-order|I have to log in twice]] below.%0a%0aQ: 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''.@@"%0a%0aA: 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.%0a%0a%0aQ: 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?%0a%0aA: Be sure all of the files in the ''wikilib.d/'' directory%0awere 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.%0a%0a[[#mod_security]]%0aQ: 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.%0a%0aA: Your webserver probably has [[http://modsecurity.org | 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).%0a%0aSince mod_security intercepts the requests and sends the "forbidden"%0amessage before PmWiki ever gets a chance to run, it's not a bug in PmWiki, and%0athere's little that PmWiki can do about it. Instead, one has to alter the%0awebserver configuration to disable mod_security or reconfigure it to allow%0awhatever word it is forbidding. Some sites may be able to disable mod_security%0aby placing [@SecFilterEngine off@] in a ''.htaccess'' file.%0a%0aQ: I get the following message when attempting to upload an image, what do I do?%0a[-@@'''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'''@@-]%0a%0a@@'''PmWiki can't process your request'''@@%0a%0a[-@@?cannot move uploaded file to /home/onscolre/public_html/pmwikiuploads/Photos/FoundationPupilsIn1958.jpeg@@-]%0a%0a[-@@We are sorry for any inconvenience.@@-]%0a%0aA: Your server is configured with PHP [[http://php.net/manual/en/features.safe-mode.php|Safe Mode]] enabled. Configure your wiki to use a [[PmWiki/UploadsAdmin#sitewideprefix|site-wide uploads prefix]], then create the ''uploads/'' directory manually and set 777 permissions on it (rather than letting PmWiki create the directory).%0a%0a[[#TableRowIndexMax]] [[#divisionbyzero]]%0aQ: I'm starting to see "Division by zero error in pmwiki.php..." on my site. What's wrong?%0a%0aA: 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 [[upgrad(es)]]ing to a later version of PmWiki to remove the error, or try setting the following in ''local/config.php'':%0a%0a $TableRowIndexMax = 1;%0a%0a[[#configphp-order]]%0aQ: 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.%0aA: 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). %0a%0aThe [[PmWiki/LocalCustomizations#configphp-order|order of config.php]] is very significant.%0a%0a[[#CrashWhenEditing]]%0aQ: 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.%0aA: When the editing of a page is initiated a file names [@.flock@] is created in the [@wiki.d@] repertory. 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.%0a time=1473164827