WordPress.org

Make WordPress Core

Opened 4 years ago

Closed 5 months ago

Last modified 4 months ago

#18307 closed defect (bug) (wontfix)

Settings mixed with WP installations sharing same database

Reported by: 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)

comment:1 @nacin4 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.

comment:2 @GDragoN4 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.

comment:3 @nacin4 years ago

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

comment:4 @GDragoN4 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.

comment:5 @prettyboymp4 years ago

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

comment:6 @GDragoN4 years ago

No, nothing like that.

comment:7 @GDragoN3 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.

comment:8 @nacin3 years ago

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

comment:9 @edward mindreantre3 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.

comment:10 @nacin3 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.

comment:11 @chriscct75 months 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

comment:12 @johnbillion4 months ago

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