So, I'm trying to create a nested toggling system for expanding / collapsing a long text by sections and sub-sections.
I've installed the Arconix Shortcodes (and a few others in the attempt).
Basically, I want to do something like this:
[toggle title="Guide Book on Topic X"]
[toggle title="Preface"]Initially hidden, expandable Preface text[/toggle]
[toggle title="Introduction"]Initially hidden, expandable Intro text[/toggle]
In my surmise, the way this SHOULD work is via NESTING.
That is, there is a PARENT toggle, and inside that there are two CHILD toggles.
If the parent toggle is "closed," the child toggles are hidden (regardless whether they're "open" or "closed" at the time; PARENT toggle takes priority over CHILD toggles).
If the PARENT toggle is "open", we can see the CHILD toggles and act upon them, to either open them, if "closed," or close them, if already "open."
However, it seems, from other sources I've managed to Google after some painstaking attempts to fix this issue, that WordPress currently doesn't handle shortcode nesting properly, in general terms.
In particular, the Codex seems to note here:
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.
That feels like it's a problem, since this sort of thing SHOULD, one would think, be fairly easy to handle in some systematic sort of way.
The WP core codebase coders seem to then want to pass off the problem onto the plugin coders, as if the codebase problem was somehow their problem:
The shortcode parser correctly deals with nested shortcode macros, provided their handler functions support it by recursively calling do_shortcode():
However the parser will fail if a shortcode macro is used to enclose another macro of the same name:
(As an aside, there's a typo in the Codex entry, above. That should really say [tag-b] not [tab-b] in the first set of block quotes. Not that it matters to the overall argument here.)
Should plugin coders really have to do a coding version of highwire gymnastics to "support" nesting? Isn't that something the core codebase should handle?
I'm kind of disappointed this hasn't been "fixed." It feels a bit like folks kind of throwing up their hands and saying "not my problem, you solve it, ad hoc."
My opinion is that the 2nd method is the correct method. Not the method requiring additional coding gymnastics to "band-aid over" the actual problem of core codebase insufficiency. Seems like a bit of unnecessary work offloaded onto plugin programmers just to avoid having to fix a single module in the core codebase that could/should have been written better? Am I wrong? Shouldn't it be fixed in one place rather than requiring oodles of extra lines of "workaround" code in the hundreds of plugins that could/should potentially be used in a "nested" manner?
Ideally, one should be able to arbitrarily "nest" whatever one feels like, and it should *just work.* I mean the "nesting" logic feels like it should be pretty simple. "Nesting" is pretty much how HTML works, so I'm a bit confused why such a mature CMS as WordPress should have a "problem" with it. It sounds like the "regexp parser" mentioned in the Shortcodes entry in Codex is in some way insufficiently designed to handle the logic? But, nobody's taken the time to fix it or invent a better parser that actually handles this kind of nesting in a more systematic way that doesn't require coding "band-aids."
If we could, y'know, get this kind of thing shored up in short order, that'd be great... I'm sure a great many page builders would be quite happy if this were the case. No? Then we wouldn't have to keep bugging our plugin makers about it or Googling all over the web or searching the Codex to figure out why something [one would think should be] intuitive... really isn't.
Sorry if this has at all been brought up before (probably?)... If so, just add my voice to those voices who may have already called WP out on this problem. A systematic solution (rather than an ad hoc 'do it yourself' one or a 'complain to your plugin programmer' one) would be best, in my opinion. Feels like this should be one of those "working directly out of the box" features. It certainly feels like it would add a certain robustness to the project.
I love shortcodes, and love them better when they function AS INTENDED out of the box without quirky ad hoc problems because some module is known to be insufficient and nobody has taken the time to burrow into the core codebase and fix it.
Just the frustrations of someone fairly new to the project and thus with a "fresh" set of eyes. Pointing out a problem, albeit one that's probably "known," if seemingly also "neglected."
Feels like if this problem with the core codebase were given some loving attention, it could probably be fixed relatively easily.
I know, I know, "...says the non-programmer." But that's kind of the point, isn't it? I'm not a programmer, which is why I like preprogrammed CMS solutions like WordPress. It's precisely so I don't have to *be* a programmer, but rather I can be a 'designer.' I can leave the "programming" to the programmers. But on the other hand, there's a certain implicit expectation that the "programming" be sufficient for as robust an implementation as possible. In essence a black box whose internal function I don't need to *know*. So long as the internals work 'as-advertised' and don't break, I should simply be able to plug things in and play with them and not have to worry about "breakage."
Right now, it feels like it's not a "black box" because there *is* apparent breakage, when I do things in the way they feel like they SHOULD be done, and the logic isn't there to handle it and something breaks and goes sideways, mucking up the works.
I don't mean to sound negative. I'm really not, I LOVE WordPress so far... It's just, there's an apparent insufficiency/shortcoming in the core codebase here. It seems to be explicitly acknowledged in the Codex. The question is, I suppose: what can/will be done about it?
Thx for your time!
P.S. If anyone knows of an easily available somewhat "mature" plugin that in some way easily SUPPORTS nested accordion or toggle boxes, it would be very handy, right about now. But don't let that stop you from fixing the aforementioned shortcoming(s), too. Thx!