We are running WP 5.6 and Beaver Builder 2.4.1.3(Pro). It is a multisite installation and we are having issues on the main site.
Our home page for the blog loads just fine: https://www.awana.org/blog
But subsequent pages return a 404: https://www.awana.org/blog?page=2 https://www.awana.org/blog?page=3 https://www.awana.org/blog?page=4 and so on. According to the text at the bottom of the blog home page, we should have 60 pages worth of posts.
I have opened the WP dashboard and looked at the posts. Sure enough, these posts do exist.
In one of our sandboxes, I have deactivated all the plugins except for Beaver Builder, Advanced Custom Fields and a custom plugin. I cannot deactivate the last two b/c no page on the site will load without Advanced Custom Fields and the blog home page will not load without the custom plugin. The custom plugin hooks into the init action, gets all the blog posts from an rss feed, creates the html to display the list of posts and returns it to a shortcode that the Beaver Builder page(blog homepage) uses. I also switched to the TwentyTwentyOne theme. I still had the same issue.
We recently upgraded WP from 5.3.2 to 5.6. This worked before we upgraded. When debugging this issue, I noticed some core WP code changed. In wp-includes/class-wp.php, a block of the handle_404 fn looked like this in 5.3.2:
// Never 404 for the admin, robots, or if we found posts.
if ( is_admin() || is_robots() || $wp_query->posts ) {
$success = true;
if ( is_singular() ) {
$p = false;
if ( $wp_query->post instanceof WP_Post ) {
$p = clone $wp_query->post;
}
// Only set X-Pingback for single posts that allow pings.
if ( $p && pings_open( $p ) && ! headers_sent() ) {
header( 'X-Pingback: ' . get_bloginfo( 'pingback_url', 'display' ) );
}
// check for paged content that exceeds the max number of pages
$next = '<!--nextpage-->';
if ( $p && false !== strpos( $p->post_content, $next ) && ! empty( $this->query_vars['page'] ) ) {
$page = trim( $this->query_vars['page'], '/' );
$success = (int) $page <= ( substr_count( $p->post_content, $next ) + 1 );
}
}
if ( $success ) {
status_header( 200 );
return;
}
}
In 5.6, it changed to this:
$set_404 = true;
// Never 404 for the admin, robots, or favicon.
if ( is_admin() || is_robots() || is_favicon() ) {
$set_404 = false;
// If posts were found, check for paged content.
} elseif ( $wp_query->posts ) {
$content_found = true;
if ( is_singular() ) {
$post = isset( $wp_query->post ) ? $wp_query->post : null;
// Only set X-Pingback for single posts that allow pings.
if ( $post && pings_open( $post ) && ! headers_sent() ) {
header( 'X-Pingback: ' . get_bloginfo( 'pingback_url', 'display' ) );
}
// Check for paged content that exceeds the max number of pages.
$next = '<!--nextpage-->';
if ( $post && ! empty( $this->query_vars['page'] ) ) {
// Check if content is actually intended to be paged.
if ( false !== strpos( $post->post_content, $next ) ) {
$page = trim( $this->query_vars['page'], '/' );
$content_found = (int) $page <= ( substr_count( $post->post_content, $next ) + 1 );
} else {
$content_found = false;
}
}
}
// The posts page does not support the <!--nextpage--> pagination.
if ( $wp_query->is_posts_page && ! empty( $this->query_vars['page'] ) ) {
$content_found = false;
}
if ( $content_found ) {
$set_404 = false;
}
// We will 404 for paged queries, as no posts were found.
}
We do not have <!--nextpage-->
in the post_content for the blog page. This was not an issue in 5.3.2 and previous versions b/c $success
was already set to true(in the code above). So if <!--nextpage-->
was not in post_content, true was returned anyway and there was not a 404 error. Since this is no longer the case, we are receiving a 404.
The value of post_content on the blog page is:
<!-- wp:fl-builder/layout -->
<h1></h1>
[cats-dropdown]
[aggregated_posts]
<!-- /wp:fl-builder/layout -->
I tried changing that to this:
<!-- wp:fl-builder/layout -->
<h1></h1>
[cats-dropdown]
[aggregated_posts]
<!--nextpage-->
<!-- /wp:fl-builder/layout -->
This works for page 2, but does not work for page 3, 4, etc. It looks like this line of code:
$content_found = (int) $page <= ( substr_count( $post->post_content, $next ) + 1 );
which is in the block above, expects <!--nextpage-->
to be printed in post_content as many times as there are pages. So if there are 60 pages <!--nextpage-->
would have to be printed 60 times.
I imagine there is a better way to get page 2, 3, 4, etc. to show up rather than copying and pasting <!--nextpage-->
into the post_content 60 times and then having to remember to update it when there are more than 60, 61, 62, etc. pages. Any ideas?
<!--nextpage-->
is programmatically added within a function. So I suspect this is a case of re-writing your custom functionality to address this change.<!--nextpage-->
code and I was getting 404 errors all over. After a lot of debugging, I ended up using the pre_handle_404 filter to programmatically add the next page comment at the end of $post->post_content. A little hacky, but worked. (I had disabled all plugins and themes to test the issue, nothing worked for me)