[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