Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
Code blocks should be editable after saving the post and reloading the editor #15780
How has this been tested?
Created the block described in #13218.
Types of changes
The PR solves the issue by making sure the content of a code block is pulled as HTML during the parsing process and escaping/unescaping tag delimiters (i.e.
It'd be worth testing to see if it is an issue. The block validation logic explicitly includes some leniency where differences are purely on differences in encoding (source), so it might not be a problem.
If it does turn out to be breaking, we can try to use the
<a href="http://wordpress.org/">WordPress</a> <strong>
becomes this (after my original PR #13996 is applied):
<a href="http://wordpress.org/">WordPress</a> &lt;strong&gt;
The problem is, when loading that block from the post content, characters like
Apparently, this seems to solve issue #13218 and all tests pass. I would recommend a few more testing, though.
Yep, wondering about why we wouldn't need to have a corresponding escaper in the setter, it occurs to me that this is already effectively escaped when the block is serialized. So I think the change is sensible in restoring a balance. It's also better for it to occur during the save than in
I'd wondered about whether we really need to unescape here, vs. setting the
This looks good to me. I'll want to give it another pass in the morning with a fresher mind.
In further confirming this, I expect it should be effectively the exact opposite of:
There are two observations:
I'd also wondered about server-side escaping we might need to anticipate, and specifically in cases of
I expect we'd used
@davilera I have some small concern about trying to keep this in sync with the specific implementation of the serializer, and I'm curious your thoughts on an alternative I have in mind:
The idea would be to change the
var e = document.createElement( 'textarea' ); e.textContent = '&'; console.log( e.innerHTML ); // '&'
It seems this alternative might pose some more risk in trying to assure safety of value escaping, so I may be comfortable as well with the current proposal, even if it needs to account for factors outside its own consideration (the serializer behavior).
To be honest, I don't have a strong opinion on any solution, as none is perfect and each poses its own problems. That said, I feel like using
Regarding the current proposal, I also don't like using an asymmetric
What do you think, @aduth? Should we introduce a breaking change? I think the risk the current proposal poses is minimal: in principle, our block would only receive a