I use version 1.27.5, and when i trying go to recent changes, i get <code>Exception encountered, of type "ParseError" </code>. What is that?
Topic on Project:Support desk
In your LocalSettings.php set:
$wgShowExceptionDetails = true; $wgShowDBErrorBacktrace = true;
$wgDevelopmentWarnings = true; error_reporting( -1 ); ini_set( 'display_errors', 1);
For further details, see Manual:How to debug.
i'll set it in localsettings and i get this:
Warning: file_exists(): open_basedir restriction in effect. File(/tmp) is not within the allowed path(s): (/var/www/second32/data:.) in /var/www/second32/data/www/veselcraft.ru/wiki/includes/GlobalFunctions.php on line 2132 Warning: Unterminated comment starting line 1164 in /var/www/second32/data/www/veselcraft.ru/wiki/vendor/zordius/lightncandy/src/lightncandy.php on line 1164 Exception encountered, of type "ParseError"
[W-fgXBqrXffq3cxp-eCY-wAAAGs] /wiki/index.php/Special:RecentChanges ParseError from line 1173 of /var/www/second32/data/www/veselcraft.ru/wiki/vendor/zordius/lightncandy/src/lightncandy.php: syntax error, unexpected end of file, expecting function (T_FUNCTION)
i mean problem in file /vendor/zordius/lightncandy/src/lightncandy.php
I see two problems:
- Please make sure that file vendor/zordius/lightncandy/src/lightncandy.php really got uploaded correctly to your server. It seems like the file is not complete.
- For the open_basedir() problem, please make sure that /tmp gets added to the allowed paths! (If that is not possible, I guess there might be a MediaWiki configuration option to use a custom location for temp files...)
When accessing our mediawiki website, we got this error:
Exception encountered, of type "ParseError"
Recently on the Debian Stretch, we did 'apt-get update' and 'apt-get upgrade'. Apparently, there was a software bug in the User.php file in 1:1.27.7-1~deb9u4. It was fine in the version 1:1.27.7-1~deb9u3.
The solution? Here are the changes we made in the User.php file under /usr/share/mediawiki/includes/user
Before the change
1803 if ( $id == 0 ) {
1804 // limits for anons
1805 if ( isset( $limits['anon'] ) ) {
1806 $keys[wfMemcKey( 'limiter', $action, 'anon' )] = $limits['anon'];
1807 }
1808 } else {
1809 // limits for logged-in users
1810 if ( isset( $limits['user'] ) ) {
1811 $userLimit = $limits['user'];
1812 }
1813 } else {
1814 // "global per name" limit, across sites
1815 if ( isset( $limits['user-global'] ) ) {
1816 $lookup = CentralIdLookup::factoryNonLocal();
After the change
1803 if ( $id == 0 ) {
1804 // limits for anons
1805 if ( isset( $limits['anon'] ) ) {
1806 $keys[wfMemcKey( 'limiter', $action, 'anon' )] = $limits['anon'];
1807 }
1808 // limits for logged-in users
1809 } elseif ( isset( $limits['user'] ) ) {
1810 $userLimit = $limits['user'];
1811 }
1812 else {
1813 // "global per name" limit, across sites
Yes, we got it fixed
- Patrick Ni, September 27, 2020
We had the exactly the same problem:
After upgrading our Debian Stretch mediawiki from 1:1.27.7-1~deb9u3 to version 1:1.27.7-1~deb9u4 we got the Exception encountered, of type "ParseError"
Your patch fixed it for us, so thanks a lot for that!
But still there should be a fix from debian to not break the thing again with the next official update. Did you report the bug to Debian?
Thank you Patrick, saved my day.