I’m not aware of a ‘load-edit.php’ action, but if it works on your system then it should be OK. I’m not too sure which hook in a default installation would be good to insure the ‘pre_get_posts’ action is only added for list table queries. Maybe ‘edit_posts_per_page’? I think it’s still early enough. I’m not too sure it wouldn’t fire under other situations, you’d need to do some testing. The filter is for another purpose, but it can still serve to only add ‘pre_get_posts’ when needed. The post type is passed to your callback, so you can at least only add ‘pre_get_posts’ for the proper post type.
The other thing I see is minor. Using is_post_type_archive()
in the conditional is probably fine, but an improvement would be to use the equivalent method of the passed query: $query->is_post_type_archive('m_product')
Come to think of it though, $query->is_post_type_archive()
is to check if the query is for the post type’s archive page. I don’t know if it returns true
for a lists table query as well. If you’ve tested this and it works, then fine. It may not be necessary at all if ‘load-edit.php’ or ‘edit_posts_per_page’ is specific enough.
That does bring up the issue of a user requesting the archive page for the post type. The solution for this is like that for an individual page. You can modify the templates responsible to only output posts belonging to the user. The query may return posts of other users, but it is the loop that does the output. Code in the loop so only the user’s posts are output will address this possible avenue of accessing other’s posts.