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

Blank page when editing custom post type #12148

Closed
elliotcondon opened this issue Nov 21, 2018 · 10 comments · Fixed by #12151
Closed

Blank page when editing custom post type #12148

elliotcondon opened this issue Nov 21, 2018 · 10 comments · Fixed by #12151
Labels
[Priority] High Used to indicate top priority items that need quick attention [Type] Bug An existing feature does not function as intended [Type] Regression Related to a regression in the latest release
Milestone

Comments

@elliotcondon
Copy link

Describe the bug
CPT edit screen is no longer working.
White screen (not of death).
ACF is completely broken.
You can no longer edit a field group.

To Reproduce
Steps to reproduce the behavior:

  1. Install Gutenberg 4.5.
  2. Install ACF (any version).
  3. Navigate to the "Custom Fields > Add New" page .
  4. Notice the lack of anything.

Expected behavior
ACF CPT should appear as expected with the classic editor edit page.

Screenshots
screen shot 2018-11-21 at 2 11 14 pm

Additional context

  • This was not an issue with Gutenberg version 4.4
@andremacola
Copy link

If you have the Classic Editor installed, you can use the dropdown menu and all works fine. But this is not the correct solution.

captura de tela 2018-11-21 as 00 48 53

@pento
Copy link
Member

pento commented Nov 21, 2018

Thank you for the bug report, @elliotcondon!

I can reproduce this same bug, it seems to be a regression caused by #12000.

@pento pento added [Type] Bug An existing feature does not function as intended [Type] Regression Related to a regression in the latest release labels Nov 21, 2018
@pento pento added this to the WordPress 5.0 milestone Nov 21, 2018
@pento
Copy link
Member

pento commented Nov 21, 2018

Ah, I see. It's because adding user_can_richedit() to the gutenberg_can_edit_post/gutenberg_can_edit_post_type filters will cause them to always return true if the current user has rich editing enabled. This will override the other checks that a CPT can work with the block editor.

I suspect that #12000 was the wrong approach here: rather than falling back to classic when rich editing is disabled, we should still load the block editor, but default to the code editor view, or perhaps a HTML block.

The fix for this should also include e2e tests confirming that CPTs that don't work in the block editor won't try to load it.

@thmarx
Copy link

thmarx commented Nov 21, 2018

I run into the same problem. Until it is fixed and released, I use this workaround:
add_filter('user_can_richedit', "disable_richedit", 10, 1);

public function disable_richedit($is_enabled) {
if (get_post_type() === "my_post_type") {
return false;
}
return $is_enabled;
}

@anantajitjg
Copy link

Same issue for me...I hope it will be fixed soon....

@merc28
Copy link

merc28 commented Dec 13, 2018

@thmarx I'm wondering if I should try this fix or try rolling back the 5.0.1 update.

I run into the same problem. Until it is fixed and released, I use this workaround:
add_filter('user_can_richedit', "disable_richedit", 10, 1);

public function disable_richedit($is_enabled) {
if (get_post_type() === "my_post_type") {
return false;
}
return $is_enabled;
}

@merc28
Copy link

merc28 commented Dec 13, 2018

I tried just deactivating my TinyMCE Advanced editor but it didn't help. So I assume this is a gantry 5 or an issue with my isotope rocket theme

@BramPeerlings
Copy link

Related; #12442

@merc28
Copy link

merc28 commented Jan 28, 2019

I found on the WordPress support forums that they have a quick fix: a script that restores the classic editor which then fixes this bug.

@alexnl
Copy link

alexnl commented Feb 6, 2020

I had this same issue. The following in register_post_type will fix the issue:
show_in_rest => false
This uses the classic editor for the post type as opposed to Gutenberg.
I realize this is not ideal and does not "fix" the issue. Commenting it here in case someone needs it working temporarily while the issue is debugged.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
[Priority] High Used to indicate top priority items that need quick attention [Type] Bug An existing feature does not function as intended [Type] Regression Related to a regression in the latest release
Projects
None yet
Development

Successfully merging a pull request may close this issue.

8 participants