Open main menu

Extension talk:UserFunctions

About this board

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

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.

Kghbln (talkcontribs)

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

84.88.66.226 (talkcontribs)

Hi! If possible, I think it would be better to submit it to MediaWiki SVN. I will follow the procedure to do this. Thanks!

This post was posted by 84.88.66.226, but signed as Toniher.

Kghbln (talkcontribs)

That's great. I guess it will not only be useful for you with regard to this extension to have access to SVN. Cheers

Toniher (talkcontribs)
Kghbln (talkcontribs)

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

Toniher (talkcontribs)

Thanks kgh! I changed credits as well.

Reply to "Rewriting of the extension"
Kghbln (talkcontribs)

... and I added the #ifingroup function, and updated the version to 1.2 .

This post was posted by Kghbln, but signed as Louperivois.

Reply to "Version 1.2"
Kghbln (talkcontribs)

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.

This post was posted by Kghbln, but signed as Lexw.

Reply to "Version 1.1"

tags missing for packagist to work

2
Kghbln (talkcontribs)

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

Kghbln (talkcontribs)

@Toniher Ping. :) Tagging is an integral mechanism of version management with Composer. So doing so will be greatly apprechiated. :)

Reply to "tags missing for packagist to work"

#ifsysop not working in Sidebar level 1

2
Planetenxin (talkcontribs)

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

Kghbln (talkcontribs)

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.

Reply to "#ifsysop not working in Sidebar level 1"
Return to "UserFunctions" page.