Extension talk:UserFunctions
Contents
| Thread title | Replies | Last modified |
|---|---|---|
| UserFunctions breaks maintenance/importImages.php | 3 | 09:23, 3 May 2012 |
| $wgUFEnablePersonalDataFunctions = true; not working | 10 | 08:43, 22 March 2012 |
| More secure version suggestion | 4 | 11:27, 3 January 2012 |
| Issue with MW 1.18.0 | 5 | 19:00, 23 December 2011 |
| Rewriting of the extension | 6 | 07:40, 20 December 2011 |
| #ip: | 0 | 12:56, 30 October 2011 |
| Request | 1 | 20:01, 28 September 2011 |
| Version 1.2 | 0 | 19:59, 28 September 2011 |
| Version 1.1 | 0 | 19:58, 28 September 2011 |
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.
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
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;
}
}
}
...
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
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!
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
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. :(
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.
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.
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.
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.
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?
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
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
uh. It works in MediaWiki Sidebar in a 1.17 installation. Let me see if I can check it in a 1.18 :O
1.17 is ok, but 1.18 ... *fear* On regular wiki pages there is no problem at all.
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.
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
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.
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
Hi! If possible, I think it would be better to submit it to MediaWiki SVN. I will follow the procedure to do this. Thanks!
That's great. I guess it will not only be useful for you with regard to this extension to have access to SVN. Cheers
Done: http://svn.wikimedia.org/svnroot/mediawiki/trunk/extensions/UserFunctions/ In a couple of days I would change the extension page.
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
Hi, this parser function is a bit redundant in this extension. Still I believe it should be there. Cheers
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?
... and I added the #ifingroup function, and updated the version to 1.2 .
