![(please configure the [header_logo] section in trac.ini)](/chrome/site/your_project_logo.png){kind=logo}
Opened 14 years ago
Closed 14 years ago
#20340 closed defect (bug) (invalid)
/wp-includes/user.php get_blogs_of_user( ) bad multisite check
| Reported by: | scottconnerly | Owned by: | |
|---|---|---|---|
| Priority: | normal | Milestone: | |
| Component: | Multisite | Version: | |
| Severity: | normal | Keywords: | |
| Cc: | Focuses: |
Description
Should not use defined( 'MULTISITE' )
should use is_multisite() instead
Change History (2)
#2
@
14 years ago
- Milestone Awaiting Review
- Resolution → invalid
- Status new → closed
is_multisite() is a broad function that returns true in one of two cases:
- If the site was a MU-era multisite, by detecting the SUNRISE or VHOST constants (or the VHOST successor, SUBDOMAIN_INSTALL).
- If the site was a 3.0-era multisite, by detecting the MULTISITE constant.
There is a distinct difference between MU and 3.0. In MU, the first site's tables were the table prefix (so we'll say wp_) plus the site ID (so wp_1_). The next site was wp_2_, etc.
In 3.0, the first site's tables keep the original table prefix. So, the first site is wp_, the second is wp_2_, etc.
We use a check against the raw MULTISITE constant whenever we need to tell the difference between wp_ and wp_1_. This happens at the database layer and in a few other places.
In this case, get_blogs_of_user() is looking to see if there is a usermeta row in the form of wp_capabilities. This is something that would only apply in a 3.0-era site, as a MU-era site would have wp_1_capabilities as the usermeta row for capabilities for the first site. Thus, the check.
Related: [18928]