Unexpected encoding of ampersand (&) to &

[martindrapeau]

I have registered a dynamic block and use a PHP function to generate some script tags and inline JavaScript. The JavaScript code gets modified upon output - some of the & get url encoded to &#38. The JavaScript interpretation then errors out.

This same code is being used by shortcodes with no url encoding (as expected).

The odd thing is that not all & get url encoded (see yellow underlined lines 117 or 118).

To Reproduce
You can view the broken JavaScript on this test page (generated from dynamic block): https://lab.amilia.com/gutenberg-bug/
You can view the working JavaScript on this test page (generated by shortcode): https://lab.amilia.com/plugin-calendar/

The source code for the plugin is here:
Block registration: https://plugins.trac.wordpress.org/browser/amilia-store/trunk/blocks/amilia-store-calendar.php
PHP back-end rendering function: https://plugins.trac.wordpress.org/browser/amilia-store/trunk/shortcodes/amilia-store-calendar.php

Desktop

• OS: Windows 10 & Linux give the same thing
• PHP: Version 5 & 7 gives the same thing
• Browser: chrome
• Versions: latest (12 Nov 2018)

[drpraveenss]

I am also facing exactly the same issue. Any fix/alternative for this ?

[martindrapeau]

I found a workaround. It is to extract the JavaScript code into its own file. In PHP, you load that file and call a function to trigger the code.

Its not a solution though - there is a true bug that needs to be fixed. And to @designsimply this is not a help request - this is a bug report.

[drpraveenss]

Thanks @martindrapeau ,
I found one more workaround for this. This issue is occurring because of comparator operator ('<' and '>') . Gutenberg is escaping characters inside '<' .
The workaround is to put these operator into a function (let's say function gt(int a, int b) {return a>b;} , then it works.

[designsimply]

And to @designsimply this is not a help request - this is a bug report.

Gotcha! I've fixed the label and send my apologies for the mistake!

[rafiee]

change condition orders. For instant if your condition is like this: ( x<y && z>w) replace with (z>w && x<y)
this will solve the conflict.

[paaljoachim]

Hi @martindrapeau and others.
Please retest with the newest version of WordPress and Gutenberg plugin.
Thanks!

[godismyjudge95]

@paaljoachim

Just ran into this issue again with the latest version of wordpress (5.7).
I realize this is probably low priority, but it kinda stinks that we can't add javascript to script blocks without possibly breaking it.

[paaljoachim]

Hi @godismyjudge95 Daniel.

I added the question into the Slack core editor channel to hear if this method is (still) valid.

[godismyjudge95]

@paaljoachim I meant to mention, this also happens with just the plain Custom HTML block. So it must be something with the HTML parser.

Another thing that might help narrow it down, the javascript appears to work in the HTML preview of the block. So maybe it is the save/retrieve functions that is malfunctioning?

[paaljoachim]

Greg @gziolo and/or Miguel @mcsf perhaps you are able to respond here?

[mcsf]

I meant to mention, this also happens with just the plain Custom HTML block. So it must be something with the HTML parser.

This should be completely independent from the render_callback issue. That said, could you provide instructions for this? In my testing I found no issues. Here's what I did:

1. In a new post, add a Custom HTML block.
2. In its blank text area, paste the snippet attached below.
3. Hit Preview to get the front-end result.
4. Observe that the browser presents an alert box, and that the page's source shows that the ampersands were preserved.

<script>
  if (true && true) alert('ok')
</script>

[dancodedev]

I meant to mention, this also happens with just the plain Custom HTML block. So it must be something with the HTML parser.

This should be completely independent from the render_callback issue. That said, could you provide instructions for this? In my testing I found no issues. Here's what I did:

1. In a new post, add a Custom HTML block.
2. In its blank text area, paste the snippet attached below.
3. Hit Preview to get the front-end result.
4. Observe that the browser presents an alert box, and that the page's source shows that the ampersands were preserved.

<script>
  if (true && true) alert('ok')
</script>

Try this case

<script>
for (var t = 0; t < 10; t+= 1) {
}

if (true && true) alert('ok')
</script>

[mcsf]

Try this case

<script>
for (var t = 0; t < 10; t+= 1) {
}

if (true && true) alert('ok')
</script>

@dancodedev: thanks, that was helpful.

I've tracked this down to a bug in wptexturize. It predates Gutenberg altogether (I was able to reproduce this issue in a vanilla WP 4.9.8 site). The issue stems from how wptexturize tries to leave certain HTML elements untouched, including — by default — <script> elements. When a script contains no < character, all is good; but when there is such a character (as in the case of for (let i = 0; i < 5; i++)), it messes with how wptexturize breaks down its input into elements.

I think this should be reported as a Core WordPress bug at https://core.trac.wordpress.org/. There is a ticket from 2018 on this: https://core.trac.wordpress.org/ticket/45387.

[mcsf]

I've added a comment under the original issue to describe this particular case.

Closing as a duplicate of t45387.

[allocater2]

Still happening in Wordpress 2023. I inverted my logic

if(a && b)

became

if(!(a || b))

since only & is affected 🤷‍♂️