Remco

Hi, thanks for the confirmation. I realized I can also upload themes manually, and uploaded the “normal” GeneratePress theme. The issue is the same though.

Also I found one other major theme that has the same issue. So this is not isolated to GeneratePress as I previously thought, but happens in some themes. Have not found what they have in common yet.

WordPress.com is doing something proprietary though, these issues don’t exist in self hosted site.

Anyway, thanks for your help!

I tested v.1.23.0.1, and can indeed confirm all these errors are not happening anymore (also when CGC Maintenance Mode is active).

Thanks again for looking into this!

Hi Mateusz,

Thanks for looking into his.

I tested the updated version (1.23.0) with all plugins deactivated and the Storefront theme.

Everything seems to be working okay now/again in this setup.

Is your above zipped version different? I noticed it is v1.23.0.1. (I did not test that.)

However, after testing, I reactivated my plugins and previous theme again.
Now I had a new 403 error in Query Monitor, when reloading a page with a Search facet keyword active. And no search results when loading this page.
Query Monitor screenshot:

https://d.pr/i/PE3ilJ

I traced this down to having the CGC Maintenance Mode plugin being active together with FiboSearch and FacetWP. That is a simple plugin that redirects if not a certain IP address:
https://www.ads-software.com/plugins/cgc-maintenance-mode/
settings:
https://d.pr/i/P9kg4Y

Now I’m not sure how much of my previous reported 2 issues was caused by this plugin being active.
But the fact is we had multiple FacetWP users in our support, reporting similar issues (which I could reproduce), for which removing gwt_wcas from the URL was the fix. Your previous fix may have fixed these issues, I am not sure.

Maybe these are 2 separate issues. Or, your fixed introduced this new error.

Remco

• This reply was modified 1 year, 11 months ago by Remco.

@aurangajeb Thanks for looking into this. In the meantime, we have documented the issue here for our users, with some ways to fix it:

https://facetwp.com/help-center/using-facetwp-with/all-in-one-seo-pro/

@gugaalves Can confirm the message is gone with 6.0.8 and Yoast 20. Thank you for fixing this!

@gugaalves / TEC team, thank you for fixing this!

I can confirm the issues with FacetWP are resolved now. Tested with The Events Calendar v6.0.7 and Yoast SEO v19.14.

Root cause tribe_is_month() is now correctly returning false on non-month-view pages.

FYI: there is still a deprecated error in front end and back end, coming from Yoast SEO:

Yoast\WP\SEO\Integrations\Third_Party\The_Events_Calendar is deprecated since version 19.12!
wp-content/plugins/wordpress-seo/src/generated/container.php:3967

@bordoni yes, TEC v6.0.6.2 and Yoast v19.13

@slothwx PHP 7.4.

I’m seeing that too in Query Monitor. It would certainly be nice if TEC and Yoast could iron out the integration issues together.

View post on imgur.com

Thanks Gustavo, I understand, thanks for making it a ticket.

One last remark, maybe useful for somebody else reading along.

The above mentioned action ‘tabify_add_meta_boxes’ may not be necessary if you have functions that use the action ‘add_meta_boxes’ to add/remove metaboxes. Tabify Edit Screen already detects those.

The only prerequisite for this to work is that the action needs a $post_type argument passed along, without it, is does not work for Tabify.
Some functions running on ‘add_meta_boxes’ may easily be adapted to have/pass $post_type as argument, so that they will work with with Tabify.

It might be an idea to mention this somewhere in the documentation.

• This reply was modified 3 years, 12 months ago by Remco.

I am not so sure anymore about above statement.

I investigated a bit more and think a lot of issues I was having had to do with the fact that the Tabify options screen did not know about other places (functions.php and other plugins) where metaboxes are removed and added.

Because of how the transients are set used for the settings on the options page and post edit pages, things were continually buggy/shifting, depending on what was saved before (a post, or the options, or another posttype with the same taxonomy). Because my taxonomies are used by multiple posttypes, the behaviour was even more unpredictable. And worsened (maybe, seemingly sometimes) by Opcache, and maybe the set expiration time for these transients in the detection script.

Then I found out there is the (more or less undocumented) action ‘tabify_add_meta_boxes’ with which you can let the Tabify Options screen know about added/removed metaboxes by plugins/own functions. I saw it used in features/plugin-support.php for support for other plugins.

As soon as I implemented that in my functions.php for my functions that remove or add metaboxes, the behaviour of Tabify now seems mostly reliable and consistent on the Options screen as well as the post edit screens.

add_action( 'tabify_add_meta_boxes', 'remove_or_add_metaboxes_function' );

Same solution could be used for other plugins.

So also: please don’t remove this action in coming updates.

My previous remark about this being solved was premature. See reply above from. I have this too, and the proposed solution fixes it.

I believe the ''=>null is coming from metaboxes that have been removed by user functions and plugins.

Update: this seems solved, now the author of the RadioButtonsForTaxonomies plugin has rewritten part of the plugin that adds and remove meta boxes.

I tracked down the cause: I have several places where I remove unwanted metaboxes added by plugins etc. with a remove_meta_box() function:
– in my functions.php
– in a plugin I use: https://www.ads-software.com/plugins/radio-buttons-for-taxonomies/
which removes and adds metaboxes.

I noticed your function get_meta_boxes() is called by show_tabs() runs on the admin_menu hook with priority 100.
The PHP notices are present when metaboxes are apparently removed before your plugin function runs.
When I let my function run on the same hook with a later priority, there are no notices.
For the other plugin (Radio Buttons for Taxonomies), coincidentally I am in contact with the author of it, for some code improvements, so I might be able to get that plugin to run later also.

However, I think it might be a good idea that Tabify Edit Screen takes into account that metaboxes might have been removed prior to it running, and a metabox array might be returning false in your get_meta_boxes() function.So that even when metaboxes are removed, php7.4 does not give notices.

Edit:
I just realised that the byproduct of letting remove_meta_box() functions run AFTER Tabify Edit Screen, is that they show up in the Tabify Edit Screens settings page, where you can move them around. This is not optimal for users and confusing. And in the case of the RadioButtonsForTaxonomies plugin, it is even more confusing, because that plugin replaces a metabox by removing it, then adding a new one. When that plugin runs AFTER Tabify Edit Screen, these metaboxes show up double in the TabifyEditScreen settings. So it would be better that Tabify Edit Screens functions account for metaboxes that have been removed before it.

• This reply was modified 4 years ago by Remco.
• This reply was modified 4 years ago by Remco.

This is the dashboard menu I am seeing:

https://bit.ly/3re2dJx

However, I just found out that it has something to do with the plugin Admin Menu Editor Pro (https://adminmenueditor.com) that I have installed. When I deactivate this plugin, the Welcome menu item is gone.
Probably this plugin puts ‘new’ menu items under Dashboard if they don’t have a dedicated place or something like that. Still, that welcome screen is not something I would like anywhere, except one time after the update. Never seen anything like this with other menu items and plugins.