s0medude

Unfortunately, I’m seeing problems in various clients so I don’t think I can find a solution through 2/3 of those options. Is there a way I can help get you the time or other resources to implement MIME support in the plugin? It would also be ideal if it could be tested through the current version of wordpress since a lot has changed between 4.4 & 6.1. Your website mentions donations, which I wouldn’t be opposed to if it will help support your work on this plugin.

@t-p Is the auto-update function not a part of WordPress Core? I believe the order of operations goes something like this:

– Core puts site into maintenance mode
– Core initiates scheduled plugin auto-updates
– Core takes site out of maintenance mode*

*This last step being the one that is not happening in this instance

I don’t think the particular plugin in this case is doing anything due to the permissions preventing the user WordPress runs as from updating the plugin. Specifically, the plugin directory being owned by root instead of web user. I have searched for a call to wp_maintenance throughout the plugin directory and do not find it there.

Just to close the loop on this, I believe this was a result of W3TC being unable to write files to WPROOT when enabling this. It seems to copy these files from WPROOT/plugins/w3-total-cache/wp-content: db.php & object-cache.php & advanced-cache.php

The issue was my WP environment does not allow the web server to write files into WPROOT. Once I copied the 3 files manually, I began to see connections to the memcached server during page refreshes.

If you are seeing connections initiated to the Memcache instance when the plugin flushes the Memcache, that means that the DB cache Memcached is working just fine.

Even if I am not seeing any connections to Memcached during normal operation?

If you want you can drop us a note via the plugin in Performance>Support and provide us with the URL or via our website https://www.w3-edge.com/contact/

I can submit contact via the website, but I still cannot provide the URL as it is inaccessible from the public internet.

• This reply was modified 4 years, 7 months ago by s0medude.

I don’t see anything in HTML on wp-admin either, but I believe W3TC is configured to ignore wp-admin pages. I do see the plugin enabled & configured in wp-admin and can provide some data from that if helpful.

The plugin is currently enabled in community mode.
Page cache: enabled - using Disk: Enhanced
Minify: disabled
Database cache: enabled - using memcached
Object cache: enabled - using memcached
Browser Cache: enabled
CDN: enabled - Amazon Cloudfront
Enable varnish cache purging: enabled - 2 varnish IP addresses
Cloudflare - disabled
New relic - disabled
Enable Google Page Speed dashboard widget - enabled
Use single network configuration file for all sites - enabled
Hide performance settings - enabled
Verify rewrite rules - enabled

Oddly, I’m not seeing that snippet either

Hi @vmarko, Thanks for your reply & I hope you are well. I do have debug enabled for the Database cache, but I was not able to find any debugging output in the php error log. Unfortunately, the URL is inaccessible as it’s behind a firewall but maybe you can point me in the right direction.

Hi @mbrsolution, I’m seeing similar behavior. I have confirmed everything is setup properly with the plugin per the above documentation. In my case, it appears your plugin works until I enable another login-related plugin (Active Directory Integration / LDAP Integration, By miniorange @ https://www.ads-software.com/plugins/ldap-login-for-intranet-sites/). Once this plugin is activated & the “Enable LDAP login” box is checked I am able to login with any/all/no text provided in the Google Authenticator field. This seems to effect all users, both LDAP & local.

I am running the latest versions of wordpress (4.9.6), your plugin (0.48), and the LDAP plugin (2.8.2) at the time of writing this comment.

I fixed this by running wp-cli.phar –url=https://my-multisite-url/ core update-db

Did some more digging the extra row in wp_options were mostly all transient ones that went away post-upgrade so I don’t think they are relevant. I then compared the changes to the table and the only one that jumped out at me as potentially relevant was rewrite_rules so I tried normalizing it to match it’s pre-upgrade state but that didn’t change the behavior. I also enabled query logging and called /wp-admin/ to capture the queries being generated and then compared the data returned from both the pre & post data sets. They return identical data so I’m not sure if the actual data is the issue vs. how something in the code is handling it. Anyone have any ideas?

Update: to try and isolate the issue, I went back and upgraded each release in between and it breaks down between 3.8.2 -> 3.8.3. I didn’t pay strict attention, but I believe this may have been the first release after 3.8 that included a database update. I’m trying to compare the before and after DB snapshots and immediately notice a huge difference in the wp_options table. In 3.8.2 there were 10527 rows in the table, but in 3.8.3 there are only 306 rows in the table. At face value this seems like a massive decrease to me. Not sure if that’s expected or an indication that something has gone awry. wp_2_options remained constant @ 267 rows in the table.