#29095 closed defect (bug) (fixed)
The get/set_user_setting fails on multisite/network with sub-domains
Reported by: |
|
Owned by: |
|
---|---|---|---|
Milestone: | 4.0 | Priority: | normal |
Severity: | normal | Version: | |
Component: | Options, Meta APIs | Keywords: | |
Focuses: | Cc: |
Description
When both the main site (network.domain) and a particular site (site.network.domain) set the wp-settings-123
cookie for a user, both cookies are send by the browsers when that user visits the sub-domain site. This results in one cookie overloading the other in the $_COOKIE
array, as both have the same name.
The end result is that user settings like default editor, image size and link when inserting in a post, menu folded/unfolded, etc. are not set properly on page load.
Attachments (1)
Change History (13)
#2
@
11 years ago
- Owner set to azaozz
- Resolution set to fixed
- Status changed from new to closed
In 29362:
#3
@
11 years ago
- Resolution fixed deleted
- Status changed from closed to reopened
Ugh, this was actually broken by [28895], more specifically by adding COOKIE_DOMAIN
to the 'wp-settings-' . $user_id
cookie...
"... However, there is a difference between a cookie set from foo.com without a domain, and a cookie set with the foo.com domain. In the former case, the cookie will only be sent for requests to foo.com. In the latter case, all sub domains are also included."
Some of this needs to be reverted.
#5
@
11 years ago
So how is this now site-specific again?
Re-opening for further review as there is a lot of churn here at a fairly low level.
#7
@
11 years ago
[29478] reverts most of [29362] keeping only whitespace/braces changes and adds secure
when setting the cookie from JS. The actual fix is removing COOKIE_DOMAIN
from the 'wp-settings-' . $user_id
cookies when setting them from PHP. That was added in [28895] probably by mistake, and I missed it the first time so [29362] didn't really fix it well.
When a cookie is set with a domain, the browsers send it to that domain and to all sub-domains. When it is set without a domain, it is sent only to the current domain, not to any sub-domains. So if we set a cookie from core.trac.wordpress.org
with a domain of wordpress.org
, it will be sent to all other sub-domains. However if we set the same cookie without a domain, it will only be sent to the current site.
The same is true for the "root" domain. A cookie set on wordpress.org
with a domain of wordpress.org
will be sent to all sub-domains. The same cookie set without a domain will be sent only to wordpress.org
. Some info and links on Wikipedia.
#9
in reply to:
↑ 8
@
10 years ago
Replying to nacin:
Pretty much. The only difference is passing the secure
flag to JS so the cookie can be set from there in exactly the same way as from PHP.
This ticket was mentioned in IRC in #wordpress-dev by helen. View the logs.
10 years ago
#11
@
10 years ago
- Resolution set to fixed
- Status changed from reopened to closed
Appears as though this is fixed.
29095.patch fixes this by appending the current blog id to the cookie name. The users won't notice any changes. The previous settings will be added to the new cookie at the first run after updating. The old cookie will be deleted when the user changes a setting (or will expire).