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.

Sign up for GitHub

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

Jump to bottom

Wide-aligned blocks: Non latin text characters are rendered as gibberish inside the block if set to Wide or Full Width #24445

Closed
ockham opened this issue Aug 7, 2020 · 5 comments · Fixed by #24447 or #24645
Closed

Wide-aligned blocks: Non latin text characters are rendered as gibberish inside the block if set to Wide or Full Width #24445

ockham opened this issue Aug 7, 2020 · 5 comments · Fixed by #24447 or #24645
Assignees
@ockham
Labels
[Priority] High Used to indicate top priority items that need quick attention [Status] In Progress Tracking issues with work in progress [Type] Bug An existing feature does not function as intended

Comments

@ockham
Copy link
Contributor

ockham commented Aug 7, 2020

Describe the bug

First reported by @zdenys at Automattic/wp-calypso#44759. The following is a copy of that issue, since it applies to Gutenberg.

To reproduce
Steps to reproduce the behavior:

  1. Add a Cover block with paragraph of text with some or all non-Latin characters (I tried Norwegian, Japanese and Chinese)
  2. Set Cover Block to Wide or Full Width
  3. View Preview or Published site

Expected behavior
See all characters rendered normally on the front end just like on the backend.

Screenshots

Link: https://d.pr/i/5gdq1V


Link: https://d.pr/i/gFwXfS

Editor version (please complete the following information):

  • WordPress version: 5.5
  • Does the website has Gutenberg plugin installed, or is it using the block editor that comes by default? gutenberg plugin
  • If the Gutenberg plugin is installed, which version is it? 8.7

Additional context
Encoding issue. PR coming right up.

cc/ @sirreal @akirk @simison @yansern
@ockham ockham added [Type] Bug An existing feature does not function as intended [Priority] High Used to indicate top priority items that need quick attention labels Aug 7, 2020
@ockham ockham self-assigned this Aug 7, 2020
@mcsf
Copy link
Contributor

mcsf commented Aug 7, 2020

Thanks for the report! To be clear, this only affects server-side-rendered blocks, is that correct?

@ockham ockham mentioned this issue Aug 7, 2020
Merged
6 tasks
@github-actions github-actions bot added the [Status] In Progress Tracking issues with work in progress label Aug 7, 2020
@ockham
Copy link
Contributor Author

ockham commented Aug 7, 2020

Thanks for the report! To be clear, this only affects server-side-rendered blocks, is that correct?

I think so, but haven't run any broader testing for other blocks yet.

@sirreal sirreal closed this as completed Aug 7, 2020
@sirreal
Copy link
Member

sirreal commented Aug 7, 2020

Apparently I closed this unintentionally. Reopening. This should be fixed by #24447

@sirreal sirreal reopened this Aug 7, 2020
@ms-studio ms-studio mentioned this issue Aug 9, 2020
Closed
@mcsf mcsf mentioned this issue Aug 10, 2020
Merged
12 tasks
@pedro-rivera
Copy link

pedro-rivera commented Aug 14, 2020 •
edited
Loading

Facing the same problem on a local environment, WP 5.5, Gutenberg 8.7.1:

Block Issue

Where it's read direção should be direção (pt-BR)

Other blocks with same and other special characters display correctly.

@lsl lsl mentioned this issue Aug 17, 2020
Closed
@mcsf
Copy link
Contributor

mcsf commented Aug 17, 2020

Facing the same problem on a local environment, WP 5.5, Gutenberg 8.7.1:

The issue is fixed in master and should land in Gutenberg 8.8 later this week.

lsl added a commit to lsl/gutenberg that referenced this issue Aug 18, 2020
@lsl
Avoid lossy htmlentities encode by setting charset
e623758 
Sets the charset of the html passed into DomDocument to utf-8.

Replaces the mb_convert_encoding call replacing utf-8 with html entities
before handing off to DomDocument.

This avoids the need to later convert back to utf-8 from html entities
afterward. This secondary mb_convert_encoding call was converting not
only the utf-8 we converted earlier but also entity encoding html stored
inside data-* or other attributes of html elements.

Fixes Automattic/wp-calypso#44897
Maintains the fix for WordPress#24445 (WordPress#24447)
@lsl lsl mentioned this issue Aug 19, 2020
Merged
6 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@ockham ockham

Labels
[Priority] High Used to indicate top priority items that need quick attention [Status] In Progress Tracking issues with work in progress [Type] Bug An existing feature does not function as intended
Projects
None yet
Milestone
No milestone
4 participants
@ockham @mcsf @sirreal @pedro-rivera