Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Classic block missing content in Preview #14861

Open
joyously opened this issue Apr 8, 2019 · 8 comments
Open

Classic block missing content in Preview #14861

joyously opened this issue Apr 8, 2019 · 8 comments
Labels
[Feature] Parsing Related to efforts to improving the parsing of a string of data and converting it into a different f [Type] Bug An existing feature does not function as intended

Comments

@joyously
Copy link

joyously commented Apr 8, 2019

The content is visible in the editor, but the Preview is missing some content.

To reproduce

  1. I was using the Theme Unit Test data from https://github.com/WPTRT/theme-unit-test/
  2. Click to edit the Post titled "Markup: HTML Tags and Formatting"
  3. Scroll down to see that the Table follows the Block Quote.
  4. Click on Preview.
  5. See that there is no Table heading following the Block Quote and the formatting of the rest of the page is for blockquote.

Expected behavior
The preview should match the content in the editor.

Screenshots
This is how it looks in the editor:
Edit Post Local Current WP WordPress-2517

And this is how the preview looks:
Markup HTML Tags and Formatting Local -0148

Desktop

  • OS: Ubuntu Studio 16.04
  • Browser: Firefox 66.0.2
  • WP Version 5.1.1
  • no plugins, Twenty Nineteen theme
@youknowriad
Copy link
Contributor

I confirm I reproduce the issue, it might be good to open a trac ticket as well as it seems that this happens on the backend in one of the the_content filters.

@youknowriad youknowriad added the [Type] Bug An existing feature does not function as intended label Apr 9, 2019
@joyously
Copy link
Author

joyously commented Apr 9, 2019

@jorgefilipecosta jorgefilipecosta added the [Type] WP Core Ticket Requires an upstream change from WordPress. Core Trac ticket should be linked. label Jun 6, 2019
@jorgefilipecosta
Copy link
Member

Thank you @joyously for creating this issue and the trac ticket, given that we already have a trac ticket following the normal process and that passed from awaiting review to the milestone 5.3, I guess we can now close this issue and use the trac ticket to follow the progress of this problem.

@SergeyBiryukov
Copy link
Member

SergeyBiryukov commented Jun 28, 2019

I was able to reproduce the issue with the following example:

<a href="#" title="&lt;cite&gt; represents a reference to a creative work.">...</a>

It results in this output on the front end:

<a href="#" title="<cite> represents a reference to a creative work.&#8221;>&#8230;</a>

Note the closing quote converted to &#8221;, breaking any markup that follows.

With the wptexturize() filter disabled, the input works as expected.

Using the Classic Editor (in both Visual and Text mode), the output is correct even with wptexturize() enabled:

<a title="&lt;cite&gt; represents a reference to a creative work." href="#">&#8230;</a>

So this appears to be a wptexturize() issue that only manifests with the Block Editor. I think the difference is that the Block Editor does not preserve the escaped &lt;cite&gt; tag in the title attribute, converting it to <cite>, and wptexturize() is confused by that.

I guess the Block Editor should preserve &lt; and &gt; entities in HTML attributes. Reopening the issue, as it seems this should be fixed in Gutenberg rather than in the back end.

@skorasaurus skorasaurus added [Feature] Parsing Related to efforts to improving the parsing of a string of data and converting it into a different f and removed [Type] WP Core Ticket Requires an upstream change from WordPress. Core Trac ticket should be linked. labels Feb 4, 2021
@paaljoachim
Copy link
Contributor

Hi @joyously
Is this issue still valid? If so how should we move forward?

@carolinan @glendaviesnz @talldan

@joyously
Copy link
Author

Yes, it is still an issue. See Sergey's comment for details.

@carolinan
Copy link
Contributor

I wonder if this should be closed in favor of #15636 which seems to be root cause?

@joyously
Copy link
Author

Both issues state the root cause and this one has a lower number...
The other issue is blaming wptexturize, when this issue specifically says that it is not.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
[Feature] Parsing Related to efforts to improving the parsing of a string of data and converting it into a different f [Type] Bug An existing feature does not function as intended
Projects
None yet
Development

No branches or pull requests

7 participants