leapdragon

This is a serious bug.

There should have been a warning.

PHP is used to manipulate data, and as a result, we have some cookie data for users that was set to PHP code strings.

Luckily we do most of our data cooking in dedicated plugins of our own, but we did have some items in A/B testing using this plugin and those user cookies are now polluted.

But it took us some time to track down the issue. We noticed the change in this plugin’s settings, but when we set the option it did not appear to resolve the problem. It took us some time to realize that PHP strings were now stored in cookies and being pulled back into the page environment. We have now had to implement new code to check cookies for PHP code and zero values if they contain PHP code. So we had to write net new code to undo what the change in defaults did on our site, and we have lost user data.

NEVER release a change in fundamental behavior unless you:

• DEFAULT to old behavior and make the new behavior an option
• Provide a WARNING prior to upgrade about what will change; word press provides a space for banners in the plugin list for this reason

I basically said this in reply to someone else just a moment ago. +1

They are trying to structure input using markup specs intended for output. The result? All of the worst problems of the unusable WYSIWYG failures.

Markup languages are to enable producers to mark up an undifferentiated stream of input to make it easy to structure repetitive output while lowering overhead on input. Only that. Input = mark up. Output = structure.

When you get that order confused or reversed, you make life a million times harder for everyone. People use WordPress precisely to build with HTML/CSS/JS/PHP. They don’t use WordPress in hopes of avoiding HTML/CSS/JS/PHP. There are other platforms and products for that, and they are far less capable. (For a reason!)

As long as you don’t modify a post or page there shouldn’t be any changes in the database.

Right, modifying posts and pages is the last thing anyone would ever do while working in a CMS. [ROLLS EYES]

The same thing just happened to me after updating wp-core and quickly testing out in a sandbox. Site loads? Pages load? Backend looks right? Okay, great, let’s get back to work.

Half a dozen page edits later, O WAIT, HTML that we didn’t touch is getting borked. Why?!

O LOOK, Gutenberg will show it in the HTML view of the editor before and after save, and will give no indication that anything is being modified, BUT will actually save to the DB filtered, rewritten code that’s been sitting there minding its own business for ages.

And you don’t get to see that it’s doing that until you either exit and re-enter the editor and switch to HTML view (at which point the changes are finally visible) or load the actual page and inspect the entire page content to see if things broke.

At the very least there should be a “DISABLE FILTER” button somewhere in the editor to let you bung in whatever code you want. Particularly if it’s W3C valid. Gutenberg has no business going around rewriting W3C validated code, especially doing so without reflecting the changes in the editor, even post-save.

Classic editor does not change the code filtering. You have to install one of the plugins to disable Gutenberg entirely. FYI.