#45022 closed feature request (wontfix)
Add a wp-ajax.php at the root of wordpress
Reported by: | tofandel | Owned by: | |
---|---|---|---|
Milestone: | Priority: | normal | |
Severity: | normal | Version: | |
Component: | REST API | Keywords: | needs-patch needs-docs needs-codex |
Focuses: | Cc: |
Description
Currently there is an admin-ajax.php that works great but has very poor performance because of the is_admin() that returns true and so some plugins or even the core start do some heavy computation being configuration arrays with tons of translations to doing heavy database queries, although normal for the backend ajax; it would be great to have a non admin wp-ajax in WordPress 5.
It would be located at the root of wordpress so the admin_hooks won't have to load/fire, the wp_query won't have to process and frontend plugins will be able to use this ajax instead of the old admin ajax, greatly reducing the loading time of the ajax-call and the load on the server, (+ there is already the nopriv hook so the separation will be easy to implement for plugins).
There is currently workarounds such as just using parameters in the url (like wc-ajax for woocommerce) but those are not actually better because the wp_query still tries to do some work beforehand and some plugins do whatever they want with this and sometimes it's really ugly...
Also some plugins use is_admin() wrong (I did the same when I first started because of the name I thought it would check that the current user would be an admin, until later I found out this wasn't the case and went back and fixed all those security holes) and this creates huge security issues because you can run those supposedly is_admin restricted code in an ajax call and many plugin authors make this mistake.
A core and unified way of doing that would be great for the community, better performances for users, better separation of frontend and backend, less security risks and happier developers spending less time implementing their ajax hooks.
Change History (7)
#2
@
6 years ago
This was proposed 7 years ago and never merged, then closed two years ago because of the Rest API, it's indeed very sad it didn't make it 7 years ago..
Should I do some archeology and dig up the fossile (aka reopen the ticket)?
Because I still think the wp-ajax.php file should be included, the rest api is something that maybe overpowered for what wp-ajax.php would be used for (Eg: Simple actions. At the top of my mind: pushing a like button that makes an ajax request or getting a share count every 2 minutes, updating a single form field via ajax that need to be very fast) so basically every ajax request that is light and needs to be fast should pass there.
And I'm pretty sure the rest API is ~30% slower than what this would achieve because of the rewrite endpoint (htaccess invisible redirect to index.php + preg_match iteration needed to find the requested endpoint then wp_query endpoint parsing)
#4
@
4 years ago
- Component changed from Security to REST API
Yeah, I agree that probably moving actions like this to the REST API is probably the best action to take. There are a lot of built-in helpers around security. Moving this suggestion over there.
#5
@
4 years ago
- Milestone Awaiting Review deleted
- Resolution set to wontfix
- Status changed from new to closed
Based on #12400 I don't think this is something we'll likely introduce support for.
I would recommend moving those actions to the REST API. Not everything needs to follow a full-blown controller model, though it is the recommended pattern.
#7
@
6 months ago
I'm very late here, but this doesn't make any sense. Tons of plugins and themes use AJAX calls, so you're effectively saying "rewrite everything in the REST API". Moreover, from the reasoning provided here and in #12400, admin-ajax.php should just be deprecated altogether. In lieu of such a terrible idea (and keeping with WordPress' extreme commitment to backwards compatibility), a more performant ajax handler should be introduced.
Related/Duplicate: #12400