Fatal error with WP 5.5.1

For more info, the plugin is generating the crash in these lines of code:

// We’re finished, make sure we save out changes
$wp_taxonomies[$taxonomy] = $args;
self::$taxonomies[$taxonomy] = $args;

It seems it changes the taxonomy data type from WP_Taxonomy to stdClass, provoking the crash when WordPress processes it.

• This reply was modified 4 years, 2 months ago by lifetimemedia.

Before I investigate this can you see if the error still occurrs if you deactivate ALL other plugins except LH User Taxonomies.

I ask this as just becuase the error stops when you deactivate my plugin that does not actually mean that my plugin is causing the error (in fact I suspect some other plugin is doing something strange to the taxonomies eralier in the processing and my plugin is then conflicting with it).

Also noting I am running 5.5.1 on my all my sites with LH User Taxonoies and have no problems at all (which is further evidence that it is another plugin doing something funky).

I am resolving this thread for good order but will still monitor it, so f?ease feel free to post if this is still a problem (after you have tried my suggestions above) and I will re open it.

• This reply was modified 4 years, 2 months ago by shawfactor.

Hi,

Just to report that I’m getting the exact same error message.

I have a simple plugin that registers the user taxonomy. If I deactivate it then I get no error, but this is still the correct way to register them I think.

// Register Country taxonomy
function redacted_register_my_taxes() {

	/**
	 * Taxonomy: Countries.
	 */

	$labels = array(
		"name" => __( "Countries", "acff-genesis" ),
		"singular_name" => __( "Country", "acff-genesis" ),
	);

	$args = array(
		"label" => __( "Countries", "acff-genesis" ),
		"labels" => $labels,
		"public" => true,
		"publicly_queryable" => true,
		"hierarchical" => false,
		"show_ui" => true,
		"show_in_menu" => true,
		"show_in_nav_menus" => true,
		"query_var" => true,
		"rewrite" => array( 'slug' => 'country', 'with_front' => false, ),
		"show_admin_column" => false,
		"show_in_rest" => true,
		"rest_base" => "country",
		"rest_controller_class" => "WP_REST_Terms_Controller",
		"show_in_quick_edit" => false,
	
		);
	register_taxonomy( "country", array( "user"), $args  );
}
add_action( 'init', 'redacted_register_my_taxes' );

As @lifetimemedia says, if you comment out line 60 of the lh-user-taxonomies.php then that seems to resolve the error. It’s out of my league in terms of understanding the code, but there’s something very similar discussed here: https://wordpress.stackexchange.com/questions/375037/wp-5-5-fatal-error-get-rest-controller-in-rest-api-php

Thanks,
Ben

(Forgot to say that I see the error message when accessing the front end pages that utilise the user taxonomy, and in the back end when trying to create a new Post)

@badlydrawnben @lifetimemedia I′ll reoopen the thread but can you please do the diagnostic that I suggested ie:

“see if the error still occurrs if you deactivate ALL other plugins except LH User Taxonomies”.

As I said I suspect you have some other plugin that is actually causing the problem but when the dodgy variables reaches LH User Taxonomies the problem occurs.

I say this because I do not see this behaviour on any of my sites, all of which use LH User Taxonomies and all of which are on 5.5.1

Pete

• This reply was modified 4 years, 2 months ago by shawfactor.
• This reply was modified 4 years, 2 months ago by shawfactor.

Hi Pete,

To replicate the issue – blank install of WP5.5.1 and TwentyTwenty theme.

With just the LH User Taxonomies plugin activated you get no error (when trying to add a new post) but you need to register the taxonomy somewhere else. If I generate the code for a new one (from GenerateWP) and put that in a separate plugin then I get this code

// Register Custom Taxonomy
function custom_taxonomy() {

	$labels = array(
		'name'                       => _x( 'Taxonomies', 'Taxonomy General Name', 'text_domain' ),
		'singular_name'              => _x( 'Taxonomy', 'Taxonomy Singular Name', 'text_domain' ),
		'menu_name'                  => __( 'Taxonomy', 'text_domain' ),
		'all_items'                  => __( 'All Items', 'text_domain' ),
		'parent_item'                => __( 'Parent Item', 'text_domain' ),
		'parent_item_colon'          => __( 'Parent Item:', 'text_domain' ),
		'new_item_name'              => __( 'New Item Name', 'text_domain' ),
		'add_new_item'               => __( 'Add New Item', 'text_domain' ),
		'edit_item'                  => __( 'Edit Item', 'text_domain' ),
		'update_item'                => __( 'Update Item', 'text_domain' ),
		'view_item'                  => __( 'View Item', 'text_domain' ),
		'separate_items_with_commas' => __( 'Separate items with commas', 'text_domain' ),
		'add_or_remove_items'        => __( 'Add or remove items', 'text_domain' ),
		'choose_from_most_used'      => __( 'Choose from the most used', 'text_domain' ),
		'popular_items'              => __( 'Popular Items', 'text_domain' ),
		'search_items'               => __( 'Search Items', 'text_domain' ),
		'not_found'                  => __( 'Not Found', 'text_domain' ),
		'no_terms'                   => __( 'No items', 'text_domain' ),
		'items_list'                 => __( 'Items list', 'text_domain' ),
		'items_list_navigation'      => __( 'Items list navigation', 'text_domain' ),
	);
	$args = array(
		'labels'                     => $labels,
		'hierarchical'               => false,
		'public'                     => true,
		'show_ui'                    => true,
		'show_admin_column'          => true,
		'show_in_nav_menus'          => true,
		'show_tagcloud'              => true,
		'show_in_rest'               => true,
	);
	register_taxonomy( 'taxonomy', array( 'user' ), $args );

}
add_action( 'init', 'custom_taxonomy', 0 );

That will then throw the error when I try to create a post. If I comment out the show_in_rest line then it works OK, but I need to have that enabled because I’m using the block editor.

Thanks,
Ben

Okay so that makes some sense as to why I have not seen any problems.

BUT before I progress tthis further can you advise why would you need ‘show_in_rest’ for a user taxonomy? I ask that as Gutenberg is for editing posts and you have registered the ‘taxonomy’ taxonomy for only users. Therefore setting show_in_rest would make no difference to gutenberg.

I guess you could need it if you did:

register_taxonomy( ‘taxonomy’, array( ‘user’, ‘post’ ), $args );

but if you share a taxonomy between object types you can get collisions so that should be avoided anyway.

• This reply was modified 4 years, 2 months ago by shawfactor.
• This reply was modified 4 years, 2 months ago by shawfactor.
• This reply was modified 4 years, 2 months ago by shawfactor.

I think it was left over in the taxonomy registration code from when I was originally trying to use the taxonomy for users and another CPT. I think I ran into some issues with doing that, which is why I reverted it back to just assigning it to ‘user’.

What’s the best way forward? I can just remove the rest_api support from my taxonomy registration code, or will the plugin be updated to resolve the error if show_in_rest is enabled?

Thanks,
Ben

Firstly a tip don′t registers taxononies across types ie don′t mix user taxononies with posts, pages, cpts etc. If you do you may get false postives. This is not a problem with my plugin but with how wordpress handles taxonomies.

In terms of this issue, remove show_in_rest from your user taxonomies (there is literally no reason to use it for user taxononies AFAIK)

I will investigate the underlying problem but it may well be that show_in_rest is not supported for user taxonomies at all (so I may not be able to fix it). Either way don′t use show_in_rest for user taxonoies.

So your support query made me review the code and there was an minor error (of sorts), ibn the compatibility with 5.5

The latest version now incorporates a fix that will enable you to add show_in_rest when registering (not that this actually makes the slightest difference to user taxonomies as they do not appear in gutenberg).

Anyway please test the latest version 1.60 and if there are any problems please let me know

Pete

@badlydrawnben @lifetimemedia I am resolving this (again) as I believe the issue should be fixed in the latest version (1.60)

However as before I will still monitor it, so please feel free to post if this is still a problem (after you have tried my suggestions above) and I will re open it.

If the above did solve you problem pleae consider writing a review.

Pete