dar12

Thanks, I look forward to any fixes related to this. Do you have any insight as to why the “removep” behavior is there in the first place? If intentional, there must be some logic behind it, as poorly conceived as it might be, but I have no clue why such p-tag stripping from the code editor would be desirable in any scenario.

Additional references:

I came across these 3 threads that discuss similar issues in the code editor (not related to this plugin, but to the Gutenberg code editor mode in general, which does/could impact the utility of this plugin). None of these threads result in any solutions, but do show the frustration and lack of understanding by others not living in the html world

The first thread below is the most relevant to my issue, note this quote “From what I can tell, Gutenberg deletes ALL paragraph tags from “Classic” posts… unless they have been styled with inline CSS… if you make any changes in the editor.”

Again, my observation is that the p tags are not actually being stripped (they do show up in the visual editor in html edit mode, and they do show up in the published code, it’s just a matter of them not showing up in the code editor display, thereby making html editing in the code editor sort of a worthless endeavor without some sort of workaround like a mentioned earlier.

https://github.com/WordPress/gutenberg/issues/11211

https://core.trac.www.ads-software.com/ticket/45636?cversion=0&cnum_hist=1

https://www.ads-software.com/support/topic/gutenberg-does-not-play-nicely-with-code-editor/

James — thanks for the reply (received it via email, and for some strange reason your reply took 30 minutes to show up in this thread later even though your reply registered immediately in the numeric stats — strange — Now after 30 minutes, your reply is finally showing)

With regard to your comments:

– I’ve been using this functions.php filter for years to stop the auto insertion of p tags by the editor ( remove_filter(‘the_content’, ‘wpautop’); ) and I’ve tried this now with and without and it makes no difference in 5.0.3

– I think, as you mentioned, the real problem is the apparently new “remove p” action that’s taking place for some strange reason. As I said originally, p tags that are in my content html, which were placed by me originally via your plugin in WP 4.X, are being removed from the “code editor” view in Gutenberg (but the p tags are really still there, they just aren’t displayed). And yes, to your point, when I deactivate your plugin, the p tags are still not showing in the native Gutenberg “code editor” mode.

– When switching back to the “visual editor” in Gutenberg, and then looking at the block using the “edit in HTML setting”, the actual HTML displays correctly, including the p tags that are missing in the “code editor” view.

– Interestingly, when I activate the “Classic Editor” plugin, if in visual editor mode before going to the text/html view, the p tags are also stripped in that case! So, simply going to Classic Editor does not fix the problem — the “remove p” phenonmenon still occurs, seemingly as a designed-in “feature” of the visual editor — why would they do this?? If however, I go into my user profile and click to disable visual editor, then the html view works correctly with nothing being stripped, so this seems like further proof it’s the gutenberg visual editor that’s doing the stripping somehow. In past years, in WP 4.x while I used your plugin for all my page editing in html, I had this “disable visual editor” setting checked to prevent any interference from the visual editor and everything was fine…
Unfortunately, with that disable setting set now in Gutenberg, your plugin does not run at all, because apparently the “visual editor” mode needs to be active to support the “code editor” functionality — also weird.

– I did find work arounds that seems to work, at least to some degree: (Remember, this problem exists with the html page code that was automatically placed into one big classic block in the upgrade process from 4.X to 5.0.2
Workaround #1: if I add a new standard block, even if its empty, to the page while in visual editor, somehow that makes the code editor NOT strip the p tags in the classic block, and seems to then show everything correctly.
Workaround #2: If I copy the correct html code display from the “edit in html” view while in the visual editor for the classic block, and then paste that into a new “custom html” standard block (and then delete the original classic block), the code editor, and your plugin, seem to show everything correctly from the html block, with nothing being stripped.. SO, it seems this odd stripping only occurs on content of the classic block that was created during the WP upgrade to 5.0.3

Unless you know how to turn off the new, undesired “remove p” behavior of gutenberg that strips p tags from classic blocks in the code editor (incorrectly so in my opinion), I seem to have no choice but to use one of these workarounds.

I guess my real question at this point, for those of us that do most of our content development and editing work at the “custom” html level, why am I the only one talking about this… it seems to be behavior that the WP community has rationalized as a feature (I see it as a major bug), but God knows why anyone would want this behavior?! It literally prevents a person from having true control of their html in the so-called “code editor” mode.

With that additional info, please advise on any other thoughts that might help me here. As with many developers, I have tons of legacy content that I need to maintain at the HTML level that is subject to this issue.

Thanks!

Thanks for looking into this Baden. Yes, the missing quote was just a typo in my post.
In the meantime, I have developed a workaround that seems to work, and also made one more odd discovery that I also worked around, as follows:
– As described, the maptastic class does not get removed when clicking the expand-all span (although the swaptitle trigger text and arrow both change normally). To work around this, I created a simple jQuery onclick function to remove the maptastic class from all collapseomatic_content divs when the expand-all span is clicked — this seems to work OK.
– I noticed a second problem that also seemed related to the expand-all/collapse-all functionality: I use an additional close trigger at the bottom of my expand content per the documentation (ie, id=bot-… with class colomat-close) and they work great with normal expand actions. But, when using collapse-all, for some reason the colomat-close class is getting removed from these bottom close triggers every time collapse-all is clicked – the result is that after expanding normally following a collapse-all, the bottom trigger arrow png was pointing the wrong way (ie, down for open, not up for close as it should be) Again I used jQuery to work around this by adding back the colomat-close class to elements with id containing “bot-” anytime collapse-all span is clicked (after a short time delay to allow the plugin to do its mysterious removal of this class before my jQ would restore it)

So, with the above workarounds, I seem to have things behaving the way I want, but I’d be interested if you find anything or have any further insights on these items. My site is in private devel so no readily available link, but if you are unable to reproduce, I may be able to provide access for you to take a look at the behavior.

Thanks Baden for the clarifications and tip about maptastic class. I tried maptastic but had a new problem surface as follows:
After your suggestion I did add maptastic inline as a class to the roll-own target divs (ie, ‘<div class=”maptastic collapseomatic_content etc… ‘). And, on the same page, where shortcodes were used for other expands, I applied it as a special class using targclass=”maptastic” in the expand shortcode, per the documentation. The result was good as far as it preventing flicker in both cases, and the content showed fine when the individual triggers were clicked. However, my page-wide expand-all link stopped working (implemented as ‘<span class=expandall”>Expand All</span>’) — with the addition of these maptastic classes, the expand-all now does not cause the content to be displayed, but it does trigger the swaptitle for the trigger text/arrow in all cases — it’s as if the maptastic class is not being managed properly (not being removed?) when expandall is clicked. Any idea on why this might be happening?

After some more digging, I found a newer post ( https://spacedonkey.de/2432/nested-collapse-elements-with-highlander-grouping/ ) which shows nested roll-your-own expands WITHOUT inline display:none styling on the target elements — so I updated to 1.7.3, removed display:none on the target elements, and the nesting seems to work OK with the roll-your-own approach. Maybe the inline display:none from the older post mentioned above were just there for flicker prevention, but I thought that when I tried deleting display:none before doing the version update, the expand content showed by default — maybe something else was going on.

Anyway, perhaps my concern about SEO is gone now, since I now have the option to operate with display:none removed, as long as I can live with flicker.