WordPress.org

Make WordPress Core

Opened 2 years ago

Closed 2 years ago

Last modified 2 years ago

#20499 closed defect (bug) (invalid)

Memcached plugin version 2.0.2 does not work with single site installation

Reported by: toddlahman Owned by: toddlahman
Milestone: Priority: normal
Severity: normal Version:
Component: Cache API Keywords:
Focuses: Cc:

Description

The old 2.0 Memcached plugin properly detected the global $blog_id variable if defined in wp-config.php, but version 2.0.2 does not. The current code only checks to see if is_multisite as such:

global $blog_id, $table_prefix;
$this->global_prefix = '';
$this->blog_prefix = '';
if ( function_exists( 'is_multisite' ) ) {
	$this->global_prefix = ( is_multisite() || defined('CUSTOM_USER_TABLE') && defined('CUSTOM_USER_META_TABLE') ) ? '' : $table_prefix;
	$this->blog_prefix = ( is_multisite() ? $blog_id : $table_prefix ) . ':';
}

I have modified this so it will give a proper value to the global $blog_id and $table_prefix variables to work with a single site installation as shown below:

global $blog_id, $table_prefix;
$this->global_prefix = '';
$this->blog_prefix = '';
if ( function_exists( 'is_multisite' ) && is_multisite() ) {
	$this->global_prefix = ( is_multisite() || defined('CUSTOM_USER_TABLE') && defined('CUSTOM_USER_META_TABLE') ) ? '' : $table_prefix;
	$this->blog_prefix = ( is_multisite() ? $blog_id : $table_prefix ) . ':';
} else {
	$this->global_prefix = $table_prefix;
	$this->blog_prefix = $blog_id;
}

Would be nice if the global $blog_id variable for a single site installation would default to the domain name listed in Site Address or WordPress Address from the database, rather than having a default value of 1. Using the domain name as the $blog_id variable would allow multiple single site installations on the same server to have a unique default $blog_id, and to use Memcached with this Memcached plugin without the need to set a global $blog_id variable in wp-config.php. A similar approach to having a unique globabl $group variable would also be helpful for the same reason if the batcache plugin is used.

Attachments (2)

object-cache.php (9.7 KB) - added by toddlahman 2 years ago.
object-cache patch
object-cache.-2.0.1-patch.php (9.2 KB) - added by toddlahman 2 years ago.

Download all attachments as: .zip

Change History (9)

toddlahman2 years ago

object-cache patch

comment:1 toddlahman2 years ago

This also applies to Memcached plugin version 2.0.1. The fix for 2.0.1 is below.

Original code:

global $blog_id, $table_prefix;
	$this->global_prefix = ( is_multisite() || defined('CUSTOM_USER_TABLE') && defined('CUSTOM_USER_META_TABLE') ) ? '' : $table_prefix;
	$this->blog_prefix = ( is_multisite() ? $blog_id : $table_prefix ) . ':';

Code that allows it to also work on single site installations:

global $blog_id, $table_prefix;
$this->global_prefix = '';
$this->blog_prefix = '';
if ( function_exists( 'is_multisite' ) && is_multisite() ) {
	$this->global_prefix = ( is_multisite() || defined('CUSTOM_USER_TABLE') && defined('CUSTOM_USER_META_TABLE') ) ? '' : $table_prefix;
	$this->blog_prefix = ( is_multisite() ? $blog_id : $table_prefix ) . ':';
} else {
	$this->global_prefix = $table_prefix;
	$this->blog_prefix = $blog_id;
}

comment:2 toddlahman2 years ago

Even after the changes above, single site installations still have data that gets replaced when it should remain persistent. Only Memcached plugin version 2.0 works properly with multiple single site installations on the same server, unless there is something I am missing.

http://plugins.trac.wordpress.org/browser/memcached/tags/2.0

comment:3 toddlahman2 years ago

Yeah I missed something. My first ticket, and I miss something. The problem is the table prefix is not unique, so Don Daniello solved the problem by using part of the NONCE_SALT constant as a unique superprefix. This might be an issue only for older installations that having defined keys and salts. I would prefer to have a unique password key generated and stored in the database to eliminate the need for wp-config.php to be edited, in case the web host doesn't allow writing to a file.

http://wordpress.org/support/topic/plugin-memcached-object-cache-shared-memcached-servers-wrong-content-retuned

http://dondaniello.com/files/release/object-cache.phps

Would like to see this fixed in the object-cache.php version 2.0.1 currently available for download on WordPress.org.

comment:4 ocean902 years ago

  • Keywords has-patch removed
  • Milestone Awaiting Review deleted
  • Resolution set to invalid
  • Severity changed from major to normal
  • Status changed from new to closed
  • Version 3.3.1 deleted

Yeah I missed something. My first ticket, and I miss something.

Yes, this is the trac for WordPress core, not plugins.

For plugins you should directly contact the author or use the plugins trac http://plugins.trac.wordpress.org/report.

comment:5 SergeyBiryukov2 years ago

FWIW, Memcached and After the Deadline (#20505) are not present in the Component dropdown on plugins trac.

While it doesn't make WordPress core trac a correct venue for plugin bug reports, I guess there might be some confusion as to where they should go in that case.

comment:6 nacin2 years ago

Trac is not the correct venue for this, but the lead developer of WordPress is also the developer of the Memcached plugin, and we also use it on WordPress.org etc. I've sent the link to ryan to ensure he sees it.

I agree with the change in the general sense. $blog_id should probably be respected for caching reasons. However, if you have multiple individual installations, you're already going to run into a potential issue with global groups, especially if they have the same table prefix (different databases). Ultimately, just be smarter about your table prefixes and ensure they are unique across a server in which you are using a shared memcached pool, and you will be all set.

comment:7 sivel2 years ago

Ryan and I have discussed this and updated the support forums thread located at http://wordpress.org/support/topic/plugin-memcached-object-cache-does-not-work-with-multiple-single-site-installations-on-same-server

Just wanted to close out the loop here.

Note: See TracTickets for help on using tickets.