Pagination rewrite on dev/staging but not on local

Running into a weird rewrite rule on the dev server - with DevKinsta local, the URL is showing correctly: https://internationalmidwivesorg.local:51343/resources/?paged=2&search=icm

However, when I push to dev, it rewrites the ?paged query var to this:

We need to keep it as a paged query var and not rewrite to /page/2 - but not seeing why it would do that on dev and not on local, given we’re using the same theme files across both.

The only rewrite rules we have in the theme are these (intended to make sure archive listing pagination works right when nested by post type, and these all seem to work correctly):

    add_action( 'init', function() {
        $taxonomies = array(

        $types = array(
        // Loop through taxonomies
        foreach( $taxonomies as $taxonomy ) {
            // Loop through custom post types and rewrite
            foreach ( $types as $type ) {
                add_rewrite_rule( '^' . $type . '/' . $taxonomy . '/([^/]+)/?$',
                    'index.php?post_type=' . $type . '&taxonomy=' . $taxonomy . '&term=$matches[1]', 'top' );

                add_rewrite_rule( '^' . $type . '/' . $taxonomy . '/([^/]+)/page/([0-9]+)?$',
                    'index.php?post_type=' . $type . '&taxonomy=' . $taxonomy . '&term=$matches[1]&paged=$matches[2]', 'top' );

            // Rewrite rules for posts as "news"
            add_rewrite_rule( '^news/' . $taxonomy . '/([^/]+)/?$',
                'index.php?post_type=post&taxonomy=' . $taxonomy . '&term=$matches[1]', 'top' );

            add_rewrite_rule( '^news/' . $taxonomy . '/([^/]+)/page/([0-9]+)?$',
                'index.php?post_type=post&taxonomy=' . $taxonomy . '&term=$matches[1]&paged=$matches[2]', 'top' );
    }, 10, 0 );

Note that the pagination link is correct when I hover on the page number, but then it’s rewriting it somewhere when I actually click on it.

Hi @kyle_conrad :wave: and welcome to the Kinsta Community!

It seems like you’re experiencing an interesting issue. Generally, the Push to Kinsta action in Devkinsta copies the WP files as is, and updates the database connection strings in the wp-config.php file. Additionally, it runs a search and replace in the database to update the domain entries from the Devkinsta domain to the site’s Staging domain.

Therefore, I suggest trying the following typical troubleshooting steps instead:

Firstly, check if the PHP version between Devkinsta and Staging is the same. If the version is different, it’s possible that the theme or plugins on the Staging site aren’t fully compatible with the PHP version.

Secondly, try pushing only the database and files at a time to determine if the issue is within the database or WP files. You may also temporarily switch the theme to a default theme, or disable plugins when doing the push to further isolate where the conflict could be from.

I hope this helps!

Looks like local is on PHP 8.2.5 and dev is 8.2.10 - assuming those are close enough that it shouldn’t be causing it.

I’ve tried pushing just the database or just the theme, as well as doing the usual Settings > Permalinks stuff, to no avail and no change. Plugins are identical between them, and unfortunately any default theme won’t work for testing since we’re using custom blocks to generate the pagination and utilize the query vars.

Wondering if there’s any sort of “built in” rewrite going on on the Kinsta side, which wouldn’t make sense but this whole thing is also very funky all around!

Based on the cURL test, it appears that the redirect is being caused by the Polylang Pro plugin. Here is the cURL command for your reference:

$ curl -IL -silence | grep  "HTTP\|location:\|redirect"
HTTP/2 301 
x-redirect-by: Polylang Pro

To check if this is the case, you can temporarily disable the plugin on the staging site and see if the redirect stops.

Ah, very strange and very funky! No idea why the plugin would be doing that there.

We worked around this by changing the query var to “pg” and using that to determine page, that way we don’t run the risk of bumping up against another WP Query parameter that a plugin or rewrite rule might hit (like page, p, paged, etc.).

Appreciate the help on tracking this down!

This topic was automatically closed 3 days after the last reply. New replies are no longer allowed.