Nesting Shortcodes… Doesn't work as expected??

I didn’t read your whole post, but I think you can use nested shortcodes the way you want by renaming the shortcodes inside the enclosing shortcode “toggle” to “toggle_inside”:

[toggle title="Guide Book on Topic X"]
  [toggle_inside title="Preface"]Initially hidden, expandable Preface text[/toggle_inside]
  [toggle_inside title="Introduction"]Initially hidden, expandable Intro text[/toggle_inside]
[/toggle]

With this in your theme’s functions.php:

function toggle_inside( $atts, $content = null ) {
   extract( shortcode_atts( array(
      'title' => 'Toggle This',
      ), $atts ) );
      return do_shortcode('[toggle title="'.$title.'"]'.$content.'[/toggle]');
}
add_shortcode('toggle_inside','toggle_inside');

btw:
consider creating a child theme instead of editing your theme directly – if you upgrade the theme all your modifications will be lost.
Or create your own plugin with the code for functions.php:
https://www.ads-software.com/extend/plugins/pluginception/

Hmm, so, question… If that’s the case, if I wanted to have more than one level of nesting would I then have to create x number of “sub-shortcodes,” one for each level of nesting, or could I alternate between strictly two shortcodes so long as neither is directly inside another copy of itself? I’m not a programmer, so I don’t know the programming logic…

So, for instance, could I do this (alternating back & forth):

[tag-a]

[tag-b]

[tag-a]

[tag-b]
[/tag-b]

[/tag-a]

[/tag-b]

[/tag-a]

Or would I have to create a hundred shortcodes if I want a hundred levels of hierarchy (clearly nobody needs 100 levels of hierarchy, but you see my point, I’m sure)?

[tag-a]

[tag-b]

[tag-c]

[tag-d]
[/tag-d]

[/tag-c]

[/tag-b]

[/tag-a]

Personally, I’d rather just see the core codebase issue fixed and not have to fiddle with ad hoc solutions, which was kind of the point of the ramble (sorry ’bout that). Seems like it’s a “known issue” that nobody wants actually fix. And it feels like it would be better if the community fixed the core issue that leads to all the other problems, rather than suggesting ad hoc solutions to band-aid over the root problem, which seems to just be getting ignored.

Which was why *I think?* I put this in suggestions & feedback rather than “how-to,” where it seems to have gotten moved to… My suggestion/feedback is that the CORE CODEBASE ISSUE needs to get addressed & fixed so things simply WORK AS EXPECTED, rather than having to kludge together an ad hoc solution out of duct tape and baling wire every time it breaks. It would be better to have a SINGLE SOLUTION that works for everyone (and for all potentially nestable shortcodes) than for everyone to have to put in extra man hours coming up with non-standard solutions on a case-by-case basis.

It’s like putting 100,000 man hours of work onto the community instead of taking 10 man-hours to figure out a systematic fix to the root problem that solves everyone’s issues in an amicable way and moreover make the core codebase more stable, flexible and robust.

Just the 2c of a pseudo-n00b. ^_^

I’m under the impression you think (after reading your first post) nested shortcodes are fairly easy. It’s not. How would WordPress differentiate between the nested structure you want and the nested structures other users want? That’s part of why these constraints exist. If you don’t like these constraints create your own plugin replacing (nested) shortcodes or work around it.

Hmm, so, question… If that’s the case, if I wanted to have more than one level of nesting would I then have to create x number of “sub-shortcodes,” one for each level of nesting, or could I alternate between strictly two shortcodes so long as neither is directly inside another copy of itself?

Try and test it. (read: I don’t know)

btw:
I didn’t moderate this post and put it in: How-To and Troubleshooting
[Moved back to Requests and Feedback]

Never said you did, but thanks. ^_^ Maybe someone else did or maybe I just forgot where I put it… C’est la vie!

Well, like I said, I’m not a programmer. So, not quite sure what you mean by “How would WordPress differentiate between the nested structure you want and the nested structures other users want?”

Seems to me like nesting is nesting, no? Things nested inside go inside, things not nested inside don’t go inside?

From Codex (listed above, already):
https://codex.www.ads-software.com/Shortcode_API#Nested_Shortcodes

This is a limitation of the context-free regexp parser used by do_shortcode() – it is very fast but does not count levels of nesting, so it can’t match each opening tag with its correct closing tag in these cases.

The codex entry sure makes it sound like a pretty simple issue (regexp doesn’t count levels of nesting to match opening and closing tags), hence my assumption it was a pretty simple issue (fix regexp or replace regexp with a better system that DOES count levels of nesting and act on that information to match up opening and closing tags), just one not yet dealt with?

If that’s not the case, my apologies for over-simplifying… Perhaps it’s “more complicated than that.” But the explanation makes it sound like a pretty simple issue to define and remedy. Hence my uncertainty over why it hasn’t been defined and remedied by whoever maintains the WP core codebase, but rather offloaded to everyone else to make up ad hoc solutions on a case-by-case bases.

Just seems like fixing the core issue of “not dealing with matching up opening / closing tags for shortcodes” is what’s at issue here.

Maybe it’s more difficult than that or maybe it’s simply ambivalence on the part of the core codebase maintainers (I know everyone has time constraints, most folks do this out of the goodness of their hearts, and there are maybe more pressing issues, etc.). I don’t know which is the case?

Just seems like one of those times where a single fix could fix a host of problems and make the system more robust / intuitive.

Anywho, not trying to be a pill… Sorry. Appreciate the input. ^_^

Just see a thing that could be improved with perhaps a little concerted effort to make the out-of-the-box experience go slightly smoother / more intuitively.

But, again, maybe I’m oversimplifying? I dunno… Problem seems pretty well defined to me, tho’? Clearly there are “workarounds,” so why not apply the “workaround” to the core codebase in a more “systematic” way that works for all cases? Again, if it’s possible. & it feels like it should be, if it’s just an issue of tracking opening and closing shortcode tags to determine nesting hierarchy?

Anywho, not trying to be a pill… Sorry. Appreciate the input. ^_^

No problem ??

Just seems like fixing the core issue of “not dealing with matching up opening / closing tags for shortcodes” is what’s at issue here.

If I read it right, core developers choose speed using regular expressions over parsing text for opening and closing shortcode tags (slow). This will cover most use cases but unfortunately not yours.

Hmm, s’pose so…? No chance at a happy middle ground?

Some way of “seeing” if there might be a hierarchy and only invoking the “slower” method when deemed necessary?

Almost seems like something where some extra meta-data could be stored in/with a page having shortcode “same name nesting hierarchy” needing processing, which would act as a “flag” to the handler script to “switch gears” when rendering this specific page in order to deal with the [shortcode] “nesting” hierarchy.

No “hierarchy-denoting” meta-data? Use the “faster” script. “Hierarchy-denoting” meta-data? Switch gears to to the slower but more accurate script to deal with hierarchical shortcodes.

Best of both worlds?

Heck, maybe it would even be some kind of a case of an enclosing

[ShortcodeSameNameNesting]
…
[/ShortcodeSameNameNesting]

shortcode that WP would insert around the offending “nested” “SameName” shortcodes (perhaps OnSave?) that could tell the handler at runtime “everything in this section, parse ‘rigorously'” “everything outside this section, parse ‘fast.'”

Seems like maybe a workable solution that allows for the extra processing only when necessary and light execution for everything else?

Dunno. Just trying to think outside the box here… ^_^

I don’t know how to build such things (still not a programmer, but get some of the basic premises, sort of, once in a while, when I feel like it), but it seems like it wold be a useful function / shortcode / plugin if someone DID build it.

———-

Sounds like there are a few other “known issue” that could use a systematic cleanup too?

The shortcode parser uses a single pass on the post content. This means that if the $content parameter of a shortcode handler contains another shortcode, it won’t be parsed:

[caption]Caption: [myshortcode][/caption]

This would produce:

<span class=”caption”>Caption: [myshortcode]</span>

If the enclosing shortcode is intended to permit other shortcodes in its output, the handler function can call do_shortcode() recursively:

function caption_shortcode( $atts, $content = null ) {
return ‘<span class=”caption”>’ . do_shortcode($content) . ‘</span>’;
}

In the previous example, this would ensure the “[myshortcode]” macro in the enclosed content is parsed, and its output enclosed by the caption span:

<span class=”caption”>Caption: The result of myshortcode’s handler function</span>

…

Note: The behavior described below involving shortcodes with hyphens (‘-‘) still applies in WordPress 3+. This could be due to a bug in do_shortcode() or get_shortcode_regex().

Take caution when using hyphens in the name of your shortcodes. In the following instance WordPress may see the second opening shortcode as equivalent to the first (basically WordPress sees the first part before the hyphen):

[tag]
[tag-a]

It all depends on which shortcode is defined first. If you are going to use hyphens then define the shortest shortcode first.

Perhaps neither here nor there.

Save that is seems like [shortcodes] generally need a bit of shoring up against bugs & some modifications to add flexibility.

I hope that someone’s actively looking into these issue and not just shrugging and walking away. ‘Cause, clearly, they’re “known” and they seem to intermittently cause some issue. Would be nice to see some spit shine to buff out some rough spots in a few places. ^_^

———-

Anywho, hope my approach to the problem / solution is a useful suggestion? ^_^ Maybe even bordering on meritorious?

Cheers,
~MG

Hi kissiemeijer,

You say:
“I’m under the impression you think (after reading your first post) nested shortcodes are fairly easy. It’s not. How would WordPress differentiate between the nested structure you want and the nested structures other users want?”

Also:

“core developers choose speed using regular expressions over parsing text for opening and closing shortcode tags (slow).”

—

First, for the other posters, it’s mathematically impossible to handle nesting structures with regular expressions. So if WP insists on using regexes for this, the problem of nested shortcodes will always be there.

Second, parsing nested shortcodes is a matter of parsing a tree (in the CS sense), which can be done for example with a simple depth-first search. It’s pretty easy to do, I had to do it recently for a job interview. Browsers parse trees from strings all the time with the DOM.

Third, I doubt that regexes are more efficient than parsing a tree with depth first search. The latter is O(n), linear in the size of the string, the former is what? With all the needed restarts over the string when some partial matching fails… For example, here https://stackoverflow.com/questions/21669/complexity-of-regex-substitution it is said that the overall complexity is O(2^m + n), where m is the size of the regex, n the size of the string.

Finally, yes, nested shortcodes could be fairly easy with the right approach. A tree (or a forest) of shortcodes (i.e. one or more nested structrues of shortcodes) is either well-formed or not, just as xml is well-formed or not. It’s not at all a matter of “what users want”. And even if not well-formed, it seems pretty easy to handle it (just close any tag that should have been closed before reaching the closing of the parent’s -or some ancestor’s- tag). Regexes are simply not the right approach.

Cheers.

AdV