Re: [Tiki-devel] Parsing regression in 7.1 (was Presumed parsing regression in 7.1)

[Louis-Philippe H. <lph...@lp...>]

The parser-level fix was needed because without it, HTML could go straight
through depending how plugins were wrapped around. It did change the input
to the plugins and some plugins did strange stuff to deal with various
situations. I fixed the issues I found. There was a major change in 7.x in
the way the parser is handled. The outer plugins are executed before,
allowing GROUP and other conditional plugins to really act as conditionals
rather than make-up acting after the fact.

I made the parser changes in the very first weeks after 6.x was branched off
and warned there would be consequences. Sadly, no one really tested until
7.x was branched off and some issues will never be fixed as part of 7
because it's simply too late. Yes, plugins have to be changed. This is no
news.

Going back pre-r34172 would introduce security issues.

--
LP

On Wed, Jul 27, 2011 at 5:02 PM, Filipus Klutiero <ch...@gm...> wrote:

> I was able to reproduce the problem on the Development page on my
> website, and to reduce it to the following test case:
>
> > {SPLIT()}
> > ---
> > {DIV()}The development of Tiki Wiki CMS Groupware is done in a
> > collaborative fashion by a friendly community of several hundred
> > contributors.
> > {DIV}
> > {SPLIT}
> (That is a DIV plugin with one newline embedded in a SPLIT plugin as its
> second column, the first one being empty.)
>
> I also reproduced the CODE plugin issue and reduced it to the following
> test case:
> > {CODE(colors="php")}>{CODE}
>
> I bisected and identified r34998 as the source of the regression:
> > [FIX] Plugin body not escaped properly due to misnamed variable
> Now, r34998 is really a fix, and merely exposes a regression introduced
> in r34172 "[FIX] Tabs plugin would not handle HTML correctly because of
> multiple parse passes, fixing mishandling of html decode in plugin
> execute".
>
> So, we had a bug pre-r34172, a commit that moves the problem, and
> another post-7.0 commit that moves the problem again. Unless someone is
> willing to dig into parsing and properly fix this (that definitely won't
> be me), we have to choose between bugs. It's difficult to choose as I'm
> not sure of the details of each problem, but I would go with either the
> current situation (regression from 7.0), or the original situation
> pre-r34172.
>
> On 2011-07-23 02:07, Filipus Klutiero wrote:
> > These are newlines inside DIV plugins, each DIV plugin being inside
> > another DIV plugin, and all the outside DIV plugins being embedded in
> > a SPLIT plugin.
> >
> > On 2011-07-23 01:52, Marc Laporte wrote:
> >> Also, some<br />  tags are showing here:
> >> http://dev.tiki.org/Development
> >>
> >>
> >>
> >> On Fri, Jul 22, 2011 at 5:05 PM, Marc Laporte<ma...@ma...>
> >> wrote:
> >>> spooky!
> >>>
> >>> On 2011-07-22 2:43 PM, "Filipus Klutiero"<ch...@gm...>  wrote:
> >>>
> >>> On 2011-07-21 21:43, lindon wrote:
> >>>> Plugin Code is showing&lt; instead of<  and&gt; instead of ...
> >>> I can't reproduce this, either on my local 7.x at r35599 or on demo
> >>> (test on
> >>> http://demo.tiki.org/7x/HomePage ), but dev is showing the problem on
> >>> r35579, so there's an unknown variable.
> >
>
>
>
> ------------------------------------------------------------------------------
> Got Input?   Slashdot Needs You.
> Take our quick survey online.  Come on, we don't ask for help often.
> Plus, you'll get a chance to win $100 to spend on ThinkGeek.
> http://p.sf.net/sfu/slashdot-survey
> _______________________________________________
> TikiWiki-devel mailing list
> Tik...@li...
> https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel
>