For multiple single-site installs on single server, should WP_CACHE_KEY_SALT default to db_name + table_prefix?

[jeffwidman]

I have multiple single-site installs on a single server. All use the same memcache server.

I want to make sure each site uses distinct keys to avoid collisions.

From the code, it looks like I have to manually specify a unique WP_CACHE_KEY_SALT in each site's wp-config.php to guarantee each site has unique namespacing of keys.

Might it be better to make WP_CACHE_KEY_SALT default to db_name + table_prefix? This should prevent collisions if I forget to define WP_CACHE_KEY_SALT. Some single-site installs on a single server will use the same database with different table prefixes, some will use different databases with the same table prefix, but a combination of the two should guarantee uniqueness. Inspired by here.

I also looked into using site_id + blog_id, but because they're single-site installs and thus unaware of each other, it doesn't look like this works. Alternatively, perhaps there's a variable for the domain name/subfolder that could be used instead?

I can submit a PR if desired, just wasn't sure if this was the best way to handle the issue... I'm rather new to Wordpress.

[tollmanz]

I want to make sure each site uses distinct keys to avoid collisions.

Are you actually having a problem with collisions or are you trying to be proactive about it?

Currently, the buildKey method attempts to handle this issue. If you are using single site installs, the blog_prefix instance variable is set to the $table_prefix global variable (e.g., something like wp_ or wp1_). 'global_prefixis similarly set using$table_prefix` in single site, meaning that each single site should have a unique prefix.

I really like to have WP_CACHE_KEY_SALT set. It allows you a very crude way to flush the cache for a single site. If you change the value, you will force cache misses for all objects for that site, effectively flushing the cache for that whole site, but not affecting the other sites.

Let me know if you are actually seeing an issue with this and we can work on a fix. As far as I know, this issue should already be taken care of.

[jeffwidman]

Thanks for the fast response. Really appreciated.

Are you actually having a problem with collisions or are you trying to be proactive about it?

Proactive. Was going to drop this in yesterday when I realized it might not protect against collisions...

I really like to have WP_CACHE_KEY_SALT set.

Agreed--it's a useful hack. Unfortunately it's not mentioned in the Readme, so most folks won't be aware of it. Plus if I set this up on a server for a client, they may later add more single-site installs without remembering to do this... for one reason or another, sometimes WP_CACHE_KEY_SALT won't get set.

Currently, the buildKey method attempts to handle this issue. If you are using single site installs, the blog_prefix instance variable is set to the $table_prefix global variable (e.g., something like wp_ or wp1_). global_prefix is similarly set using $table_prefix in single site, meaning that each single site should have a unique prefix.

So you're saying that in single-site installs, the uniqueness of the memcache key prefix is solely based on $table_prefix?

Then if an admin doesn't change the default wp_ prefix, and doesn't realize they need to set WP_CACHE_KEY_SALT, there will be collisions.

Let me know if you are actually seeing an issue with this and we can work on a fix. As far as I know, this issue should already be taken care of.

No problem. I can set WP_CACHE_KEY_SALT.

Thankful for your hard work here, and not trying to invent edge cases. However, not sure this is an edge case because it happens when an admin leaves everything at default.

This is how I was originally going to set things up yesterday. I wasn't aware of WP_CACHE_KEY_SALT, and currently each of my single-site installs use the default wp_ prefix, which works even though they're connecting to the same MySQL server instance because they use separate MySQL databases. Changing the table prefix is of dubious security value, so I just left it at the default value.

Sounds like we both agree this plugin should safely handle the scenario where an admin leaves everything at default. One simple solution is use db_name in addition to $table_prefix for building keys when WP_CACHE_KEY_SALT isn't set.

[tollmanz]

Agreed--it's a useful hack. Unfortunately it's not mentioned in the Readme, so most folks won't be aware of it.

Yep...your point is well taken. I need some improvements there. I do remember that when I first started messing with memcached in the WP context, the cache poisoning from two sites on the same memcached server was maddening. I can definitely save people headaches if this is better documented.

Then if an admin doesn't change the default wp_ prefix, and doesn't realize they need to set WP_CACHE_KEY_SALT, there will be collisions.

Realizing now that my comments assumed the db tables were in the same db. If that is the case, there will be no collision. If the admin sets up unique dbs, the prefix will mostly likely be the same.

One simple solution is use db_name in addition to $table_prefix for building keys when WP_CACHE_KEY_SALT isn't set.

Yeah...this seems really reasonable. I need to think about this some more, but seems like it might be a good thing to add.

[portablesoft]

Hi, all.

I also have questions about the multiple single-site installs on single server.

I use different db_name and different table_prefix for the multiple single-sites. However, when I update the WordPress on one of the single-site. The entir cache in Memcached was delete. WordPress calls wp_cache_flush() when updating which flush the entir Memcached cache.

How to flush the cache of the only affected site?

Shoud I define WP_CACHE_KEY_SALT in the wp-config.php?

Thanks.

[tollmanz]

Shoud I define WP_CACHE_KEY_SALT in the wp-config.php?

Absolutely! If you have two single sites using the same memcached instance, you must set a unique WP_CACHE_KEY_SALT value in each wp-config.php file or you will have significant cache poisoning issues.

WordPress calls wp_cache_flush() when updating which flush the entir Memcached cache.

This is a result of how Memcached works. There is no concept of separate "buckets" that are individually flushable. If you flush the cache, you flush the whole cache. It does not care which application was using the cache. I wish I could say that this is a feature we could build in, but it's a feature of memcached that we cannot change.

[khromov]

@tollmanz Bucket clearing could be accomplished using changeable prefixes (based on time stamp, for example).

Here's an object cache wrapper we wrote for a recent project where we needed to be able to flush parts of the object cache:
https://gist.github.com/khromov/eeb7e21b49c03cfcf86f

Usage:

Cache::set('foo', 'bar'); //Uses object cache
Cache:invalidate(); //will clear only foo => bar
Cache::get('foo'); //null, but rest of object cache is preserved