[wp-trac] [WordPress Trac] #63946: Introduce a mechanism for lazy-loading REST routes and handlers

WordPress Trac noreply at wordpress.org
Mon Apr 20 14:22:43 UTC 2026


#63946: Introduce a mechanism for lazy-loading REST routes and handlers
--------------------------------------+------------------------------
 Reporter:  prettyboymp               |       Owner:  (none)
     Type:  enhancement               |      Status:  new
 Priority:  normal                    |   Milestone:  Awaiting Review
Component:  REST API                  |     Version:
 Severity:  normal                    |  Resolution:
 Keywords:  has-patch has-unit-tests  |     Focuses:  performance
--------------------------------------+------------------------------

Comment (by rmccue):

 Replying to [comment:9 rmccue]:
 > [https://3v4l.org/v6Xio#v8.4.18 Here's an example implementation],
 tested against [https://3v4l.org/v6Xio#v8.4.18 code from Really Simple
 Security]. The Resolvable class here implements just-in-time resolution
 for any callable, so actually we likely wouldn't need to change the Server
 code itself either. I'll see about spinning up a PR for this.

 https://github.com/WordPress/wordpress-develop/pull/11606 implements this,
 along with some minimal unit tests for the behaviour. I haven't done any
 significant compatibility testing with the ecosystem, only some minimal
 tests for the array behaviour.

 I've not benchmarked this as I'm partially out-of-office currently; there
 shouldn't be a huge overhead to instantiating these objects, but given
 that the overhead of the endpoint registration isn't super high, I'm not
 sure where it nets out. Finger in the air, I'd guess it's probably
 slightly worse at small scale (~100 endpoints).

 There's one minor compatibility issue this introduces. If you pass an
 endpoint's options to `wp_parse_args()`, this internally calls
 `get_object_vars()` if the variable is an object, so will break - I had to
 resolve this by using `iterator_to_array()`. That's a pretty minor break,
 as you mostly only need that type of merging when applying defaults, but
 something we can document; I haven't done an extensive search yet to see
 if that's in broad use, but I can't imagine so. (It's safe to call
 `iterator_to_array()` on arrays, so this can be backported as well.)

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


More information about the wp-trac mailing list