Version 1.1

I just added the #nickname function, and updated the version to 1.1 . This was tested with the "post wiki-1.8" version only, but I believe the "pre 1.8" version will be all right too. Lexw 13:19, 27 June 2008 (UTC) 19:58, 28 September 2011 (UTC)

Version 1.2

... and I added the #ifingroup function, and updated the version to 1.2 . Louperivois 16:29, 25 July 2008 (UTC) 19:59, 28 September 2011 (UTC)

Request

Hi, I would like to add a method that use getId() to get the user ID (the integer one), this way references survive user name changes. How do I contribute code here? By just editing the page, or what? //Nicklas 20:00, 28 September 2011 (UTC)

Yeah, since this extension is not in SVN you may just edit the page. Cheers [[kgh]] 20:01, 28 September 2011 (UTC)

More secure version suggestion

The page says that this extension has a major security risk because these functions can be used to superficially hide information from sysops and can expose e-mail address.

I have some suggestions to enhances this extension and make it safe:

• Limit its functionnality to some namespace where only sysops can modify pages (MediaWiki:) to define message.
• Add the possibility to select only some functionnality of this extension and disable the other (like #useremail).

It would be great to enable this extension on Wikimedia sites, in particular for the #username, otherwise the {{gender:}} tag is quite useless. DavidL 12:46, 30 September 2011 (UTC)

Hi, after some comments from Platonides here: Special:Code/MediaWiki/106597, I rechecked this page and I've seen your comments. I'm going to add these possibilities. Would you and other users suggest some defaults for each of these two points? Toniher 00:15, 21 December 2011 (UTC)

Perhaps a setting like $wgUFDisclosePrivateInformation might be a good idea to control if #realname, #useremail should be enabled or not. Something like $wgUFDiscloseRealName or $wgUFDiscloseUserName would allow a more fine grained control, but I do not think that is necessary. To remove these functions is not a good idea since there are valid usecases around for wikis. Cheers [[kgh]] 20:38, 23 December 2011 (UTC)

I just saw that you already introduced this improvement three days ago. Shame on me. Cool and thank you. [[kgh]] 16:53, 24 December 2011 (UTC)

Hey, no problem. I've just also added also the NS allowance/blocking suggestion from DavidL. Happy New Year to all! Toniher 11:27, 3 January 2012 (UTC)

#ip:

Hi, this parser function is a bit redundant in this extension. Still I believe it should be there. Cheers [[kgh]] 12:56, 30 October 2011 (UTC)

Rewriting of the extension

Following the model of ParserFunctions, but mainly for making it compatible with extensions such as Variables, I have rewritten the extension.

Code is here.

I would update extension page unless anyone finds any objection. Toniher 23:12, 12 December 2011 (UTC)

Heiya Toniher, that's cool. No objections from my side. You also added I18N, which was missing too. Is it supposed to stay at gitorious or do you also have plans for moving it to SVN to allow translations via translatewiki.net. Cheers [[kgh]] 23:17, 12 December 2011 (UTC)

Hi! If possible, I think it would be better to submit it to MediaWiki SVN. I will follow the procedure to do this. Thanks! Toniher 09:50, 13 December 2011 (UTC)

That's great. I guess it will not only be useful for you with regard to this extension to have access to SVN. Cheers [[kgh]] 10:12, 13 December 2011 (UTC)

Done: http://svn.wikimedia.org/svnroot/mediawiki/trunk/extensions/UserFunctions/

In a couple of days I would change the extension page. Toniher 23:35, 18 December 2011 (UTC)

Cool, the first five translations are already there too. :) At $wgExtensionCredits you may change 'al.' to '...' Since MW 1.18 this gets automatically transformed in the wiki language for, e.g. 'others', 'andere' etc. I have already done the first update of the page to save you some time. You may now add notes for the new magic you added to the extension as soon as you have time to do so. Cheers [[kgh]] 22:03, 19 December 2011 (UTC)

Thanks kgh! I changed credits as well. Toniher 07:39, 20 December 2011 (UTC)

Issue with MW 1.18.0

Heiya Toniher, I just upgraded my wiki to MW 1.18.0 and UF 2.0 and found out that the functions do not work in the sidebar (MediaWiki:Sidebar) on Monobook skin. It just displays everything in the sidebar. This is sad. :( What kind of behaviour do you experience on your wiki? I ruled out sidebar caches on my wiki. Cheers [[kgh]] 23:23, 19 December 2011 (UTC)

uh. It works in MediaWiki Sidebar in a 1.17 installation. Let me see if I can check it in a 1.18 :O Toniher 15:22, 20 December 2011 (UTC)

1.17 is ok, but 1.18 ... *fear* On regular wiki pages there is no problem at all. [[kgh]] 15:25, 20 December 2011 (UTC)

No parser function seems to work there.

ifexpr, ifeq, etc. are ignored inside MediaWiki:Sidebar as well. I would research for any comment anywhere. If I don't find anything, I would fill a bug in case it's not intentional. Toniher 14:33, 22 December 2011 (UTC)

Filled bug here: https://bugzilla.wikimedia.org/show_bug.cgi?id=33321

If it is not / cannot be solved, I would check whether this alternative works in 1.18:

Extension:CustomNavBlocks Toniher 15:37, 22 December 2011 (UTC)

Hi Toniher, thank you for checking this and filing a bug. Let's hope for the best. Perhaps CustomNavBlocks is an alternative. First I will wait and see how this bug develops since I prefer UserFunctions. Cheers and thank you again. [[kgh]] 19:00, 23 December 2011 (UTC)

$wgUFEnablePersonalDataFunctions = true; not working

Heiya Toniher, I just deployed UF 2.2 together with MW 1.17.2 and realised that enabeling PersonalDataFunctions does not work at all. May you please check if there is an issue. UF 1.5 is working as expected. Thank you and cheers [[kgh]] 19:38, 12 January 2012 (UTC)

Hi! Maybe the problem is 'Allowed Namespaces' ? Maybe that should be more clear :/

Is it only PersonalDataFunctions or any other function? I've tried in a MW 1.17.2 installation today and no problem. Let me know! Toniher 22:47, 13 January 2012 (UTC)

Heiya, no it cannot be an allowed namespace issue. I set

$wgUFAllowedNamespaces = array(
        NS_MAIN => true,
        NS_TEMPLATE => true,
        NS_USER => true
);

in LocalSettings.php, so it should at least work in these namespaces. However, it does not. That's why I thought it must be $wgUFEnablePersonalDataFunctions. The other parser functions in NS_MAIN are working. I guess I will have to add NS_MEDIAWIKI since this array will override the standart setting. I will do another test tomorrow. Cheers [[kgh]] 23:30, 13 January 2012 (UTC)

Heiya,

now I tried with MW 1.18.1 and this setting in LocalSettings.php

require( "extensions/UserFunctions/UserFunctions.php" );
$wgUFEnablePersonalDataFunctions = true;
$wgUFAllowedNamespaces[NS_MAIN] = true;

Sadly I cannot get it to work. All functions from this exetension are broken. I wonder what I am doing wrong. :( [[kgh]] 16:21, 15 January 2012 (UTC)

With 1.18.1 I get it work, for instance for NS_MEDIAWIKI and NS_MAIN.

I use this:

require_once( "$IP/extensions/UserFunctions/UserFunctions.php" );
$wgUFEnablePersonalDataFunctions = true;
/** Restrict to certain namespaces **/
$wgUFAllowedNamespaces[NS_MAIN] = true;

I will try 1.17.2 now. Toniher 16:46, 15 January 2012 (UTC)

A typo, I meant MW 1.18.1! The only difference is the way of the extension's inclusion. I tested your proposal before and just tried again now. However, the result is the same. :( Hmm ... It must be something tiny, but I cannot think of what this may be. [[kgh]] 16:51, 15 January 2012 (UTC)

One thing that just came to my mind. My server is running PHP 5.3 I the past I learned that quite a few extensions have trouble with it. Thus I just tested it on a server running PHP 5.2 et voila: it is working. There must be something in the code which is not liked by PHP 5.3. [[kgh]] 17:24, 15 January 2012 (UTC)

Hi, I can make it work in 1.17.2 as well. PHP version I'm using is: PHP Version 5.3.6-13ubuntu3.3

Maybe a specific php.ini or PHP minor version problem? It would be nice if more people could report... Toniher 18:25, 15 January 2012 (UTC)

Hi I use 5.3.8 (apache). I suspect some ini-problem too. I will try to investigate. Cheers [[kgh]] 20:32, 16 January 2012 (UTC)

I hacked UserFunctions 2.2 to get it to work on our MediaWiki 1.18.1. In UserFunctions.php, line 80

if (class_exists("RequestContext")) {</pre>
returns "true" but line 81 after it
<pre>$cur_ns = RequestContext::getMain()->getTitle()->getNamespace();

always sets $cur_ns to "0". Since my MW installation is on an internal Corporate network, and I'm not worried about NameSpace restrictions, I've just set line 87 to "true"

$process = true;

I wish I knew PHP better to get it working right, but at least now it works (abet with no restrictions). Ckong3309 (talk) 17:51, 2 March 2012 (UTC)

How to tune which namespaces are allowed is explained here: http://www.mediawiki.org/wiki/Extension:UserFunctions#Allowing_namespaces

By default, because of the concerns raised in this talk page comments, it's rather restrictive. Toniher (talk) 08:43, 22 March 2012 (UTC)

Heiya Toni,

after upgrade from 1.17.5 to 1.18.4 and to UF 2.4 I can confirm that this problem does not longer occur for all namespaces except for NS_SPECIAL.

$wgUFAllowedNamespaces = array_fill(-1, 200, true); does not work. Additionally I tested just $wgUFAllowedNamespaces[NS_SPECIAL] = true; but failed too. I am really puzzled by this behaviour. O_o

Cheers

Addendum: Please disregard this message since I have new insights. Cheers --[[kgh]] (talk) 17:11, 23 June 2012 (UTC)

Heiya Toni,

I did some further testing. I now believe that the reason for $wgUFEnablePersonalDataFunctions = true; not working must have lain somewhere within MW 1.17.x. I just deployed UF 2.2 to the wiki again and found everything working perfectly. :)

I guess this case may be closed.

Cheers [[kgh]] (talk) 17:11, 23 June 2012 (UTC)

Call to a member function getNamespace() on a non-object in extensions/UserFunctions/UserFunctions.php on line 82

Jlerner 17:12, 20 January 2012 (UTC)

UserFunctions breaks maintenance/importImages.php

The UserFunctions extension breaks the importImages.php maintenance script:

Importing ******.mp3...
Fatal error: Call to a member function getNamespace() on a non-object in /var/******/extensions/UserFunctions/UserFunctions.php on line 84

I thus temporarily added if( is_object( $wgTitle ) ) to get it back to a working state. Clausekwis (talk) 14:06, 15 April 2012 (UTC)

Hi, in which MW version did it happen? Toniher (talk) 15:36, 19 April 2012 (UTC)

Hi, I encountered the same error using http://www.mediawiki.org/wiki/Extension:Data_Import_Extension with MW 1.17.0 and SemanticMediaWiki 1.6.1. I enabled all namespaces including -1 for UserFunctions with no success. Any help is very appreciated.

Best

Karsten Kaboomki (talk) 13:47, 26 April 2012 (UTC)

I'm going to provide a fixed version in Git as soon as I can.

This is the change I tried myself in UserFunctions.php:

        function registerParser( &$parser ) {
                global $wgUFEnablePersonalDataFunctions, $wgUFAllowedNamespaces;
                // Whether it's a Special Page or a Maintenance Script
                $special = false;
                // Depending on MW version
                if (class_exists("RequestContext")) {           
                        $pagetitle = RequestContext::getMain()->getTitle();
                        if (method_exists($pagetitle, 'getNamespace' )) {
                                $cur_ns = $pagetitle->getNamespace();
                                if ($cur_ns == -1) {
                                        $special = true;                
                                }
                        }
                        else {
                                $special = true;
                        }
                } else {
                        global $wgTitle;
                        if (method_exists($wgTitle, 'getNamespace' )) {
                                $cur_ns = $wgTitle->getNamespace();
                                if ($cur_ns == -1) {
                                        $special = true;
                                }
                        }
                        else {
                                $special = true;
                        }
                }
                $process = false;
                // As far it's not special case, check if current page NS is in the allowed list 
                if (!$special) {
                        if (isset($wgUFAllowedNamespaces[$cur_ns])) {
                                if ($wgUFAllowedNamespaces[$cur_ns]) {
                                        $process = true;
                                } 
                        }
                }
...

Toniher (talk) 09:23, 3 May 2012 (UTC)

Hi, I uploaded changes. You can get new version from Git master download link (extension info box). Toniher (talk) 17:39, 27 May 2012 (UTC)

UserFunctions in namespace Special (-1)

Heiya Toni,

I just tested UF 2.3 and UF 2.4 on MW 1.18.4 and realised that the extension stopped working for namespace -1. Whereas $wgUFAllowedNamespaces = array_fill(-1, 200, true); works fine for UF 2.2 it stops working for UF 2.3+. For testing purposes I just added $wgUFAllowedNamespaces[NS_SPECIAL] = true; but failed. Thus some problem was introduced with the UF 2.3 release.

Cheers [[kgh]] (talk) 17:18, 23 June 2012 (UTC)

Hi, just for checking, from which page are you experiencing the problem? Toniher (talk) 09:16, 26 June 2012 (UTC)

Heiya, it is happening on all special pages without exception, at least I have not found one so far which was working, e.g. Special:SpecialPages etc. Thus MediaWiki:Sidebar is returning scrambled wikitext. Cheers [[kgh]] (talk) 09:20, 26 June 2012 (UTC)

Ok, I'm also experiencing the problem. That is happening when showing special pages when UserFunctions is used in MediaWiki Sidebar. But it's not happening when it's being used in other places where a NS -1 is returned, such as a Semantic Form. I'll try to find what's going on! Thanks! Toniher (talk) 14:13, 26 June 2012 (UTC)

Yes, I should have been more precise at the beginning. Special pages as such, e.g. for SF, are not a problem here either. It is "just" the Sidebar. Thank you for having a look at this. Cheers [[kgh]] (talk) 14:18, 26 June 2012 (UTC)

Hi,

For now, you can replace the following in UserFunctions.php.

I should test more how affect different cases:

        else {
                if ($wgUFEnableSpecialContexts) {
                        if ($special) {
                                $process = true;
                        }
                }
        }

Toniher (talk) 07:46, 3 July 2012 (UTC)

Just to make sure for other interested users. I replaced this

	else {
		if ($wgUFEnableSpecialContexts) {
			
			$pagetitle = "";
			if (class_exists("RequestContext")) {
				$pagetitle = RequestContext::getMain()->getTitle();
			}
			else {
				global $wgTitle;
				$pagetitle = $wgTitle;				 
			}
			// Case when creating forms. Others?
			if ($pagetitle->mTextform) {
				if (preg_match("/^FormEdit/", $pagetitle->mTextform)) {
					$process = true;
				}
			}
		}
	}

by the code you provided in your post. So far I was not able to detect any problems. Seems to be fine to me.

Cheers and thank you for looking into this. [[kgh]] (talk) 23:33, 9 July 2012 (UTC)

Committed. Sorry for taking so long. So far I haven't found any problem myself.

Please, report if you find any problem. Toniher (talk) 21:11, 17 July 2012 (UTC)

One step at a time. Thank you for doing this. :) I tested with a locally patched version and did not experience any problems so far either. Cheers [[kgh]] (talk) 21:12, 17 July 2012 (UTC)

MediaWiki 1.19 & {{#ifingroup}}

Hi Toni, I just upgraded my wiki from 1.16 to 1.19.1, use UserFuntions 2.2, and now the {{#ifingroup}} is displayed only, but not executed. The extension is included via,

 include_once("$IP/extensions/UserFunctions/UserFunctions.php");
               $wgUFEnablePersonalDataFunctions = false; # true does not alter behaviour

Sample template to display an arrow if the content is transcluded from a different page:

{{#ifingroup:sysop
  |{{#ifeq:{{{1}}}|{{FULLPAGENAME}}
    |
    |<div style="float:right; clear:right; margin:0 0 0 .5em;">[[file:bullet_go.png|{{{1}}}|link={{{1}}}]]</div>
  }}
}}

displays{{#ifingroup:sysop|}} and the arrow regardless of the user's sysop status.

Do you have a hint for me? Surak ^Talk 14:46, 18 July 2012 (UTC)

Hi Surak, apart from trying last version, 2.4.1 (which should work well in 1.19.1), I would try to substitute '|' either by ! Template or by using Extension:PipeEscape. Cheers! Toniher (talk) 20:36, 18 July 2012 (UTC)

Stopped working on MW 19.2 ?

Hello, great extension, I used it a lot on earlier wiki projects. However, I didn't get the parser function running on MW 19.2. UserFunctions (Version 2.4.1) shows up in Special:Version. I enabled all namespaces just as said in the documentation but it still shows the entire string {{#ifanon:unregistered|registered}}. Whats wrong? Thanks!! Kaboomki (talk) Kaboomki (talk) 09:45, 6 November 2012 (UTC)

I can confirm this behaviour. I just upgraded from 1.18.5 to 1.19.2. I just works on special pages, but not on regular pages. Cheers [[kgh]] (talk) 22:20, 11 November 2012 (UTC)

Hi,

I have just tried in MW 1.19.3 and it seems to work in NS_MAIN.

However, you need to define it explicitly. Look at examples.

# Enable UserFunctions in Main Namespace
$wgUFAllowedNamespaces[NS_MAIN] = true;

Let me know if any problem. Toniher (talk) 14:25, 14 December 2012 (UTC)

I must apologise, but I thought that I have already replied. :( Yeah, I forgot to set the namespaces, so there is no problem after all. :) [[kgh]] (talk) 19:18, 31 January 2013 (UTC)

Stopped working with MW 1.20.x

Hi.

I've just upgraded a MW 1.19.3 instance to 1.20.2 and all my #ifsysop and #ifingroup functions have stopped working. They just display {{#ifsysop: instead of being parsed. All works fine with 1.19.3. I have $wgUFAllowedNamespaces[NS_MAIN] = true;

I guess, once again, MW has changed something vital between 1.19.3 and 1.20.2 that has broken this.

Any ideas? Thanks Mitchelln (talk) 13:50, 12 February 2013 (UTC)

I can confirm this on MW 1.20.

Funnily adding $wgUFAllowedNamespaces[NS_MAIN] = true; fixed the issue for the #ifsysop command - but not for the #username command. Achimbode (talk) 17:02, 15 February 2013 (UTC)

Please make sure you didn't forget to put "$wgUFEnablePersonalDataFunctions = true;" in your LocalSettings.php... ;-) Simon Fecke (talk) 13:51, 20 February 2013 (UTC)

Hi.

I thought "$wgUFEnablePersonalDataFunctions = true;" was only needed if you want to use #realname, #username, #useremail, #nickname, #ip?

I'm finding the basic #ifsysop and #ifingroup are not working with MW 1.20.2.

Thanks. Mitchelln (talk) 11:00, 27 February 2013 (UTC)

I cannot replicate it. Maybe you run a maintenance script? I will commit one patch soon to have higher control on this kind of issues. Toniher (talk) 17:57, 13 March 2013 (UTC)

I just realise that it is not working on an 1.20.6 install as Mitchelln reported. These parameters are set:

$wgUFEnablePersonalDataFunctions = true;
$wgUFAllowedNamespaces = array_fill( 0, 200, true );

Which maintenance script do I have to run to fix this issue? [[kgh]] (talk) 22:42, 19 July 2013 (UTC)

Disregard my previous post. Well I touched LocalSetting.php which somehow caused all links to show. For some reason $wgEnableSidebarCache = true; was set. Thus there was no immediate chance to get it working. Stupid me. O_o I makes sense that this setting does not mix with this extension. Everything is ok now. :) [[kgh]] (talk) 22:57, 19 July 2013 (UTC)

UserFunctions.php:88 is broken by e0c40e55

Commit e0c40e55 introduced these lines to UserFunctions.php: <pre>// As far it's not special case, check if current page NS is in the allowed list process = (!$special && isset($wgUFAllowedNamespaces[$cur_ns]) && wgUFAllowedNamespaces[$cur_ns]) || ($wgUFEnableSpecialContexts && $special)) {

if ($process) {</pre>

The last three characters ") {" of the middle line are a syntax error and can't possibly be correct. Should that line simply end with a semicolon? Uckelman (talk) 19:37, 4 April 2013 (UTC)

I've recovered previous edition of the file. It still needs some cleaning and handling cases such as maintenance scripts more comfortably, but at least is not broken. Thanks for warning, now I'm watching the repository. Toniher (talk) 17:37, 8 April 2013 (UTC)

Mediawiki 1.19

Hi,

I have problem with draw graphs statistics for my users, arcticles etc. I tryint to do it this way http://www.mediawiki.org/wiki/Extension:Usage_Statistics . But when i press the button "Generate Statistics" nothing happens. Below I add my logs from apache.

[12/Aug/2013:17:59:45 +0000] "POST /index.php/Specjalna:SpecialUserStats HTTP/1.1" 200 21276 "http://mypage/index.php/Specjalna:SpecialUserStats" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.22 (KHTML, like Gecko) Ubuntu Chromium/25.0.1364.160 Chrome/25.0.1364.160 Safari/537.22" 83.175.144.6 18:02, 12 August 2013 (UTC)

You probably might want to ask on the talk page of the "Usage Statistics" extension. This is the talk page of a different extension called UserFunctions. [[kgh]] (talk) 06:21, 13 August 2013 (UTC)

Redirecting

For some reason I cannot redirect pages, using the following: {{#ifanon:#REDIRECT [[Page]]}}

Any ideas? Am I doing something wrong or is this not possible? 194.150.65.241 11:04, 24 December 2013 (UTC)

Call to a member function getNamespace() on a non-object in UserFunctions.php:69

I'm seeing this error with MW 1.21 and UserFunctions 2.4.2:

PHP Fatal error: Call to a member function getNamespace() on a non-object in /usr/share/mediawiki/extensions/UserFunctions/UserFunctions.php on line 69

It looks like what's failing is this:

$cur_ns = RequestContext::getMain()->getTitle()->getNamespace();

Apparently getTitle() is not returning an object. Uckelman (talk) 23:17, 20 February 2014 (UTC)

Here's a patch which fixes the bug.

--- a/mediawiki/extensions/UserFunctions/UserFunctions.php
+++ b/mediawiki/extensions/UserFunctions/UserFunctions.php
@@ -66,7 +66,8 @@ function wfRegisterUserFunctions( $parser ) {
        $special = false;
 
        // Initialize NS
-       $cur_ns = RequestContext::getMain()->getTitle()->getNamespace();
+       $title = RequestContext::getMain()->getTitle();
+       $cur_ns = $title === null ? -1 : $title->getNamespace();
        if ( $cur_ns == -1 ) {
                $special = true;
        }

Uckelman (talk) 23:03, 26 February 2014 (UTC)

This post is Old but al try to assist you guys experiencing this error. What happens is that when the response from the SoapCall is returned it fails to get captured with the simplexml_load_string so a workaround to assist you those facing this problem. First capture the response in an xml $request = file_put_contents('response.xml',$data);

Then load the xml captured using simplexml_load_file the trick is ordinary xml will get captured but an xml response with namespaces has to be treated differently this is how i managed to sort out the issue in php 41.81.70.95 (talk) 18:45, 5 May 2017 (UTC)

{{#ifanon:then|else}}

Hello Everybody,

i am trying to block the sidebar for anonymous users by using the {{#ifanon:then|else}} . The only problem i have is, i can not figure out what to put in "then|else". Could someone give me a hint?

Thank you in advance.

kind regards, 78.52.199.30 07:40, 4 August 2014 (UTC)

Heiya, that's how I do it on "MediaWiki:Sidebar", e.g.

**{{#ifanon:Special:UserLogin{{!}}Log in|}}

So I am using the "!" template to do a pipe trick. Starting with MW 1.24 you will not need the template since {{!}} will be available as a magic word. On regular pages the pipe trick is not necessary so a {{#ifanon:Special:UserLogin|Log in}} should make you happy.

Cheers [[kgh]] (talk) 12:36, 4 August 2014 (UTC)

thanks for you quick response. I have tried both versions on my mediawiki:sidebar with no luck. If i am not logged in it will still display me the sidebar. I am using mediawiki 1.23. Any hints?

• • {{#ifanon:Special:UserLogin|Log in|}}
  • {{#ifanon:Special:UserLogin|Log in}}

Thanks in advance. 92.225.81.176 08:09, 5 August 2014 (UTC)

In your sidebar only version one should work. I have just tried it on a 1.23.2 test wiki using UF 2.5 and found this working perfectly. One possible cause: You are using the sidebar cache. Make sure that the parameter $wgEnableSidebarCache is set to "false". [[kgh]] (talk) 08:21, 6 August 2014 (UTC)

#ifsysop not working in Sidebar level 1

The #ifsysop parser function is not rendered in my setup for Sidebar level 1 menu.

• MW 1.23.x
• Vector or Chameleon Skin
• latest UserFunctions

Sidebar code:

* {{#ifsysop:Admin{{!}}Admin|}}
** {{#ifsysop:Spezial:Letzte_Änderungen{{!}}Letzte Änderungen|}}
** {{#ifsysop:Spezial:Neue_Dateien{{!}}Liste der Dateien|}}

'Letzte Änderungen' as well as 'Liste der Dateien' works as expected. But for the level 1 menu entry, I get <{{#ifsysop:Admin|Admin|}}< output (unparsed). Planetenxin (talk) 16:02, 21 December 2014 (UTC)

Yeah, I think this started with MW 1.18 and for all skins. I think for some reason the sidebar mechanism did not permit to make it work for the headers back then. Perhaps the situation is different now. It will indeed be great to be able to hide the headers too. [[kgh]] (talk) 12:54, 6 January 2015 (UTC)

tags missing for packagist to work

I think that this extension needs to be tagged for the versions to show up on packagist. So far one can only do dev or REL1_24 [[kgh]] (talk) 18:40, 17 February 2015 (UTC)

@Toniher Ping. :) Tagging is an integral mechanism of version management with Composer. So doing so will be greatly apprechiated. :) [[kgh]] (talk) 17:21, 22 May 2015 (UTC)

refreshLinks/htlmCacheUpdate jobs

I have noticed that whenever a page that uses the #ifanon or #ifingroup parser functions (and probably others that we do not use) is visited, a refreshLinks job and an htmlCacheUpdate job are added to the job queue. The job queue is quickly growing as the wiki is visited, even without any edits taking place. I have traced the jobs to the fact that both functions begin with:

$parser->disableCache();

If I comment that line out, the jobs are not added to the queue, and everything behaves as expected. Different logged in users and anonymous users see the expected content, filtered by whether they are logged in or belong to the appropriate group. Cached content does not appear to be being served inappropriately. The problem of the job queue growing is a considerable one. Is disabling the cache truly necessary in these functions? Is there another workaround for this problem? Cindy.cicalese (talk) 21:01, 23 September 2015 (UTC)

Cindy.cicalese (talk) 21:06, 23 September 2015 (UTC)

Hi Cindy, not fully sure myself :/. It would be worth to test it in different MW >=1.23 instances. I'm wary of any effect in some wikis if enabling caching by default. This extension maybe has already too many parameters, but a conservative solution may be to provide a parameter for disabling/enabling cache at least for some versions until we may finally disable it because we're fully sure of no consequences. What do you think? Toniher (talk) 08:35, 27 September 2015 (UTC)

Adding a parameter sounds like a good compromise, as you say at least until we are sure that there are no consequences. By default, the behavior could stay as it is now. In our case, the functions are used to show additional information to advanced users, but there are no security implications. So, even if a cached page with additional information were served (which I am not seeing happen in testing), the results would not be a security compromise. Cindy.cicalese (talk) 15:25, 28 September 2015 (UTC)

I just tried with a 1.23 installation, and disable cache seems fully necessary. Last edited / cached version is shown otherwise regardless of current visiting user. I'll check with 1.25 anyway. Toniher (talk) 11:43, 3 October 2015 (UTC)

Same situation with 1.25.2. I just tried

{{#ifingroup:sysop|Sys}}

and visited with sysop and anonymous user.

If no other workaround or idea, I would not make any change. We can add a warning in extension page, though. That is, something such as: if any of this parser functions is included in templates transcluded in many pages, job queue can highly increase. Toniher (talk) 19:56, 3 October 2015 (UTC)

Interesting. I would have expected to see that behavior, but I am not seeing cached pages on our installation. We are using squid. Thank you for testing. I agree that, given that you are seeing cached pages when you do not disable caching, it should be left as is for the time being. We don't see those jobs being added for other extensions that (I believe) disable caching, so I will investigate further. A warning would be helpful. Thank you! Cindy.cicalese (talk) 13:09, 5 October 2015 (UTC)

Is it possible to use not in group?

I would like to hide the edit tab if a user is not in a group 148.177.65.215 (talk) 11:10, 9 November 2016 (UTC)

User Functions stops Auto Create Category Pages

Hello,

For unknown reason, while I'm using User Functions on my MediaWiki (checked on 1.28.2 and 1.31.0) the Auto Create Category Pages extension don't work. It seems to happen in every configuration I'm trying to do for the User Functions extension.

The problem happens not only on pages who has {{#ifsysop:}} (the only command I need from the extension), but all over the mediawiki, even when User Functions Allowed only on MediaWiki namespace.

I've tried to figure it out but it is simply way over my abilities..

Does anyone met this problem before? 213.57.135.184 (talk) 07:20, 27 August 2018 (UTC)

I'm the maintainer of AutoCreateCategoryPages; I just installed UserFunctions on my wiki and AutoCreateCategoryPages still worked fine for me. Can you tell me the following to help me test?

1. MediaWiki version
2. AutoCreateCategoryPages version/branch
3. UserFunctions version/branch
4. Do you see a specific error message, or are category pages just not created?
5. If you disable UserFunctions, does AutoCreateCategoryPages immediately work?

Thanks! FFS ^Talk 13:16, 28 August 2018 (UTC)

Hi, Thanks a lot for the fast responsive..

I've tested the situation on two different systems, because I'm planning to move my mediawiki as soon as this problem will be solved. Therefor, I'll have 2 answers for your questions :)

My MediaWiki version is 1.28.2 (tested also on 1.31.0 which I'm planning to be moved for)

AutoCreateCategoryPages version is 1.0.1 (tested also on 1.0.3)

UserFunction version is 2.7.0

I don't get any massage, and I've noticed that the whole functions of category doesn't work. What I mean is that once UserFunction is installed, as well as the AutoCreateCategoryPages which don't create pages, also other functions as adding a page into existing category doesn't work... Once I remove the UserFunctions from LocalSettings the MediaWiki starts doing the magic...

Thanks Again 213.57.135.184 (talk) 19:22, 31 August 2018 (UTC)

So far I could find nothing new. In all my testing both extensions worked. Do you have any new information?

As an aside, please make sure to use v1.0.3 - it queries the DB much more efficiently than v1.0.1. FFS ^Talk 21:17, 17 September 2018 (UTC)

By the time, seems the problem has solved, somehow. Thanks A-lot! 5.28.166.54 (talk) 19:02, 18 September 2018 (UTC)

Glad to hear it! Let's hope for no repeats :-) FFS ^Talk 14:26, 20 September 2018 (UTC)

Suggesting new feature

Hi Guys, We, at Dokit, need to create a parsing function to check if the logged-in user has/hasn't a specific permission. So we suggest to develop a new feature in your UserFunctions extension to do that. Something like :

{{#ifhaspermission:edit|then|else}}

What do you think? We can develop it and ask for a merge request if you like the idea. Best, Clément ClemFlip (talk) 15:21, 2 October 2018 (UTC)

I think you will be better off using the RightFunctions extension. When using Semantic MediaWiki 3.0.0 and later you will be able to check for the rights with the Semantic Extra Special Properties extension 2.0.0 and later. [[kgh]] (talk) 15:57, 2 October 2018 (UTC)

Upgrading to MW 1.31.7

This extension used to work nicely with my MW 1.27.3 - after upgrading to 1.31.7 the realname Parser function hook seems to not be activated any more. What can i do about this? Seppl2013 (talk) 13:02, 23 May 2020 (UTC)

Upgrading to MW 1.35

When I upgrade to MW 1.35 get error on Parser::disableCache. Looking on forum and found https://www.mediawiki.org/wiki/Extension%20talk%3APDFEmbed#h-Use_of_%22Parser%3A%3AdisableCache%22_was_deprecated_in_MediaWiki_1.28.-2020-03-25T13%3A07%3A00.000Z

So i repleced '$parser->disableCache();' to '$parser->getOutput()->updateCacheExpiry(0);' in UserFunctions_body.php and it works. Adrianzlobinski (talk) 06:47, 17 November 2020 (UTC)

Some troubles on some namespaces

Hi, In a local wiki (witch will be moved on the web later) I've found a way to display in infoboxes shortway links to technical pages according to the current namespace (e.g. special:All Categories|Templates|Properties...). Very handful ! those links are in a template in a #ifsysop condition. It works well in several namespaces : main, template, category, help (ns: 12)... and not in some : Property (from Semantic Mediawiki, ns: 102), Reference (ns: 3010) in spite of configuration at the end of LocalSetting.php like :

$wgUFAllowedNamespaces[SMW_NS_PROPERTY] = true; // ns: 102 or : $wgUFAllowedNamespaces[102 ] = true; // ns: 102 SMW_NS_PROPERTY

(the namespace numbers are checked with the special:AllPages : when choosing a namespace, the corresponding number is shown in the url) In those case, the "{{#ifsysop:" ... "|}}" code is displayed as not interpreted by the parser.

Anny hint ? How to enable UserFunctions in extention and custom namespaces ?

Thanks

mw: 1.36.1 php: 7.4.22 smw: 3.2.3 userfunction: 2.8.0 FrViPofm (talk) 13:46, 22 August 2021 (UTC)

It seems that $wgUFAllowedNamespaces is overwritten in MediaWiki due to the usage of array_merge and it's "Values in the input arrays with numeric keys will be renumbered with incrementing keys starting from zero in the result array". 83.255.155.133 (talk) 12:48, 15 November 2021 (UTC)

Composer test fails

How to show ifingroup in VisualEditor?

We use ifingroup for several reasons. One is to not show content to visitors as long as an article is in draft mode. However in the VisualEditor all ifingroup statements show up as a puzzle icon. See https://pasteboard.co/I4ckujT4MShA.png for a screenshot.

Is there any way to show the content of ifingroup in the VisualEditor so that it can be edited? At least to the corresponding user group?

To edit the content in the (very small) puzzle pop up is not an option for us. Stefahn (talk) 18:30, 26 April 2022 (UTC)

MagicWord.php: Error: invalid magic word 'ifanon'

Adding a #displaydate function?

It would be great to have a parser function that takes in a date string - or a date/time - and then displays it based on the user's preferences: "1 January 2023", "January 1, 2023", etc. (If a time is included, there are even more options.) There are various ways to implement such a thing (maybe it should even be two parser functions), but before we get to any of the specifics: is that something that it would make sense to add to UserFunctions? Yaron Koren (talk) 13:27, 5 April 2023 (UTC)

composer/installers 2.2.* support

This is a duplicate of htt ps://phabricator. wikimedia.org/T343009 since it turned out that phabricator is the wrong place for this. I have to cripple the links with spaces, because I may not send them here.

Hello!

I tried to install many extensions with composer, but a few times I ran into a few issues, this one is about the requirement of composer v1.

Many other extensions depend on composer v2, so installing them together is not possible.

This can be changed like in this commit in a fork of mine: htt ps://github .com/markus-96/mediawiki-extensions-UserFunctions/commit/06fec0c8fb3e27650c10731b00efe8f321791d82

Or like this: htt ps://gerrit.wikimedia. org/r/c/mediawiki/extensions/PageForms/+/942478/

That resolves the same issue in the PageForms extension: htt ps://phabricator. wikimedia.org/T340818 MarB-96 (talk) 11:14, 21 September 2023 (UTC)

ifsysop and ifingroup broken on avid.wiki

These two tags appear to have just stopped working completely on avid.wiki for some reason. The extension is enabled, but the parser tag just doesn't work for some reason. We raised the issue with WikiForge sysadmins, in case it was something on their end, they said thay'd try updating the extension, but suggested it was more likely an issue with the extension itself. We'd apprectate having the tags fixed because we make extensive use of them on our DPLForum templates. Example page (This was a test from when I built the forum, but it demonstrates the issue clearly.):

https://www.avid.wiki/User:Hb1290/sandbox/test Hb1290 (talk) 11:35, 4 October 2023 (UTC)

Extension was working but has stopped

Sometime in the last month or so, this extension seems to have stopped working. I set up a few pages with the ifsysop tag and tested them successfully. However, I didn't return to the pages for a week or so, and when I came back, I can't get any of the tags to work. I've tried ifingroup, ifsysops, and ifanon, but they all just display on the page as plain text. I've even tried escaping the pipe symbols, thinking that might have something to do with it, but that didn't help. It sounds very similar to the problem that Hb1290 posted about 7 months ago, but I'm sure that the extension was working when I first set it up. Does anyone have any ideas? GilTolley (talk) 20:04, 6 May 2024 (UTC)

It is always good to add the versions of MW, PHP, and this extension to your issue reports. The extension is still working for me, but I am running it on a more "conservative" setup. [[kgh]] (talk) 09:15, 13 June 2024 (UTC)