Two instances of wp_list_table and tabs how to configure Screen Options separate

It looks like the list tables were never intended to be tabbed. I think you’d need to modify the query for the first table to use the value saved that’s only applied to the second. If this is a posts list table, use the “pre_get_posts” action and set the “posts_per_page” arg accordingly. The challenge will be having code that differentiates this table query from all other posts queries. There ought to be some distinctive query vars set that will let you do this.

Thanks for the help. Yes I can set some tab query vars, but it’s not clear to me how to get the screen options to only examine one table dataset. It seems to be pulling data from whatever table instance was most recently accessed. Is there a way to specify to the screen options which instance to use?

It’s a bit of a mystery to me how the screen options interface with the wp_list_table object.

The items per page count is stored in the current screen’s WP_Screen object’s options property, keyed 'edit_' . $post_type . '_per_page'. Use the object’s get_option() method. The value is stored in the current user’s meta data under the same key.

Ok thanks. I’ve been looking at this object using get_current_screen.

It seems to be ignoring what I’ve set. For example when I look at the current screen:

_options:WP_Screen:private] => Array
(
[per_page] => Array
(
[label] => Stalls Per Page
[default] => 50
[option] => stalls_per_page
)
)

However this does not appear to have any impact on the Screen Options as it is populated with column names and item counts and per_page settings that do not match what is shown in the object. It does show the Pagination for Stalls and set at 50 but it does not seem to be carried into the wp_list_table as 20 are shown per page.

Anyway that could be related to something else. Is there an acceptable way to define screens based on tabs? Is that a valid approach or should I just change from tabs to pages?

Thanks again for all your help.

It may be you’re altering the value too late (or too early) to affect the current screen. And its not persisting between requests. I tried changing the meta value in the DB and it was reflected in the next request. Note that if the value is still the default, there is no stored meta value. It’s only set on change.

It may not fit your need, but I’m sure if you saved the user meta value in the DB, it’ll be applied to the next screen request.

Incidentally, you could override the set value on the current request by altering the respective posts query’s “posts_per_page” query var through the “pre_get_posts” action.

Thanks. I’ll experiment with some of those suggestions to see what works.