Talk:Extensions FAQ

I'm having trouble making the current suggested cache-avoidance code work. Rather, it simply fails to negate the cache in my browser. However, I noticed in the revision history that the original field updated is the cur_touched field, and it was changed to the timestamp field. When I convert the code in my extension to use cur_touched, I get the desired cache-free behavior. Any comments before I update the recommendation? Jwolfe 21:08, 7 Jun 2005 (UTC)

I've included this code in my extention php-file. global $wgTitle; $dbw =& wfGetDB( DB_MASTER ); $dbw->update( 'cur', array( 'cur_touched' => $dbw->timestamp( time + 120 ) ),     array( 'cur_namespace' => $wgTitle->getNamespace, 'cur_title' => $wgTitle->getDBkey ), 'nameOfYourExtension' );

I got this error msg: Fatal error: Call to undefined function: wfgetdb in /home/httpd/html/wiki/extensions/uptime.php on line 38

Any suggestions?


 * Sounds like you included it straight in the file where it's executed on include, before the functions are defined. It should be in your hook function. --brion 21:32, 13 July 2005 (UTC)

Parsing with $wgOut->parse
Is there anything wrong with parsing input using $wgOut->parse($input)?


 * Just beware that the parse method wraps its output in   tags. $wgOut->parse($input,false) prevents that. Thanks to the folks in #mediawiki on Freenode for that bit of info.--Yock 01:02, 28 October 2005 (UTC)


 * This method can cause the NaodW output in a special case. If a template contains an extension which uses $wgOut->parse and you call this template from another page which use extensions, the extensions on the calling page will return as NaodW... --frantik 06:29, 9 November 2005 (UTC)

I am having problems with the $wgOut->parse($input) method myself. If $input=" one|two ", then I get back the results "&lt;myextenstion&gt;one|two&lt;/myextension&gt;". Obviously, I do not want the "<" and ">" symbols simply turned into HTML special chars. I want my extension code to be executed and replaced with the output from the extension. I would appreciate any help with this. I am using MediaWiki 1.5.2. --Mrainwater 02:47, 13 November 2005 (UTC)

Caching Problems
I followed the cache faq and added $wgParser->disableCache inside the hook function of my extension It is a form mailer (FormHandler) and thus should absolutely be executed every time the page is loaded (especially also in a post request). Sometimes this works, but sometimes mediawiki seems to cache the output. Any ideas? --Dbu 16. March 2006

Prefixindex extension: where?
I'm looking all over for a way to add/activate Special:Prefixindex. I fail however. Who can point me in the right direction? 145.43.250.3 07:30, 12 April 2006 (UTC)
 * Upgrade to a modern version of MediaWiki. --brion 06:50, 25 May 2006 (UTC)

Extensions mess up font, traced to #globalWrapper in main.css
I'm running MediaWiki 1.6.5. I added a couple pre-written extensions to my site. Suddenly, the font everywhere got much larger. After much fiddling, I found that the font-size in main.css#globalWrapper was 127%. This is my current workaround, though it seems to mess with the p-personal portlet placement. /* scale back up to a sane default */ font-size: 98%; width: 100%; margin: 0; padding: 0; } .visualClear { clear: both; }
 * 1) globalWrapper {

View source on http://chickshare.com/wiki/Main_Page ... I'm wondering if div nesting is getting messed up somehow? I'm a PHP newbie, though I've been programming in other languages for 20+ years, so I'm sure I can hack it given enough time, I'm just hoping someone saves me some effort! ;) --68.21.231.27 18:27, 23 May 2006 (UTC) (Woops, wasn't logged in, this was from me: --Julie 18:28, 23 May 2006 (UTC))

Is there any workaround for this?

 * How can I avoid modification of my extension's HTML output?
 * This will probably require moving some code around in the parser. The current extension :code assumes extensions will produce inline material and they are inserted before the :final block-level rendering stages.
 * This will probably require moving some code around in the parser. The current extension :code assumes extensions will produce inline material and they are inserted before the :final block-level rendering stages.

Is there no solution for this, yet? or is there any method for hooking some predefined wiki syntax? 210.94.41.89 05:14, 25 May 2006 (UTC)
 * Nope. --brion 06:50, 25 May 2006 (UTC)
 * I found one solution by utilizing OutputPageBeforeHTML. Here's a full article describing how to Keep MediaWiki from Modifying Your Extension Output  Hope it helps. --Jimbojw 18:05, 14 February 2007 (UTC)
 * I have tried your solution, Jim, but the decoding phase just wouldn't work. Any ideas? Peleg 07:04, 13 May 2007 (UTC)
 * If you use a parser-function instead ($parser->SetFunctionHook instead of $parser->setHook) you can return parameters along with your output text to protect it against wiki-parsing, in this case, instead of return $text, use:
 * return array($text, 'noparse' => true, 'isHTML' => true);
 * noparse means don't strip unsafe tags etc, isHTML means to armour it against wikitext transformation, see Extending wiki markup. --Nad 21:59, 13 May 2007 (UTC)

SkinTemplate SpecialPage Gotcha
Not sure where the following gotcha should go, but it was a real pain to figure out. If you're migrating SpecialPage extensions from MW 1.5.x to 1.6.x, note that in order to avoid this error:

Fatal error: Call to a member function getID on a non-object in \path\to\wiki\includes\SkinTemplate.php on line 306

You must add the following line to the execute function of your SpecialPage class:

$wgOut->setArticleFlag(false);

The above tells MW to stop trying to treat the special page as an article, and was not required in previous MW versions. I'm not sure if this question is &quot;Frequently Asked&quot;, but it took a long time to discover and Google was no help.
 * --Jimbojw 21:46, 15 June 2006 (UTC)

Including js files only once when extension is called many times
I'm creating an extension that requires me to include a javascript file. Right now, I do something like

$output .= " ";

in the render function. Unfortunately, I often use my extensions multiple times in a page so the file gets included multiple times. This doesn't cause a problem with the function of the extensions, but it is messy and it really makes my html files long. Is there away to check to see if a .js file has been included and if not include the file? I guess if I had access to the header or something from php, I could check to see if it has already been included. Any ideas?


 * Take a look at how Cite.php handles numbering for the extension. You should be able to similarly track invocations within the page, and only include the JS the first time. --brion 07:16, 25 June 2006 (UTC)

thanks Brion, I've looked at Cite.php and think I have the is the solution. I had to create a class within my wgExtensionFunction. To be honest, I don't entirely understand this solution (I only started php last week...a class within a function is odd to me) but it seems to work although I'm not sure how safe it is.

$wgExtensionFunctions[] = "wfMyFunc";

function wfMyFunc {

class myExtensionClass{ var $mCount = 0; function myExtensionClass { global $wgParser; $wgParser->setHook( "myExtensionTag", Array(&$this,"renderMyExtension")); }       function renderMyExtension( $input, $argv ,$parser = null) { $this->mCount = $this->mCount + 1; ...

if($this->mCount==1) {	 			     $output = " "; }          return $output; }       }    new myExtensionClass; }

Extension Does not Render in  tags
I've noticed that if I create an extension, mediawiki does not render it if it is inside pre tags. For example, if myExtension is an extension that simply writes 'foo' then this is what happens

 - renders correctly and outputs only 'foo'   - renders incorrectly and outputs ''

Any ideas?


 * I have found one solution (which I don't love but it works). The only problem is that media wiki inserts    tags which messes it up a bit.



Other ideas? I would rather just change the pre tag.

FAQ gives bad advice
Perhaps the FAQ section should be changed to discourage people from accessing the $wgOut object via global $wgOut; and instead to use the parser object passed to the callback function. Using global method seems to cause a problem where the UNIQ...QINU string is returned instead of the actual parsed output. (See also...)

I'm willing to change it but I wanted the advice of the more experienced community first. --Socoljam 20:26, 23 July 2006 (UTC)

Passing a space as argument to an extension
Don't know if this is the right space to discuss this. If not, please point me ... I also asked on Mediawiki:Help_talk:FAQ ...

I am trying to pass a space as an argument to an extension.

Example: text

The extension code registering the extension is as follows: function extension { global $wgParser; $wgParser->setHook( 'extension', 'doit' ); } function doit( $input, $args, &$parser ) {

...

}

The $args in the function 'doit' are already space free. It seems that the arguments get trimmed, because something like  goes through but   results in just a single   without leading and trailing space.

Is there a way to avoid this?

--217.9.113.155 09:08, 14 August 2006 (UTC)

Solution found
Ok ... it drove me crazy not being able to pass a space to an extensions argument. So I dug into the code. Boy this is a lot of code and not easy to understand. But I finally found the function where attribute handling is done.

You can find it in Sanitizer.php, line 745ff, function.

I don't know why in line 767 the value is trimmed. Perhaps it is necessary but I removed the  and a first test worked just fine.

So perhaps someone with more knowledge about the mediawiki internal workings and wonders can shed some light on this.

And perhaps a developer can just remove the  or make it optional with default to true and a rule on how extensions can switch off that behaviour.

--83.171.153.127 21:37, 14 August 2006 (UTC)

Extension including Category-Tag?
I want my extension to also include, so all articles using this extension will be collected in a category automatically.

I tried: global $wgOut; $output = "whatever the extension does"; $output .= $wgOut->parse(""); return $output;

It only creates the link to the category at the bottom of the page, so I thought it worked, but the category is empty.

Then I tried: $output .= $wgOut->parse("");

So a template should be inserted, which includes the part. But it does the very same thing. Just the link, but the category stays empty.

Any solutions?

Response 1

It appears that your extension executes every time the user views the page. It doesn't execute when the user saves the page. The category links are processed and the category DB table is updated when the page is saved, so your extension has no way of setting the category of the page. One workaround would be to create a template that includes your extension AND sets the category.

128.244.206.128

Several lines
Im trying to get an -tagstyle extension to output these lines of wikicode: I cant however figure out how to tell the extension to make line breaks. Any hints??? Thx. Rune

Update1
I haven't tested it much. But for now this looks like its working fine. Rune. function wfprojectParserFunction_Render($text, $args, &$parser) { global $wgOut; $output.= $wgOut->addWikiText("==Something==\n"); $output.= $wgOut->addWikiText("===Testing===\n"); $output.= $wgOut->addWikiText("*and a bullet\n"); return $output; }

What are the extensions installed on wikipedia?
What are the extensions installed on wikipedia? 202.57.110.166 06:37, 30 January 2007 (UTC)
 * see w:Special:Version --Nad 08:57, 30 January 2007 (UTC)

WikiText parsing example does not work in MW 1.9.1
The WikiText parsing example function efWonderfulHook( $text, $args, &$parser ) { $local_parser = new Parser; $output = $local_parser->parse( $text, $parser->mTitle, $parser->mOptions, true, false ); return ' '. $output->getText. ' '; } does not work in MW 1.9.1. It produces a PHP error:

Fatal error: Call to a member function mergeArray on a non-object in /daten/daniel/MediaWiki/mediawiki-1.9.1/includes/Parser.php on line 622

--Dschwen 16:17, 31 January 2007 (UTC)


 * However it does work, if the last parameter

$output = $local_parser->parse( $text, $parser->mTitle, $parser->mOptions, true, true );
 * is set to true. --Dschwen 16:20, 31 January 2007 (UTC)

What does it all do?
I've read the page and read the talk page, but I am confused on something. Do the functions only work for the individual users, or does it apply to everyone. If I create a new function, can people use it without downloading anything. I don't know, I am confused on the whole thing. Any clearifcation would be nice.
 * These functions apply to everyone who uses the wiki they're included in. You'd have to do a condition based on $wgUser properties to make it specific to users. --Nad 20:22, 15 April 2007 (UTC)

Reading from another database
Is there any way to have an extension read a row from another database? Every time I try it gives an error, but this certainly isn't my area of expertise.
 * the wfGetDB function returns a connection to the DB specified in the $wgDBname/user/password globals, so you'd need to create a new connection yourself to a different DB. The $wgDBprefix allows many wiki's or other applications to share the same database without any of their table names conflicting. If all the tables you need to access are in the same DB you can then use the wfGetDB function like normal. --Nad 10:09, 14 June 2007 (UTC)

Enable caching for an extension
I'm a total newbie when it comes to writing extensions. I want to force an existing extension, Extension:TemplateTable to not cache its output (tables)--at least I think that's what it's doing since I have to re-edit the page the template table is on in order to refresh its data. How do I do this or, can someone else add that functionality to the extension please? Thanks. -Eep² 14:50, 25 July 2007 (UTC)