WordPress 5.5 – jQuery Migrate Fixes and Pagination Fixes

Photo of a book
Photo by BENCE BOROS on Unsplash

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', )
WordPress JS Authors: Add jquery-migrate as a script dependency for a temporary band-aid.
Click to Share share

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();

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();

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 );

The output on the “first” page (no /page/2/) is:

null 0

On the second page of the front-page (i.e., /page/2), the global are:

2 ""

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 0

The “second” page shows:

null 2

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' ) );

Front page on the first page:

null 0

Front page on the second page:

2 ""

First page on Inner Page Template

0 0

Second page on the Inner Page Template

"" 2

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; }

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 -->

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.

Ronald Huereca
Ronald Huereca

Ronald Huereca

Ronald has been part of the WordPress community since 2006, starting off writing and eventually diving into WordPress plugin development and writing tutorials and opinionated pieces.

No stranger to controversy and opinionated takes on tough topics, Ronald writes honestly when he covers a topic.

Leave a Comment