Patterns: Decode potentially-malformed ampersands in block content

[ryelle]

Fixes #488 — As described there, sometimes images are saved with the ampersands multiply-encoded, resulting in strings like …img.jpg?w=1200\u0026amp;h=1200\u0026amp;fit=clip. When used in the editor, the first encoding is decoded, but then …img.jpg?w=1200&h=1200&fit=clip is not decoded, and causes a 403 error from rawpixel.

Additionally, sometimes the slash is stripped, leading to these URLs …img.jpg?w=1200u0026amp;h=1200u0026amp;fit=clip, which cause a block validation error.

This PR does a very simple string-replacement for these two cases, only on output. Looking for review to make sure this doesn't have any unexpected side effects.

I also removed get_all_the_content, it isn't used in this project after all.

How to test the changes in this Pull Request:

1. Apply to your sandbox
2. Try copying this pattern: https://wordpress.org/patterns/pattern/step-by-step-process/
3. It should load with no validation error
4. Try copying this pattern: https://wordpress.org/patterns/pattern/shark-hero-banner/
5. The image should show up, with no 403 errors in the console
6. Make sure other patterns still work

Copy patterns using both copy buttons — the one on the single pattern page and in the grid view.

[StevenDufresne]

This is working as expected. 👍

I'm not sure what's the best way to test but sometimes & are encoded to &.
That shouldn't cause any issues, right?

[ryelle]

I'm not sure what's the best way to test but sometimes & are encoded to &.

I think that's fine because they'll be decoded, the issue is the double-encoding of \u0026amp; — but we can see if there are still issues after this merges.

[ntsekouras]

Do you think it's safe not to sanitize through wp_kses_post here? Check my comment: WordPress/gutenberg#47636 (comment)

The issue here is a result of GB sanitizing the pattern content through wp_kses_post. The flow there is:

• wp_kses_normalize_entities replaces & to &
• wp_pre_kses_block_attributes replaces & to \u0026 that results in \u0026amp; in the final output.

The above though is for security reasons and normally is not an issue for block attributes that are not URLs. In the Cover
block case though it is a problem, as it results to a malformed URL.