List Table Factory Needs to be Pluggable

[miqrogroove]

Better design planning should have been considered for http://core.trac.wordpress.org/browser/trunk/wp-admin/includes/list-table.php

function _get_list_table() is identical to an object factory pattern, which would make more sense as a static member of WP_List_Table. In other words...

$wp_list_table = _get_list_table('WP_Terms_List_Table');

... which looks simple, is actually confusing because it would be more intuitive if written as ...

$wp_list_table = WP_List_Table::factory('Terms');

Further, the factory hasn't offered any extensibility. Locking edit-tags.php against WP_Terms_List_Table makes it unusable for custom taxonomies that need a custom UI. Despite all of the great API improvements for taxonomies, this case still necessitates duplicating the entire category editing UI within a plugin just to tweak a table column or a link path.

Please adjust the ticket Type and Component as necessary. It could be a taxonomy design flaw or an administration enhancement, depending how you look at it.

_get_list_table() used to be get_list_table(), and it had a filter to allow for switching out tables.

When we pulled out XHR bits and made the entire API private near the end of 3.1, we renamed it to the current, private version.

When someone finally takes ownership of and rewrites the list table API, I think this would indeed be a good approach.

Somewhere in Space this may all be happening right now.

Related: #16031, #18127