Wp-calypso: CoBlocks Post Carousel: Conflict with Gutenberg on AT sites

Created on 21 Apr 2020  ·  16Comments  ·  Source: Automattic/wp-calypso

Steps to reproduce

  • Testing with Twenty Twenty theme on a WordPress.com AT site.
  • The Post Carousel block being used is from Coblocks coblocks/post-carousel
  • With Gutenberg (v7.8.1) and Coblocks (v1.24.0) active, I get an error when inserting the first post carousel block, or trying to access the Feed Settings options for the block:
  • TypeError: Cannot convert undefined or null to object in https://c0.wp.com/c/5.4/wp-includes/js/dist/vendor/react-dom.min.js
  • Turning off the Gutenberg plugin allows the post carousel block to work as expected.

Context / Source

user-report

p9F6qB-57X-p2

Atomic Blocks [Pri] High [Type] Bug

All 16 comments

cc @Automattic/ajax

Would be good to know if upgrading to Gutenberg 7.9.1 fixes this, as we're doing that soonish (p7DVsv-8tt-p2, pbAok1-Fu-p2).

Can confirm that this is reproducible in 7.8.1 but is fixed in 7.9.1 :tada:

It was fixed here.

Edit: I didn't test this properly.

I have tested this in core WP install, with Gutenberg and CoBlocks plugins straight from the plugin repo, latest versions, and I can replicate the bug.

It has nothing to do with our custom wpcom version (which runs only on Simple) but seems to be a Core vs CoBlocks bug.

@alshakero that's core's latest-posts block though?

@marekhrabe would be great to make sure there's an issue open for this at CoBlocks repo.

@alshakero I haven't yet seen your comment when I posted mine. I can reproduce the issue in WP w/ CoBlocks 1.24.0 & Gutenberg 7.9.1. Can you confirm?

The link to fix you have posted is for the Latest Posts block from core, which has no relation to CoBlocks. Would it be possible that Latest Posts was updated to break the incompatibility with the Category selector and CoBlocks must do a similar fix?

I'm double-checking right now.

You're right. It seems the categories get cached and the issue isn't always happening. I could repro in 7.9.1.

OK, I did some investigation and I can't figure out what's going on exactly.

But I have some interesting findings:

  1. The bug is reproducible on both WordPress 5.4 and 5.5-alpha.
  2. The bug isn't reproducible in Gutenberg v7.9.1 locally.
  3. The bug is reproducible in Gutenberg v7.9.1 on an AT site 🤷‍♂️

I found that this issue isn't reproducible locally in Gutenberg master. But here is some info on how to reproduce it.

On your machine:

  1. Clone Gutenboarding#master.
  2. Setup your env as instructed in Gutenberg docs.
  3. Install Co-blocks extension on your local site.
  4. Checkout commit 4cc8121c95b507809056fca158b6bae60ed22157 the issue should be reproducible.
  5. Checkout commit 16e4f2032777d63984d0dbf53569018c10f77dca the issue should be fixed.

These commits come right after each other. Meaning the latter fixes the issue. Although I couldn't find why.

Thanks for confirmation. I was using Jurassic.ninja sites and on some of them, I can no longer replicate the issue. Some sort of cache might be in play here.

The error, as I understand it, comes from passing null/undefined to the category selector that Posts Carousel block uses (it has category picker in its inspector controls). This happens when you insert the block but the list of categories is not fetched yet.

A wild and unconfirmed guess - if something did change around the way sidebar is instrumented and initialized (which looks like it did in one of those commits you link), I think it might be possible that the sidebar previously pre-fetched categories for its own use, because it also has the same control which you use to set category for the post. That way categories were actually always loaded before you had a chance to insert any block and the Posts Carousel never had to deal with the empty category list.

Nothing confirmed but I think it might be worth checking and adding some guard against empty categories to CoBlocks or into the category selector component directly.

I have another example of this in #20941806-hc

Steps to reproduce:

User has added the Post Carousel block on their Atomic site.
When clicking on "Feed Settings" in options panel we get:

"This block has encountered an error and cannot be previewed."

https://d.pr/i/cFG82W

Deactivating Gutenberg plugin resolved the issue.

Possibly another example: #22208321-hc, #3097186-zd

Steps to reproduce:

  1. Add CoBlocks/Post Carousel Block on AT site
  2. Go to Feed Settings to add a category, and this happens:

https://www.loom.com/share/b25346fce80c47e0b76b6665c39e46f9

The same thing happens for **Posts block.

I am NOT able to reproduce the original issue with the error on inserting the Posts Carousel. Is anyone still able to reproduce this part (and perhaps have any more specifics)?

I am able to reproduce @rosepajaroja 's issue - Adding a category gives a rest param error (and infinite loading spinner):

Screen Shot 2020-07-06 at 3 36 30 PM

  • I also reproduce this on a local install with only Gutenberg and CoBlocks activated.
  • on atomic - deactivating Gutenberg 'fixes' this in the sense that you can no longer type in your own category and must select it from a dropdown list
  • on local install - deactivating Gutenberg does not fix this (more recent version of core WordPress I'm guessing is why?) 🤔

I tried to test on simple sites for comparison, and encountered another issue there blocking me from doing so (created #43920). On simple sites, the block can't seem to find my posts the same way 'Blog Posts' or 'Latest Posts' blocks do:

Screen Shot 2020-07-06 at 3 26 40 PM

@Addison-Stavlo I'm _not_ able to reproduce the original issue with Posts Carousel on up to date versions of Gutenberg/CoBlocks.

Created an Issue for the Categories bug at CoBlocks - https://github.com/godaddy-wordpress/coblocks/issues/1561 - given this is reproducible locally without Gutenberg (or any other plugins) on WordPress 5.5.

This is now fixed in this PR. https://github.com/godaddy-wordpress/coblocks/pull/1576
Included in CoBlocks 2.1.0.

Was this page helpful?
0 / 5 - 0 ratings