Undefined property: WP_Error::$taxonomy

Hi,

If you are able to do further investigation using the Query Monitor plugin, please do feel free to get back to us with your findings.

Well this is quite a search. I found a query that triggers this notice. Weird thing it is not always triggering it as if some remnant of a previous query resolves the notice…..
It concerns a tag page and apparently one of the posts in the query does not have ‘terms’ defined. As it does not trigger each time this is hard to debug to find the post involved.

I took a look in your code. I have to make you aware that I am on PHP 7.4.
The code reads

if ( empty( $queried_terms[ $this->source->taxonomy ]['terms'] ) ) {
	return false;
	}

So in my view it is quite easy to first check whether [‘terms’] and taxonomy isset?
After all PHP 7.4. gives notices for these kinds of situations.
Can you please have a look at my suggestion?

@harm10 We apologize for closing the issue. We typically close issues if they haven’t had any activity in over a week.

Please let us know what the results are once you have had time to complete your testing.

Please reply on my previous reply containing a coding suggestion.

It sounds like having an isset() check in the $queried_terms[ $this->source->taxonomy ]['terms'] might fix the issue bu we are unable to confirm exactly on this.

If you think this is a bug, please do feel free to either submit a bug report directly at our GitHub development repository or submit a pull request for this so our development team can look into this further.

Isn’t this a bit turning it around? If you think it is a bug then a fix should be done. What process to follow for this is depending on each plug-in to decide. Asking reporters to create a new report elsewhere seems to me as counter productive?

I think the notice is just there because PHP 7.4 says it must be there as one of the fields addressed is not defined at all (whatever the underlying cause).
So if you ask me either
– the notice should be suppressed by first checking the field is defined and leave it with that
– an error should occur when the field is not defined as the functionality could break.
Both cases lead to a change in the code.

What do you think?

Hi,

We are not familiar with your site or set-up and we are unable to reproduce the issue on our testing sites. We do not know why that notice is exactly appearing.

We understand you want a resolution for this. We ask the following:

1. Please make sure all your non-Yoast plugins and themes are updated.

2. While it is not clear to use if a conflict check was performed, we do ask that one is completed. Please deactivate all your non-Yoast plugins and switch to the theme 2020. Does the issue still happen? This guide explains more:https://yoast.com/help/how-to-check-for-plugin-conflicts/

3. If the issue continues to happen when Yoast being the only plugin on the site and you are on a standard theme, it is likely an issue.

We’re actively using the bug tracking on our GitHub repository so your best next step would be to create a new issue for our developers at https://github.com/Yoast/wordpress-seo/issues/new. You will need an account to create a new issue. If this is your first bug report, please check out: https://kb.yoast.com/kb/how-to-write-a-good-bug-report/.

I understand your reasoning but I cannot do these actions.
First of all this is a live site so I cannot fiddle around with switching plug-ins and themes.
Secondly I have big difficulties in triggering the notice by something I do myself. As I reported it is on a tag page. But it only happened 3 times last Sunday and after that I could not trigger them myself anymore. The notices are still there in the log and are triggered during the night so maybe it is a robot passing by?
Up until now I only managed to trigger it once on my test site which obviously does not have any traffic.

My feeling is that it is something that is left over of a previous action. On one occasion I had a 404 followed by a tag page to get these Notices.

Does this make any sense?

Hi,

We are not sure why those have been triggered or even if its a robot doing it.

To clarify, all your non Yoast themes and plugins are updated? We ask as we are not sure if they have been. This can help rule out old versions as causing the issue.

If all are updated you may want to make a free staging site instead and try the conflict check there. This guide explains more: https://yoast.com/help/how-to-create-a-staging-environment-for-your-wordpress-site/.

If the issue is still happening on the staging site with all your non-Yoast plugins deactivated and your theme on 2020 we ask that you please make an issue report as previously described.

My themes, plugins and WP are updated. I do not know what you mean by Yoast themes.
The test site I mentioned is part of the domain that has these problems and has mainly the same set-up. As also reported I managed to trigger it there only once. I can only think for one reason: no traffic at all. On the live site there is a lot of traffic but still it is hard to trigger it myself so I can do some investigation by using an own error handler.
So I am at a loss. Should I downgrade to PHP 7.3?

I think I found something!
I looked again at the user logs and found that the tag page involved is set-up by a PHP 404 script of myself. So the standard action to the incoming query would be a 404. With the query vars I try to find something relevant within the tags defined on the site.
In this case I find something so I execute a reroute in the query by manipulating it’s content. If I redo the same URL on my test site I also get the same notices.

So my question to you: what is Yoast missing in the wp_query? So I know what to add in my custom script!

Hello,

What was previously meant was if all non-Yoast themes were updated. Unfortunately, we are not sure what to advise in your particular situation in order to fix your custom script.

If you are able to consistently generate this error with a default theme, up-to-date WordPress versions, and only Yoast SEO for WordPress 14.4.1 activated, and if you think this is a bug, please do feel free to either submit a bug report directly at our GitHub development repository or submit a pull request for this so our development team can look into this further — https://github.com/Yoast/wordpress-seo/issues/new

Why is it so hard to answer my question “So my question to you: what is Yoast missing in the wp_query? “?

I had to delete the test site I was testing this on so I need to get the same notices on another test site.
Can you please answer my question in stead of telling me what to do when I think it is a bug?
(It looks like my script trying to resolve a tag 404 is the reason these notices arise; so I guess that means this cannot be triggered in the situation you describe…..)

We are sorry to hear that you’re having trouble. We totally understand how that could be frustrating for you! Let’s get down to the bottom of what’s going on here.

We are afraid to say that we are unable to confirm what exactly is missing in the Yoast wp_query as this needs deep investigation before we can confirm anything.

As I already mentioned in a previous response, it might be useful to use the isset() on the relevant condition that you have highlighted in your prior response as well. However, we are also unable to confirm this exactly as this needs to be reviewed by our development team, and as such, we requested you to submit a proper bug report for our development team with all the information you have.

We hope this points you in the right direction!

I have looked into this further. The notices are not because the WP query object is missing parts but a Yoast object. Is there some documentation available that tells what parts of the WP query are used to create Indexable_Term_Archive_Presentation Object?