Before I start this article, I do want to state that I know there are two logo images. I’ll them shortly, or stop procrastinating on my re-design transitioning away from Beaver Builder to just straight Gutenberg. </siderant>
WordPress 5.5 Broke jQuery on Many Sites
If you are on WordPress 5.5 and having site issues involving JavaScript (page not loading, toggles not working, scripts erroring out), it is likely because of the jQuery Migrate issue in WordPress 5.5.
A quick fix is to install the Enable jQuery Migrate Helper plugin on affected sites:
A quick fix for WordPress plugin/theme authors is to include jquery-migrate as one of their script dependencies when you are enqueueing your scripts.
array(
'jquery',
'jquery-ui-dialog',
'jquery-migrate',
)Code language: PHP (php)The jQuery Migrate Helper plugin is a long-term solution, but will not help in the long-term. The goal is to bring jQuery in WordPress up-to-date gradually.
The first step was removing jquery-migrate in WP 5.5. The script is still “there”, so you can still enqueue it. It isn’t until WordPress 5.7 that jQuery Migrate will actually disappear from core. So you have until WP 5.7 to figure out where your JS code is failing and fix it long-term. We don’t want to rely on a “helper” plugin to fix every site in existence, but we can do our part to make jquery-migrate a thing of the past.
BTW, if you do write a WP CLI tool that’ll scan files and point where the jQuery Migrate issues are, you will be Internet famous. At least in my book.
Breaking Pagination
A more WordPress 5.5 issue, that isn’t really fixable, is pagination.
Pagination being broken was brought to my attention by one of the users of my plugin.
Not sure if it helps but pagination appears to have affected many sites with the update to wordpress 5.5
There is an official bug report here:
But WordPress developers say that it is theme and plugin developers that are using the variable ‘page’ incorrectly.
Anyway, don’t know if this is involved or not but thought it might help.
fatherb
My first reaction was crap. WordPress 5.5 broke pagination, and I thought I was using it right my entire career. I was apparently wrong.
The pagination issue at play is this type. of query, which worked in WP 5.4.
This can be duplicated by creating a bunch of dummy posts, creating a page, and assigning it as the homepage for the site with pretty permalinks enabled.
In the theme, according to the template hierarchy, I created a file named front-page.php and stripped out most of the fluff. For this example, I’ll piick on the Twenty Twenty theme.
<?php
get_header();
?>
<main id="site-content" role="main">
<?php
echo "Hi there front page.";
?>
</main><!-- #site-content -->
<?php get_footer();Code language: PHP (php)Now let’s do some basic query code to query some posts and get pagination to work.
<?php
get_header();
?>
<main id="site-content" role="main">
<?php
$my_page = 0;
if ( absint( get_query_var( 'paged' ) > 1 ) ) {
$my_page = absint( get_query_var( 'paged' ) );
}
$post_args = array(
'post_type' => 'post',
'post_status' => 'publish',
'posts_per_page' => 10,
'paged' => $my_page,
);
$my_query = new WP_Query( $post_args );
if ( $my_query->have_posts() ) {
while ( $my_query->have_posts() ) {
$my_query->the_post();
echo get_the_title() . '<br />' ;
}
}
echo paginate_links(
array(
'total' => $my_query->max_num_pages,
'current' => max( 1, get_query_var( 'paged' ) ),
'format' => 'page/%#%',
'show_all' => false,
'type' => 'list',
'end_size' => 1,
'mid_size' => 2,
'prev_next' => false,
'prev_text' => sprintf( '<i></i> %1$s', __( 'Newer Items', 'post-type-archive-mapping' ) ),
'next_text' => sprintf( '%1$s <i></i>', __( 'Older Items', 'post-type-archive-mapping' ) ),
'add_args' => false,
'add_fragment' => '',
)
);
?>
</main><!-- #site-content -->
<?php get_footer();Code language: PHP (php)This should in theory work. But on the front page of the site, the “paged” query var is not set.
Let’s output some var_dumps and see what’s in the globals:
global $page, $paged;
var_dump( $page );
echo '<br />';
var_dump( $paged );Code language: PHP (php)The output on the “first” page (no /page/2/) is:
null
0Code language: PHP (php)On the second page of the front-page (i.e., /page/2), the global are:
2
""Code language: PHP (php)Let’s see how they behave on an “inner” page using the same tests. For this, I just created a page with the slug “test” and created a file in my theme called “page-test.php” and let it have the exact same code as “front-page.php”.
The output on the “first page for an inner page is:
0
0Code language: PHP (php)The “second” page shows:
null
2Code language: PHP (php)If you’ve been paying attention, the globals are completely different on an “inner” page and the “front page”. This can cause bugs if the globals are assumed to be the same as on the front page and an inner page.
Now what about query vars? They are more reliable than globals.
var_dump( get_query_var( 'page' ) );
echo '<br />';
var_dump( get_query_var( 'paged' ) );Code language: PHP (php)Front page on the first page:
null
0Code language: PHP (php)Front page on the second page:
2
""Code language: PHP (php)First page on Inner Page Template
0
0Code language: PHP (php)Second page on the Inner Page Template
""
2Code language: PHP (php)In summary of the above tests, the “paged” variable can be relied upon for internal pages. On the front page, we kinda need to rely on the “page” variable.
Here’s Core’s way of fixing it for both inner pages and front-page templates according to their docs:
if ( get_query_var( 'paged' ) ) {
$my_page = get_query_var( 'paged' );
} elseif ( get_query_var( 'page' ) ) {
$my_page = get_query_var( 'page' );
} else {
$my_page = 1;
}Code language: PHP (php)So here’s my updated code that I’ve placed in both templates:
<?php
get_header();
?>
<main id="site-content" role="main">
<?php
if ( get_query_var( 'paged' ) ) {
$my_page = get_query_var( 'paged' );
} elseif ( get_query_var( 'page' ) ) {
$my_page = get_query_var( 'page' );
} else {
$my_page = 1;
}
$post_args = array(
'post_type' => 'post',
'post_status' => 'publish',
'posts_per_page' => 10,
'paged' => $my_page,
);
$my_query = new WP_Query( $post_args );
if ( $my_query->have_posts() ) {
while ( $my_query->have_posts() ) {
$my_query->the_post();
echo get_the_title() . '<br />' ;
}
}
echo paginate_links(
array(
'total' => $my_query->max_num_pages,
'current' => max( 1, get_query_var( 'paged' ) ),
'format' => 'page/%#%',
'show_all' => false,
'type' => 'list',
'end_size' => 1,
'mid_size' => 2,
'prev_next' => false,
'prev_text' => sprintf( '<i></i> %1$s', __( 'Newer Items', 'post-type-archive-mapping' ) ),
'next_text' => sprintf( '%1$s <i></i>', __( 'Older Items', 'post-type-archive-mapping' ) ),
'add_args' => false,
'add_fragment' => '',
)
);
?>
</main><!-- #site-content -->Code language: PHP (php)In both cases, on WordPress 5.4, pagination works using the above techniques.
Let’s try it on WordPress 5.5. And thankfully they both work as before. However, this doesn’t account for all the plugins using pre_get_posts and trying to get pagination working there.
Anyways, I could not find a “right” way to get the actual page number, no matter where in WordPress you are, although you are welcome to steal the snippet above. If you find such an article about the best practices of pagination, please leave a comment and I’ll update this post.
Conclusion
WordPress 5.5 broke a lot of sites with old jQuery and some plugins/themes pagination systems. I presented some solutions to address them.
