Wrong parent shortcode returned in nested shortcodes

[giansi]

Hello,
I'm dealing with nested shortcodes and I faced the following issue. Giving this shortcode structure:

[shortcode1]
    [shortcode2]
        [shortcode3]
        [/shortcode3]
    [/shortcode2]
[/shortcode1]

calling getParent() on shortcode3 returns the shortcode1 and not the expected shortcode2.

[thunderer]

Hi @giansi, could you tell me a bit about how you use this library? Maybe a failing test or a gist to debug?

[thunderer]

Oh, I see that you're working on GravCMS with @rhukster. :) Could you please check the current dev-master as I've just pushed some fixes? If it resolves your issues, I'll tag a new release. Thanks!

[giansi]

To be honest the new branch breaks my code while it works with @rhukster plugins, so it is something on my side. I have to fix that problem then I'll let you know.

[thunderer]

@giansi this library was committed directly into @rhukster plugins repository (last time I looked at it, it was not installed through composer) without my new commits so if it breaks something for you it may mean that there are still bugs I was unable to find. Please keep me posted on what is wrong and I'll try to help.

[giansi]

Actually it does not run my handles. When I switch back to previous
shortcode version it works again. I investigated and looks like now it
uses the WordpressParser and this might be the problem.

Here's the actual code I use to instantuiate the new handler

     $shortcodeObject = new $class($this->grav);
     $this->handlers->add($shortcodeObject->shortcode(), 

function(ShortcodeInterface $shortcode) use($shortcodeObject) {
$shortcodeObject->processShortcode($shortcode);
$this->grav["assets"]->add($shortcodeObject->assets());
});

The $shortcodeObject is correctly created but the handler does not run.
Let me know if you need more code.

[thunderer]

I recently added a note in WordpressParser to use it only if you want full compatibility with WordPress. From what I see you want to use at least RegexParser as it's the default choice if you do not need full parsing correctness provided by RegularParser as I explained in this comment. Please change it and tell me if it works as expected.

[giansi]

Hi,
I found where the Process class is intantiated in @rhukster's plugin. He actually switched to WordpressParser and this does not parses my shortcode. I tried both with RegularParser and Regex one and only the last works. This was the parser used in previous @rhukster's plugin. I attach the html code produced the page which is parsed to create the shortcodes. Mine is blurred_jumbotron

page.zip

[rhukster]

What is the significance of this [...] stuff in your code example? I'm sure this is tripping up the parser.
Why don't you try wrapping that whole code block in [raw][/raw] shortcode so it's not processed.

[giansi]

Hi, the problem was caused by the shortcode name: I chose blurred_jumbotron and this breaks both the WordpressParser and the RegularParser. I fixed simple changing the shortcode name to blurred-jumbotron.

@thunderer looks like parents are correct now.
@rhukster the [...] are just a part of a blog article and they do not break the parser. :-)

[thunderer]

Yes, underscore _ is not allowed in shortcode name, only alphanumerics and dash -. It does not break those parsers, they will just consider it invalid and won't match it. I use \w- as the fragment for names in RegexParser, seems that underscore is an added bonus I was not aware of, it's now fixed in 3a8d537 .