Table of contents
Of course, we could have been cheeky, and called this article: Navigating Compatibility Challenges: A Close Look at Gutenberg 16.0.0. But this article is not only here to elaborate on an issue in Gutenberg that was finally resolved.
It’s to confirm to anyone that partaking in the discussions and bug reports on GitHub is a sensible thing to do! This is part of sharing our WordPress Community journey. Because, no matter from what angle we’re looking at this: in the end it’s WordPress that is the means to our daily bread and butter.
Building on the Block Editor
As a team that builds their product natively on the Block Editor, our mission is to ensure 100% compatibility. It’s an essential aspect of providing a seamless user experience. However, Gutenberg updates often include far-reaching changes that aren’t always fully traceable or documented. That’s why we engage in extensive testing before recommending any new core updates to our customers. Our backend always contains the latest information on the supported versions to keep our users informed.
We ran into a major issue
During our recent testing with Gutenberg 16.0.0, we encountered a significant problem related to iFrame enqueuing. (Please bear with us, if all these technical terms confuse you, an explanation is added at the bottom of this article!)
The introduction of the enqueue warning led to many console warnings, especially when changing the preview to “tablet” or “mobile.” As a result, both our processed styles and inline style elements were now “wrong.” Although these warnings were not immediate issues, they led to a fatal error when switching back to Desktop. The selected block would become uneditable, displaying the message, “An error has occurred in this block and a preview is not possible.”
We went to look on GitHub if anyone else had already reported this issue. We found it mentioned in the pull request made by ellatrix though it had been linked, it remained unanswered for several weeks. As we are new to the ways to contribute code or suggestions to the Gutenberg Project, we incorrectly assumed this was part of a ticket (bug report).
The Impact of the Issue
This was a substantial problem for us. Most of our styles are dynamic, based on the greydStyles concept. A modification was not possible. Our style processing is also vital in the classic suite, for the correct application of thememods. We found that other tools like Editor Plus were also affected, with no apparent solution.
Taking Action
Recognizing the gravity of the problem and its impact on the WordPress community, we did something that is probably not the most elegant way to handle things, and we hope we did not offend anyone by doing so. We reached out to Birgit Pauli-Haack, knowing she is a member of the 6.3 release squad.
An Important Lesson
From Birgit we learned that the reason there had been no response, was that it was already a merged PR. Once merged, it doesn’t get much attention beyond the release. She explained: “So, although the issue was severe, it was reported on page 10 instead of Page 1 and with the effort to respond to new bug reports coming in, a comment on an already completed PR doesn’t get much notice.” Thank you, Birgit, that’s a lesson learned and one we happily share here for others to learn.
At her request, we created an official ticket regarding the iFraming problems when switching Preview (Issue #52648). It was then promptly forwarded it to the relevant parties.
A Swift Resolution
The collaborative effort bore fruit, and the issue was resolved within a few days, to be included in WordPress Release 6.3. We’re so happy! Especially knowing that more people and plugin companies will benefit from the solution. It has been added to the dev notes on Make WordPress.
Conclusion
The swift resolution of the issue demonstrates the strength of the WordPress Developers Community. We remain dedicated to keeping pace with its evolution, ensuring that our users always have the best possible experience, free of any hindrance or glitches. We want to thank all people involved in core and the Gutenberg project, and we promise to walk the right way, next time.
The geek speak translation of some of the terms in this article
The issue with the console warnings, in non-technical terms:
Imagine trying to read a book, but every time you turn the page, you see a warning message that something might be wrong. That’s a bit like what happened with a recent update to the software we use. When trying to see what a website would look like on a tablet or mobile phone, this update started showing many warning messages.
Everything still seemed fine at first, but when switching back to see what the website would look like on a regular computer (Desktop), a big problem occurred. It’s as if one of the pages in the book became glued together, and you couldn’t read it anymore. On the screen, you would see a message saying, “An error has occurred in this block and a preview is not possible,” meaning you couldn’t work on or even view that part of the website anymore.
What a “pull request” means, in non-technical terms:
In WordPress, different people contribute to the software by writing pieces of code to add new features or fix issues. When someone finishes their part, they submit a “pull request.” This is like raising their hand and saying, “Hey everyone, I’ve made some changes or added something new to the WordPress project. Could you please take a look and consider adding it to the main project?”
