FAQ

Q 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 pmwiki.php, even if this was caused by a recipe.

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 (config.php, farmconfig.php, Group.php) and test your wiki. If the warning persists, please notify us ASAP with some information on how to reproduce the bug and on your installation (PHP version). If the error doesn’t appear, go to (2).

(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.

Q 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.

Q 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 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 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 first section.

Q 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 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. Otherwise, to track down the addons that cause the warnings, see the first section.

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.

See categories:

Q My wiki displays warnings “PHP Deprecated: crypt(): Supplied salt is not valid for DES. Possible bug in provided salt format” or “Uncaught Argument Count Error?: crypt() expects exactly 2 arguments, 1 given”.

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.Group Attributes, Site Admin.Group Attributes, Site.Auth User and/or PmWiki.Group Attributes? 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.)

Q My wiki displays warnings “Compilation failed: invalid range in character class”.

A character class range in a regular expression is something in brackets like [A-Z]. An invalid character class may look like [Z-A], where the “Z” character should not be before but after the “A” character. It may not be that obvious, but it would be in brackets with a dash between the wrong characters.

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:
[-AZ] or [AZ-]

To track the error, see the first question on this page, and check the variables $GroupPattern, $NamePattern, $MakePageNamePatterns, $ROSPatterns and other locally configured core variables that contain “Pattern” or “Patterns” in the name.

Q 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 “wiki.d” and “uploads”; “read ®” access to those in the “wikilib.d” directory; “list/search (x)” for the directories themselves. Search the documentation of your hosting provider for more information.

Alternatively, this may 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 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.

Q 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 local/config.php:
@ini_set('pcre.backtrack_limit', 10000000);

Q 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 match not begin/end of strings but also begin/end of lines (i.e., right before/after a newline). Also make sure your markup is executed during the fulltext phase.

Q How can the text returned by my markup function be re-processed by the markup engine?

If the result of your markup contains more markup that should be processed, you have two options. First is to select a “when” argument that is processed earlier than the markup in your result. For example, if your markup may return [[links]], your “when” argument could be “<links” and your markup will be processed before the links markup. The second option is to call the PRR() function in your markup definition or inside your markup function. In this case, after your markup is processed, PmWiki will restart all markups from the beginning.

Q How do I get started writing recipes and creating my own custom markup?

(alternate) Introduction to custom markup for Beginners

Q How do I make a rule that runs once at the end of all other rule processing?

Use this statement instead of the usual Markup() call:

$MarkupFrameBase[‘posteval’][‘myfooter’] = “\$out = onetimerule(\$out);”;

Q 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.

Q 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.

Q Does PmWiki support WYSIWYG editing (or something like the FCK Editor?)?

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. See also Cookbook:Worse and Cookbook:PmSyntax.

Categories: PmWiki Developer