[wp-trac] [WordPress Trac] #33885: meta_form performs a potentially expensive query

[WordPress Trac]

#33885: meta_form performs a potentially expensive query
-------------------------------------+-----------------------------
 Reporter:  jorbin                   |       Owner:
     Type:  defect (bug)             |      Status:  new
 Priority:  normal                   |   Milestone:  Future Release
Component:  Administration           |     Version:  4.3.1
 Severity:  critical                 |  Resolution:
 Keywords:  has-patch needs-testing  |     Focuses:  performance
-------------------------------------+-----------------------------

Comment (by dd32):

 Replying to [comment:43 pento]:

 Unfortunately, I find myself agreeing with @pento here.

 Diverging DB structures and shortening field lengths is pretty much off
 the table IMHO, if only to prevent data destruction now or later (in a few
 years when the reason for some people having different field lengths has
 been long forgotten)

 > Removing the meta box is probably a big task that will involve a lot of
 ongoing work unrelated to this particular ticket. Ultimately, that’s the
 right solution, but I’m not sure if it’s something we should tackle to
 solve this bug.

 Personally I see the need for the metabox, but I also think it could
 benefit greatly from a re-think, which will probably happen as part of a
 new post interface at some point in the future, probably reliant upon meta
 keys being registered and some form of UI being assigned, but that isn't
 for this ticket :)

 > That leaves caching the query result. Now, we can either cache using
 `WP_Object_Cache` (so the cache is really only valuable to sites with a
 persistent caching setup), or cache the results in an option, so that it’s
 valuable to any site. I lean towards using the object cache, as the usual
 caching solution, but I’m open to arguments either way.

 A Transient seems like the best of both worlds here - memory cached when
 available, DB when not. The downside is that some people will be clearing
 all transients more often, and I fear those who are impacted by this the
 most are probably the same users, despite that, I still think it's the
 best option.

 I'm thinking something along the logic lines of:
 {{{
 if transient doesn't exist then
    create transient as unique meta_key

 on initial db upgrade then
    queue a single cron task to generate transient

 on new meta_key addition then
    suffix to transient meta_key

 for display then
    merge registered meta_keys with transient and display
 }}}

--
Ticket URL: <https://core.trac.wordpress.org/ticket/33885#comment:44>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform