Extension talk:ParserFunctions
Contents
![]() First page |
![]() Previous page |
![]() Next page |
![]() Last page |
#switch in MediaWiki:Pagetitle
Once I tried to use #switch in MediaWiki:Pagetitle to make the <title>...</title> different when viewing different pages, like this:
{{#switch:$1
|Some page=Some page - {{SITENAME}}, this should appear differently
|Some other page=Some other page - {{SITENAME}}, the main topic is unrelated to this page
|$1 - {{SITENAME}}}}
However, it still always displays the option for if $1 is not "Some page" or "Some other page". Is there a workaround for that or must this be reported at Bugzilla?
I looked over these pages:
Manual:FAQ#How_can_I_change_what_the_.3Ctitle.3E_of_each_page_is.3F_Where_do_I_make_changes.3F Thread:Project:Support_desk/Is_it_possible_to_change_page_title?
and I think you may need to change your #switch to something like this:
{{#switch: {{FULLPAGENAME}}
|Some page = Some page - {{SITENAME}}, this should appear differently
|Some other page = Some other page - {{SITENAME}}, the main topic is unrelated to this page
|default = $1 - {{SITENAME}}
}}
Your mistake may have been not using Extension talk:ParserFunctions/ switch in MediaWiki:Pagetitle/reply or Thread:Extension talk:ParserFunctions/ switch in MediaWiki:Pagetitle/reply to determine what page you're on. See Help:Magic words for more info about those. However, I'm not 100% sure that will work, since I haven't tried it. That would only work if MediaWiki treats MediaWiki:Pagetitle like a transcluded page, which I suspect it does.
I'm trying to execute the following function on every page that exists for an uploaded file: {{filepath:{{PAGENAME}}.pdf}}
So, if I uploaded a file called "File.pdf", on the wiki page for File.pdf, I'd expect {{PAGENAME}} to return "File". I'd expect the entire function to return something like: http://mywiki.com/mediawiki/images/4/4d/File.pdf
Instead, nothing at all is returned when PAGENAME is embedded within filepath. If I type the expression without {{PAGENAME}}, i.e. {{filepath:File.pdf}}, it works fine and returns: http://mywiki.com/mediawiki/images/4/4d/File.pdf
Is it just not possible to embed magic words in string functions, or am I missing some escape character or something?
Thanks in advance,
-
- UPDATE: This can be done by simply writing {{filepath:{{PAGENAME}}}} the ".pdf" part is unnecessary.
Whenever I get a new version of ParserFunctions, I need to manually add min, max, and sqrt for my site. Can we put them back (I'd be glad to), or was there some good reason for pulling them awhile ago?
What exactly does $wgPFEnableStringFunctions do?
It will enable String Functions parser functions. Those were integrated in r50997. Seems like this isn't documented very well. IMHO these two extensions should still be separated.
I am curious why you think they should be separated? I might agree with you, but I'm not sure.
It just doesn't feel right, ParserFunctions is more for adding some kind of control flow statements whereas StringFunctions is for processing strings. Both are for extending MW markup to some kind of programming language which is ugly but seems like a necessary evil. The more features you add, the more twisted it gets, String Functions is just the start but take a look at Variables or Loops and you get the idea how far this could go. So I'd prefer providing either all of these as package with some clear configuration guide to allow everybody to choose how far he'd like to go there OR to put all of these into single extension packages where you can clearly choose what twisted feature you want and how far to go.
But for this particular example, ParserFunctions joining with StringFunctions, I have another problem. It is a extension employed at Wikimedia foundation wikis such as Wikipedia! Therefore it would be very confusing for users of those wikis to look at Help:Extension:ParserFunctions where they should find information about string functions as well (right now they are not even documented there) whereas they are not even available in those wikis.
It really seems like StringFunctions were just put into ParserFunctions as a cheep attempt to get them into Wikipedia without anybody noticing/complaining. I'd really be happy to see them separated again so maintenance of these two extensions wouldn't be so mixed up and confusing.
I think for maintenance reasons alone it would be a good idea to keep them separated. All the other reasons you mentioned are additional good reasons. Given the pressure to include string functions in Wikipedia, it seems plausible that adding StringFunctions to ParserFunctions was an end-run attempt to get it enabled on Wikipedia, especially now that ParserFunctions and a few other extensions are now bundled with MediaWiki 1.18+. There is a lot of resistance for MediaWiki markup becoming a programming language, but it seems to be happening on its own, and I have been very pleased with the capabilities. Since it has happened naturally, without anyone planning it - and with a lot of resistance - it seems inevitable now that MediaWiki markup is becoming an important scripting/programming language. I know it gets a lot done for me!
Sure, it gets a lot done but it is/was buggy and ugly as hell. If I could travel back in time, I would have put all my programming efforts in further developing Extension:Lua or some alternative as a programming language which can be used within MediaWiki. Now I already depend on these programming extensions too much.
Hi, would it be possible to have a function similar to #ifexist but that also checks that the page is not empty ?
For example, some templates (like fr:Modèle:Wikiprojet for TODO subpages) currently use #ifexist to chech that the page exists before including it and putting decorations around it (rounded frame, explanations, ...). It could be useful to be able to check also that the page is not empty before including it.
This can already be done using the {{PAGESIZE}} magic word. It will give you the page size, and you can use ParserFunctions #ifexpr to set some minimum size threshold before performing some other action. I hope that info helps.
Yes, thanks. I could use {{PAGESIZE}}, but I wanted to avoid using a magic word marked as expensive for a template that is used on many talk pages (probably several 100.000). Would it be a problem?
And a minor disagreement: I would need to repeat the text that is inserted when the subpage is not filled, something like {{#ifexist: {{FULLPAGENAME}}/Subpage | {{#ifexpr: {{PAGESIZE:{{FULLPAGENAME}}/Subpage}} > 0 | {{/Subpage}} | Other text }} | Other text}} Anyway, thanks for the answer.
--NicoV 09:59, 14 January 2012 (UTC)
In portuguese ,and I think also in several other languages, the comma is the decimal separator and the dot is the thousand separator, but in english is the opposite. In templates that use #expr in the portuguese Wikipedia the editors fill the fields using comma as decimal separator and it frequently generate erros. How can we solve this problem? Danilo.mac 02:39, 27 April 2011 (UTC)
I do have the same problem in a German Wiki
Are there ANY issues I should know about when updating from the last Extension:StringFunctions?
I am still using Extension:StringFunctions (version 2.0.3, Nov 30, 2008) and an old version of parser functions from about that time (v1.1.1). So I wonder what has improved in the mean time and will everything still work as expected? Are there any changes from including StringFunctions into Parser functions? Of course I could try, but I have lots of templates and very likely things would look normal for a while until somebody stumbles into some wrong template functionality where nobody knows where it could come from, requiring some ugly bug solving. Would be thankful for any information on that.
Hi,
i work on a Wiki, where i have Articles with name like this: H'nanza or La'Res. I try to get follow things bring to work:
{{#switch: {{PAGENAME}}|H'nanza = Test 1|La'Res = Test 2|}}
but it didn't work. It only works, if the Name where written like this: H´nanza or H`nanza.
But this isn't correct. Have someone a idea why? Or how i can fix it?
{{#switch:{{PAGENAMEE}}|H%27nanza = Test 1|La%27Res = Test 2}}
I am trying to make a template display text if A or B has anything. like instead of:
{{#if:{{{A|}}}|text text text}}
have it do:
{{#if:{{{A|}}} or {{{B|}}}| text text text}}
Is there a way to do this?
There is a bug between the use of ParserClearState hook and transcluding special pages. Whenever transcluding a special page, the hook will be called which leads to resetting those counters in this exytension. Right now we've got to deal with the same thing in Extension talk:VariablesExtension#Variables Become Unset When Transcluding a Special Page. For ParserFunctions this might not be a big thing, but it allows users to bypass rules set by the admin.
In Arabic wiki ,How can i convert English numbers characters to Arabic numbers characters with out having Comma(,) . I want to use these numbers as year but having comma inside year number is not good. formatnum function 2,010/12/05 in Arabic wiki shows numbers in Arabic characters with comma.
I guess you need to be more precise. What's your input?
Warning: Parameter 1 to ExtParserFunctions::ifObj() expected to be a reference, value given in C:\xampp\htdocs\mediawiki\extensions\ParserFunctions\ParserFunctions.php on line 122
I recently migrated a dev wiki from one computer to the next, and any page using Parser Functions gets this error. I cannot find any information about how it is being caused, nor anything about how to fix it. After refreshing the browser cache, the error goes away, but only until I restart my copy of XAMPP. Any suggestions?
It sounds like your new computer is running PHP 5.3.1; it has a bug that causes this error. You should use PHP 5.3.0 or 5.3.2 instead.
This extension should make StringFunctions obsolete but I don't think Sub is working - so I'm still using StringFunctions. Anyone else have this issue (or not have it?!)?
svn: Working copy '/mnt/upload6/private/ExtensionDistributor/mw-snapshot/trunk/extensions/ParserFunctions' locked svn: run 'svn cleanup' to remove locks (type 'svn help cleanup' for details)
I have received this error on three trunk versions now of different extensions, could be a general problem with MediaWiki.
I have the same problem, same error too but with 1.16x version
I'm using wiki2xml to generate some text output and it does not like | statements from an #if if the template parameter has a link in the form of [[link|alt]] Is there a way from the wiki2xml extension to invoke the ParserFunctions parser?
I was looking at the code for #switch, it struck me odd that once a match was found, it continued to try to match subsequent single values. The solution is to replace lines #170 ("} elseif ( count( $parts ) == 1 ) {") with "} elseif ( !$found && count( $parts ) == 1 ) {" and #221 ("} else {") with "} elseif ( !$found ) {".
If #ifexists checks that the page does not exist, the page is shown on Wanted Pages. How do I turn that off? "Programming" with that function is not possible with that behaviour, thanks! :)
Yes, it's a known bug, it's required for caching to work properly, you can't disable it. see bugzilla:12019
In early version 1.1.1 the extension uses strtotime() php function for getting the date. strtotime only works with English date formats and month names. In the current 1.1.1 versions (quiet confusing the versioning of ParserFunctions…) we use the class DateTime at least for php >=5.2. I am not familiar with the DateTime class but I saw on the German Wikipedia (which uses ParserFunctions 1.3.0) that German month names and date formatting is working there with #time. So under which circumstances and since when does #time work with other languages formats? Does it work since some 1.3 version (which revision exactly?) or should it work with one of the 1.1.1 revisions already? In my wiki it won’t work with 1.1.1 and I don’t use the MW 1.16 trunk version yet. I think the versioning is a little bit confusing and the documentation is not very clear about this topic.
Ok, sorry, looks like i was wrong after all. I just tried it again and the German Wikipedias #time wasn't able to interpret german month names. Looks like this still is an open feature. Are there any plans how to implement this? A simple solution which would be helpful could be to replace english month names and their shortcuts against the local languages month names.
Yes. At most Wikipedia versions (for example Swedish) it {{#time: Y-d-m|~~~~~}} results in error, but at enwp it results in 2011-06-10). To make this work would be useful in auto-categorization of templates based on date. One approach would be to alow an input date format/locale parameter, for example {{#time: Y-d-m|sv|6 oktober 2011 kl. 08.59 (CEST)) }} for swedish date format. Today this results in Error: Invalid time.. The locale parameter should defualt be sv at Swedish Wikipedia, etc.
when i enable this extension, going to Special:Specialpages generates an error at the top of the page:
Warning: Invalid argument supplied for foreach() in path/to/wiki/includes/MessageCache.php on line 636.
disabling the extension makes the error go away. currently i cannot find another page that generates this error.
![]() First page |
![]() Previous page |
![]() Next page |
![]() Last page |



