EHLOVader

I actually found this issue occurring on virtual pages from a plugin. Tribe events.

The call to static::get_user_data_from_wp_global_styles( wp_get_theme()) returned an empty post, seemingly related to the page content.

array(28) { ["ID"]=> int(-1) ["post_author"]=> int(1) ["post_date"]=> int(0) ["post_date_gmt"]=> int(0) ["post_content"]=> string(0) "" ["post_title"]=> string(21) "Attendee Registration" ["post_excerpt"]=> string(0) "" ["post_status"]=> string(5) "draft" ["comment_status"]=> string(6) "closed" ["ping_status"]=> string(0) "" ["post_password"]=> string(0) "" ["post_name"]=> string(0) "" ["to_ping"]=> string(0) "" ["pinged"]=> string(0) "" ["post_modified"]=> int(0) ["post_modified_gmt"]=> int(0) ["post_content_filtered"]=> string(0) "" ["post_parent"]=> int(0) ["guid"]=> string(0) "" ["menu_order"]=> int(0) ["post_type"]=> string(4) "page" ["post_mime_type"]=> string(0) "" ["comment_count"]=> int(0) ["filter"]=> string(3) "raw" ["ancestors"]=> array(0) { } ["page_template"]=> string(0) "" ["post_category"]=> array(0) { } ["tags_input"]=> array(0) { } }

I thought this was fixed in 6.1.1 but it doesn’t appear to be resolved for me.

WP_Theme_JSON_Resolver::get_user_data_from_wp_global_styles call to WP_Query incorrect. (#56900)

They are just notices, but in at least one instance the theme I use (Sage 10) escalates the notice to an exception.

Hi Timothy I also am having the same trouble as igor.

Wondering if the plugin can be updated to check !defined before trying to define DISALLOW_FILE_EDIT this would prevent the issue from arising every update, and also ensure that the configuration from ithemes cannot be changed to remove it, since it has already been hardcoded somewhere else within the config.

This was specifically a problem with Roots.io Bedrock as a framework since it has this built in for production sites.

I can confirm this is still happening in 8.1.2

The same warnings that k15lmk98 has been receiving. I am not using debug.log but actually showing these errors in development environments.

It makes the site unusable. I prefer to develop with errors noticeable to prevent myself from creating any of these issues. So silencing the errors with display_errors or wp_debug_display is not an option