Getting redirection during wp_list_table pagination

If the page requested is greater than what the class thinks is the total pages, it’ll 302 redirect to what it thinks is the last page. Something is apparently wrong with how the total pages is determined. In the prepare_items() method you should be calling set_pagination_args() class method with the correct values. If the pagination args are correct, you shouldn’t be getting redirects.

Thanks I’ll look into that.

I discovered the root cause and it does somewhat relate to set_pagination_args() but it is also a problem of scope which isn’t quite clear to me yet.

There is another plugin that is extending WP_LIST_TABLE. I noticed that both that plugin and my plugin have a prepare_items routine that calls set_pagination_agrs().

Even though the namespace appears separate to me they seem to be overriding each other. I set a page parameter inside each to return immediately from the prepare_items routine:

        if (isset($_GET['page'])) {
            if ($_GET['page'] != 'plugin1_options') {
                // not viewing this table
                return;
            }
        }

This fixed the pagination values from being overwritten by the other extended object. I’m probably missing something but this seems like a good way to end up with conflicts in the plugins. They are declared like this:

Class plugin1Table extends WP_LIST_TABLE
Class plugin2Table extends WP_LIST_TABLE

And each make a similar call inside their own class method of prepare_items:

$this->set_pagination_args(array(
            'total_items' => $totalItems,
            'total_pages' => $totalPages,
            'per_page' => $perPage
        ));

However they seem to be sharing the same pagination memory space. Is there something I can do to avoid this? I’m not sure what I’m doing wrong here but I’m new to the WP framework.

Thanks again.

• This reply was modified 3 years, 11 months ago by EricB50.
• This reply was modified 3 years, 11 months ago by EricB50.

Interesting theory. While it’s very enticing, I don’t see how two different classes, even if extended from the same basic class, could somehow share the same memory space. Even if there were some sort of name collision, it would cause a PHP error. It’s not even a WP quirk, it’s how PHP and all OOP work. While memory overflows have been know to be possible, we usually have to try very hard to cause it. It doesn’t happen in conventional usage.

There are numerous core extensions of WP_List_Table. None of them have displayed pagination issues.

Oh! Maybe the shared space is not in the class per se, but in the variable to which a class object is assigned? So if I do $obj = new Foo(); and your plugin does $obj = new Bar();, my operations on my $obj could influence your $obj. So don’t look at what’s in the class for conflicts, but what is done with the class object’s assigned variable.