Last modified: 2013-07-25 07:08:11 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T46214, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 44214 - The extension doesn't succeed to include the bundled geshi library when a geshi folder is available in the path
The extension doesn't succeed to include the bundled geshi library when a ges...
Status: RESOLVED FIXED
Product: MediaWiki extensions
Classification: Unclassified
SyntaxHighlight (GeSHi) (Other open bugs)
master
All All
: Low critical (vote)
: ---
Assigned To: Dereckson
: code-update-regression
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2013-01-21 18:24 UTC by Dereckson
Modified: 2013-07-25 07:08 UTC (History)
2 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description Dereckson 2013-01-21 18:24:48 UTC
[ PHP error ]

Fatal error: Call to undefined method GeSHi::enable_keyword_links() in /path/to/wiki/extensions/SyntaxHighlight_GeSHi/SyntaxHighlight_GeSHi.class.php on line 278


[ Bug analysis ]

The extension tries to include the local GeSHi library, if it's not already included in the configuration:
        /**
         * Initialise messages and ensure the GeSHi class is loaded
         * @return bool
         */
        private static function initialise() {
                if( !self::$initialised ) {
                        if( !class_exists( 'GeSHi' ) ) {
                                require( 'geshi/geshi.php' );
                        }
                        self::$initialised = true;
                }
                return true;
        }

I've a strange scenario where this doesn't work anymore[*]: when a up to date GeSHi library is available in include_path, it will try to include it instead of the 

[*] It worked before: I installed a wiki in May 2010 in this same environment with extensive usage of GeSHi (which is coherent with git blame output, it seems this line is from 2010-08-09).


[ Steps to reproduce ]

(1) Install the last GeSHi version in a library accessible in include_path

(2) Install the extension

(3) Edit a page and add a source block, then preview it.


[ Note about include_path ]

PHP include_path ordering isn't relevant here: you can have like .:/usr/local/share/pear:/var/wwwroot/.libs, but that won't help: in this context, . is the MediaWiki core, not the extension one.


[ Side issue. We should always include our copy of the library. ]

This last year, we accepted two code divergences between our bundled GeSHi library and the version upstream to fix bugs. Furthermore, we use a slowly upstream maintained and legacy version, not the last one.

I don't see any rationale to document "Install your copy of GeSHi elsewhere".


[ Suggested fix ]

(1) Code -> require( __DIR__ . '/geshi/geshi.php' );

(2) Documentation -> ask to include GeSHi code in the extension in LocalSettings before the extension instead to edit the extension code with custom path


[ Alternative solution ]

If we really want to go on with this situation where we let people install elsewhere GeSHi, we have a performance problem: my suggested fix will include GeSHi for every page, including for requests not needing the GeSHi library.

We could also in this case create a wgGeshiPath setting, with a null value, include __DIR__ . '/geshi/geshi.php' when it's null, $wgGeshiPath /geshi.php otherwise.
Comment 1 Dereckson 2013-01-21 18:25:07 UTC
[ Taking this bug ]
Comment 2 Dereckson 2013-01-21 18:28:33 UTC
To be compatible with PHP 5.2, I won't use __DIR__ in my fix.
Comment 3 Dereckson 2013-01-21 18:37:54 UTC
Gerrit change #44992.
Comment 4 Andre Klapper 2013-07-22 17:02:50 UTC
Patch got merged on March 06th. Assuming this is fixed.

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links