Make WordPress Core

Opened 13 years ago

Closed 9 years ago

Last modified 9 years ago

#18307 closed defect (bug) (wontfix)

Settings mixed with WP installations sharing same database

Reported by: gdragon's profile GDragoN Owned by:
Milestone: Priority: normal
Severity: normal Version: 3.2.1
Component: Administration Keywords:
Focuses: Cc:

Description

I have WP website installed on main domain, and another WP installation on subdomain. These two share users tables.

When I rearrange admin dashboard widgets, or post editor widgets in one installation, other one uses same settings making the mess due to differences in available elements (different plugins installed).

All WP settings cookies are saved without proper setting of the cookie path/domain, and all sub-domains use same cookies as the main domain does. Cookies have to have full domain set to avoid mix-up like it happens now.

Same issue happens with Opera, Chrome and Firefox.

Milan

Change History (12)

#1 @nacin
13 years ago

So, two things. For some of this, this might be the problem: They're in different databases but have the same database prefix. (It should be noted that neither of those situations are supported.)

For the rest of this, the problem is that most widget positioning keys are global. I didn't necessarily agree with that due to these kinds of issues, but that's how it currently is.

#2 @GDragoN
13 years ago

They are in the same database, but they don't have same DB prefix. One is 'wp_' and other is 'wpdev_', Both use users tables with 'wp_' prefix. I didn't look deeper how cookie names are generated, but these are not same websites and they are not sharing anything other than users table, and cookies should be different. What if owners of websites are different? I make changes on my website and cause widgets layout problems for other one? This should be changed.

#3 @nacin
13 years ago

They're user-specific, not user-and-site-specific. They're not stored in cookies, they're stored in user metadata.

#4 @GDragoN
13 years ago

OK, than something else is wrong. In usermeta table I have this for a user:

For subdomain website: wpdev_capabilities, wpdev_user-settings, wpdev_user-settings-time. For main domain website: wp_capabilities, wp_user-settings, wp_user-settings-time. Different meta records exist, but still, when I make changes on one website, they are used by the other one. Also, subdomain user-settings meta doesn't contain any editor layout changes (tinymce or html editor for instance), but whatever I set it mirrors to main domain website.

#5 @prettyboymp
13 years ago

Any chance you're running memcached or another object cache and sharing the instance between the two?

#6 @GDragoN
13 years ago

No, nothing like that.

#7 @GDragoN
12 years ago

  • Summary changed from Settings cookies mixed with WP installations on main domain and subdomains to Settings mixed with WP installations sharing same database

I was playing in more details with this. Each panel settings is saved in the database. But, while some use database prefix to save (like capabilities or user settings), settings for edit panels don't use prefixes, so if you have more than one website in same database, they will have same panel settings record.

#8 @nacin
12 years ago

This is intended behavior. As mentioned above, some keys are global for the user, some aren't.

#9 @edward mindreantre
12 years ago

  1. This isn't major.
  1. OP's scenario is neither supported nor a good idea. Asking two installations to share the same user and usermeta tables is asking for tons and tons and tons of trouble.

Suggest no bug / won't fix.

#10 @nacin
12 years ago

This also exists in multisite. It's not ideal. We probably shouldn't unset unrecognized panels in the array, in case they are used on a different site.

#11 @chriscct7
9 years ago

  • Resolution set to wontfix
  • Severity changed from major to normal
  • Status changed from new to closed

As this operates as intended, closing (as suggested above) as wontfix

#12 @johnbillion
9 years ago

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