Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Users without unfiltered HTML capability cannot save pages with cover image blocks without invalidating these #7706

Closed
nbrummerstedt opened this issue Jul 4, 2018 · 8 comments
Labels
[Status] Duplicate Used to indicate that a current issue matches an existing one and can be closed [Type] Bug An existing feature does not function as intended [Type] WP Core Ticket Requires an upstream change from WordPress. Core Trac ticket should be linked.

Comments

@nbrummerstedt
Copy link

nbrummerstedt commented Jul 4, 2018

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?
@designsimply
Copy link
Member

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", …} ).

@designsimply
Copy link
Member

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?

@designsimply designsimply added [Feature] Blocks Overall functionality of blocks [Status] Needs More Info Follow-up required in order to be actionable. labels Jul 5, 2018
@designsimply
Copy link
Member

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

@nbrummerstedt
Copy link
Author

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

@nbrummerstedt nbrummerstedt changed the title Cover image block on mac doesn't save the background Users without unfiltered HTML capability cannot save pages with cover image blocks without invalidating these Jul 5, 2018
@designsimply designsimply added [Type] Bug An existing feature does not function as intended and removed [Status] Needs More Info Follow-up required in order to be actionable. labels Sep 13, 2018
@mtias
Copy link
Member

mtias commented Oct 27, 2018

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

@mtias mtias closed this as completed Oct 27, 2018
@mattrn
Copy link

mattrn commented Feb 6, 2019

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.

@designsimply designsimply added [Type] WP Core Ticket Requires an upstream change from WordPress. Core Trac ticket should be linked. [Status] Duplicate Used to indicate that a current issue matches an existing one and can be closed and removed [Feature] Blocks Overall functionality of blocks labels Feb 6, 2019
@designsimply
Copy link
Member

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 #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.

@mattrn
Copy link

mattrn commented Feb 6, 2019

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
[Status] Duplicate Used to indicate that a current issue matches an existing one and can be closed [Type] Bug An existing feature does not function as intended [Type] WP Core Ticket Requires an upstream change from WordPress. Core Trac ticket should be linked.
Projects
None yet
Development

No branches or pull requests

4 participants