Extension talk:MyVariables

Survey of users

This extension was originally written as an example, but many people (including me) use it in their wiki.

I propose this extension to unite the like, such as UUID, TotalRevisions and etc...

Question: whether to do it, or leave this extension as simple as it is now, that it could be further used as an example? --Pastakhov (talk) 05:05, 26 December 2012 (UTC)

I think it is not a bad idea to consolidate them into one extension. Instead of installing heaps of them only one would be needed. Perhaps it would be a good idea to add a security switch for user related confidential information, as the UserFunctions extension does right now. Cheers --[[kgh]] (talk) 22:47, 26 December 2012 (UTC)

Old Talks

Hello there,

this is a very useful extension but it do not work the way i expected. This variables seem to be not actual when a page is reloaded. I changed the return value of the variable but it has the old value (after reloading the page). When i worte "Hello {{CURRENTUSER}}" on my main page an i logged out, it always shows my former login name. I thougt that this could be a caching problem, but when a fried edited the main page and I visited it afterwards, the page shows the login name of my friedn.... There is something strange about parsing the CURRENTXYZ values. Is there a solution?

Thanks in advance 88.76.203.237--

Yeah I've noticed that as well, I think it's that the current user variable reset after logging out after the page renders, but I'll check it out properly when I get some time. --Nad 22:09, 10 March 2007 (UTC)

---

Hi Nad,

i tried different ways but it is really strange and does not work. My php skills are not that good (as same as my english skills :-) ), but i ask myself how the whole session is handled. When i am logged in everything (for example MY watchlist) is rendered depending on my login name. So i think there must be a reliable information about the user which is currently logged in. (Or how does all this customized rendering work?). Naive as i am, i expected $wgUser stores this information, but obviously it does not. Greetings from Germany. ---~~

I've recently found that this extension doesn't work in 1.9.x - it works in 1.4 - 1.6.x. I'm working a lot on some 1.9's now and will need to get it going for that so I'll update it here when I get it working. --Nad 21:49, 14 March 2007 (UTC)

Hi Nad,

i hope i do not bother you. I forgot to mention, that "our wiki" is running a 1.6.9 version. I am now really suprised that you do not notice this problems in a 1.6.x version. I am running two 1.6.9 wiki on different target systems (Windows XP / PHP 5 AND Linux PHP 4) and in both i noticed this problem. I am trying to get throug the source codes but as i mentioned my skill are not that good.

I believe that the parsing of the wiki code does not work correctly. For testing purposes i customized your code to render

$user=new User();

$user->getName();

but this does also have the same "side effects". Sometimes i think this code is not really rendered each time. Then i edit the site and click on "preview" i ALWAYS get the correct value of the variable.

But this seems to be not only "your problem" the standard values like NUMBEROFARTICLES act the same (strange) way.

I hope my information are helping you anyway. Have a nice day. --193.19.114.132

All I can think of is that maybe the pages you're viewing are cached, it's always good to turn off the caching when experimenting with the following couple if lines in LocalSettings.php,

$wgEnableParserCache = false;

$wgOut->enableClientCache(false);

The $wgUser global is definately the object you want which holds the info on the currently logged in user. --Nad 20:19, 15 March 2007 (UTC)

Hello Nad, thank you very much for your competent help. I disabled the Cache in LocalSettings.php (only the $wgEnableParserCache=false) and everything works as i expected. Thanks a lot for your support!! Have a nice weekend! Greetings from Germany. --193.19.114.132

Excellent, glad to hear it's working out ;-) --Nad 21:18, 16 March 2007 (UTC)

Parser Caching?

Hello,

in 1.8.4, variables retain their values after having been computed once. Touching LocalSettings.php helps, so I'm pretty shure there must be some caching problem.

Workaround

set $wgEnableParserCache to false in LocalSettings.php

Solution

Sorry, Nad, I'm new to MediaWiki and as well to php. There must be some solution to prevent pages that contain dynamic variables from being cached. Perhaps setting some per-page flag... I don't know.

Harm in disabling?

I want to put a cool icon and edit instruction on the unedited personal page (#if on Media Wiki:Noarticletext), but then the CURRENTUSER variable has to be functional.

What will be damaged if I set $wgEnableParserCache to false? I guess at least it would make the count of the number of times each page has been displayed to go crazy... any other damages? Maybe performance? Thank you :-) --87.68.208.47 22:35, 18 May 2007 (UTC)

Completely disabling the parser cache will affect performance badly, especially if you have any high traffic to serve. I've added a line in to the CURRENTUSER example which marks the returned content as uncacheable, so see if that does the trick --Nad 23:38, 18 May 2007 (UTC)

More Examples?

I'm trying to create new variables with this extension that call user stats like registration date and last login of a user. It's for a template so the user is called with MyVariables. Any hints? Thanks. --Subfader 21:57, 14 May 2008 (UTC)

It would probably be easier to make it as a parser function such as #user and make the parameter the property you want to read, that way you can easily extend the number of properties etc without having to create many different magic words. --Nad 23:28, 14 May 2008 (UTC)

Not working for me (MW1.12.0)

Hi - I've tried this using the include in LocalSettings.php, but I just get a few lines of programming superimposed at the top of the wiki page, and the variable doesn't work. Should it work in 1.12.0? Thanks. - Derrickfarnell 11:06, 19 May 2008 (UTC)

MW 1.12.0 may not work due to the significant changes to the way the parser works. --Zven 20:37, 19 May 2008 (UTC)

WOrked fine for me on 1.12.0rc. Try placing the line above all other extension includes / requires --Subfader 06:41, 20 May 2008 (UTC)

Perhaps I'm doing something wrong: I created a folder, within the extension folder, called 'MyVariables', and then created a php file within that folder with the name MyVariables.php, and containing simply the code provided here. I then added the following line at the end of LocalSettings.php, although before all the other lines I've added at the end in the past:

require_once( "$IP/extensions/MyVariables/MyVariables.php" );

Should that work?! It still doesn't for me... I just get a few lines of code superimposed at the top of every page, which is what has happened in the past when other extensions have not worked or been incorrectly installed.

Is there perhaps another way of automatically inserting the user's username into a page? I'm wanting the user's username to be automatically inserted in the form field on this page:

http://www.chainsofreason.org/wiki/Create_a_new_chain

- I can get the date and time automatically inserted, but the user has to manually replace 'User' with their username. Derrickfarnell 09:59, 22 May 2008 (UTC)

Now working after adding <?php to the beginning of the code. - Derrickfarnell 09:07, 1 June 2008 (UTC)

More variables

The extension works very well (MediaWiki: 1.10.1; PHP: 5.1.2). If there is a second Wiki installed as a shared repository for media files, the users might need information about the available disc space. Therefore I added two variables:

                case MAG_DISCTOTALSPACE:
                        $ret = disk_total_space ( $GLOBALS['wgSharedUploadDirectory'] );
                        break;
 
                case MAG_DISCFREESPACE:
                        $ret = diskfreespace ( $GLOBALS['wgSharedUploadDirectory'] );
                        break;

The functions disk_total_space and diskfreespace use $wgSharedUploadDirectory to get the path information. The variables can be processed using ParserFunctions to get the required output for users on a wiki page. --ThT 14:47, 2 June 2008 (UTC)

Give out javascript

Is it possible to give out a simple javascript this way? Something like $ret = echo ('<a href="javascript:...>Text</a>? --Subfader 19:17, 5 June 2008 (UTC)

Give it a try, if not you can set up a parser-function instead which can be made to return HTML --Nad 21:16, 7 June 2008 (UTC)

Database query?

Is it possible to give out a database query? I'd like to use a code to display 3 random mp3 links from Special:MIMESearch/audio/mp3 on an article page. --Subfader 23:14, 25 September 2008 (UTC)

You'd have to look at the code they use in that special page to query those types and modify it to produce a random selection, and then include that code in a magic variable or parser function. --Nad 20:01, 26 September 2008 (UTC)

Is user logged in?

To differ page content for logged in and anonymous (not logged in) users do this (requires Extension:ParserFunctions):
Variables.php:

$wgCustomVariables = array('CURRENTUSER','ANONYMOUS');
...
               	case MAG_ANONYMOUS:
			$parser->disableCache(); # Mark this content as uncacheable
			$ret = $GLOBALS['wgUser']->isAnon();
			break;

On a wiki page use e.g.:

{{#ifeq:{{ANONYMOUS}}|1|You're anonymous.|You're logged in.}}

Note that it will return "You're logged in." also if your code is not working. Only if code is properly working it will return "You're anonymous." for anonymous users. --Subfader 20:20, 26 February 2009 (UTC)

Real name

Here's a tip that I thought others might be interested in. Currently the extensions shows the log in name. To show the real name change:

$wgCustomVariables = array('CURRENTUSER','LOGO');

to

$wgCustomVariables = array('CURRENTUSER','CURRENTUSERREALNAME','LOGO');

and add the code below to the wfGetCustomVariable switch statement:

case MAG_CURRENTUSERREALNAME:
$parser->disableCache(); # Mark this content as uncacheable
$ret = $GLOBALS['wgUser']->mRealName;
break;

--Robinson Weijman 12:17, 8 November 2010 (UTC)

I've added this to the main code. --Robinson Weijman 18:50, 12 February 2011 (UTC)

Get mime type

I want to return the mime type of the current page title. So {{MIME}} on File:Foo.jpg would return "image".

case MAG_MIME:
$ret = $GLOBALS['wgTitle']->getMimeType();
break;

That doesn't work. Any idea? --Subfader 16:06, 12 December 2010 (UTC)

"Extension code in wiki" Template

Is this template Extension code in wiki on top really correct? It creates new magic words which you can use in articles, but no code is stored in wiki pages... --Subfader (talk) 21:55, 4 March 2012 (UTC)

Not working on Mediawiki 1.19.3

I updated my wiki for 1.18 to 1.19 and now MyVariables does not seem to be working. Any ideas on why this might be so? Catamarandreams (talk) 22:45, 25 January 2013 (UTC)

I tested this extension with MediaWiki version 1.19.3 and it works well. You are using the latest version (3.1.1) of this extension? --Pastakhov (talk) 04:05, 26 January 2013 (UTC)

Requires Disabling the Cache

I think that it is very important to note within this extension's description —at the very top— that the intended functionality of this extension (e.g., querying and returning the user name) requires disabling page caching, which in turn obviates a fundamentally-important aspect of wiki functionality. I can see this extension maybe being applicable within certain use-case scenarios, but it is not practical in almost every real-world implementation of Mediawiki. I mean no offense but am surprised that Mediawiki admin have not mandated full disclosure in the case of this extension and others like it. ~z929669 Talk 17:11, 17 January 2015 (UTC)

The variables appear as templatelinks (MW 1.25)

In MW 1.25.2 the variables appear as templates in the edit section "Templates used on this page". That should not be the case.

Before I used MW 1.22 and everything was fine there. I use 3.0.2. --Subfader (talk) 20:37, 13 August 2015 (UTC)

Version number mismatch?

The download file MyVariables-REL1_25-de4c078.tar.gz produces an installation with version 3.2.0 while the Documentation indicates 3.3.0 is current. Is there a more up-to-date file? WmBliss (talk) 02:20, 12 October 2015 (UTC)

Has the Parser Caching problem been fixed?

As seen in the above discussion, there was once the (purported) problem that variables were not being updated unless caching was turned off. Is this still the case? WmBliss (talk) 02:23, 12 October 2015 (UTC)

Wrong context after redirect

$GLOBALS['wgTitle'] has the wrong context after a redirect.

Say "Old Page" redirects to "New Page". $GLOBALS['wgTitle']->getDBkey() on "New Page" will read "Old_Page" after the redirect.

How can this be fixed? I suppose $this->getContext()->getTitle()->getDBkey(), but there is no $this. --Subfader (talk) 18:25, 18 October 2015 (UTC)

I had the same problem some 5 years later... I guess you found a solution. I post mine here :

$ret = $cache[$magicWordId] = $GLOBALS['wgTitle']->getDBkey();

Hope it may help someone^^

Auctores varii (talk) 14:45, 22 August 2020 (UTC)

UUID Examples?

Hiya! Thank you for this extension. It will be very helpful to make user-language-aware templates in our neighborhood's wiki. I am unfamiliar with UUIDs though. I've read the relevant page on Wikipedia but I can't quite figure out an application in the context of a wiki. Could you provide some examples? -- manu3d (talk) 09:17, 16 September 2016 (UTC)

Call to undefined method Parser::disableCache()

MediaWiki 1.35.0, MyVariables 3.5.1

Problem preventing the page from displaying!

Call to undefined method Parser::disableCache()

Problem solved by replacing the call to disableCache() in lines 41, 47, 54, 58 in extensions/MyVariables/MyVariablesHooks.php with this:

//$parser->disableCache();
$parser->getOutput()->updateCacheExpiry(0);

Anyone to propose a better solution?

By the way, thank you MW team for all these regressions at each upgrade!

--Megajoule (talk) 17:53, 22 November 2020 (UTC)

Hrmph! I only had one call to $parser->disableCache(); and it was at line 36 in the MyVariablesHooks.php files. But commenting it out did the trick. You saved me a ton of time and fear of having to revert. Thanks! Now we just need to hope the extension is updated... --Tgschaef (talk) 21:17, 27 December 2020 (UTC)

Probably a good idea to also report this on Phabricator. --[[kgh]] (talk) 10:55, 30 December 2020 (UTC)

Done: https://phabricator.wikimedia.org/T270972 --Megajoule (talk) 08:03, 31 December 2020 (UTC)

I see it was quickly closed as invalid and that the repository had been changed, but apparently not released as a version? Strange as I use the version #/date as my cue to update an extension. I downloaded the master and installed it for this fix and any other improvements as well as for UrlGetParameters. --Tgschaef (talk) 20:24, 3 January 2021 (UTC)

I did the same. It works for me as well. This adventure gave me the opportunity to discover Phabricator and Mediawiki Code search. I'm starting the year less stupid. ;-) --Megajoule (talk) 09:09, 4 January 2021 (UTC)

Not working is MW 1.35.3

System Setup

Product	Version
MediaWiki	1.35.3
PHP	8.0.7 (apache2handler)
MariaDB	10.1.48-MariaDB-0ubuntu0.18.04.1
ICU	65.1
Lua	5.1.5
MyVariables	3.5.1 (cde2562)

MyVariables gives BLANK output when used {{CURRENTUSER}}, {{CURRENTUSERREALNAME}}

Referred to one previous answer and checked MyVariablehooks.php and actually found at line 41,47,54,58

$parser->getOutput()->updateCacheExpiry( 0 );

( Which is correct according to the answer !)

But still MyVariables is not working.

Thanks for reporting Pharmankur, we'll have a look at this and get back to you. --X-Savitar (talk) 14:03, 3 August 2021 (UTC)

Pharmankur, which version of the extension are you running? NOTE that master of the extension is not backward compatible with MW release versions.

Warnings appear when using

Deprecated

Use of $wgUser was deprecated in MediaWiki 1.35. [Called from MediaWiki\HookContainer\HookContainer::callLegacyHook in /var/www/html/includes/HookContainer/HookContainer.php at line 338] in

/var/www/html/includes/debug/MWDebug.php on line 375

Deprecated

$wgUser reassignment detected [Called from MediaWiki\HookContainer\HookContainer::callLegacyHook in /var/www/html/includes/HookContainer/HookContainer.php at line 338] in

/var/www/html/includes/debug/MWDebug.php on line 375

Will test this on MW 1.35 and let you know. If I can reproduce, I'll make a patch for the fix.

I think this has been resolved. Can you confirm please? Try to run MediaWiki REL1_35 & MyVariables REL1_35 and let's see if the problem still exists. Thanks! --X-Savitar (talk) 15:15, 30 March 2022 (UTC)