Add New Reusable Block interface displaying blank page #12324
Comments
|
I tested with WordPress 4.9.8 and Gutenberg 4.5.1 using Firefox 63.0.3 on macOS 10.13.6 and was able to go to Reusable Blocks > Add New without any problems.
Testing note: try testing with Chrome and then try testing with WordPress 5.0-RC1 to see if it is a problem happening only with one of those constraints. |
|
This certainly deserves more testing, but I couldn't replicate this bug or find that error in the console. Win 10, Firefox 63.0.3, WordPress 5.0-RC1-43944, Twenty Nineteen, no plugins. |
|
I think it's worth mentioning that I am running the wordpress instance on a "Local By Flywheel" VM. Also here's a complete copy of the console output, in case this helps illuminate the cause. |
|
My tests were also with Local. |
|
Update: If I spin a completely new wordpress install with local and then add the Beta testing plugin and update to "Bleeding Edge Nightly" (In this case 5.0-RC1-43944) I get the error behavior. However if after taking the steps above I also install the plugin called "Gutenberg" the error stops and I am able to see the appropriate page at |
|
Same results when I tested on a new Amazon Lightsail instance. At first broken, then I added the 'Gutenberg' plugin and error stopped. |
|
I tested with WordPress 5.0-RC1-43945 on Chrome 70.0.3538.110 on macOS 10.13.6 and still cannot replicate. Host is Bluehost. I noticed a 403 error in the console output you posted:
Can you verify the API isn't being blocked for some reason? |
designsimply
added
[Status] Needs More Info
|
When I go directly to that url I see json:
|
|
🤔 ok, the API needs to be accessible. I'm not 100% sure whether we're on the right track, but do you have a local firewall or security rules or a security plugin in your local setup even which might be the source of the trouble in this case? I re-tested with a local install running WordPress 4.9.8 and Gutenberg 4.6 |
|
I was able to generate the same issue in new fresh WordPress 5.0 setup. When I tried to add 'Reusable Block', it ended up showing me a blank screen. |
|
@dhirenpatel22 thanks for posting. I also get the same behavior with the new 5.0 release. |
|
I got the same issue on Windows 7 x64, PHP 7.2.12, MySQL 5.6.24, am I supposed to add 'Gutenberg' plugin? |
|
I have a website already for testing themes and plugins and updated to 5.0. Testing Gutenberg by creating a new post from a theme with custom meta blocks to check it works, I get the "update failed" but, it's already published. Not sure what is the problem and the error comes from tinymce. Here are the view and the result. and the console |
|
@M1k3xUr your issue looks unrelated to the rest of the thread here. Based on the error, it appears to be related to this TinyMCE bug tinymce/tinymce#2194. Please try testing with all plugins turned off and using the default theme and again with your custom theme to verify the theme is truly the source of the problem. From there you can either wait for an update from TinyMCE or try adjusting your code to work around the problem defined in the TinyMCE issue. |
|
I re-tested a few more times and was able to confirm that going to Posts > Add New > More (top toolbar) > Manage All Reusable blocks > Add New results in a blank page and the following console errors but only from some servers and not others. In my case, I cannot see the problem if I use a local setup outlined in the Local Environment section in the Contributing documentation, and I cannot see the problem from one of my test sites hosted at Bluehost but I do see the problem if I create a temporary WordPress site using https://jurassic.ninja/. (1m38s)
I also see the same failed API request for
|
designsimply
added
Needs Technical Feedback
|
I have the same issue, but when i installed plugin https://pl.wordpress.org/plugins/gutenberg/ it start work correct. Even I disabled or remove this plugin, it still works. Then it not nginix problem but some wordpress. Something what is changed by installing plugin https://pl.wordpress.org/plugins/gutenberg/ |
|
Greetings, Did a vanilla install of WordPress 5.0.2 via Softalicious installer on Cpanel. Once WP was up, I installed and activated the recommended plugins. Edited the "Sample Page"
Open "Manage All Reusable Blocks"
Edited the "Sample Page" - reopening
Same error as reported here in dev tools |
|
Hello, |
Solved my issueAfter the vanilla install mentioned above I installed the Gutenberg Plugin and I was able to make use of the reusable blocks. |
|
So, I have the same issue. |
|
I've been getting the same issue and did some digging. I noticed that the request URL contains a post ID which is interesting because this only happens when trying to create a new reusable block (editing existing blocks works fine). So I checked my database for the post ID in question and there is a post with that ID with the status |
designsimply
added
[Type] Bug
|
I re-tested today using WP 5.0.4-alpha-44523 and also with WP 5.0.3 using test sites created using https://jurassic.ninja/ and I can still repeat the problem but I found something interesting… if I activate the plugin at any point then it starts working normally even if I subsequently deactivate and delete the plugin! (1m55s) Steps to reproduce:
Result: even if the "Add New" button on the "Manage All Reusable Blocks" wasn't working before, it starts working after the Gutenberg plugin is activated even if it is subsequently deleted. What a strange 🐛!! Seen at https://bad-emu-474.jurassic.ninja/wp-admin/post-new.php?post_type=wp_block tested with WordPress 5.0.3 and with/without Gutenberg 4.8.0 using jurassic.ninja and checked from Firefox 64.0.2 on macOS 10.13.6. |
|
So worked through this a bit today. I posted a lengthy description on the Trac ticket . In summary: the REST API request to the blocks endpoint is returning a 403 error. I believe that this is causing the blank screen error that is being stumbled on. This should be fixed here. A REST API error should not cause a white screen for the user when editing a reusable block. At a minimum, an error message should be displayed with a path forward. When the Gutenberg plugin is activated, the Add New Block page works and it continues to work even after the plugin is deactivated. This happens because the plugin adds block capabilities to the user roles, which are stored in the database. These are not cleaned up after the plugin is deactivated/removed, so they remain and the functionality continues to work. This second issue brings up a bug that could probably be fixed in both locations (Core and the Gutenberg Plugin) so that there is consistency moving forward. The bug in core causing the 403 permissions issue should be fixed, and then, potentially, the plugin should have its capabilities updated to match what is currently in core. |
|
I'm adding this to 4.9 because IMO this is a bug that should be fixed in 5.1. |
|
Agreed, this seems like a critical issue that should be backported to 5.1. Just a small not on milestones and workflow, we use Gutenberg versions (4.9, 5.0...) for PRs and WordPress versions for issues. |
designsimply
added
the
[Priority] High
|
There are a few contributing issues here:
To me then, the actionable items are:
There's still an open question as to whether this ought to have been handled already with the equivalent capabilities mapping. I think the issue here is that the capabilities mapping doesn't occur recursively. The triggering condition occurs on the singular |
|
For testing purposes: If you're unable to reproduce due to having once had the Gutenberg plugin active, installing the following plugin will reset all roles to their default set of capabilities. https://wordpress.org/plugins/reset-roles-and-capabilities/ (You should probably only do this in a local development environment, since there may be unanticipated consequences of resetting roles) |
|
I'm going to close this one as deferred to the corresponding Trac ticket, which has since been closed with a resolution slated for release as part of WordPress 5.1. In #13468, Gutenberg's custom registration of the |
|
hope this helps someone because I ended up on this page when looking for the useless 'publishing failed' error message. For me it was because my session had timed out and all I had to do was refresh the page and retry publishing. Had this happen to clients recently too, not sure if the latest version of wordpress introduced something that's logging people out? |
@condensed-io I don't think so. Also, the session timing out and being logged out are slightly different cases. Check out the issue at #9260 which sounds to me like it's closer to what you've described. |
Describe the bug
Add new (reusable) block feature seems to be broken. When accessing through link on Manage All Reusable Blocks page or directly at
.../wp-admin/post-new.php?post_type=wp_blockError in console:
api-fetch.min.js?ver=2.2.5:1 GET http://gutentest.local/wp-json/wp/v2/blocks/43?context=edit&_locale=user 403 (Forbidden)redux-routine.min.js?ver=3.0.3:1 Uncaught (in promise) Error: [object Object]To Reproduce
Steps to reproduce the behavior:
Expected behavior
I would expect a new reusable block creation interface.
Desktop (please complete the following information):
Additional context
The text was updated successfully, but these errors were encountered: