WordPress.org

Make WordPress Core

Changes between Version 1 and Version 2 of Ticket #33885, comment 47


Ignore:
Timestamp:
05/25/2017 10:40:33 AM (4 years ago)
Author:
johnjamesjacoby
Comment:

Legend:

Unmodified
Added
Removed
Modified
  • Ticket #33885, comment 47

    v1 v2  
    4141* @dd32's transient approach in [https://core.trac.wordpress.org/ticket/33885#comment:44 #44] is a sound work-around for this isolated problem, for now.
    4242* For later, we should consider what a redux of this meta-box experience looks like.
    43 * Like we have `wp_is_large_network()`, we could consider a `wp_is_large_site()` companion. In theory, it could be used by plugins like WooCommerce or bbPress to announce to the rest of the environment "hey, maybe the posts table will have more rows than is considered typical" so other aspects of the system can respond accordingly.
     43
     44Tangent ideas:
     45
     46* Like we have `wp_is_large_network()`, we could consider a `wp_is_large_site()` companion. In theory, it could be used by plugins like WooCommerce or bbPress to announce to the rest of the environment "hey, maybe the posts table will have more rows than is considered typical" so other aspects of the system (I.E. this meta-box query) can respond accordingly.
     47* Pippin and I have started working on a [https://github.com/stuttter/wp-meta-manager Meta Manager] plugin, which includes a [https://github.com/stuttter/wp-meta-manager/blob/master/wp-meta-manager/includes/classes/class-wp-meta-data-query.php WP_Meta_Data_Query] class for querying `meta` tables directly (without `JOIN`ing their paired object table.) I'd written those classes to eventually make into a core ticket. It's a bit premature to mention them now, but they still might be useful if we need to build a caching strategy around meta-only queries.