Greetings,
I've got a simple Extension that expands an {{#include}} parser function into random text. It works well for most things, but if I try to stick in a new heading, includes/Preprocessor_DOM.php::expand() fails on this...
$titleText = $this->title->getPrefixedDBkey();
because "$this" (a PPFrame_DOM) does not have a title object. As a temporary band-aid, I inserted this into Preprocessor_DOM.php:
if(! $this->title) $this->title = Title::newFromText("XXX");
But is there a way to fix this from within the extension? Code attached, it's pretty trivial.
While I'm at it, for extra credit, is there a way to determine the equivalent of expand's $expansionDepth (== how deep in the transclusions we are) from within an extension?
Cheers, -jani
Jani Patokallio wrote:
I've got a simple Extension that expands an {{#include}} parser function into random text. It works well for most things, but if I try to stick in a new heading, includes/Preprocessor_DOM.php::expand() fails on this...
$titleText = $this->title->getPrefixedDBkey();
because "$this" (a PPFrame_DOM) does not have a title object. As a temporary band-aid, I inserted this into Preprocessor_DOM.php:
There's always $wgTitle. I'm not sure (without actually looking into it) if that's the cleanest solution, but enough things in MediaWiki rely on that global that you can pretty much assume that it'll always be set to something reasonably meaningful.
Ilmari Karonen wrote:
Jani Patokallio wrote:
I've got a simple Extension that expands an {{#include}} parser function into random text. It works well for most things, but if I try to stick in a new heading, includes/Preprocessor_DOM.php::expand() fails on this...
$titleText = $this->title->getPrefixedDBkey();
because "$this" (a PPFrame_DOM) does not have a title object. As a temporary band-aid, I inserted this into Preprocessor_DOM.php:
There's always $wgTitle. I'm not sure (without actually looking into it) if that's the cleanest solution, but enough things in MediaWiki rely on that global that you can pretty much assume that it'll always be set to something reasonably meaningful.
...eh, sorry, I didn't read your message carefully enough and just assumed that it was your own code that couldn't find the title rather than the parser preprocessor. Should've finished that cup of coffee first. :)
Anyway, I still haven't looked at the code and thus can't offer any concrete advice, but, presumably, if the code expects the PPFrame_DOM object to have a "title" property then you should try to figure out why it doesn't and how to provide it with one. Maybe look at how the parser itself handles it for things like template transclusion.
(Oh, just realized that that's probably where the problem is. The code that generates section edit links must be using that "title" property to decide which page to point the links to, and thus expects whomever is providing the content to parse to set it to something meaningful. If you're outputting headings that don't come from editable wikitext at all, and therefore have no meaningful title to provide, then you need to find out how to disable the section edit links for those headings entirely. Or just kluge it with HTML headings instead.)
Thanks for the response!
Ilmari Karonen wrote:
(Oh, just realized that that's probably where the problem is. The code that generates section edit links must be using that "title" property to decide which page to point the links to, and thus expects whomever is providing the content to parse to set it to something meaningful. If you're outputting headings that don't come from editable wikitext at all, and therefore have no meaningful title to provide, then you need to find out how to disable the section edit links for those headings entirely. Or just kluge it with HTML headings instead.)
Yeah, I figure this is the issue. However, since we *are* including other articles and creating headings for them, it would be great if the edit link did actually point to the included article. I'm just baffled by how I can insert that title object, since the markup I'm outputting to the parser is simply:
==Title== {{:article}}
Cheers, -jani
Jani Patokallio wrote:
Greetings,
I've got a simple Extension that expands an {{#include}} parser function into random text. It works well for most things, but if I try to stick in a new heading, includes/Preprocessor_DOM.php::expand() fails on this...
$titleText = $this->title->getPrefixedDBkey();
because "$this" (a PPFrame_DOM) does not have a title object. As a temporary band-aid, I inserted this into Preprocessor_DOM.php:
if(! $this->title) $this->title = Title::newFromText("XXX");
But is there a way to fix this from within the extension? Code attached, it's pretty trivial.
The code is not attached, presumably it was stripped out by Mailman. Can you provide a link?
In any case, it's likely that you're not entering the parser correctly. It should only be entered via one of the five entry points documented at the top of Parser.php: parse(), preSaveTransform(), preprocess(), cleanSig() and extractSections().
While I'm at it, for extra credit, is there a way to determine the equivalent of expand's $expansionDepth (== how deep in the transclusions we are) from within an extension?
There's no way to determine the expansion depth. Note that it's heavily dependent on the implementation details, with various tricks being used to expand certain kinds of trees without recursion. So it doesn't have much to do with the syntax if that's what you're looking for.
Maybe you just don't get what it is. This has an expansion depth of 3 but a frame depth of 0:
{{#if: {{#if: {{#if: x | y | z }} }} }}
If you had this:
[[Page]]: {{A}} [[Template:A]]: {{B}} [[Template:B]]: {{C}} [[Template:C]]: foo
then expanding [[Page]] would give you an expansion depth of 3 at "foo", and also a frame depth of 3.
-- Tim Starling
Greetings,
Thanks for the response!
In any case, it's likely that you're not entering the parser correctly. It should only be entered via one of the five entry points documented at the top of Parser.php: parse(), preSaveTransform(), preprocess(), cleanSig() and extractSections().
It's not entering the parser directly at all, the extension is just a function hook that returns:
return array($output, 'noparse' => false);
...and MW itself then sends the $output to the parser.
Anyway, since the failing code was within the section edit link generator, I figured the easiest way out was just to not generate section edit links for nodes that lack $this->title.
Maybe you just don't get what it is. This has an expansion depth of 3 but a frame depth of 0:
{{#if: {{#if: {{#if: x | y | z }} }} }}
If you had this:
[[Page]]: {{A}} [[Template:A]]: {{B}} [[Template:B]]: {{C}} [[Template:C]]: foo
then expanding [[Page]] would give you an expansion depth of 3 at "foo", and also a frame depth of 3.
That's fine -- we're importing structured content, so the #includes will be generated programmatically. As long as the recursive case (#2) works, and it does, we don't need to worry about the nested case (#1).
So the question remains: since the parser knows the expansion depth at any given point in time, can I check that depth from/expose that depth to the extension?
Cheers, -jani
wikitech-l@lists.wikimedia.org