CUNY Academic Commons

Thanks, Jeremy. See also #20692.

I've removed the Gutenberg update (to 18.9) from my update batch for August 28. Instead, it'll go into the Sep 24 release, along with the WP 6.6.x update. Please continue to update this ticket or the other one as you figure this all out.

This is entirely frustrating. I thought I had it and then poof... How to start.

I guess first: Gutenberg as a framework is the future for the CV editor project. It is generally possible to build an editor using components in Gutenberg that have been written in a way to make them appropriately reusable.

I tried this and got pretty far. It's a little annoying because things have been forced into an iframe, but not too bad. I got hung up on trying to provide the list view interface, which I personally think is valuable in a complex document like we've provided for CVs. The <ListView /> claims to be reusable, but I was not having much luck and after sinking a bit of time into it decided that it'd be better to try and fix selective bits and save the rebuild for another day.

So. I forked the isolated block editor and stripped a bunch of stuff out of it to try and make it easier to wrangle. I changed the private API unlock string, updated Gutenberg, and it worked. Great stuff.

Then I created a new package, wp-super-unlock, with the idea that we could theoretically support multiple versions of WP/Gutenberg and their private API unlocking strings, helping us for future upgrades.

This all worked great as I stepped through Gutenberg 18.4.1 to 19.1.0. Then I updated to WordPress 6.6 and it all broke. Because I missed the key line in all of this fancy private API stuff:

Pretend to register a @wordpress package (and trigger an error as soon as the real package is loaded)

In WordPress 6.6, instead of just throwing an error when the string is wrong, it says that the package I'm pretending to be (@wordpress/edit-post) has already registered for private APIs.

Which goes back to the beginning. I think the way this moves forward is with a full split from the isolated block editor and a sort of reimplementation with public components provided by Gutenberg. The good news is that all of the components/logic we've built around the actual editor interface (i.e. update, save, cover modal, notices) all still work.

I'm still processing what I would do next here, but I think the viable options are:

• New editor interface, without list view (very close, though not close enough for this month)
• New editor interface with some kind of list view (this may involve Gutenberg bug reports, etc...)

I think either way, we miss WP 6.6 this month. I don't have the bandwidth to push hard on this again for a couple weeks, though I will be around a few folks I can pester in person during WordCamp US, so that may provide helpful inspiration.

Wow, sounds like a complete headache, Jeremy!

Then I created a new package, wp-super-unlock, with the idea that we could theoretically support multiple versions of WP/Gutenberg and their private API unlocking strings, helping us for future upgrades.

This all worked great as I stepped through Gutenberg 18.4.1 to 19.1.0. Then I updated to WordPress 6.6 and it all broke.

I'm not up-to-speed with everything that's been going on with the Isolated Block Editor and Gutenberg, but I saw a Github comment that took a similar approach to your wp-super-unlock -- https://github.com/Automattic/isolated-block-editor/issues/260#issuecomment-2233961187 -- and that person says his workaround is working on Gutenberg 6.6. Instead of forking the Isolated Block Editor, the user added an additional npm package, replace-in-file, to re-add the private API declarations. In the same Github ticket, another user worked around this by copying the private API JS from before WP 6.6, deregistered the WP 6.6 one and included the older one in their plugin. Would either approach work for us in the short term, Jeremy? Perhaps you've already ruled these approaches out because our CV implementation is more complicated with the ListView component, etc., if so, forget I said anything!

copying the private API JS from before WP 6.6, deregistered the WP 6.6 one and included the older one in their plugin

Ray, thank you so much. You have no idea.

I had seen that comment, but glossed over it originally thinking that updating the string would just work and then completely forgot about it.

We're back in business with the fix/cv-editor-wp-compat branch.

• I added our own private-apis.js script and updated it to allow all private APIs. We're effectively working outside of WordPress here, so I'm totally okay with this approach.
• WordPress 6.6 also removed the regenerator-runtime dependency by default, which the isolated block editor requires. That is injected as a dependency before the script enqueues.
• I stuck with the forked isolated block editor (now an NPM package) so that we have control over dependency updates, etc...

• WordPress 6.5, no Gutenberg
• WordPress 6.5, Gutenberg 18.4.1 (current)
• WordPress 6.5, Gutenberg 19.1.0
• WordPress 6.6, Gutenberg 19.1.0
• WordPress 6.6, no Gutenberg

Okay, I poked around some more with this. There's one small UI fix I need to make in the toolbar—I'll address that today.

Boone - I think we can merge this branch (@fix/cv-editor-wp-compat) when we ship WordPress 6.6 and Gutenberg 19.3.0. I've tested with multiple versions of Gutenberg and none have caused an issue, so that part is flexible.

I'll do some advanced testing with the 6.7 beta shortly as well so that we can be ahead of anything.

Thanks! I'll review this before the release in two weeks.