In case anyone's interested, I've figured out how to keep the parser
from breaking lists when used from the Tasks extension.
Parser apparently conditionally inserts a "<p>" tag and an HTML
comment with usage statistics under certain circumstances. I located
this in Parser.php and determined that I could stop it from doing so
via:
$parser->mOptions->enableLimitReport(false);
It seems to me to be a bug that the parser inserts an unexpected "<p>"
tag, at least when invoked from an extension via "$parser->parse(...)"
even if there is good reason to write usage stats out in an HTML
comment. Should I report this as a bug?
I also wrote the owner-of-record for the Tasks extension, but received
no reply. Is there some preferred way of getting this change into the
distributed Tasks.php file, so others can embed tasks in lists without
screwing up the list formatting?
Finally, in further hacking Tasks.php, I am finding it difficult to
understand when "$wgHooks['ArticleSaveComplete'][]" is called.
The changes I have made are somehow keeping the extension's database
table from being updated upon save, which happens in the function
called by the hook (saveTasks). I've put a "print_r(...)" trace in
there, and it doesn't seem to be getting called when saving an article
containing "<tasks>...</tasks>"
Are there any particular tricks needed to make sure
$wgHooks['ArticleSaveComplete'][] happens?
Thanks for any thoughts or help!
On 24 May 09, at 16:52, Jan Steinman wrote:
> We've been using the great Tasks Extension to put lite (extremely
> lite) project management in our wiki.
>
> Unfortunately, where we '''really''' want to use <tasks> is within
> lists, which is how we format meeting minutes, which is where action
> items are assigned, formatted individually as <tasks>...</tasks>.
>
> Tasks are run through the parser, which apparently is putting extra
> line breaks in, which then messes up the list formatting. You can
> see a good example here:
> http://www.ecoreality.org/wiki/Minutes:20090503
>
> If you scroll down to the 2nd, 3rd, and 4th bold ACTION text, you
> can see that they are embedded in a level-2 bullet list, but that
> they are causing the list to be re-set with an extra line feed.
>
> I know it's the parser that's doing this, as I can edit extensions/
> Tasks.php and replace "$parserOutput->getText()" with "$summary",
> which is what is being sent through the parser. In such a case, the
> $summary is not parsed, and the bullet list looks like it is
> supposed to.
>
> I have a copy of Tasks.php (modified to do agreements, rather than
> tasks) that you can see behaving in this non-parsed manner, in our
> Sandbox:
> http://www.ecoreality.org/wiki/Sandbox
>
> I've looked at ParserOptions, hoping to find something like
> $mDontAddExtraLinefeeds but to no avail. :-)
>
> If I replace parse($summary...) with the private method
> replaceInternalLinks($summary), it looks like it is supposed to,
> except of course that wikitext formatting and internal links are
> lost. (And I don't really want to be sending private methods nor
> hacking around in Parser.)
>
> Any thoughts on what's going on, and how best to fix it?
>
> Thanks for whatever advice you can offer!
>
> :::: Magic: using envisioned intent and directed action to select
> your desired future path from among the infinite ones available. ::::
> :::: Jan Steinman, Communication Steward, EcoReality:
> http://www.EcoReality.org
> ::::
>
>
>
:::: After years of disclosures by government investigations, media
accounts, and reports from human rights organizations, there is no
longer any doubt as to whether the current administration has
committed war crimes. The only question is whether those who ordered
the use of torture will be held to account. -- US Army Major General
(Retired) Antonio Taguba about Abu Ghraib ::::
:::: Jan Steinman http://www.Bytesmiths.com ::::
_______________________________________________
MediaWiki-l mailing list
[email protected]
https://lists.wikimedia.org/mailman/listinfo/mediawiki-l
