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

5.1.1: PHP Fatal error: Uncaught Error: Call to undefined function use_block_editor_for_post() in wp-content/plugins/gutenberg/lib/register.php:36 #14012

Closed
lkraav opened this issue Feb 21, 2019 · 9 comments · Fixed by #14096
Labels
[Type] Bug An existing feature does not function as intended [Type] Regression Related to a regression in the latest release

Comments

@lkraav
Copy link

lkraav commented Feb 21, 2019

Describe the bug
It's related to deprecated gutenberg_can_edit_post().

I was using Toolset Views conditional shortcode like follows: [wpv-conditional if="( gutenberg_can_edit_post( [wpv-post-id] ) )"]

This, very recently (either core 5.1rc2, or Gutenberg plugin 5.1.0 release) started crashing, after working error free for nearly a year.

Traceback:

[21-Feb-2019 14:39:30 UTC] PHP Notice:  gutenberg_can_edit_post is <strong>deprecated</strong> since version 5.0.0! Use use_block_editor_for_post instead. in /wp-includes/functions.php on line 4329
[21-Feb-2019 14:39:30 UTC] PHP Fatal error:  Uncaught Error: Call to undefined function use_block_editor_for_post() in /wp-content/plugins/gutenberg/lib/register.php:36
Stack trace:
#0 /wp-content/plugins/wp-views.git/embedded/inc/wpv-condition.php(707): gutenberg_can_edit_post('839489', 'posts', Object(WP_Post))
#1 /wp-includes/class-wp-hook.php(286): wpv_add_wpv_if_functions_support('( gutenberg_can...')
#2 /wp-includes/plugin.php(208): WP_Hook->apply_filters('( gutenberg_can...', Array)
#3 /wp-content/plugins/wp-views.git/embedded/inc/wpv-conditional.php(830): apply_filters('wpv-extra-condi...', '( gutenberg_can...')
#4 /wp-content/plugins/wp-views.git/embedded/inc/wpv-conditional.php(684): WPV_Views_Conditional::parse_conditional(Object(WP_Post), '( gutenberg_can...', false, Array, 839489, true)
#5 /wp-includes/shortcodes.php(325): WPV_Views_Conditional->wpv_shortcode_wpv_conditional(Array, '\n<a class="post...', 'wpv-conditional')
#6 [internal f in /wp-content/plugins/gutenberg/lib/register.php on line 36

Expected behavior
gutenberg_can_edit_post() should be able to forward to use_block_editor_for_post() from all angles.

Additional context
It's weird, because use_block_editor_for_post() is defined in wp-admin/includes/post.php and I would expect that to be always loaded, right...?

@radar6
Copy link

radar6 commented Feb 25, 2019

I have same problem. Guttenberg should check the functions if they exist before using them

@radar6
Copy link

radar6 commented Feb 25, 2019

Actually I cannot view orders in Woocommerce and reset password and other things. Bug is in Guttenberg.

@youknowriad
Copy link
Contributor

Which WordPress version are you using?

@radar6
Copy link

radar6 commented Feb 25, 2019

Which WordPress version are you using?

5.0.3

@youknowriad
Copy link
Contributor

cc @aduth I guess we're using this function in a context where it's not loaded?

@youknowriad youknowriad added the [Type] Bug An existing feature does not function as intended label Feb 25, 2019
@aduth aduth added the [Type] Regression Related to a regression in the latest release label Feb 25, 2019
@aduth
Copy link
Member

aduth commented Feb 25, 2019

It's weird, because use_block_editor_for_post() is defined in wp-admin/includes/post.php and I would expect that to be always loaded, right...?

I don't think we can expect this; rather, only in a wp-admin context. It's not clear, but from where are you seeing the errors?

Regardless, I see two outcomes:

  • In retrospect, Gutenberg should have always ensured this file was loaded if it assumed to call use_block_editor_for_post. However, as far as impacting a fix, gutenberg_can_edit_post is already slated for removal in the next Gutenberg minor release, and thus the "fix" will be through removing this function altogether.
  • A plugin author should transition to use_block_editor_for_post if they need an equivalent behavior, and as such would similarly need to make sure the file defining the function is loaded.

This may look something like:

require_once ABSPATH . 'wp-admin/includes/post.php'
if ( use_block_editor_for_post( $post ) ) {
	// ...
}

@lkraav
Copy link
Author

lkraav commented Feb 25, 2019

I don't think we can expect this; rather, only in a wp-admin context. It's not clear, but from where are you seeing the errors?

Frontend rendering [wpv-conditional] shortcode via Toolset Views plugin, as described in issue opener.

However, as far as impacting a fix, gutenberg_can_edit_post is already slated for removal in the next Gutenberg minor release, and thus the "fix" will be through removing this function altogether.

OK probably not a huge deal, then.

Classic Editor plugin for one seems to lag catching up w/ removing gutenberg_* functions WordPress/classic-editor#87

@aduth
Copy link
Member

aduth commented Feb 25, 2019

gutenberg_can_edit_post was wrongly labeled as being deprecated in Gutenberg 5.0.0 . In fact, its deprecation was included with 5.1.0 (see #13470). Thus, the function will exist for one more minor version of the plugin and this should be fixed in the meantime.

@aduth
Copy link
Member

aduth commented Feb 25, 2019

Fix at #14096

To be clear, these functions are still deprecated, and still will be removed in Gutenberg 5.3. Plugin authors should transition to the core-equivalent use_block_editor_for_post and use_block_editor_for_post_type. #14096 will only at least ensure no fatals occur in the time between Gutenberg 5.2 and 5.3.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
[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.

4 participants