I had a user who had trouble with editing new gallery blocks within their posts, and it has only been happen recently with their new posts. When they try to add a gallery block, they receive different messages based on which browser is being used, as see in the below screenshots.
I'm having a hard time replicating what I saw while speaking with the user, but it seems to have been happening several times with others. Since I didn't see a prior issue mentioning this, I'm opening this bug report here.
For the gallery block to allow me / the user to add new images from their media library or via uploading in the usual manner.
The new block displays the message To edit this block, you need permission to upload media
and will not allow any option for the user to add new media.
Furthermore, where the user used a different browser to add a gallery and I went to check again via SU, the gallery block is displaying a different message saying This block contains unexpected or invalid content
with options to fix it; I elected not to click them since the post preview seems to display the user's image.
Safari, but also for me in Chrome when editing the user's post via SU.
^ First screenshot, while working with user in livechat. This actually happened to me while I was in Chrome during livechat rather than Safari
^ Second screenshot while double checking in the user's account. Note that both of these are gallery blocks, but the one on top is the one the user must have edited in another browser after I provided that suggestion in livechat. It shows that it was a Gallery block in the sidebar, however.
Meanwhile, the second block was one I added recently, which seems to display exactly what I had expected.
Livechat 184115-hc
Blog 82343472
p1548695461570500-slack-livechat
This only seems to be happening in this user's account as I wasn't able to replicate it in mine, but in the Slack discussion, it'd been mentioned to happen for other users who were using Safari.
This is a recurring bug that I've seen across at least four other tickets.
Switching browsers seems to fix it every time. It seems specific to Safari.
The gallery block tells the user that they need to be the owner to use it. In all cases I've seen there have been no other users on the site. Will post links here.
Another report here:
HC-5421615
User had issues switching browsers, so we ended up switching them to the classic editor and that resolved it for the time being.
Is this reproducible in all Safari versions, or did anyone happen a specific number?
I wasn't able to reproduce this, but it likely requires more steps. I tested on a private and public site in Safari so far.
I recreated this on Chrome unintentionally, I didn't do anything special which I'd imagine could cause this. If it helps though, it happened on my private test site.
With an Image Block
A few refreshes later and it's gone. :thinking:
Oh interesting @torres126, maybe this suggests a race condition then.
As @torres126 mentioned I was able to view this error in my Chrome browser as well (Version 71.0.3578.98), but only when I SU'd the user's account and viewed their drafted post; I couldn't recreate it on my account's test sites yet.
When I suggested for the user to switch to a new browser I mentioned Firefox or Chrome, but the user said that they were able to fix it by switching to Internet Explorer (Version unknown). And after taking another look at the livechat, the listed browser where the user had this error was actually for Firefox (Version 52.0).
I heard that this issue was most persistent for those using Safari, but maybe it's actually not browser specific? Also interesting that it seems to be affecting image blocks as well.
Also reported in:
HC-9605430
HC-1476988
ZD-1714227
Probably not browser specific, either a caching issue or a race-condition from how the editor is being initialized. We'll try and have folks investigate soon on this.
Related placeholder code in Gutenberg core: https://github.com/WordPress/gutenberg/blob/3fd221845bfb6b3c553368b8b3cfbcc29452932f/packages/editor/src/components/media-placeholder/index.js#L264
This should be added to the userPermissions reducer, but I do wonder if multiple redux stores are accidentally being created.
Still not having luck reproducing, but I'll see if listening to the RECEIVE_USER_PERMISSION
redux action leads me anyplace.
Where this action is generated:
https://github.com/WordPress/gutenberg/blob/3fd221845bfb6b3c553368b8b3cfbcc29452932f/packages/core-data/src/resolvers.js#L125
@TeniCola you didn't happen to have a capture of the HTML for that post when it showed the "unexpected or invalid content" message did you?
If you can reproduce it, could you enter the code view for the editor and copy/paste the HTML here? You can either get to the code view through the editor menu in the top-right corner (with the three vertically-stacked dots) or through the shortcut (on Mac at least) of ⌘ + ⎇ + shift + m
Probable report in this thread, I checked their site linked in the thread and they seem to own it. It also seems to be a new site.
@dmsnell Originally I didn't, as I wanted to avoid having any changes auto-saved in the users account. But I just returned to the user's account and saw that the error block is still there.
When I used the code editor shortcut you mentioned, the HTML code that displayed for the broken gallery block was this:
<!-- wp:gallery {"ids":[]} -->
<p> </p>
<!-- /wp:gallery -->
...Which differs from the way that an empty, editable gallery block appears:
<!-- wp:gallery -->
<ul class="wp-block-gallery columns-0 is-cropped"></ul>
<!-- /wp:gallery -->
Here's a gif to demonstrate how it looked between views (also notice in the sidebar that the "Advanced" panel is not available for the broken gallery block):
@TeniCola the broken block looks suspicious
<!-- wp:gallery {"ids":[]} -->
<p> </p>
<!-- /wp:gallery -->
It's suspicious not only because of the fact that it's empty inside but also because of the space inside the <p>
tags. I don't think that the Block Editor should produce that in its output.
Is there a way we can look at the revision history and see if this content was manually edited as HTML? If that was entered in by hand vs. generated from the block we would be conflating two separate issues. If that _was_ generated in the editor we might have some Javascript error causing some weird behaviors, though I would expect things to break in bigger ways at that point, like freezing the editor. We can look for console warnings too.
This helps though, thanks for getting that HTML. I suppose we still haven't been able to recreate this on block insertion?
@dmsnell I checked the user's revision history in both calypso and wp-admin but there only seem to be two restore points, which is the one I might have created when I visited 50 mins ago, and when they first created their post 4 days ago.
Even looking at the recent revision point, I'm not sure how much sense it makes...
The only thing I changed was inserting a new gallery block for comparison (within the block editor), and then removing it afterwards before I SU'd out, so there should be no other changes. The broken block was there when I first entered the post, but the revision history suggested that it added itself later... which I'm really not sure what to make of, or how to fine tune each change that was made.
Not sure how helpful this would be, but it's what I'm finding so far. And correct, I still can't replicate this gallery error within my own test sites; even now the block are working as expected for this user's account, save for this one that broke following our livechat
@TeniCola I think something unexpected happened there in that change from "52m ago." was this edit inside the classic editor, maybe? or possibly in the mobile app? that revision history adds evidence to me that the block was broken due to an out-of-the-Block-Editor change.
if this is the case then it can help us focus in on the other block and what caused it to not work as expected. it could explain why we haven't been able to recreate the broken block too
Another report here in HC-10125231
User was having trouble adding a video to a block and getting the error: "To edit this block, you need permission to upload media." Was able to add the video using Chrome.
Not sure if it's related here but I surfaced an error where an API call failure resulted in setting the author
attribute of the post to [ "e", "r", "r", "o", "r" ]
and then all my permissions were messed up. I'm curious if we can reproduce this if we can go into that post and run this in the browser's console…
wp.data.select( 'core/editor' ).getCurrentPostAttribute( 'author' )
Another report of this issue in #10159795-hc. User mentioned they had just upgraded from Blogger plan to Personal plan and had not experienced this issue before that. They are using Chrome. Switching to another browser resolved the issue.
Another report in HC-10196918.
The site is WP BIZ
(not AT yet). Was trying to add an image in the Simple Payments block and is getting the error given your current role, you can only link an image, not upload
(screenshot noted in transcript)
Another report in #10212857-hc.
The user was using Chrome. Using Firefox worked. Asked the user to clear browser cache and cookies in Chrome and that worked as well.
Another report in #10231486-hc. User tried clearing cache but there was no change.
Another report of this same bug (HC-2071367), the account is 3 years old and the user had never experienced this error before now.
I asked the user to trying logging in/out or to try another browser, and then offered the Classic block workaround if it didn't work. They left the chat at my EOS to log out, but haven't seemed to return yet, so it may have worked.
Sorry for any delay with replies tho, I'll try to revisit that same user's post once I have a break from core shifts, if the post is still there. Then we can see if running that function (?) in the browser console produces any interesting results @dmsnell
@dmsnell Sorry for the extra ping but I just tried to run the function you have mentioned for the post with the broken block (within Chrome DevTools > Console), just wanted to check if this is the type of output you were expecting...?
The very bottom one, at any rate, since the others had appeared from the the moment I checked the console. But admittedly I'm not sure if I ran the script correctly since it's mentioning a reference error. Would you be able to navigate to the user's post in SU mode to check within the post editor?
User ID 78401221, the drafted post titled "...wie lange denn noch..."
Another report in 9987221-hc. The user is using Google Chrome. Suggested trying another browser but didn't get a reply.
@TeniCola I see that's probably the Calypso view - we need to run that code from wp-admin
or with an iframe version of the editor - sorry for not making that clear. I'll see if I can circle back to this soon.
Another report 10304734-HC. User is using Google Chrome. Suggested new browser.
Chrome on Mac 10136138-hc
Safari worked for them, but not Chrome.
They're working with the image block in this case, not gallery, so media upload generally seems to have this issue.
Another report on 10045735-hc
User was working in Safari, but they were able to use Chrome to edit blocks normally.
They had trouble with the Media and Video blocks.
Another report on 4688379-hc
I have usually seen this issue getting resolved on logging out and logging back into their WordPress.com account. That is what I suggested too to this one as well as to a bunch of other users in the past.
Though I will ask for the browser and the type of block they are using when faced in the future.
User reported it in 8785531-hc, but ghosted after their message.
I've followed up with them for more info in 1804916-zen.
Report here in regards to the Image Block: https://en.forums.wordpress.com/topic/image-uploading-permission-issue/
I had the same issue recently on a test site, on Chrome. I added a column block and when I tried to add an image on one column it showed _"given your current role, you can only link an image, not upload"_. I just opened the same post on WP-Admin and it showed correctly, once back to Calypso, it was working again.
This happened to me in Chrome's latest version. I had just registered and made a domain primary, when this message appeared in the post editor:
To edit the featured image, you need permission to upload media.
I had been able to add images before registering the domain.
When I refreshed the page, the message disappeared and I could upload images again.
Another report in 1816342-zen
I had the same issue with my test site too. The site is made last year (2018), and just recently I changed the editor to Block Editor. Somehow this happened only on this test site (WP BIZ/Simple) while others seem to work well.
I refreshed the page; the message disappeared and I could upload image(s)
My browser is Chrome.
So @mmtr noted this section in https://github.com/Automattic/wp-calypso/pull/30848, which runs a permission check only once per browser refresh (navigating to the section doesn't refire this) and has no error handling if the network request fails.
For example one error state that's pretty easy to reproduce is within a single navigation session, upgrade to a new plan and see that blocks do not reflect the feature gating of the new plan.
This may be contributing to the number of reports seen on this issue. So two things to fix here:
Chrome 10505430-hc
Another report: 1828249-zen
So @mmtr noted this section in #30848, which runs a permission check only once per browser refresh (navigating to the section doesn't refire this) and has no error handling if the network request fails.
Unfortunately, that behavior is unrelated to this. The issue with loadGutenbergBlockAvailability
not being executed after a plan upgrade/downgrade only affects to Jetpack blocks / extensions and not to the gallery or image blocks (which is where the message requiring upload permissions is displayed).
I have not been able to reproduce this yet (tried different scenarios like upgrading/downgrading a plan in the same browser session or setting a site as private without luck) but I wonder if this can be solved by preloading the OPTIONS
request to /wp/v2/media
before initializing the editor like Gutenberg does (#).
Note that the above won't be required as soon as we move away from Gutenlypso and we start embedding Gutenberg in a iframe.
Thanks @mmtr maybe let's focus on helping ship Gutenframe more quickly then to see if these issues resolve.
+1, 9948701-hc
Safari using Gallery and Image block: 6970373-hc
Chrome using Gallery block: 7636709-hc
Adding another occurrence via 10795245-hc
Another case in 2988107-hc
Since we still unable to reliably reproduce this issue, and we've deployed a new integration of Gutenberg on #31196, I'll be closing this issue. Please, reopen if there's another report.
This is happening to me with the image block, logged in as Admin and using FireFox Developer 73.0b8 (64-bit). OS X (10.15.2 (19C57)) and WP 5.3.2. Happens on Safari as well. I've checked roles and everything is fine, I am able to upload files to the gallery folder.
Have logged out, refreshed and nothing seems to work, any pointers are greatly appreciated.
Please ignore that, it has to do with something in my theme code, if it's relevant I'll post here, but it's definitely something on my end.
Most helpful comment
Also reported in:
HC-9605430
HC-1476988
ZD-1714227