Extension talk:GeSHiCodeTag

For questions/comments/suggestions/etc. please post it here.

QUESTIONS
Please add:

Q: for questions

A: for answers

GeSHiCodeTag and templates
Q: GeSHiCodeTag doesn't work good with templates using pure html.

A: To make it work better, turn off the "simple" mode in GeshiCodeTag.php:

// 1 - enabled, 0 - disabled $codeTag["simple"] = 0;                      // ex. &lt;php&gt; echo &lt;/php&gt; $codeTag["advanced"] = 1;                    // ex. &lt;code php n&gt; echo &lt;/php&gt;

It appears that the "simple" mode for the DIV language will interfere with any &lt;div&gt; elements in HTML code.

''You can avoid this behaviour by simply changing the name of div.php to something like langdiv.php and also change the Constant in div.php to something like LANGDIV. I am aware that changing this tag the language itself is not "usable" by adding div but only by using langdiv, but as I have a big wiki up and running with an older version it won't be possible to simply disable the simple feature. So changing div to libdiv made my day. Good work, I like your extension and especially the numbering feature...''

Auto indentation
Q: The Beautifier syntax highlighting engine supports auto indentation. Can GeSHi do this too?

A: I've looked on the Geshi documentation, and it seems to me that there's no feature for auto indentation. For more features available for GeSHi check out the link.

NOTICE after installation
Q: i've install geshi and get 2 NOTICEs

Notice: Use of undefined constant div - assumed 'div' in extensions/GeSHICodeTag.php(55) : runtime-created function on line 1

Notice: Undefined variable: languagesPath in extensions/GeSHICodeTag.php(55) : runtime-created function on line 1

and i cant turn the notice off by

error_reporting(E_ALL ^ E_NOTICE);

what can i do ?

A: Can you please specify the version of geshi you're using and the version of mediawiki? I'll try to test out and see if there's a fix that I can do. Thanks! --Paul516 22:03, 8 February 2007 (UTC)

A: I had the same problem, I'm using PHP 5.2.1 (I think that was the problem), with MediaWiki 1.9.3 and latest version of Geshi. Was able to fix, in GeshiCodeTag.php replace the entire ExtensionCodeTag function with this: function ExtensionCodeTag {       global $wgParser, $codeTag, $languages;

ReadLanguages;

if($codeTag["advanced"]["mode"]) $wgParser->setHook('code', 'AdvancedCodeTag'); $languagesPath = 'extensions/geshi/geshi'; if($codeTag["simple"]) foreach($languages as $lang) {                    $wgParser->setHook($lang,                                   create_function( '$source', '                                       global $languagesPath; $geshi = new GeSHi($source,\'' . $lang . '\', $languagesPath); return $geshi->parse_code;' ));               }       } Differences:  Added global $languagePath; to created function, and added single quotes around the $lang.

--Jonyo 14:51, 3 May 2007 (UTC)

COMMENTS
Q: This plugin and the code on other sites to do syntax highlighting with GeSHi in Mediawiki does not seem to work with older versions of MediaWiki - including the current default install on Ubuntu Dapper: mediawiki v 1.4.14. Can anyone confirm that? When I try, everything seems to work but the text does not get highlighted. If anyone can confirm or deny this, please comment here!

A: I've tried installing a Mediawiki 1.4.14 using GeSHi-1.0.7.12 and GeSHiCodeTag 1.5 it seems that only the simple mode works. There seems to be some slight differences on how the parsing is setup in the older versions. I'll try to see if I can fix it to work in advanced mode as well. --Paul516 06:37, 24 September 2006 (UTC)

A: I just read somewhere that from Mediawiki 1.5 they support giving an argument to a tag. This indeed means that in previous versions only simple mode would work.

Q: I downloaded the code, and it only worked for simple mode. After a while of editing, the problem appeared to be the use of strict mode (which in a previous version was not used by default). Also, the examples at http://www.wikics.org/GeshiCodeTag_Samples suffer from the same problem.

I have removed the strict mode line, and now it works fine. Btw: I use mediawiki 1.6.8 and GeSHi-1.0.7.15.

A: Hmm... if that the case then I'll just disable the strict mode by default. Also instead of removing the line, you can just set it to  0 (false) so you'll still have the feature if you want to enable it later on --Paul516 18:28, 10 November 2006 (UTC)

Q: I just installed GeSHi-1.0.7.16 with mediawiki 1.9.0. When I try to use it, I get error: Undefined index: STRICT_MODE_APPLIES ..... in geshi.php line 1018 I browsed the geshi code, and I just don't understand why this error occurs. There is STRICT_MODE_APPLIES in language file (I'm using php.php), and constants GESHI_MAYBE, etc. are defined. Can somebody help me? Right for now I just disabled check for STRICT_MODE_APPLIES in code.

An easy fix for the "div" problem is just to rename the geshi/div.php file to something not needed for a tag (I used divg.php). I don't know if this will have unintended consequences, but I haven't seen any and it did fix the munging of the message that appears under the edit box and all other places where the "div" tag was in use as far as I can tell. --Woozle 19:32, 10 March 2007 (UTC)

SUGGESTIONS
Q. No biggie but the name and author in the credits are switched. In Special:Version it shows up as Paul Nolasco by GeshiCodeTag. --Icep 23:55, 24 September 2006 (UTC)

A. Thanks for telling me! Fixed :) --Paul516 05:26, 25 September 2006 (UTC)

Q: How would you make a default language so &lt;code> automatically highlights it to a certain language?

Q: I suggest to remove from GeSHi languages catalog language 'div'. At least in MediaWiki 1.12 GeSHiCodeTag highligts contents of some  elements. Other solution could be rewrite ReadLanguages to ignore 'div' language.

Behave properly using multi-lined code in numbered lists
Q: I was having problems putting multi-lined code in numbered lists, the list would start over and the code would get hosed up. Example: Try the following text in a wiki article: # To fix, open the file example.php.
 * 1) Now, find the lines:
 * 2) Replace with the code:
 * 3) Now it should print the correct text.

On mine, it restarts the numbering to 1 whenever there is a newline in the code, and it jacks up the &lt;pre> tags.

A: I came up with a fix, I added a new parameter, "nl2br", and modified the advanced function to allow the parameters after the language to be in any order. Replace the AdvancedCodeTag function with: function AdvancedCodeTag ($source, $settings){

global $languages, $languagesPath, $codeTag; $language = array_shift($settings);     // [arg1] // [arg1] if($language == ''){ $language='text'; // bugfix: to work for existing
 * 1) Replace with the code:
 * 2) Now it should print the correct text.

Not sure if you want to put the modification as part of the main app or not... I know we are probably going to be using it a lot on our site...

--Jonyo 15:18, 3 May 2007 (UTC)

Thanks for the fix Jonyo. I added the changes as you've suggested to main app. --Paul516 08:44, 9 May 2007 (UTC)

Word wrap
Q: It would be neat to enable the word-wrap feature of GeSHi for the wiki-syntax. This could be done, for example:  . ~24.80.179.197 22:59, 6 July 2007 (UTC)

A: I'll take a look on it, and see if this can be implemented. --Paul516 04:22, 24 May 2008 (UTC)

Version in Extension Credits
'version' => '1.65', 'description' => 'Syntax highlighter using GeSHi',
 * The version number is useful in the Extension Credits. Also suggest a description.

A: Thanks for the suggestion! I've added it in the code. --Paul516 04:22, 24 May 2008 (UTC) Servel333 20:29, 27 March 2008 (UTC)

Included in MediaWiki Protection
Towards the top of the file, below the credits, you could add the following. // Ensure file is included as part of MediaWiki. Prevents limited security issues. if ( !defined('MEDIAWIKI') ) die( " This file is part of MediaWiki and is not a valid entry point \n" ); Servel333 20:29, 27 March 2008 (UTC)

Include support for settings settings in another file
This code will check for certain variables before setting the default values. This adds an optional variable $GeSHiPath and allows values from $codeTag to be set before this file is included.

This is based on old code for 1.6, but if this section hasn't changed, it's all good.

if ( isset($GeSHiPath) ) { $languagesPath = $GeSHiPath. '/geshi'; include_once($GeSHiPath . '/geshi.php'); } else { include_once('GeSHi/geshi.php'); $languagesPath = "extensions/GeSHi/geshi";

}

// Syntax: Code // Example: Php Code if ( !isset($codeTag["simple"]) ) $codeTag["simple"] = false;

// Syntax: // Example: if ( !isset($codeTag["advanced"]["mode"]) ) $codeTag["advanced"]["mode"] = true;

// strict mode - http://qbnz.com/highlighter/geshi-doc.html#using-strict-mode if ( !isset($codeTag["advanced"]["strict"]) ) $codeTag["advanced"]["strict"] = true; Servel333 20:37, 27 March 2008 (UTC)

using full page templates
Q: i've added the modifications necessary to have full page source code articles, the templates including categorization. unfortunately, the wikitext to categorize the article also gets GeSHied and as a result the article does not get categorized. how can this be fixed? (MW 1.9.3 WAMP, using square brackets for categorizing) - neoNOexSPAMmachina at gmail dot com

highlighting with a template
Q: Hello, I would like to use semantic forms to create my pages.

As you may know semantic forms wants every bit of the generated page to be in a template.

My (experimental) template is as follows:

but it seems that for some reason the variables don't get parsed and everything I see is similar to the following: php

Note that the code element is interpreted but the language which is a parameter in it is not. it's like the parser gets the by:

That way our old code tags are rendered properly and not processed by Geshi. Just wondering if that could become a new setting like:

Thanks for the great extension, anyway! Ciao :-) Stronk7 17:02, 8 August 2008 (UTC)


 * This one will keep default code behaviour if the code hasn't a special tag and is inline (no linebreaks)
 * }
 * --153.96.104.2 11:11, 27 April 2009 (UTC)
 * --153.96.104.2 11:11, 27 April 2009 (UTC)

pdf_embed
Conflicts with pdf_embed extension, taking over the syntax and formatting it without

According to PHP documentation the preg_match function has some issues with the replacement parameter being ambiguous. The following makes it a little clearer: