Make WordPress Core

Opened 3 years ago

Closed 7 months ago

Last modified 3 months ago

#54087 closed enhancement (wontfix)

A plugin can't change the parameters of a REST API endpoint

Reported by: antonvlasenko's profile antonvlasenko Owned by:
Milestone: Priority: normal
Severity: normal Version: 5.9
Component: REST API Keywords: has-patch
Focuses: rest-api Cc:

Description

Sometimes a plugin needs to change the parameters of an already registered REST API endpoint.
Now we need to override the whole WP_REST_Controller::register_routes method to achieve it. Unfortunately, that leads to code duplication, and that is not the best practice.
See an example of this here: https://github.com/WordPress/gutenberg/blob/trunk/lib/class-wp-rest-menu-items-controller.php#L26.

We should add a new filter (add_filter) at the very beginning of the register_rest_route's function body. That filter must allow to modify all arguments of the register_rest_route function.

Change History (6)

This ticket was mentioned in PR #3730 on WordPress/wordpress-develop by @dd32.


17 months ago
#1

  • Keywords has-patch added

Add a register_route_args filter.

Trac ticket: https://core.trac.wordpress.org/ticket/54087

#2 @spacedmonkey
17 months ago

@TimothyBlynJacobs Can you provide any context here?

#3 @TimothyBlynJacobs
16 months ago

I don't have any context here, why this function was implemented without a filter was probably a very early decision.

Personally, I worry that such a low-level filter will get abused to add parameters to controllers without using the more intentional exposed APIs like register_rest_field.

I'm of the opinion that if controllers want to make portions of their route registration customizable, they should provide specific filters for that.

Gutenberg has pretty specialized needs as a place for prototyping features for Core, but I don't think we should be encouraging plugin developers to do the same.

#4 @rachelbaker
14 months ago

why this function was implemented without a filter was probably a very early decision.

@TimothyBlynJacobs is correct.

We intentionally avoided making it "easy" for plugins to have full control over the core endpoints. This design decision was made to favor standardization across all WP sites for the built-in endpoints. Plugins can easily extend existing endpoints or add new endpoints.

#5 @antonvlasenko
7 months ago

  • Resolution set to wontfix
  • Status changed from new to closed

Thank you all for the feedback.
A special thanks to @dd32 for submitting a PR. ❤️
I'm closing this ticket due to concerns, which I believe are valid, about potential abuse of the proposed filter.
However, if anyone believes this filter should be implemented, please feel free to reopen the ticket.
Once again, thank you everyone for your efforts.

#6 @swissspidy
3 months ago

  • Milestone Awaiting Review deleted
Note: See TracTickets for help on using tickets.