Gutenberg: Users without unfiltered HTML capability cannot save pages with cover image blocks without invalidating these

Created on 4 Jul 2018  路  8Comments  路  Source: WordPress/gutenberg

Describe the bug
Using a Windows computer, I am perfectly capable of creating a cover image block, assigning a background image, adding extra css classes etc. Upon saving, the page is saved correctly and can be viewed.
Opening the same page in Gutenberg on my mac (In both Safari and Chrome), everything looks fine until i Update the page. Viewing the page after Updating on a mac, the cover image is gone (the content is still there). Opening the page in Gutenberg, block validation fails, with the following console log.

screen shot 2018-07-04 at 12 12 25

I have not tried this on another Mac, or on a clean install of the OS. It might be

To Reproduce
Steps to reproduce the behavior:
1: Update a page with a Cover Image using either Safari or Chrome on a Mac
2: Reload Gutenberg Editor - Observe if block validation fails
3: View the post - Observe if the background image for the cover image block was saved.

Expected behavior
Block validation should not fail, and the image should be saved correctly.

Desktop (please complete the following information):

  • OS: Mac
  • Browser: Chrome + Safari
  • Version: Current

Additional context

  • Gutenberg Version: Issue at least present in v. 3.1.0 and v. 3.1.1
  • Software "1password.com" installed on the Mac. Could it be this?
[Status] Duplicate [Type] Bug [Type] WP Core Bug

All 8 comments

Error message in plain text for reference:

Block validation: Block validation failed for core/cover-image ( {name: "core/cover-image", title: Cover Image", description: "Add a full-width image, and layer text over it - great for headers, icon: {鈥, category: "common", 鈥 ).

I tested with WordPress 4.9.6 and Gutenberg 3.1.1 on Safari 11.1.1 on macOS 10.13.5 and did not see any problems with a test Cover Image block or any console errors.

screen shot 2018-07-04 at wed jul 4 6 17 34 pm
Seen at http://alittletestblog.com/2018/06/27/cover-image-block-test/ running WordPress 4.9.6 and Gutenberg 3.1.1 using Safari 11.1.1 on macOS 10.13.5.

Software "1password.com" installed on the Mac. Could it be this?

馃 that doesn't seem likely to me.

You mentioned you're using a current version of Safari, would that be version 11.1.1? May I ask what version of macOS you are running? (I am not sure it makes a difference but I know it is good to note the version.)

Does this happen on every post or page you try? If you put a Cover Image block alone on a test page and try the same test does the problem still happen?

@nbrummerstedt are you using a multisite install by chance? See #2539.

Hi @designsimply,

Thank you for pointing me in the right direction.
I can now report that the bug is absolutely not related to OS or browser.
On my mac, I was using a test user with user role "Shop Manager" from WooCommerce. On my PC, I was using the default admin user. The difference between the two is indeed that the shop manager does not have the unfiltered html capability. Enabling unfiltered html for a user role removes the problem.

Actual issue
Users with unfiltered html disabled will not be able to edit pages with cover images without removing these. I think this is a serious bug indeed. All blocks should work for all users with edit capabilities.

Regards,
Niels

This should have been addressed by https://core.trac.wordpress.org/changeset/43781

I am experiencing what seems to be the same Issue on Wordpress 5.03.
Like @nbrummerstedt I created a custom Block that lets the editor choose the background Image for a Hero section.

I created a post as Admin and whenever I edit this post as Editor the Image gets removed and the block breaks.

I am also running a multisite installation and granting the Editor the unfiltered html capability(via https://wordpress.org/plugins/unfiltered-mu/) fixes the problem.

I tried re-testing the original reported case from this issue by adding a cover block logged in as a super_admin and also as an author role (no unfiltered_html capability) using WordPress 5.0.3 Multisite with subdomains and then refreshed the saved post, and the background image worked normally for cover blocks in my test. I believe that my test was good and that the cover block issue, which is the one originally raised here and at https://github.com/WordPress/gutenberg/issues/2539, was fixed. Can you confirm this by adding a cover block to your site as an admin and then checking to see what happens to that block when you open it after logging out and logging back in as an editor?

Don't forget to deactivate https://wordpress.org/plugins/unfiltered-mu/ while testing!

If the cover block works correctly for you, then it's possible the problem lies with the custom code and I would recommend starting at either https://wordpress.org/support/forum/wp-advanced/ or https://wordpress.stackexchange.com/ to ask for help with that. If you feel strongly it's a bug, and you are able to document with steps to reproduce and some sample code either from your custom block or something similar that you can provide as an example, then it would be okay to open a new issue in this repo to ask for a check. The more clearly you can document it, the easier time someone may have helping to sort it out. In either case, I would recommend documenting the following:

  • Current WP version (you already mentioned this one, WP 5.0.3 Mulstisite / Editor role, 馃憤).
  • Note whether you've tested the cover block and what happened.
  • Include the full block validation error from the browser console (or a screenshot of it).
  • If the cover block works normally but your custom block does not, including a code sample and steps to reproduce can really help someone get setup the best way possible for debugging.

I was under the wrong impression that this is about a custom block, sorry about the fuzz.

Regarding this issue, I tested the cover block with my setup and can confirm it is working as expected.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

DeveloperWil picture DeveloperWil  路  102Comments

melchoyce picture melchoyce  路  169Comments

ahmadawais picture ahmadawais  路  101Comments

afercia picture afercia  路  78Comments

smp303 picture smp303  路  98Comments