Talk:Extensions FAQ

From mediawiki.org
Latest comment: 15 years ago by Derrickfarnell in topic Unable to disable caching
The following discussion has been transferred from Meta-Wiki.
Any user names refer to users of that site, who are not necessarily users of MediaWiki.org (even if they share the same username).

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

Parsing with $wgOut->parse[edit]

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

Just beware that the parse method wraps its output in <p></p> 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)Reply
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="<myextenstion>one|two</myextension>", then I get back the results "<myextenstion>one|two</myextension>". 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)Reply

Caching Problems[edit]

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?[edit]

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

Upgrade to a modern version of MediaWiki. --brion 06:50, 25 May 2006 (UTC)Reply

Extensions mess up font, traced to #globalWrapper in main.css[edit]

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 */
 #globalWrapper {
 	font-size: 98%;
	width: 100%;
	margin: 0;
	padding: 0;
 } 
 .visualClear {
	clear: both;
 }

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

Is there any workaround for this?[edit]

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.

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

Nope. --brion 06:50, 25 May 2006 (UTC)Reply
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)Reply
I have tried your solution, Jim, but the decoding phase just wouldn't work. Any ideas? Peleg 07:04, 13 May 2007 (UTC)Reply
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)Reply

SkinTemplate SpecialPage Gotcha[edit]

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 "Frequently Asked", but it took a long time to discover and Google was no help.

--Jimbojw 21:46, 15 June 2006 (UTC)Reply

Including js files only once when extension is called many times[edit]

I'm creating an extension that requires me to include a javascript file. Right now, I do something like

$output .= "<script language=\"javascript\" type=\"text/javascript\" src=\"$path/extension.js\"></script>";

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 <ref> 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)Reply

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 = "<script language=\"javascript\" type=\"text/javascript\" src=\"$path/myJavaScript.js\"></script>";
	   }
           return $output;
        }    
    }
    
    new myExtensionClass;
}

Extension Does not Render in <pre></pre> tags[edit]

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


 <myExtenson></myExtension> - renders correctly and outputs only 'foo'
 <pre><myExtenson></myExtension></pre> - renders incorrectly and outputs '<myExtenson></myExtension>'

Any ideas?

I have found one solution (which I don't love but it works). The only problem is that media wiki inserts <p></p> tags which messes it up a bit.
   <div style="white-space:pre">
      <myExtenson></myExtension>
   </div>

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

FAQ gives bad advice[edit]

Perhaps the FAQ section #How_do_I_render_wikitext_in_my_extension.3F 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)Reply

Passing a space as argument to an extension[edit]

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:

<extension argument=" ">
text
</extension>


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 argument=". ." goes through but argument=" | " 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)Reply

Solution found[edit]

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

I don't know why in line 767 the value is trimmed. Perhaps it is necessary but I removed the trim() 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 trim() 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)Reply

Extension including Category-Tag?[edit]

I want my extension to also include [[Category:Name here]], 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("[[Category:Name here]]"); 
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("{{test}}");

So a template should be inserted, which includes the [[Category:Name here]] 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[edit]

Im trying to get an {{#projects: bla | bla}}-tagstyle extension to output these lines of wikicode:

{| class="wikitable"
| test1 || test2
|}

I cant however figure out how to tell the extension to make line breaks. Any hints??? Thx. Rune

Update1[edit]

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?[edit]

What are the extensions installed on wikipedia? 202.57.110.166 06:37, 30 January 2007 (UTC)Reply

see w:Special:Version --Nad 08:57, 30 January 2007 (UTC)Reply

WikiText parsing example does not work in MW 1.9.1[edit]

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 '<div class="wonderful">' . $output->getText() . '</div>';
}

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

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

What does it all do?[edit]

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

Reading from another database[edit]

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

Enable caching for an extension[edit]

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

I'm not sure this is about an extension...[edit]

Sorry if I'm posting in the wrong place (tell me where to post and I'll move this). I'm trying to create a little code to add an user to the db without the login form. I'm trying using something similar to this:


<?php

require_once( "includes/WebStart.php" );

require_once( "includes/Wiki.php" );

$mediaWiki = new MediaWiki();

$test=new User;

$test->createNew("test",array('password'=>'pass','email'=>'test@test.com','real_name'=>'test'));

?>


The code create an sql query, execute it but NO RECORD is added to the user's table but if I check the auto_increment value of the ID field it has been incremented.

Why the code insert a record and delete it ? I'm really puzzled

thanks

Unable to disable caching[edit]

Hi - I've read the instructions for disabling caching for a particular extension, but I don't know where exactly to insert the code:

http://www.mediawiki.org/wiki/Extensions_FAQ#Recent_versions

I've using the CreateBox extension:

http://www.mediawiki.org/wiki/Extension:CreateBox

Can anyone help?! - Derrickfarnell 07:42, 28 May 2008 (UTC)Reply