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