[wp-trac] [WordPress Trac] #58962: Provide a way to load multiple specific options with a single database request

WordPress Trac noreply at wordpress.org
Tue Oct 24 21:49:48 UTC 2023


#58962: Provide a way to load multiple specific options with a single database
request
-------------------------------------------------+-------------------------
 Reporter:  flixos90                             |       Owner:  flixos90
     Type:  enhancement                          |      Status:  reopened
 Priority:  normal                               |   Milestone:  6.4
Component:  Options, Meta APIs                   |     Version:
 Severity:  normal                               |  Resolution:
 Keywords:  has-patch has-unit-tests has-dev-    |     Focuses:
  note dev-reviewed                              |  performance
-------------------------------------------------+-------------------------
Changes (by peterwilsoncc):

 * status:  closed => reopened
 * resolution:  fixed =>


Comment:

 I really don't understand the reluctance to use the words prime and cache
 in a function designed to prime a cache.

 As I've said repeatedly, the **other cache priming functions are public
 and have been since 6.1**. There is no ''may'' about it. Both Yoast SEO
 and WooCommerce are using them, each of which have over 5M installs (the
 highest number listed on the plugins directory). It's disingenuous to
 suggest they are not used by plugin authors.
 [https://wpdirectory.net/search/01HDF8F5GPN0MRSB826BC11E0J They are].

 Re the functions with a similar name:

 * `wp_load_alloptions()` does not accept arguments regarding which options
 should be cached
 * `wp_load_core_site_options()` does not accept arguments regarding which
 options should be cached
 * `_prime_thing_cache()`, like these new functions, accepts an array of
 arguments to define which items should be cached.

 > All they need to know is: Call this function early during the request,
 with the options from your plugin that you're going to access throughout
 the request, in order to improve performance.

 I think this is really dismissive of extenders skills. Extenders DO and
 should know about caching. This is something I and other members of the
 team have been working on. There may be an opportunity to improve
 documentation but there have been dev notes about this for many reelases
 now.

 > Given that this has been dev-reviewed by another committer, and in order
 to prevent inconsistent trunk and 6.4 branches, I will move forward with
 the backport, and update the dev note accordingly. I think we have
 exhausted the conversation here and everybody involved shared their
 perspectives, and they were considered. If there remains any strong
 objections against the current names that I may have missed, we can always
 reopen again.

 I am really disappointed in this action and think it goes well beyond the
 spirit and intent of double sign off.

 Tonya and I are both very experienced committers and were continuing the
 discussion. Tonya is the tech lead of the current release.

 I had chosen not to commit anything while the discussion was ongoing and
 find it quite disrespectful that you did not observe the same courtesy.

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


More information about the wp-trac mailing list