Extension talk:ParserFunctions

Previous page history was archived for backup purposes at Extension talk:ParserFunctions/LQT Archive 1 on 2015-07-10.

Whenever I use something like {{#timel: r}} or {{#time: r | now | en | 1}}, it outputs the current date and time using the wiki's timezone instead of the user's timezone set in Special:Preferences. This does not behave as expected according to the documentation for #timel, which currently states that "it always uses the preferred time zone of the user or the configured time zone of the wiki". Since #timel is described as effectively #timel but with the local parameter set to true, it is reasonable to believe that #time would also use the user's timezone.

The code currently only uses the value of $wgLocaltimezone and some server value if that is not set (per commit 1430c5a: ParserFunctions.php line 523). When the documentation for #timel was "clarified" to say that it follows the user's timezone (revision 6259692, 11 December 2023), the version of ParserFunctions at the time (commit bccd783, 22 November 2023) also only uses $wgLocaltimezone and some server value (per that commit's ParserFunctions.php line 523).

I initially thought that #time with local/#timel not using the user's timezone was a bug, but according to two Phabricator tasks (T9133 and T34923), this appears to be known? I'm not sure if a lack of support for the user's timezone is intentional or not, can someone clarify whether or not it is?

My parserfunctions extension does not work on both my wiki, MoscowAmerican.com and on project zomboid www.pzwiki.net do you have to enable it? Or is it there by default?

using 1.27 and 1.39

The page Special:Version on your wiki will tell you if the extension is installed or not. If it's not listed there, it needs to be installed.

Has anyone made an extension for VSCode (or any other IDE) for working with parser functions?

How to set unlimited String length?

BUMP

The maximum size of a string is 2GB in PHP. The effective string length this will give you varies according to the type of encoding used. Set that number to 2³¹ and you should be fine for most use cases.

I was wondering if there was an existing option or variable that we can set, either within the functions or within the php, to toggle case-sensitivity? Ideally it would be something within the function for on-the-fly modification, but that might be asking too much and possibly confusing. Anyway, I figured it couldn't help to ask.

This post was posted by Peachey88 (Flood), but signed as 66.135.130.19.

To clarify, I am specifically interested in #ifeq. I have a rather complex template that uses this function quite a lot.

This post was posted by Peachey88 (Flood), but signed as 66.135.130.19.

you could hack it into the code very easy. But you could also use {{lc:}} or {{uc:}} magic words to convert a string. Those are MW functions.

This post was posted by Peachey88 (Flood), but signed as Danwe.

ImageRangeTest is a the range check template; it returns either a 0 or a 1 depending on if the {{{1}}} number is in any of the matching ranges. The number indicates a specific graphic in a game - there's a max possible graphic number, and there are unused graphic positions, so this allows me to test if the particular graphic is one that exists, or which doesn't exist.

This is a simplified version of the ifeq test I'm using to then link to an image of that particular graphic: {{#ifeq: {{ImageRangeTest | {{{1}}} }} | 1 | This image does not exist. | [[File:{{{1}}}.png]] }}

Everything works fine, displays fine, etc. The resulting HTML is fine; either it has the img tag and links the image, or there is no img tag, and "This image does not exist." is displayed.

• However*, there's still one problem, and it looks like a possible bug with #ifeq. When I look at Special:WantedFiles, all of those {{{1}}}.png files that fail the rangetest here show up there as missing files. When I look at the details on any of them, the only page showing a link to any particular missing file is the one which has the above ifeq test.

So, say the page name is Foobar, and {{{1}}} is 2001. 2001 fails the rangecheck. The template then creates the text "This image does not exist." on the page Foobar. The generated HTML for Foobar has no img tag linking 2001.png. However, Special:WantedFiles still shows 2001.png as a WantedFile, and File:2001.png shows: File usage The following page uses this file:

Foobar

So it looks like both possible results from an #if are generated, and only then is the system deciding which one to actually use - which in this case, is generating a bogus WantedFile. (And in my case, that adds up to a few thousand bogus wantedfile entries, making it much harder to spot valid wantedfiles.)

I'm guessing ImageRangeTest contains some code to the effect of {{ #ifexist: File:{{{1}}}.png || 1 }}? #ifexist always counts as a link to the tested page; as it is currently implemented, this is the only way to determine if the page does exist, and also the only way to ensure it correctly updates if a previously nonexistent page is created (or a previously existing page is deleted).

No, no calls to ifexist. This is ImageRangeTest: {{#switch: 1 | {{Rangecheck|{{{1}}}|4318|4323}} ... | {{Rangecheck|{{{1}}}|42325|99999}} = 1 | #default = 0 }}

and this is Rangecheck: {{#ifexpr: {{{1|}}} >= {{{2|}}}|{{#ifexpr: {{{1|}}} <= {{{3|}}}|1|0}}|0}}

Does this still happen if you test some contrived case where the outermost #ifeq doesn't call any template? Something like {{ #ifeq: 1 | 1 | This image does not exist. | [[File:{{{1}}}.png]] }}.

Managed to fix it, I think. I'd oversimplfied above. For whatever reason, the following combo of templates, ifeq, and var seems to have been the combined trigger for the issue (in v. 1.27.0 through 1.33.1) {{#vardefine: graphic|99999}}{{#vardefine:image|{{#ifeq: {{ImageRangeTest | {{#var: graphic}} }} | 1 | This image does not exist. | [[File:{{#var:graphic}}.png]] }} }} .. {{#var:image}}

99999 can be anything; in my particular case, it was taking it from the category page using the above template's title:

{{#vardefine: graphic |{{#replace:{{PAGENAME}}|UO:Items using graphic |}} }}

The image var was actually only used in one place, so I took it out of a var and moved the ifeq to where {{#var:image}} had been. That stopped the invisible non-use of the file from happening.

This is a generic error. Please add $wgShowExceptionDetails = true; at the end of your LocalSettings.php, it should give a more detailed error, then ask in a new thread if it's still not clear from the error message what's the cause of the problem and how to solve it.

Fatal exception of type MWException Error Seen this in several threads but have not found a solution.

How do I fix this?

After adding - require_once( "extensions/ParserFunctions/ParserFunctions.php" );

I get "Fatal exception of type MWException Error", seen this in several threads but have not found a solution.

How do I fix this?

Firstly, I thought this extension was part of the MW core now and there was no reason to install it separately (which would cause an internal conflict if I'm right about that). Secondly, you're not following the directions in Extension:ParserFunctions#Installation which says you should add require_once( "$IP/extensions/ParserFunctions/ParserFunctions.php" );

1) I did reupload the files contained just to be sure and it still gives me that error. 2) That is what I put in LocalSettings.php it was just a typo in my post here..

So still have no idea what is wrong...

I get the same error after installing the mediawiki-package and uploading the created LocalSettings.php. Any solution?

Hello, maybe this will help some people with that error. I got the error when uploading the LocalSettings.php aswell, so I tried and tried to reinstall it and at one point I skipped the configuration process and noticed it worked without. Later I noticed I could need the configuration anyway and skipping it isn't a good sollution so I tried to remove everything from the LocalSettings.php which was not on the unconfigurated one one after the other till it worked. For me it was the following line:

require_once( "$IP/extensions/LocalisationUpdate/LocalisationUpdate.php" );

which caused this error. Simply removing it from the LocalSettings.php removed the error.

@2.245.35.71 Thanks, it worked for me as :) As an experienced net expert I'm sorry for such a script containing this problem.

Great! it worked for me as well. Thanks for your research.

I'm getting this error when MediaWiki attempt to send any emails. But I don't have the line

require_once( "$IP/extensions/LocalisationUpdate/LocalisationUpdate.php" );

in my LocalSettings.php file.

Any other ideas?

I got the same problem as yours. Have you solve it?

I am experiencing the same issue as you and the fixes described in this forum do not address it. If anyone has a fix for the email issue please share!

Old thread, but since I came across this while looking for a solution, I thought I'd let future googlers know what I found. running "pear install mail" and possibly "pear install Net_SMTP" fixed this error. After that I just had to make sure my smtp settings in localsettings.php.

I hope this helps someone!

WORKED!!! This solution is quite hidden between the answers, but for a fresh install in a Debian Wheezy (MW v1.26.2), based on a proxmox CT, is needed.

Thanks a lot.

Thanks you! It's works.

how do you removed this? "MediaWiki internal error. Exception caught inside exception handler." and "Fatal exception of type MWException" it has stopped me from editing wikipedia.. what did i do to make this happen? i do the same things every day? how can i fix this???

I'm getting a lot of these on WP today as well. Everything worked fine yesterday. Example: "[7e0f687c] 2013-06-28 04:56:55: Fatal exception of type MWException".

I can load the main page and click on wikilinks, but clicking "View History" or doing any kind of search results in the above error.

I know what you mean. Seems to be back for me now...

Awesome ;9 Thanky you a thousend!

Great! it worked for me as well. Thanks for your research. (copy and paste)

You don't need to remove LocalisationUpdate! See Bug 46885 - Fatal error after installation when using LocalisationUpdate. The problem is that the MW installer does not do the proper configuration of LU extension. All you have to do is add the cache dir below the require_once like this:

require_once( "$EXT/LocalisationUpdate/LocalisationUpdate.php" );
$wgLocalisationUpdateDirectory = "$IP/cache";

Perhaps wrong place to comment this here but I do it anyway because googling this issues directed me here. This same problem still is with MW 1.22.4 when doing fresh installation of MW and in case LocalisationUpdate is included in initial setup.

Thanks, works for me with Synology Diskstation

When I add:

require_once( "$EXT/LocalisationUpdate/LocalisationUpdate.php" ); $wgLocalisationUpdateDirectory = "$IP/cache";

I get:

Warning: require_once(/LocalisationUpdate/LocalisationUpdate.php) [function.require-once]: failed to open stream: No such file or directory in /home/ideakwty/public_html/dclegalfirm.com/mw/LocalSettings.php on line 134

Fatal error: require_once() [function.require]: Failed opening required '/LocalisationUpdate/LocalisationUpdate.php' (include_path='.:/usr/lib/php:/usr/local/lib/php') in /home/ideakwty/public_html/dclegalfirm.com/mw/LocalSettings.php on line 134

it works, thanks!

Thanks Dude. It worked for me!! You're the Master!!

by best wishes, Danilo.

Was same for me!!

Thank you! It worked for me! :D

Well, when I Put your solution:

require_once( "$EXT/LocalisationUpdate/LocalisationUpdate.php" ); $wgLocalisationUpdateDirectory = "$IP/cache";

The page turns white, and nothing appears... :S why?

Usually your error log should tell you or the browser when setting

$wgShowExceptionDetails = true;

Try this for a change:

require_once "$IP/LocalisationUpdate/LocalisationUpdate.php";
$wgLocalisationUpdateDirectory = "$IP/cache";

I am not sure about this $EXT bit since I have so far never come across something like this.

$IP = wiki's root dir (i.e. yourdomain/wiki)

$EXT = extension's dir (i.e. yourdomain/wiki/extensions)

Great, I did not know this existeted. This points me to a mistake in my previous post. It should be

require_once "$IP/extensions/LocalisationUpdate/LocalisationUpdate.php";
$wgLocalisationUpdateDirectory = "$IP/cache";

However this is no different to the previous suggestion. So back to the log file and exception details.

Beware, that if you try to install the VisualEditor Extension, you need at least mediawiki-core 1.23 (still in development). Otherwise, you got this error too.

You talk way too much but the solution is good. Learn to get to the point.

All you have to do is add this following line to the end of your Localsettings.php

$wgLocalisationUpdateDirectory = "$IP/cache";

I know this thread is a little old, but I just had this error upgrading from 1.22.8 to 1.23.1, and I thought I'd provide the solution that helped me.

In my case, I had a poorly-coded skin that seemed to work on 1.22.8. I guess it used deprecated functions or something, and didn't work caused the Fatal Error when I accessed Special:Preferences.

I changed the default skin to Vector, and all is well in the world.

I faced this problem and it was because I'm using the master image of ParserFunctions . you have to checkout to the version fit your mediawiki version : for me :

git checkout -b mywork origin/REL1_24

Just as a duh..you might want to check that your images folder is writable. I received the same MCException error when it wasn't writable. Which of course I made it writable by chown, chgrp to the apache account.

This was the problem for me too - I had to give 'other' write privileges on the images folder in my install, after that it all seems to work correctly.

same for me, images folder did not have the good rights so apache could not 'mkdir'

After recent update it stopped working because my hoster still uses Magic quotes which are deprecated. I just added following lined to an existing .htaccess file in the root of MW:

php_flag magic_quotes_gpc Off php_value magic_quotes_gpc Off

...and it worked :-)

Thank you!

The same error appears when the owner of the wiki's folder(s) isn't apache

Make you sure about that

chown -R apache.apache wiki_folder/

Problem for me is: All folders are owned by me, not by Apache. My ISP doesn't allow me to change this ownership, and I get the same error after having uploaded the LocalSettings.php file.

I did all suggestions in this thread. None worked for me.

I do not have a require_once( "$EXT/LocalisationUpdate/LocalisationUpdate.php" ); $wgLocalisationUpdateDirectory = "$IP/cache"; line

If I add it the program complains about a missing directory /LocalisationUpdate which actually does not exist:

Warning: require_once(/LocalisationUpdate/LocalisationUpdate.php): failed to open stream: No such file or directory in /home/www/62585963bc9e2a5e92eba0113c714f19/web/AAT/inventaire/LocalSettings.php on line 136

Fatal error: require_once(): Failed opening required '/LocalisationUpdate/LocalisationUpdate.php' (include_path='.:/opt/php/lib/php') in /home/www/62585963bc9e2a5e92eba0113c714f19/web/AAT/inventaire/LocalSettings.php on line 136

Any other clue, anyone, please? Thanks.

EDIT: Some files had size set to 0. Uploaded whole kit again, issue fixed.

Hello,

The issue has been fixed by disabling magic quotes.

I fix this error by set permission to 775

Ext:

$ chgrp -R apache images/

$ chmod -R 775 images/

Thanks. I also had the same problem because I manually copied the latest mediawiki version to the debian standard folder /var/lib/mediawiki but without checking the group settings of the images/ folder.

For Debian Jessie the apache2.4 group is www-data. Changing the group and the 755 chmod did the fix.

Fixed my problem also.

I disable SE linux it is resilve problem. (centos7)

I did a fresh install of Mediawiki and the Extension:VisualEditor when enabling the extention it is asking for Mediawiki 1.26?

[84e98a00] /Spezial:Einstellungen MWException from line 3215 of /var/www/.../includes/GlobalFunctions.php: MediaWiki 1.26wmf12 required--this is only 1.25.2

Backtrace:

#0 /var/www/clients/client1/web39/web/wiki/extensions/VisualEditor/VisualEditor.hooks.php(20): wfUseMW(string) #1 [internal function]: VisualEditorHooks::onSetup() #2 /var/www/.../includes/Setup.php(676): call_user_func(string) #3 /var/www/.../includes/WebStart.php(138): require_once(string) #4 /var/www/.../index.php(38): require(string) #5 {main}

Sorry just found it after asking here - there are special download options:

(German) Special:ExtensionDistributor/VisualEditor

Got the same MWException Error after fresh installation.

Resolved installing missing package php-apc .

Regards, Mateusz

Reply to "Fatal exception of type MWException Error" How to fix this problem? Please help me.

Your error about temp directory has nothing to do with ParserFunctions

After a while the problem was solved for me .

Fir-stable I highly recommend for you to enable the Debugging mode .

add this 2 lines in the end of LocalSettings.php

error_reporting( -1 );

ini_set( 'display_errors', 1 );

then the errors will shown up .

The problem was in the permission to rename /tmp/l10n_cache-en.cdb ,so ,In your terminal

$ cd /tmp

$ sudo mv l10n_cache-en.cdb l10n_cache-en.cdb.tmp.697754271

Now refresh the index page !

Solved :) .

To solve a problem with permissions you should give the necessary permissions. I wouldn't expect doing the rename manually would solve the problem if the long term, when something makes the localisation cache to be invalidated.

My site coetus.eu is down since some time. I don't believe I had edited anything that caused this so I find this strange.

I got the Fatal exception MWException error, so following the recommendation above I added at the end of Phpmyadmin.php :

$wgShowExceptionDetails = true;

As a result I get the following more detailed diagnosis which I struggle to make sense of and to know where to start my investigation.

May you help ?

Many thanks in advance.

Frederic.

When I open page www.coetus.eu

I get :

[088720a5] /wiki/Accueil Exception from line 222 of /home/coetus/public_html/w/includes/Hooks.php: Detected bug in an extension! Hook ExtVariables::init has invalid call signature; Parameter 1 to ExtVariables::init() expected to be a reference, value given

Backtrace:

#0 /home/coetus/public_html/w/includes/GlobalFunctions.php(4004): Hooks::run(string, array, NULL)

#1 /home/coetus/public_html/w/includes/parser/Parser.php(275): wfRunHooks(string, array)

#2 /home/coetus/public_html/w/includes/cache/MessageCache.php(1023): Parser->firstCallInit()

#3 /home/coetus/public_html/w/includes/cache/MessageCache.php(1000): MessageCache->getParser()

#4 /home/coetus/public_html/w/includes/Message.php(977): MessageCache->transform(string, boolean, Language, Title)

#5 /home/coetus/public_html/w/includes/Message.php(669): Message->transformText(string)

#6 /home/coetus/public_html/w/includes/Message.php(732): Message->toString()

#7 /home/coetus/public_html/w/includes/OutputPage.php(853): Message->text()

#8 /home/coetus/public_html/w/includes/OutputPage.php(898): OutputPage->setHTMLTitle(Message)

#9 /home/coetus/public_html/w/includes/Article.php(556): OutputPage->setPageTitle(string)

#10 /home/coetus/public_html/w/includes/actions/ViewAction.php(44): Article->view()

#11 /home/coetus/public_html/w/includes/Wiki.php(428): ViewAction->show()

#12 /home/coetus/public_html/w/includes/Wiki.php(292): MediaWiki->performAction(Article, Title)

#13 /home/coetus/public_html/w/includes/Wiki.php(588): MediaWiki->performRequest()

#14 /home/coetus/public_html/w/includes/Wiki.php(447): MediaWiki->main()

#15 /home/coetus/public_html/w/index.php(46): MediaWiki->run()

#16 {main}

One of your MediaWiki extensions is not compatible with the MediaWiki version you're using.

If you upgraded MediaWiki recently, be sure to also upgrade your extensions as well, by downloading them for the same version of MediaWiki you're using. Note that some extensions may be unmaintained and may not work for your MediaWiki version even if you download it for the version you're using.

To know which extension is causing the problem, comment all require_once() or wfLoadExtension() that loads extensions from your LocalSettings, and enable them one by one until you find the one that causes the error.

thanks for the tips.I believed it was working before it crashed but perhaps I had changed something. I'll follow your suggestion to investigate. Many thanks !

I had a pretty bad night which resulted in my MediaWiki being down. Now I have everything half-way working again, only I can't edit anything now. Now I need someone to held me with this error message.

Maybe you can help me figure it out.

Many thanks in advance

[XVdr8b-myRv10DFSRxmpHgAAAAs] /vampire/index.php?title=Hauptseite&action=edit Error from line 3978 of /home/sites/site24/web/vampire/includes/OutputPage.php: Class 'OOUI\MediaWikiTheme' not found

Backtrace:

#0 /home/sites/site24/web/vampire/includes/OutputPage.php(3991): OutputPage::setupOOUI(string, string)

#1 /home/sites/site24/web/vampire/includes/EditPage.php(2762): OutputPage->enableOOUI()

#2 /home/sites/site24/web/vampire/includes/EditPage.php(659): EditPage->showEditForm()

#3 /home/sites/site24/web/vampire/includes/actions/EditAction.php(59): EditPage->edit()

#4 /home/sites/site24/web/vampire/includes/MediaWiki.php(499): EditAction->show()

#5 /home/sites/site24/web/vampire/includes/MediaWiki.php(293): MediaWiki->performAction(Article, Title)

#6 /home/sites/site24/web/vampire/includes/MediaWiki.php(862): MediaWiki->performRequest()

#7 /home/sites/site24/web/vampire/includes/MediaWiki.php(523): MediaWiki->main()

#8 /home/sites/site24/web/vampire/index.php(43): MediaWiki->run()

#9 {main}

See Topic:U4xrik709n36lgfl

Any support? At least simple conversion to and from decimal? Of course it could be made from scratch, interpreting hex numbers as strings and evaluating each cahracter as a power of 16, but I was hoping to find something ready made, just like, say, #invoke:Roman (which is harder to implement, and seldom used, than hex).

If you install Extension:Scribunto you can create a function to do that: https://stackoverflow.com/questions/27294310/convert-hexadecimal-to-decimal-number

Having Scribunto for that, I doubt you'll get that functionality included in Parser Functions. Anyway, if you're interested, the only way to get it is to bugreport it.

Thanks and apologies: I should have said that I'm asking not for a wiki I’m managing myself, but for the Portuguese-language Wikipedia.

Then you can use the Scribunto extension, because it's already installed on WMF wikis.

Entering a datetime value with timezone "AST" or "ACST" produces an incorrect result.

{{#time:YmdHi|11 March 2018 02:00 AST}} gives 201803102300, while the expected output is 201803110600.

{{#time:YmdHi|7 October 2018 02:00 ACST}} gives 201810070600, while the expected output is 201810061630.

Other timezones, including "ADT" and "ACDT", do work correctly.

Created a ticket at Phabricator for this: https://phabricator.wikimedia.org/T193346

Time zone abbreviations can be ambiguous as there are abbreviations shared by multiple time zones. One solution is to use ISO 8601 notation: +hh:mm or -hh:mm. Another solution is to convert to UTC before entering it.

I'm not sure if this is related to the ParserFunctions plugin, but all research I've exhausted points to this. I'm not sure how to fix this, however. Hopefully someone can help.

Out of nowhere, when a term is searched that has an ampersand (&) or an apostrophe ('), the URL returns the article double-encoded. i.e. a term with an "&" is selected from the search box drop-down and instead of the standard %26, it returns as %2526, thus producing a "Bad title" error. With apostrophes in the term, it transcodes to %2527.

I'm using MediaWiki version 1.31.

Any ideas?

Disable Extension:ParserFunctions. If it still happens without ParserFunctions installed, open a new thread in Project:Support desk

Still happening after disabling the extension. I will open a new thread there - thanks.