Jump to content

Extension talk:UserFunctions

About this board

Extension was working but has stopped

2
GilTolley (talkcontribs)

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?

Kghbln (talkcontribs)

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.

Reply to "Extension was working but has stopped"

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

5
Summary by Kghbln

Rebuild the localisation cache to mitigate the issue.

Antdragone (talkcontribs)

I'm trying to install BlueSpice 4 on my Green Geeks hosted webserver, and I have been getting the following error when attempting to run wiki/mw-config/index.php for updating tables.

[5d21ae33df9a95266fcf8af3] /mw-config/index.php?page=ExistingWiki MWException from line 129 of /home/positro2/public_html/nomadsgalaxy/wiki/includes/MagicWord.php: Error: invalid magic word 'ifanon'

Backtrace:

#0 /home/positro2/public_html/nomadsgalaxy/wiki/includes/MagicWordFactory.php(230): MagicWord->load(string)

#1 /home/positro2/public_html/nomadsgalaxy/wiki/includes/parser/Parser.php(4872): MagicWordFactory->get(string)

#2 /home/positro2/public_html/nomadsgalaxy/wiki/extensions/UserFunctions/UserFunctions.php(109): Parser->setFunctionHook(string, string, integer)

#3 /home/positro2/public_html/nomadsgalaxy/wiki/includes/HookContainer/HookContainer.php(329): wfRegisterUserFunctions(Parser)

#4 /home/positro2/public_html/nomadsgalaxy/wiki/includes/HookContainer/HookContainer.php(132): MediaWiki\HookContainer\HookContainer->callLegacyHook(string, array, array, array)

#5 /home/positro2/public_html/nomadsgalaxy/wiki/includes/HookContainer/HookRunner.php(2960): MediaWiki\HookContainer\HookContainer->run(string, array)

#6 /home/positro2/public_html/nomadsgalaxy/wiki/includes/parser/Parser.php(532): MediaWiki\HookContainer\HookRunner->onParserFirstCallInit(Parser)

#7 /home/positro2/public_html/nomadsgalaxy/wiki/includes/parser/Parser.php(477): Parser->firstCallInit()

#8 /home/positro2/public_html/nomadsgalaxy/wiki/includes/parser/ParserFactory.php(142): Parser->__construct(MediaWiki\Config\ServiceOptions, MagicWordFactory, LanguageEn, ParserFactory, string, MediaWiki\SpecialPage\SpecialPageFactory, MediaWiki\Linker\LinkRendererFactory, NamespaceInfo, MediaWiki\Logger\LegacyLogger, MediaWiki\BadFileLookup, MediaWiki\Languages\LanguageConverterFactory, MediaWiki\HookContainer\HookContainer)

#9 /home/positro2/public_html/nomadsgalaxy/wiki/includes/ServiceWiring.php(817): ParserFactory->create()

#10 /home/positro2/public_html/nomadsgalaxy/wiki/vendor/wikimedia/services/src/ServiceContainer.php(447): Wikimedia\Services\ServiceContainer->{closure}(MediaWiki\MediaWikiServices)

#11 /home/positro2/public_html/nomadsgalaxy/wiki/vendor/wikimedia/services/src/ServiceContainer.php(416): Wikimedia\Services\ServiceContainer->createService(string)

#12 /home/positro2/public_html/nomadsgalaxy/wiki/includes/MediaWikiServices.php(1000): Wikimedia\Services\ServiceContainer->getService(string)

#13 /home/positro2/public_html/nomadsgalaxy/wiki/includes/installer/Installer.php(732): MediaWiki\MediaWikiServices->getParser()

#14 /home/positro2/public_html/nomadsgalaxy/wiki/includes/installer/WebInstaller.php(657): Installer->parse(string, boolean)

#15 /home/positro2/public_html/nomadsgalaxy/wiki/includes/installer/WebInstallerExistingWiki.php(104): WebInstaller->getInfoBox(string)

#16 /home/positro2/public_html/nomadsgalaxy/wiki/includes/installer/WebInstallerExistingWiki.php(92): WebInstallerExistingWiki->showKeyForm()

#17 /home/positro2/public_html/nomadsgalaxy/wiki/includes/installer/WebInstaller.php(269): WebInstallerExistingWiki->execute()

#18 /home/positro2/public_html/nomadsgalaxy/wiki/mw-config/index.php(82): WebInstaller->execute(array)

#19 /home/positro2/public_html/nomadsgalaxy/wiki/mw-config/index.php(40): wfInstallerMain()

#20 {main}


BlueSpice 4 is using Media Wiki 1.35.6

I have tried manually updating the extension, but I'm still getting this error. I'm fairly new to all of this, so I'm trying to figure out how to get passed this.

My PHP is Version 7.4 if that helps.

Antdragone (talkcontribs)

What's strange is that this only happens at;

mw-config/index.php?page=ExistingWiki

When I access the wiki, everything loads perfectly normal, and I can use the site without issue, and when I check Special:Version, UserFunction is marked as loaded.

Antdragone (talkcontribs)

I can't say exactly what fixed it, but I tried a code branch I found here;

https://github.com/Universal-Omega/mediawiki-extensions-UserFunctions

That fixed the error I was experiencing.


I did have to change

if ( isset( (int)$wgUFAllowedNamespaces[$cur_ns] ) ) {

to

if ( null !== ( (int)$wgUFAllowedNamespaces[$cur_ns] ) ) {

in UserFunctions_body.php


So, hopefully this is useful for anyone trying to run BlueSpice 4.

ProbablePrime (talkcontribs)

I'm still experiencing the same issue on the latest mediawiki version with this updated from its main branch.

I see others experiencing issues. I've tried the Universal-Omega branch but that seems very down revision now from the main repository.

ProbablePrime (talkcontribs)

ifsysop and ifingroup broken on avid.wiki

1
Hb1290 (talkcontribs)

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

Reply to "ifsysop and ifingroup broken on avid.wiki"

composer/installers 2.2.* support

1
MarB-96 (talkcontribs)

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

Reply to "composer/installers 2.2.* support"
Summary by GregRundlett

The failure was related to a poorly structured composer.json which automatically loaded the 'php entry point' file all the time - even when running scripts like PHPCS which wouldn't have a defined "MediaWiki". Fixed in the most current branch (and possibly in the REL1_35 branch). There is no PHP entry point file anymore, and the class code is in a new file.

Note: the correct way to remove a dependency in Composer is to delete the requirement in composer(.local).json and then regenerate the autoload files with composer dumpautoload

The correct way to autoload files in general is to structure your code for PSR4 autoloading and only specify your classes for autoloading (do not autoload settings non-class code).

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.

Cavila (talkcontribs)

Your issue appears to have been fixed with this commit, although I'm not sure if the necessary commits are included in the REL_1_35 branch.

It's a highly annoying issue though, which I ran into myself and made it impossible for me to continue using Composer until I dug into the /vendor/composer folder and manually deleted a couple of lines from various autoload files - not usually the way to go, but Composer got stuck.

GregRundlett (talkcontribs)

Interesting, I think I took the same approach as you - manually inspecting/editing the autoload of Composer. It looks like the UserFunctions extension has gotten some recent love ❤️


Nice!

Adding a #displaydate function?

1
Yaron Koren (talkcontribs)

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?

Reply to "Adding a #displaydate function?"

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

Upgrading to MW 1.31.7

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