Second level 404 pages pull Posts page content

Where is the breadcrumbs functionality coming from? Your parent theme? Plugin? Self developed?

I don’t know enough of your site’s organization to offer meaningful advice. What is “borrowers”? Post type? Taxonomy term? Parent page? working-with-us is a page?

You needn’t make a whole new header template for a single glitch under one condition. You could add a conditional on the header template where it is outputting a page title. For example if ( ! is_404()) the_title();

Thanks for the reply.

The breadcrumb is just a hint that the 404.php page is firing as is from the Posts page (in my case it’s called /articles/). However, they are just inserted in my child theme header.php file via Yaost => yoast_breadcrumb('<p id="breadcrumbs">','</p>');

“Borrowers” is a landing page and the parent page of the “Working with us” page. The menu structure at top uses landing pages for first level, and then the subpages are are referenced to their parent page in order to get the /landing/child/page/ structure.

Permalinks are ‘Post name’ default : https://www.stronghill.com/sample-post/

This happens on any of the 2nd level pages:

https://www.stronghill.com/borrowers/first-time-borrower/xxxx
https://www.stronghill.com/loan-programs/stronghill-commercial/xxxx
https://www.stronghill.com/resources/frequently-asked-questions/xxxxx
etc etc

But not on first level landing pages:
https://www.stronghill.com/loan-programs/xxxx

The ONLY clue I have here is how the post page hierary is setup. The Post page (Articles) is a child page of the Resources page:

https://www.stronghill.com/resources/articles/

However, if you view that page, for some reason the breadcrumbs do NOT show the >> Resources >> level item and instead only show Articles as if it was 1st level even though in the URL it is second level.

Beyond that one clue, I am totally lost in how it’s rewriting 2nd level 404.php to come from the /articles/404.php (and then also using the most recent post to pull the Title into my custom title overlay in functions.php)

function crel_page_header() {
	if ( is_front_page() && is_home() ) {
	  // Default homepage
	} elseif ( is_front_page() ) {
	  // static homepage
	} elseif ( is_home() ) {
	  // blog page
	} else {
		echo '<div id="content" class="page-wrap pageHeader"><div class="container">';
		the_title( '<h1 class="title-post entry-title">', '</h1>' );
		echo '</div></div>';
		}
}
add_action( 'sydney_after_hero', 'crel_page_header' );

• This reply was modified 6 years, 10 months ago by ben8jam.
• This reply was modified 6 years, 10 months ago by ben8jam.
• This reply was modified 6 years, 10 months ago by ben8jam.

Thanks for the explanations. You said “…using the most recent post to pull the Title into my custom title overlay…”

The best clue evah! ?? It’s coming from global $post, which was set in the final iteration of the last displayed post. It’s not normally cleared because the next request overwrites it. But requests that return nothing, causing the 404 template to be called, bypass the normal overwriting of $post so any functions related to the 404 template that rely on global $post will be using stale data. It’s likely the explanation for why the Yoast bread crumb trail is behaving erratically as well.

We are not supposed to use any template tags that rely on global $post on a 404 response. Template tags like the_title(), the_permalink(), the_excerpt(), etc. It’s unusual for the common header template to use these functions, so usually no strange behavior results. When you modify the header to use anything related to global $post, it needs to be within a conditional like this: if ( ! is_404()) { /*template tag call*/ }

It’s reasonable to assume yoast_breadcrumb() also relies on global $post for part of its output. It probably was never intended to be used with a 404 response. It’s not even logical for there to be a breadcrumb in a 404 situation. How can code know what a page’s parentage is when the page cannot be found?

That explains the behavior you have observed, but what’s not explained is how global $post came to have stale data in the first place. For a request where nothing is found, global $post should not even be defined. Something on your site using sessions to manage user data between requests is the most likely explanation. Why $post is defined does not need to be solved, the fact remains it cannot be referred to in 404 situations.

Well simply wrapping if ( ! is_404()) around the breadcrumbs in Header.php as well as my hook’s the_title() in Functions.php has masked the problem.

However, it’s going to drive me nuts to not know why it ONLY happened on 2nd level pages.

Could it have anything to do with the “Articles” (default Posts page) being a child of /Resources/ but when on the Articles page, the Breadcrumbs don’t show the Resources page as the parent? I feel like I forced it to not show >> Resources >> that way the blog posts appear as top level pages, but I can’t for the life of me remember where I would have set that…. Something is off for sure.

Either way, thank you for your help. At least from the user end it looks correct.

You’re welcome. You can certainly still dig around and try to solve this. To avoid having debug data be visible to visitors while you’re digging, send debug output either to error log or email it to yourself, or wrap the output code with something like if ( $your_user_ID == get_current_user_id()) { /*debug output code here*/ }

I don’t know how the Yoast breadcrumbs work, so I couldn’t speculate why it behaves that way. Especially if its behavior has been altered. To find out for sure will involve detailed debugging of the function. Check various intermediate variable values at strategic points in the code. It can be tedious going, but you should be able to zero in on the cause eventually.