Loading...
 

Tikiwiki-devel (mailman list mirror)


[Tikiwiki-cvs/svn] SF.net SVN: tikiwiki:[67949] branches/19.x/lib/core/WikiParser/ Parsable.php

Hi luciash,

>De : luciash mailto:luci@tiki.org
>Envoyé : 12 octobre 2018 10:53
>
>Imho it should be parsing all together. If it is included page or not should be taken care of by the Footnote/Footnotearea plugin itself (like by introducing specific ID references so the footnote in included page is not referenced in footnotearea of the parent page unless it is specifically asked to do so by a new param or so)...


I'm skeptical, but I would appreciate example source to better understand your suggestion.

>luci
>
>
>On 12.10.2018 16:13, Victor Emanouilov wrote:
>> Yes, I agree. We should probably choose one way, standardize and use
>> it instead of switching behavior back and forth.
>>
>>
>> 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-a
>>>> nymore-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
https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel

There is no example source. It has to be coded.

luci


On 12.10.2018 17:01, Cloutier, Philippe (DGARI-Consultant) wrote:
> Hi luciash,
>
>> De : luciash mailto:luci@tiki.org
>> Envoyé : 12 octobre 2018 10:53
>>
>> Imho it should be parsing all together. If it is included page or not should be taken care of by the Footnote/Footnotearea plugin itself (like by introducing specific ID references so the footnote in included page is not referenced in footnotearea of the parent page unless it is specifically asked to do so by a new param or so)...
>
> I'm skeptical, but I would appreciate example source to better understand your suggestion.
>
>> luci
>>
>>
>> On 12.10.2018 16:13, Victor Emanouilov wrote:
>>> Yes, I agree. We should probably choose one way, standardize and use
>>> it instead of switching behavior back and forth.
>>>
>>>
>>> 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-a
>>>>> nymore-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
https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel

>De : luciash mailto:luci@tiki.org
>Envoyé : 12 octobre 2018 11:49
>
>There is no example source. It has to be coded.


I meant what the wiki page code could be and the Tiki syntax of the including object.

>luci
>
>
>On 12.10.2018 17:01, Cloutier, Philippe (DGARI-Consultant) wrote:
>> Hi luciash,
>>
>>> De : luciash mailto:luci@tiki.org
>>> Envoyé : 12 octobre 2018 10:53
>>>
>>> Imho it should be parsing all together. If it is included page or not should be taken care of by the Footnote/Footnotearea plugin itself (like by introducing specific ID references so the footnote in included page is not referenced in footnotearea of the parent page unless it is specifically asked to do so by a new param or so)...
>>
>> I'm skeptical, but I would appreciate example source to better understand your suggestion.
>>
>>> luci
>>>
>>>
>>> On 12.10.2018 16:13, Victor Emanouilov wrote:
>>>> Yes, I agree. We should probably choose one way, standardize and use
>>>> it instead of switching behavior back and forth.
>>>>
>>>>
>>>> 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
>>>>>> -a nymore-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
https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel

Could be \{footnotearea incfootnotes=y ...\} or something?

So when the footnote from the ncluded page has
id="ref_footnote1-page_3688" generated on page with <html id="page_3689"
...> it will be included in the footnotearea on that page despite having
different page id.

Otherwise it would not be included.

luci


On 12.10.2018 17:51, Cloutier, Philippe (DGARI-Consultant) wrote:
>> De : luciash mailto:luci@tiki.org
>> Envoyé : 12 octobre 2018 11:49
>>
>> There is no example source. It has to be coded.
>
> I meant what the wiki page code could be and the Tiki syntax of the including object.
>
>> luci
>>
>>
>> On 12.10.2018 17:01, Cloutier, Philippe (DGARI-Consultant) wrote:
>>> Hi luciash,
>>>
>>>> De : luciash mailto:luci@tiki.org
>>>> Envoyé : 12 octobre 2018 10:53
>>>>
>>>> Imho it should be parsing all together. If it is included page or not should be taken care of by the Footnote/Footnotearea plugin itself (like by introducing specific ID references so the footnote in included page is not referenced in footnotearea of the parent page unless it is specifically asked to do so by a new param or so)...
>>> I'm skeptical, but I would appreciate example source to better understand your suggestion.
>>>
>>>> luci
>>>>
>>>>
>>>> On 12.10.2018 16:13, Victor Emanouilov wrote:
>>>>> Yes, I agree. We should probably choose one way, standardize and use
>>>>> it instead of switching behavior back and forth.
>>>>>
>>>>>
>>>>> 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
>>>>>>> -a nymore-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
> https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel



___
TikiWiki-devel mailing list
TikiWiki-devel at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel

>De : luciash mailto:luci@tiki.org
>Envoyé : 12 octobre 2018 12:37
>
>Could be \{footnotearea incfootnotes=y ...\} or something?


Where "incfootnotes" would mean what?

>So when the footnote from the ncluded page has id="ref_footnote1-page_3688" generated on page with <html id="page_3689"
>...> it will be included in the footnotearea on that page despite having different page id.


<html id="page_3689" ...>? Do you mean the INCLUDE plugin would generate an iframe?

If not, I do not understand your suggestion. Perhaps it would be clearer with the full source of some including object and the full source of an included page.

>Otherwise it would not be included.
>
>luci
>
>
>On 12.10.2018 17:51, Cloutier, Philippe (DGARI-Consultant) wrote:
>>> De : luciash mailto:luci@tiki.org
>>> Envoyé : 12 octobre 2018 11:49
>>>
>>> There is no example source. It has to be coded.
>>
>> I meant what the wiki page code could be and the Tiki syntax of the including object.
>>
>>> luci
>>>
>>>
>>> On 12.10.2018 17:01, Cloutier, Philippe (DGARI-Consultant) wrote:
>>>> Hi luciash,
>>>>
>>>>> De : luciash mailto:luci@tiki.org Envoyé : 12 octobre 2018 10:53
>>>>>
>>>>> Imho it should be parsing all together. If it is included page or not should be taken care of by the Footnote/Footnotearea plugin itself (like by introducing specific ID references so the footnote in included page is not referenced in footnotearea of the parent page unless it is specifically asked to do so by a new param or so)...
>>>> I'm skeptical, but I would appreciate example source to better understand your suggestion.
>>>>
>>>>> luci
>>>>>
>>>>>
>>>>> On 12.10.2018 16:13, Victor Emanouilov wrote:
>>>>>> Yes, I agree. We should probably choose one way, standardize and
>>>>>> use it instead of switching behavior back and forth.
>>>>>>
>>>>>>
>>>>>> 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-pars
>>>>>>>> ed -a nymore-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
https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel



On 12.10.2018 19:40, Cloutier, Philippe (DGARI-Consultant) wrote:
>> De : luciash mailto:luci@tiki.org
>> Envoyé : 12 octobre 2018 12:37
>>
>> Could be \{footnotearea incfootnotes=y ...\} or something?
>
> Where "incfootnotes" would mean what?

short for includedpagefootnotes

>
>> So when the footnote from the ncluded page has id="ref_footnote1-page_3688" generated on page with <html id="page_3689"
>> ...> it will be included in the footnotearea on that page despite having different page id.
>
> <html id="page_3689" ...>? Do you mean the INCLUDE plugin would generate an iframe?

no, it was just an example the include plugin would get the id of the
page from the page it is including and it is actually visible there in
the html tag of each wiki page

>
>



___
TikiWiki-devel mailing list
TikiWiki-devel at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel

>De : luciash mailto:luci@tiki.org
>Envoyé : 12 octobre 2018 13:55
>
>On 12.10.2018 19:40, Cloutier, Philippe (DGARI-Consultant) wrote:
>>> De : luciash mailto:luci@tiki.org
>>> Envoyé : 12 octobre 2018 12:37
>>>
>>> Could be \{footnotearea incfootnotes=y ...\} or something?
>>
>> Where "incfootnotes" would mean what?
>
>short for includedpagefootnotes


I think we don't understand fully. I don't know about footnote areas (directly) in the including page, but my first concern is about calls to FOOTNOTEAREA in the included page.

>>> So when the footnote from the ncluded page has id="ref_footnote1-page_3688" generated on page with <html id="page_3689"
>>> ...> it will be included in the footnotearea on that page despite having different page id.
>>
>> <html id="page_3689" ...>? Do you mean the INCLUDE plugin would generate an iframe?
>
>no, it was just an example the include plugin would get the id of the page from the page it is including and it is actually visible there in the html tag of each wiki page

That id may be there when viewing the included page directly, but we're discussing inclusion here... sorry, I don't understand your point.

___
TikiWiki-devel mailing list
TikiWiki-devel at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel

Apparently. Sorry, then you need to figure it out yourself. Bye bye!

:-)


On 12.10.2018 20:21, Cloutier, Philippe (DGARI-Consultant) wrote:
>> De : luciash mailto:luci@tiki.org
>> Envoyé : 12 octobre 2018 13:55
>>
>> On 12.10.2018 19:40, Cloutier, Philippe (DGARI-Consultant) wrote:
>>>> De : luciash mailto:luci@tiki.org
>>>> Envoyé : 12 octobre 2018 12:37
>>>>
>>>> Could be \{footnotearea incfootnotes=y ...\} or something?
>>> Where "incfootnotes" would mean what?
>> short for includedpagefootnotes
>
> I think we don't understand fully. I don't know about footnote areas (directly) in the including page, but my first concern is about calls to FOOTNOTEAREA in the included page.
>
>>>> So when the footnote from the ncluded page has id="ref_footnote1-page_3688" generated on page with <html id="page_3689"
>>>> ...> it will be included in the footnotearea on that page despite having different page id.
>>> <html id="page_3689" ...>? Do you mean the INCLUDE plugin would generate an iframe?
>> no, it was just an example the include plugin would get the id of the page from the page it is including and it is actually visible there in the html tag of each wiki page
> That id may be there when viewing the included page directly, but we're discussing inclusion here... sorry, I don't understand your point.
>
> ___
> TikiWiki-devel mailing list
> TikiWiki-devel at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel



___
TikiWiki-devel mailing list
TikiWiki-devel at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel


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.