WordPress.org

Make WordPress Core

Opened 3 years ago

Closed 3 years ago

#36614 closed defect (bug) (wontfix)

admin-ajax.php is not compatible with multisite

Reported by: helium-3 Owned by:
Milestone: Priority: normal
Severity: normal Version: 4.3
Component: Networks and Sites Keywords:
Focuses: multisite Cc:
PR Number:

Description

I have noticed a major problem with admin-ajax.php on multisite.

admin-ajax.php works completely only for the primary blog

It seems like on mulisite admin-ajax.php is just a regular primary blog page. You could use switch to blog, but it doesn't work completely. For example $user->roles will return roles for the primary blog, even after you switched. current_user_can_for_blog doesn't seem to work at all during ajax call. The only way to check user roles for a specific blog is to check usermeta.

But that's just if the plugin is active networkwide. What if the plugin is active for a blog, other than primary? It won't fire at all in admin-ajax.php . Meaning admin-ajax.php is unusable to plugins activated on a blog other than primary.

WordPress needs to stop treating admin-ajax.php as if it was a primary blog page. There should be a request parameter, like blog_id which would tell which blog we are running request for.

I think this should be fixed asap in the next release. This basically prevents writing plugins which should work on a specific blog of multisite and use ajax.

Change History (5)

#1 @dd32
3 years ago

  • Keywords reporter-feedback added

admin-ajax.php should definitely work on Multisite setups already.

This sounds like the server rewrite rules for your install may be setup incorrectly, can you clarify what your configuration is?

  • Apache, nginx, or something else
  • Multisite with subdirectories, or subdomains? etc.
  • Is this a new install of Multisite? Which version did you first install? (If you can remember)

#2 @helium-3
3 years ago

Ok, I'm sorry it seems to be working. I just thought that there's only one admin-ajax.php, I didn't think of rewrites. But it would be nice if we could call admin-ajax.php directly without rewrite and specify blog_id as a request parameter.

#3 @dd32
3 years ago

  • Keywords reporter-feedback removed
  • Milestone Awaiting Review deleted
  • Resolution set to invalid
  • Status changed from new to closed

Would you like to also call wp-admin/ by specifying a blog_id parameter too?

It doesn't make much sense to allow that, the context of the site is determined by the URL structure of the request, either subdomain or sub folder.

#4 @helium-3
3 years ago

  • Resolution invalid deleted
  • Status changed from closed to reopened

In my humble opinion it creates confusion, as if there were multiple admin-ajax.php files, but there is just one. I only suggested an alternative that could co-exist, not a replacement of what is currently used. Your example quite differs from my situation. /wp-admin is a part of WordPress, but I'm using admin-ajax to fetch json data for single page application that lives outside of WordPress. It would very much make sense to call the file directly, that's why I created this ticket, it confused me. With the current approach you have to know whether network uses subdomains or directories, with this approach all you would need is blog id. I think it would be a move in the right direction.

I'd very much prefer to use
domain.com/wp-admin/admin-ajax.php?action=my_action&blog_id=4 than
domain.com/blog_path/wp-admin/admin-ajax.php?action=my_action AND
subdomain.domain.com/wp-admin/admin-ajax.php?action=my_action

for making ajax calls outside of WordPress. Just my 2 cents.

#5 @dd32
3 years ago

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

In that case, I'll mark it as wontfix instead.

We have no desire to allow this format, although you could enable this style of access by either defining the site to load through wp-config.php or wp-content/sunrise.php

The WordPress REST API and XML-RPC are also only available through the individual blog URLs.

Note: See TracTickets for help on using tickets.