Tikiwiki-devel (mailman list mirror)

Inclusiveness challenges ( SF.net SVN: tikiwiki:[67949] branches/19.x/lib/core/WikiParser/ Parsable.php)

>De : Victor Emanouilov mailto:victor@tiki.org
>Envoyé : 12 octobre 2018 10:13
>Yes, I agree. We should probably choose one way, standardize and use it instead of switching behavior back and forth.

It's been a number of years since I used MediaWiki significantly and I never knew anything about implementation, but regarding the syntax, https://www.mediawiki.org/wiki/Transclusion shows that while MediaWiki may not have a parse_included_page parameter, there are complex features to manage inclusion, which may be considered as equivalents.

This is a difficult problem and looking at other engines may be a good idea. The only other engine which I know supports inclusion is MediaWiki, but then I don't know much about other engines besides MediaWiki and MoinMoin.

>On 10/11/2018 07:42 PM, Cloutier, Philippe (DGARI-Consultant) wrote:
>> Hi Victor,
>> Adding tikiwiki-cvs to recipients so this discussion is archived there too.
>>> De : Victor Emanouilov mailto:victor@tiki.org
>>> Envoyé : 11 octobre 2018 11:12
>>> Hi Devs (mostly Jonny and chealer),
>>> I stayed away from your discussion regarding commit 66644 but now I had to fix https://dev.tiki.org/item6850-Tiki-comments-wiki-syntax-not-parsed-anymore-on-https-nextdev-tiki-org-File-a-bug
>>> Decided to share my findings in case they help.
>>> In short, I agree with chealer that parse_included_page option in PluginInclude must not be needed. PluginInclude says its output is wiki format which makes it a bit confusing to have parsed content. I see that wrong behavior existing in certain Tiki versions and it is not easy to revert now, so I'd vote for the option to stay but warn people to stay away from it.
>>> I have went through a lot of the parserlib code connected with parsing a wiki page and executing plugins and see that once plugins are replaced with their output contents (like PluginInclude replaced by the target page wiki content), they are run through most of the parser logic. So, I don't see a reason why we should parse it first in PluginInclude and then again in the parser itself. The actual parsing must stay in the parser.
>>> The related bug I fixed is connected with some refactoring done between Tiki 15 and Tiki 18. I didn't research more but the comments parsing was moved before the plugin execution. It used to run after that, so plugin output comments were properly parsed in Tiki 15. I am sure someone had a good reason to move that - maybe comments did something wrong to other code in the parser. Anyway, I just added comment handling code once again after plugin execution runs. This makes sure plugin output comments are properly parsed. If you see any problems with the code, let me know.
>>> Regarding the parsing of included pages, I really think we should not do that. Including a wiki page and having the parser expect PluginInclude returns wiki while it returns parsed wiki does not feel right. If any specific functionality depends on that option and cannot run without it, we should revisit and do the proper fixes in the parser. I think it is too late now to change this for 19, but maybe 20. Jonny might have more reasoning behind this change, so I will let him elaborate more here when he has time. We are not in a hurry to make this happen for Tiki 19 now.
>> It's not an easy choice between the 2 approaches. Parsing everything together has its issues. For example, if you have contextual plugins like FOOTNOTEAREA and FOOTNOTE, the FOOTNOTEAREA could display something different depending on whether an included page is displayed directly or via inclusion.
>>> Regards,
>>> Victor
>>> On 10/11/2018 05:53 PM, kroky6--- via Tikiwiki-cvs wrote:
>>>> Revision: 67949
>>>> http://sourceforge.net/p/tikiwiki/code/67949
>>>> Author: kroky6
>>>> Date: 2018-10-11 14:53:25 +0000 (Thu, 11 Oct 2018)
>>>> Log Message:
>>>> -----------
>>>> FIX parser handling of Tiki comments: a regression between 15 and 19
>>>> resulted in comments being stripped before parsing plugin output and
>>>> thus comments in plugin output became visible to end user; this fix
>>>> parses comments a second time after plugins are parsed, so they are
>>>> handled correctly. An example is PluginInclude a wiki page with Tiki
>>>> comments in its body
>>>> Modified Paths:
>>>> --------------
>>>> branches/19.x/lib/core/WikiParser/Parsable.php
>>>> Modified: branches/19.x/lib/core/WikiParser/Parsable.php
>>>> =============
>>>> --- branches/19.x/lib/core/WikiParser/Parsable.php 2018-10-11 13:16:12 UTC (rev 67948)
>>>> +++ branches/19.x/lib/core/WikiParser/Parsable.php 2018-10-11 14:53:25 UTC (rev 67949)
>>>> @@ -260,6 +260,9 @@
>>>> // FIXME produces false positive for strings containing html comments. e.g: --some text<!-- comment -->
>>>> $data = preg_replace("#(?<!<!|//)--([^\s>].+?)--#",
>>>> "<strike>$1</strike>", $data);
>>>> + // Handle comments again in case parse_first method above returned wikiplugins with comments (e.g. PluginInclude a wiki page with comments)
>>>> + $data = preg_replace(';;s', '', $data);
>>>> +
>>>> // Handle html comment sections
>>>> $data = preg_replace(';;s', '<!-- $1 -->', $data);

TikiWiki-devel mailing list
TikiWiki-devel at lists.sourceforge.net

Why Register?

Register at tiki.org and you'll be able to use the account at any *.tiki.org site, thanks to the InterTiki feature. A valid email address is required to receive site notifications and occasional newsletters. You can opt out of these items at any time.