Moin,
as an extension developer I'd like to have two new features. I looked at the doc, the code the FAQ etc but I couldn't find out if it is not already possible to achive that:
* addCSS();
You can call from your extension things like addMeta(), addHeader() etc, including addStyleSheet(), which adds a link to a stylesheet to the page. However, forvarious reaons and extensions adding CSS code into the head ala:
addCSS('YourCodeHere') would result in:
<style type="text/css"> <!-- YourCdeHere --></style>
Is this already possible and did I just overlook it? If not, could it be implemented? (Adding a link to a stylesheet requires external files, which is messy and leaks files,see my other post "File leakage in extensions")
Likewise, I would like something along the lines of:
__NOCATEGORIES__ (or __NOCAT__ __NOMENU__ __NOTOOLBOX__ __NOSEARCH__ __NOFOOTER__
that supress the various elements of the interface. (This is for a slide extension, that allows one to give presentations from a wiki diectly). Now, with the addCSS() from above that could be hacked (if you know which skin to use, and add an extenion to each slide article, but the special variables would be much cleaner and they would also allow these things to be used on other pages w/o an extension.
For wikipedia, they should be probably disabled, but this can be achieved via a technical solution (config var, or spamblicking etc).
What do I need to get these things into the current code?
Best wishes,
Tels
On Friday 07 April 2006 10:53, Tels wrote:
Moin,
as an extension developer I'd like to have two new features. I looked at the doc, the code the FAQ etc but I couldn't find out if it is not already possible to achive that:
- addCSS();
You can call from your extension things like addMeta(), addHeader() etc, including addStyleSheet(), which adds a link to a stylesheet to the page. However, forvarious reaons and extensions adding CSS code into the head ala:
addCSS('YourCodeHere') would result in:
<style type="text/css"> <!-- YourCdeHere --></style>
Is this already possible and did I just overlook it? If not, could it be implemented? (Adding a link to a stylesheet requires external files, which is messy and leaks files,see my other post "File leakage in extensions")
I don't know about this, since I am fine with addStyleSheet. Another problem, however, is *where* to call this method in an extension. If, e.g., you have a tiny parser extension that adds some new elements to each article-output during parsing, then you want all articles to have your new CSS. However, articles are often produced from the parser cache, which does not include the headers. Thus your code for adding CSS is typically not exectued on each view, but the CSS is not recovered from the cache either.
I don't know whether 1.6 provides new hooks for adding CSS and similar header stuff in extensions. AFAIK, the only way to get CSS into every page in 1.5 was to patch Ouptupage.php or something similar ...
See http://bugzilla.wikimedia.org/show_bug.cgi?id=5077
Best regards,
Markus
Tels wrote:
as an extension developer I'd like to have two new features. I looked at the doc, the code the FAQ etc but I couldn't find out if it is not already possible to achive that:
$wgOut->addScript( "<style>....</style>" );
Note that this applies only to the current HTTP invocation. At this time there's not a clean way to attach headers or external style sheets to a *parser hook* extension other than adding it to every page invocation in your setup function.
Likewise, I would like something along the lines of:
__NOCATEGORIES__ (or __NOCAT__ __NOMENU__ __NOTOOLBOX__ __NOSEARCH__ __NOFOOTER__
Vandals would love this! However it would not be generally useful on a wiki, so I'd recommend against.
(You could make a custom skin which works this way.)
-- brion vibber (brion @ pobox.com)
Moin,
On Friday 07 April 2006 19:05, Brion Vibber wrote:
Tels wrote:
as an extension developer I'd like to have two new features. I looked at the doc, the code the FAQ etc but I couldn't find out if it is not already possible to achive that:
$wgOut->addScript( "<style>....</style>" );
Ah cool, thanx.
Note that this applies only to the current HTTP invocation. At this time there's not a clean way to attach headers or external style sheets to a *parser hook* extension other than adding it to every page invocation in your setup function.
I am a bit confused about this comment:
Here is a snippet from DynamicPageList2:
// The callback function for converting the input text to HTML output function DynamicPageList2( $input ) { ... global $wgTitle; global $wgOut; $ts = mktime(); $now = gmdate("YmdHis", $ts + 60); $ns = $wgTitle->getNamespace(); $ti = wfStrencode($wgTitle->getDBkey()); ... [snip] $wgOut->addMeta("http:Pragma", "no-cache"); ...
When I add $wgOut->addScript( "<style>....</style>" ); here, would that add the style to every page in the wiki, or only pages that have a <DPL> tag on it (which triggers that extension).
The later would be just what I want :)
As for the cache, I don't intent to do the "no-cache" etc, so, if I added AddScript(), would the added style get cached or would it disappear when someone views a cached copy?
(Ok, ok, i just might it try instead of buggering you :)
Thanx a lot!
Likewise, I would like something along the lines of:
__NOCATEGORIES__ (or __NOCAT__ __NOMENU__ __NOTOOLBOX__ __NOSEARCH__ __NOFOOTER__
Vandals would love this!
That's why I said it is probably not usefull for wikipedia. However, on small or closed wikis, it would be incredible usefull for some pages.
However it would not be generally useful on a wiki, so I'd recommend against.
Er, it would be on mine :) Just think about: "setup a small test wikion a laptoo, take it to a conference, make a presentation." There is no vandalism to worry about, because you (and maybe your coworkers) are the only one allowed to edit it.
(You could make a custom skin which works this way.)
But that would change all pages. What I want to achive is that everypage is normal, even the first page of a presentation (the table of contents), and when you switch to the second one, only the navigation box remains and the menu etc disappears, making more space available for the actula slide.
Sure, one could switch skins forth and back, but thats very awkward.
If the CSS trick works, one could achive this with CSS and an extension, probably.
best wishes,
tels
Tels wrote:
Here is a snippet from DynamicPageList2:
// The callback function for converting the input text to HTML output function DynamicPageList2( $input ) { ...
[snip]
$wgOut->addMeta("http:Pragma", "no-cache"); ...
When I add $wgOut->addScript( "<style>....</style>" ); here, would that add the style to every page in the wiki, or only pages that have a <DPL> tag on it (which triggers that extension).
That would only add the style when the <dpl> tag gets parsed and rendered; it looks like a bug in the extension code.
It would, for instance, *not* add the style when the page containing the tag is shown if the HTML is pulled from the parser cache (as it would be, most of the time.)
As for the cache, I don't intent to do the "no-cache" etc, so, if I added AddScript(), would the added style get cached or would it disappear when someone views a cached copy?
It would disappear.
(You could make a custom skin which works this way.)
But that would change all pages. What I want to achive is that everypage is normal, even the first page of a presentation (the table of contents), and when you switch to the second one, only the navigation box remains and the menu etc disappears, making more space available for the actula slide.
Let me be more specific. :) You could make a custom skin which responds to the custom signals you add in your extension.
-- brion vibber (brion @ pobox.com)
Moin,
On Friday 07 April 2006 21:26, Brion Vibber wrote:
Tels wrote:
Here is a snippet from DynamicPageList2: // The callback function for converting the input text to HTML output function DynamicPageList2( $input ) { ...
[snip]
$wgOut->addMeta("http:Pragma", "no-cache"); ...
When I add $wgOut->addScript( "<style>....</style>" ); here, would that add the style to every page in the wiki, or only pages that have a <DPL> tag on it (which triggers that extension).
That would only add the style when the <dpl> tag gets parsed and rendered; it looks like a bug in the extension code.
It would, for instance, *not* add the style when the page containing the tag is shown if the HTML is pulled from the parser cache (as it would be, most of the time.)
Ah. That really smells like a bug.
[snip]
(You could make a custom skin which works this way.)
But that would change all pages. What I want to achive is that everypage is normal, even the first page of a presentation (the table of contents), and when you switch to the second one, only the navigation box remains and the menu etc disappears, making more space available for the actula slide.
Let me be more specific. :) You could make a custom skin which responds to the custom signals you add in your extension.
Ah. Thanx. I wil toy around and see how to get it best working,
Tels
Tels wrote:
Here is a snippet from DynamicPageList2:
// The callback function for converting the input text to HTML output function DynamicPageList2( $input ) { ... global $wgTitle; global $wgOut; $ts = mktime(); $now = gmdate("YmdHis", $ts + 60); $ns = $wgTitle->getNamespace(); $ti = wfStrencode($wgTitle->getDBkey()); ... [snip] $wgOut->addMeta("http:Pragma", "no-cache"); ...
Please don't use $wgTitle in parser hook functions, it will break the job queue, and anything else that wants to parse more than one article. runJobs.php is set up to die with a backtrace if anyone attempts it. Instead, take a parser object as the third parameter, and use the $parser->mTitle member variable. Like this:
function DynamicPageList2( $input, $params, &$parser ) { ... $ns = $parser->mTitle->getNamespace(); ...
As Brion points out, using $wgOut won't work either, because data sent to $wgOut won't be saved in the parser cache. That's why all data generated in parser hooks needs to find its way into the ParserOutput object. Put an array of head items there, have the parser hook add one, maybe via an accessor in Parser. Then have OutputPage copy those items to itself in OutputPage::addParserOutputNoText(). Then it will all work with the parser cache.
-- Tim Staring
Moin,
On Saturday 08 April 2006 06:49, Tim Starling wrote:
Tels wrote:
Here is a snippet from DynamicPageList2:
// The callback function for converting the input text to HTML output function DynamicPageList2( $input ) { ... global $wgTitle; global $wgOut; $ts = mktime(); $now = gmdate("YmdHis", $ts + 60); $ns = $wgTitle->getNamespace(); $ti = wfStrencode($wgTitle->getDBkey()); ... [snip] $wgOut->addMeta("http:Pragma", "no-cache"); ...
Please don't use $wgTitle in parser hook functions, it will break the job queue, and anything else that wants to parse more than one article. runJobs.php is set up to die with a backtrace if anyone attempts it. Instead, take a parser object as the third parameter, and use the $parser->mTitle member variable. Like this:
function DynamicPageList2( $input, $params, &$parser ) { ... $ns = $parser->mTitle->getNamespace(); ...
As Brion points out, using $wgOut won't work either, because data sent to $wgOut won't be saved in the parser cache. That's why all data generated in parser hooks needs to find its way into the ParserOutput object. Put an array of head items there, have the parser hook add one, maybe via an accessor in Parser. Then have OutputPage copy those items to itself in OutputPage::addParserOutputNoText(). Then it will all work with the parser cache.
Could you give some short example of how that would be written? Also does this need 1.6 or would it work with 1.5.x too?
I intend to write a FAQ about all this later, and toy around with it. That is certainly underdocumented and thus done wrong by some extensions. :)
Thanx for the time and explanations,
Tels
Moin,
On Saturday 08 April 2006 12:09, Tels wrote:
Moin, On Saturday 08 April 2006 06:49, Tim Starling wrote:
Tels wrote:
[snip]
function DynamicPageList2( $input, $params, &$parser ) { ... $ns = $parser->mTitle->getNamespace(); ...
Very cool. I toyed around with that, and having access to the Parser is really nice. :-)
However, in 1.5.x, the third param is not actually passed in when calling the callbacks, so I had to patch the source (itÄs a one-line patch, and quite safe). Haven't checked, but I assume that in 1.6 this works "out-of-the-box".
In addition, I found no documentation on what you can all do with the Parser object. There is some autogenerated API doc, but this covers only methods. And mTitle is a member variable, and these seem not to be listed on SF. Is there a doc which would help someone using the Parser in an extension?
Another unrelated question, would this code work on 1.5 and 1.6 alike and would there be any gotcha!'s with it: (Yes, I could test it, but I would still not be knowing if this is considered "safe" :-)
function MyExtension( $input, $params ) { global $wgParser; ... $ns = $wgParser->mTitle->getNamespace(); ...
As for the original problem with the style-sheets, my current solution is to emit the <style> tags in mid-HTML. Ugly, but it works, opposed to the other proposed solutions to get it into the header.
What I haven't found out yet is how/why a custom skin would allow me to switch off the menu (more easily, that is). AFAIK you need something along the lines
<style type="text/css">#p-navigation { display: none; }</style>
and having a custom skin (where menubox is named, oh, mymenubox or something) wouldn't actually change anything except the class name. But maybe I am just very stupid today :)
I am currently beta-testing and documention my slide extension, should hit CPAN later this week. Thanx alot for your patience and time!
Best wishes,
Tels
On 4/8/06, Tels nospam-abuse@bloodgate.com wrote:
(Ok, ok, i just might it try instead of buggering you :)
The devs do tend to be more productive when they aren't being sodomised :)
-- Stephen Bain stephen.bain@gmail.com
On Sun, Apr 09, 2006 at 09:03:28AM +1000, Stephen Bain wrote:
On 4/8/06, Tels nospam-abuse@bloodgate.com wrote:
(Ok, ok, i just might it try instead of buggering you :)
The devs do tend to be more productive when they aren't being sodomised :)
Well, in *my* experience of open source developers over 20 years, some of them *like* it. :-)
Cheers, -- jra
wikitech-l@lists.wikimedia.org