Last modified: 2006-05-27 08:25:48 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 T7077, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 5077 - Hook for inserting custom CSS missing / inserted CSS lost on later view
Hook for inserting custom CSS missing / inserted CSS lost on later view
Product: MediaWiki
Classification: Unclassified
Parser (Other open bugs)
All All
: Normal normal (vote)
: ---
Assigned To: Nobody - You can work on this!
Depends on:
  Show dependency treegraph
Reported: 2006-02-24 17:08 UTC by Markus Krötzsch
Modified: 2006-05-27 08:25 UTC (History)
0 users

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


Description Markus Krötzsch 2006-02-24 17:08:40 UTC
The suggested way of adding custom CSS and scripts for a MediaWiki extension is
via $wgOut->addLink and $wgOut->addScript. However, even if extensions call
these functions during parsing (so that everything appears in the header as
expected), these modifications are (of course) not stored within the database.
Hence, when the article is viewed at a later stage, the headers are missing
again whenever the parsing hooks are not triggered.

The problem is that there is no hook "InitializeOutputPage" (or whatwever) where
extensions can add standard scripts and CSS. This hook would also be useful as a
clean way for performing all kinds of wgOut-customizations that apply to all
pages. It should be easy to fix the issue by providing such a hook.

The required code would probably be:


to be added in Setup.php after '$wgOut = new OutputPage();' No parameters should
be needed for he hook, since all relevant variables at this stage are global anyway.
Comment 1 Brion Vibber 2006-02-24 21:28:09 UTC
Parser hooks can only output HTML and other parser state information to the parser.
If it were desirable for parser hooks to be able to add page-wide CSS (which it perhaps 
isn't, since this would not be portable to other output styles) this would have to go 
into the ParserOutput object to be stored in the cache.
Comment 2 Markus Krötzsch 2006-02-24 22:48:09 UTC
(In reply to comment #1)

The rationale of having parser extensions add their own CSS/JScript is to make
small graphical or interface enhancements that do not jeopardize compatibility
with the various styles (to the extent that this can be guaranteed). For
example, one might want to have a link- or span-class that adds some small
icons, as is done in the geo-coordinate feature currently tested in Wikipedia. 

An alternative for this function might be to have a variable that allows
registering additional CSS, Scripts, or header metalinks within LocalSettings.
Maybe there is a way and I just do not know how to do it properly in the current
version ... but using wgOut->addLink currently seems to be no option for
extensions that try to live on hooks only.
Comment 3 Markus Krötzsch 2006-03-15 13:33:45 UTC
A better proposal for a solution which is also suitable for extensions that have
nothing to do with parsing (but still might want to modify certain header
elements for whatever reason):

Add a hook in OutputPage.php, right after "wfProfileIn( 'Output-skin' );" As
parameters, the hook should get the outputpage ($this), so that CSS/Scripts can
be added based on the status and title of the page.

This seems to be a sufficiently general and robust solution, and extensions
could easily add their header tags there without patching anything or modifying
the parser cache. Whereever the hook is placed, it is important that the
OutputPage's mIsArticle and mPagetitle are normally available at this stage.

Problem with the above position: this hook would sometimes be called more than
once during parsing

* Solution 1: add a bool member to OutputPage that records whether the hook was
already called. Do not call it more than once for one output. I am not sure
whether this might possibly conflict with the requirement that mPagetitle is set. 

* Solution 2: (maybe cleaner) add a duplicate elimination to OutputPage
functions "addScript", "addLink", "addMeta", ... This can e.g. be done by
generating PHP array keys from the added elements. Maybe add an optional
parameter to "ignore duplicates" to avoid performance impacts for the internal
calls to addFoo that are known not to generate duplicates.

* Solution 3: do nothing and leave it to the extensions to record what they have
already added in a certain run.
Comment 4 JeLuF 2006-05-27 08:25:48 UTC
Fixed in r14420 (1.7 alpha)

Add this to SemanticMediaWiki/includes/SMW_Settings.php:

$wgHooks['BeforePageDisplay'][] = 'SMWBeforePageDisplayHook';

function SMWBeforePageDisplayHook( $out ) {
        smwfAddHTMLHeader( &$out );

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