Quantcast

[Tiki-devel] Nested Plugins Break

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

[Tiki-devel] Nested Plugins Break

Brendan Ferguson
HI guys

Have had a issue on one of my sines, and have tracked down the issue to this bug report: https://dev.tiki.org/item4217?highlight=nested+plugins

I have also found the same bug responsible for this bug report https://dev.tiki.org/item5697?highlight=nested+plugins. I know we had a recent issue on tiki.org because of it.

I have already eliminated all styling plugins in favour of HTML in order to reduce the number of plugins to only that which can not be achieved through HTML.

In my case, the issue occurred in a secondary nested plugin, instead of the 167 plugins available, as reported in the bug report, one can only use about 32 second level nested plugins. There seems to be an exponential reduction in the number of plugins one can use for each nested level. It appears that the reason only 7 levels can be reached is because the number of plugins that can appear at each level is decreased in order of magnatude, this eventually working out to zero.

I found I could temporarily fix the issue by changing the 500 passes to 1000 in PluginMatcher.php. Obviously its not a great fix, but my pages dont appear broken any longer, but its not enough to fix the 7 level nesting issue.
if (++$passes > 500) {
return;
}
With a little experimentation, I found simply removing this check entirely works best. It allows me to use as my nested plugins as I want at any depts of nesting. Yes. It also fixes the 7-level nesting issue as well.

I presume it was put in place as an error check to prevent infant loop situations, but its a error check that is currently causing a whole lot of errors its self. 

Anyone have any insight into this?

Brendan




------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
TikiWiki-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [Tiki-devel] Nested Plugins Break

luciash d' being

Hi Brendan,

thanks for bringing this up again. IMHO as mentioned in one of the comments of the bug report I would vote for to make this optional (enabled by default) so site admins can switch it off or set their own number of passes maybe?

luci


On 03/31/2017 08:27 PM, Brendan Ferguson wrote:
HI guys

Have had a issue on one of my sines, and have tracked down the issue to this bug report: https://dev.tiki.org/item4217?highlight=nested+plugins

I have also found the same bug responsible for this bug report https://dev.tiki.org/item5697?highlight=nested+plugins. I know we had a recent issue on tiki.org because of it.

I have already eliminated all styling plugins in favour of HTML in order to reduce the number of plugins to only that which can not be achieved through HTML.

In my case, the issue occurred in a secondary nested plugin, instead of the 167 plugins available, as reported in the bug report, one can only use about 32 second level nested plugins. There seems to be an exponential reduction in the number of plugins one can use for each nested level. It appears that the reason only 7 levels can be reached is because the number of plugins that can appear at each level is decreased in order of magnatude, this eventually working out to zero.

I found I could temporarily fix the issue by changing the 500 passes to 1000 in PluginMatcher.php. Obviously its not a great fix, but my pages dont appear broken any longer, but its not enough to fix the 7 level nesting issue.
if (++$passes > 500) {
   return;
}
With a little experimentation, I found simply removing this check entirely works best. It allows me to use as my nested plugins as I want at any depts of nesting. Yes. It also fixes the 7-level nesting issue as well.

I presume it was put in place as an error check to prevent infant loop situations, but its a error check that is currently causing a whole lot of errors its self. 

Anyone have any insight into this?

Brendan





------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot


_______________________________________________
TikiWiki-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
TikiWiki-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [Tiki-devel] Nested Plugins Break

Brendan Ferguson
Ive tracked down to the bug introduced here: https://sourceforge.net/p/tikiwiki/code/33863/

hmm… Im wondering if that is overkill.

Without knowing under which circumstances this is utilized, its hard to say, but I have a few thoughts.

It appears as though the iterations are not being calculated properly. Finding a solution to that issue could fix this so it just works for everyone, instead of giving people the option to tinker with it.

It was meant to prevent “near-infanate” loops. So perhaps we should immediately increase the number to something like 5000. Its nowhere close to the 100’s of thousands of iterations that it was meant to prevent, but would provide a much greater array of legitimate use. We could then perhaps provide an option to disable it, if its not enough….  That is assuming we cant fix the issue about counting iterations properly.

One of the big issues is that iteration counts should be recursive. Right now its declared as a static value. So if parse_data is called several times, the number starts to become accumulative. Or that is at least one of the issues. Every time parse_data (or what ever the best function is) should create is own counter, so all the iterations of recursive calls dont cause this error. The parsing is already recursive, but the counting is static… hence the issue. (I haven’t tested this theory) But if that were fixed, it may just work well and not cause issues for anyone.

Brendan



On Mar 31, 2017, at 2:45 PM, luciash <[hidden email]> wrote:

Hi Brendan,

thanks for bringing this up again. IMHO as mentioned in one of the comments of the bug report I would vote for to make this optional (enabled by default) so site admins can switch it off or set their own number of passes maybe?

luci


On 03/31/2017 08:27 PM, Brendan Ferguson wrote:
HI guys

Have had a issue on one of my sines, and have tracked down the issue to this bug report: https://dev.tiki.org/item4217?highlight=nested+plugins

I have also found the same bug responsible for this bug report https://dev.tiki.org/item5697?highlight=nested+plugins. I know we had a recent issue on tiki.org because of it.

I have already eliminated all styling plugins in favour of HTML in order to reduce the number of plugins to only that which can not be achieved through HTML.

In my case, the issue occurred in a secondary nested plugin, instead of the 167 plugins available, as reported in the bug report, one can only use about 32 second level nested plugins. There seems to be an exponential reduction in the number of plugins one can use for each nested level. It appears that the reason only 7 levels can be reached is because the number of plugins that can appear at each level is decreased in order of magnatude, this eventually working out to zero.

I found I could temporarily fix the issue by changing the 500 passes to 1000 in PluginMatcher.php. Obviously its not a great fix, but my pages dont appear broken any longer, but its not enough to fix the 7 level nesting issue.
if (++$passes > 500) {
   return;
}
With a little experimentation, I found simply removing this check entirely works best. It allows me to use as my nested plugins as I want at any depts of nesting. Yes. It also fixes the 7-level nesting issue as well.

I presume it was put in place as an error check to prevent infant loop situations, but its a error check that is currently causing a whole lot of errors its self. 

Anyone have any insight into this?

Brendan





------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot


_______________________________________________
TikiWiki-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot_______________________________________________
TikiWiki-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
TikiWiki-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [Tiki-devel] Nested Plugins Break

Jonny Bradley-4
Hi Brendan and Luci

Thanks for bringing this us, i'm afraid i don't know what a good fix for this is, i've been looking at the plugin matching code recently (and for several years) and i have to admit i don't understand fully how changing this might effect the parser in general, and if it might end up killing some pages when people upgrade if we tinker with this.

So Brendan, are you suggesting making $passes a field of the PluginMatcher object to avoid some sort of "overlap" happening? Hmm, i tried that but then $this-=>passes never gets to more than 1 so effectively is being reset on every pass, so that would effectively be like rolling back r33863.

I'm just about to branch 17.x so maybe you can experiment with trunk after that, as i would strongly advise against making changes we don't fully understand in the parser and plugin system at this stage of the release process.

Maybe a pref for that 500 limit would be a safe enough work around for now?

jonny




> On 31 Mar 2017, at 20:33, Brendan Ferguson <[hidden email]> wrote:
>
> Ive tracked down to the bug introduced here: https://sourceforge.net/p/tikiwiki/code/33863/
>
> hmm… Im wondering if that is overkill.
>
> Without knowing under which circumstances this is utilized, its hard to say, but I have a few thoughts.
>
> It appears as though the iterations are not being calculated properly. Finding a solution to that issue could fix this so it just works for everyone, instead of giving people the option to tinker with it.
>
> It was meant to prevent “near-infanate” loops. So perhaps we should immediately increase the number to something like 5000. Its nowhere close to the 100’s of thousands of iterations that it was meant to prevent, but would provide a much greater array of legitimate use. We could then perhaps provide an option to disable it, if its not enough….  That is assuming we cant fix the issue about counting iterations properly.
>
> One of the big issues is that iteration counts should be recursive. Right now its declared as a static value. So if parse_data is called several times, the number starts to become accumulative. Or that is at least one of the issues. Every time parse_data (or what ever the best function is) should create is own counter, so all the iterations of recursive calls dont cause this error. The parsing is already recursive, but the counting is static… hence the issue. (I haven’t tested this theory) But if that were fixed, it may just work well and not cause issues for anyone.
>
> Brendan
>
>
>
>> On Mar 31, 2017, at 2:45 PM, luciash <[hidden email]> wrote:
>>
>> Hi Brendan,
>>
>> thanks for bringing this up again. IMHO as mentioned in one of the comments of the bug report I would vote for to make this optional (enabled by default) so site admins can switch it off or set their own number of passes maybe?
>>
>> luci
>>
>> On 03/31/2017 08:27 PM, Brendan Ferguson wrote:
>>> HI guys
>>>
>>> Have had a issue on one of my sines, and have tracked down the issue to this bug report: https://dev.tiki.org/item4217?highlight=nested+plugins
>>>
>>> I have also found the same bug responsible for this bug report https://dev.tiki.org/item5697?highlight=nested+plugins. I know we had a recent issue on tiki.org because of it.
>>>
>>> I have already eliminated all styling plugins in favour of HTML in order to reduce the number of plugins to only that which can not be achieved through HTML.
>>>
>>> In my case, the issue occurred in a secondary nested plugin, instead of the 167 plugins available, as reported in the bug report, one can only use about 32 second level nested plugins. There seems to be an exponential reduction in the number of plugins one can use for each nested level. It appears that the reason only 7 levels can be reached is because the number of plugins that can appear at each level is decreased in order of magnatude, this eventually working out to zero.
>>>
>>> I found I could temporarily fix the issue by changing the 500 passes to 1000 in PluginMatcher.php. Obviously its not a great fix, but my pages dont appear broken any longer, but its not enough to fix the 7 level nesting issue.
>>> if (++$passes > 500
>>> ) {
>>>
>>>    return
>>> ;
>>>
>>> }
>>> With a little experimentation, I found simply removing this check entirely works best. It allows me to use as my nested plugins as I want at any depts of nesting. Yes. It also fixes the 7-level nesting issue as well.
>>>
>>> I presume it was put in place as an error check to prevent infant loop situations, but its a error check that is currently causing a whole lot of errors its self.
>>>
>>> Anyone have any insight into this?
>>>
>>> Brendan
>>>
>>>
>>>
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Check out the vibrant tech community on one of the world's most
>>> engaging tech sites,
>>> Slashdot.org! http://sdm.link/slashdot
>>>
>>>
>>> _______________________________________________
>>> TikiWiki-devel mailing list
>>>
>>> [hidden email]
>>> https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel
>>
>> ------------------------------------------------------------------------------
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot_______________________________________________
>> TikiWiki-devel mailing list
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot_______________________________________________
> TikiWiki-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
TikiWiki-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel
Loading...