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 ::::