Extension talk:UserFunctions

About this board

How to show ifingroup in VisualEditor?

1
Stefahn (talkcontribs)

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.

Reply to "How to show ifingroup in VisualEditor?"

Some troubles on some namespaces

2
FrViPofm (talkcontribs)

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

83.255.155.133 (talkcontribs)

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

Reply to "Some troubles on some namespaces"
GregRundlett (talkcontribs)

From the $IP of my mediawiki installation, running composer test fails with a message originating from UserFunctions:

This file is a MediaWiki extension, it is not a valid entry point

Is there a way to exclude the offending file (./extensions/UserFunctions/UserFunctions.php); or is there a technique that would make this file compatible with composer test?

Note: This is using the REL_1_35 branch with

Product Version
MediaWiki 1.35.4 (87ad58f)

14:19, 22 October 2021

PHP 7.4.24 (apache2handler)
MariaDB 10.4.21-MariaDB-log
ICU 67.1
Elasticsearch 6.7.2

If I checkout 'master' of UserFunctions, I get "This version of the UserFunctions extension requires MediaWiki 1.35+" from the same file.

Reply to "Composer test fails"
Adrianzlobinski (talkcontribs)

When I upgrade to MW 1.35 get error on Parser::disableCache. Looking on forum and found https://www.mediawiki.org/wiki/Topic:Vj94nk4mug1yfn1t

So i repleced '$parser->disableCache();' to '$parser->getOutput()->updateCacheExpiry(0);' in UserFunctions_body.php and it works.

Reply to "Upgrading to MW 1.35"
Seppl2013 (talkcontribs)

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?

Reply to "Upgrading to MW 1.31.7"
ClemFlip (talkcontribs)

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

Kghbln (talkcontribs)
Reply to "Suggesting new feature"

User Functions stops Auto Create Category Pages

7
213.57.135.184 (talkcontribs)

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?

FreedomFighterSparrow (talkcontribs)

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!

213.57.135.184 (talkcontribs)

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

FreedomFighterSparrow (talkcontribs)

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.

5.28.166.54 (talkcontribs)

By the time, seems the problem has solved, somehow. Thanks A-lot!

FreedomFighterSparrow (talkcontribs)

Glad to hear it! Let's hope for no repeats :-)

This post was hidden by FreedomFighterSparrow (history)
Reply to "User Functions stops Auto Create Category Pages"

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

3
Uckelman (talkcontribs)

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 (talkcontribs)

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;
        }
41.81.70.95 (talkcontribs)

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

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

Is it possible to use not in group?

1
148.177.65.215 (talkcontribs)

I would like to hide the edit tab if a user is not in a group

Reply to "Is it possible to use not in group?"

refreshLinks/htlmCacheUpdate jobs

7
Cindy.cicalese (talkcontribs)

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 (talkcontribs)
Toniher (talkcontribs)

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?

Cindy.cicalese (talkcontribs)

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.

Toniher (talkcontribs)

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 (talkcontribs)

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.

Cindy.cicalese (talkcontribs)

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!

Reply to "refreshLinks/htlmCacheUpdate jobs"
Return to "UserFunctions" page.