i.macdonald

It seems that certain chmod actions via ftpsockets are failing [in created directories with hidden files], and a change on the FS method to ftpext resolves it, even though it is still via FTP.

Indeed we were not able to replicate the failed chmod using FTP directly via localhost on the cli with the same user and ACLs.

We do not know why this happens with ftpsockets vs ftpext for local FTP upgrades, but we captured a similar instance with another plugin and then started to look more closely. It seems not many plugin upgrades are chmoding hidden files, so it was not caught.

We do not know why this workaround works, or what causes it not to work. It seems likely that via sockets has some constraints beyond just the ACLs in newly created directories, possibly using a different creation mask during the upgrade session that results in the permission change.

Below the change that worked and our acl just for reference

#define(‘FS_METHOD’,’ftpsockets’);
define(‘FS_METHOD’,’ftpext’);

Redacted facl with changed username:
`~# getfacl /usr/share/wordpress/wp-content/plugins/
user:[ftpuser]:rwx
default:user:[ftpuser]:rwx

~# getfacl /usr/share/wordpress/wp-content/upgrade/
user:[ftpuser]:rwx
default:user:[ftpuser]:rwx

~# getfacl /usr/share/wordpress/wp-content/plugins/woocommerce-pdf-invoices-packing-slips/
user:[ftpuser]:rwx
default:user:[ftpuser]:rwx

So an Export feature, in addition to an import feature would be the feature request.

I’ll also add my 2c on new feature request (I was hoping for a pay version that enabled this)

It would be great to be able to switch redirection templates during upgrades.

In our case, we would like to be able to put up /temporarily-out-of-service during upgrades of our major payment gateway WP plugins.

Even though we have a QA environment and can promote in minutes, we don’t want to risk a single transaction going through, and this would avoid manual work using IPtables, DNS and/or manual mod_rewrite during these windows. It would just make things easier.

Okay, so I have a gray bar, and some cropped images.

On that last note, I think the error is unrelated. I can’t reproduce any longer, so I think it may have occurred when I tested the older v1.4 version of the plugin (currently packaged for Debian as wordpress-shibboleth).

I am still having no luck getting this working.

I have tested this on a couple of different instances, with no luck. I can see the user created after authentication, the Shibboleth session is active but the user session is not recognized by WordPress.

A few more details on my setup:
Debian 8.0(Jessie) with the following packages:
wordpress 3.9.1+dfsg-1
libapache2-mod-shib2 2.5.3+dfsg-1+b1
php5 5.6.0~b5+dfsg-4
mysql 5.5.37-1
apache 2.4.9-2

I also found this error in my Apache logs which I assume has to be related (site obfuscated). It looks like a shib hook/action failing, which I assume must be where wordpress is failing. Could this be a SQL syntax bug?

[Tue Jul 01 13:59:34.282248 2014] [:error] [pid 5768] [client 99.234.122.9:53610] WordPress database error You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near ‘WHERE meta_key = ‘shibboleth_update_roles’ AND site_id = 0′ at line 1 for query SELECT meta_value FROM WHERE meta_key = ‘shibboleth_update_roles’ AND site_id = 0 made by activate_plugin, do_action(‘activate_shibboleth/shibboleth.php’), call_user_func_array, shibboleth_activate_plugin, shibboleth_add_option, referer: https://<sitename>/wp-admin/plugins.php

Using the vanilla tarball seems easy (at least at first), but in my experience/opinion the Debian packages are preferred for production environments, particularly where security and stability are paramount.

A couple of tricks with Debian (or the DotDeb repos).
* Make sure your FTP autoupdate user has permissions set properly using extended access lists. This way you avoid granting access to the webserver or other users to write in your sensitive wp-content directory. A lot of HOWTOS just chmod the entire path as writable by the www-data user. (I base my own setup off of https://shiftedbits.org/2012/01/29/enable-wordpress-automatic-updates-on-a-debian-server/)
* Do the same for your developers in terms of ACLs via SFTP/SSH.
* The aliased /var/lib/wordpress/wp-content provides additional security and is easily maintained by using “dpkg-reconfigure wordpress” which will symlink themes and plugins installed as necessary.

So, you can have a single web root /site where all the core code and user content sits completely accessible to the webserver and rely entirely on wordpress/plugin developers to put security over functionality
OR
You can run a packaged version that separates permissions related to resource modification and separates readable and writable resources to help indemnify against the never ending discover – expose – fix lifecycle of vulnerabilities across the platform. No to mention it actual runs against OS built libraries so no worrying about versions of any supporting PHP components.

After more testing I can confirm that the decode error I am seeing is only present when HTML/XML gzip option is enabled; So I have disabled it for now.

I also confirmed what looks like a related bug. If you follow these steps, gzip encoding is still enabled even though it should not be.

a) Turn on Browser Cache with gzip enabled generally and restart nginx/phpfpm.
b) Confirm in browser content encoding as expected
c) Turn off the HTML/XML gzip compression
d) Restart nginx/phpfpm to reload config
e) Clear browser cache and close browser
f) Open up and go to website
g) Additionally refresh the page
h) Headers still show content encoding gzip
i) Confirm w3tc config shows false in written configuration

It seems the configuration is being ignored for whatever reason when you follow these steps. Deactivation and re-activation is one workaround.

After a thorough review of my setup, it seemed that the gzip encoding was not my phpfpm or nginx; So even though I had disabled the W3TC browser cache gzip settings (in the general part, and each sub-section of the config), I went ahead and disabled the entire W3TC plugin.

And at that point the gzip encoding stopped.

After re-enabling W3TC and turning on the same browser cache settings without the gzip enabled, I am now seeing the expected text/html encoding on my web site pages.

It seems that there is something strange going on with the gzip configuration W3TC is applying.

Verification of nginx conf rewrites and nginx restarts following settings changes does not seem to be a factor. I use the auto-install which seem to be accurately detect when settings have been properly applied – both in terms of auto-install to nginx.conf and if the server is using them (reload/restart).

I have modified my W3TC browser cache config to disable gzip compression. I have confirmed that nginx does not have gzip set, and w3tc nginx.conf is not setting it and that nginx gzip default is still off (all expected).

However I still have a gzip encoding header. It looks like I have introduced a config issue with phpfpm (my assumption right now). I thought I had ruled out double encoding already, but missed something. I’ll confirm my assumptions later, but it doesn’t appear W3TC has anything to do with my issue after further investigation.

Below is the access log from another two tests today. Here is the transcript of my first session.

a) Opened browser, checked google calendar, opened up our site with W3TC enabled in a new tab and received an Error 330. [9:42:26]

b) Closed all browser windows completely, opened up browser, navigated to our site with W3TC enable, and it appears instantly, fine. [9:44:01]

Looking at the access logs (no other traffic in this window, I have included all logs from this time frame, nothing in error log), in the second working case, the web site was still loaded completely from cache as there were no additional requests – which is great, but why the decode error on the first attempt?

70.28.78.161 – – [10/Apr/2012:09:42:26 -0400] “GET / HTTP/1.1” 200 3487 “-” “Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/535.19 (KHTML, like Gecko) Chrome/18.0.1025.151 Safari/535.19”
70.28.78.161 – – [10/Apr/2012:09:42:42 -0400] “-” 400 0 “-” “-“
70.28.78.161 – – [10/Apr/2012:09:42:42 -0400] “-” 400 0 “-” “-“
70.28.78.161 – – [10/Apr/2012:09:42:42 -0400] “-” 400 0 “-” “-“
70.28.78.161 – – [10/Apr/2012:09:42:42 -0400] “-” 400 0 “-” “-“
70.28.78.161 – – [10/Apr/2012:09:42:42 -0400] “-” 400 0 “-” “-“
70.28.78.161 – – [10/Apr/2012:09:44:01 -0400] “GET / HTTP/1.1” 200 3474 “-” “Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/535.19 (KHTML, like Gecko) Chrome/18.0.1025.151 Safari/535.19”
70.28.78.161 – – [10/Apr/2012:09:44:15 -0400] “-” 400 0 “-” “-“
70.28.78.161 – – [10/Apr/2012:09:44:15 -0400] “-” 400 0 “-” “-“
70.28.78.161 – – [10/Apr/2012:09:44:15 -0400] “-” 400 0 “-” “-“
70.28.78.161 – – [10/Apr/2012:09:44:15 -0400] “-” 400 0 “-” “-“
70.28.78.161 – – [10/Apr/2012:09:44:15 -0400] “-” 400 0 “-” “-“

Here is the second session from another computer, using IE8 this time. In this case I hit the main page [09:55:30] no issues and it is served from cache except the minified css and js, proceed to the /products URL [09:55:35] and receive the equivalent decode error from IE. I close the browser, re-open and go directly to the /products URL [09:56:43 and the page loads correctly. In this case, I can see the “page prime” occur on the server [09:56:44] , but I am not sure this has an impact on my request or [suspected] browser caching issues.

70.28.78.161 – – [10/Apr/2012:09:55:30 -0400] “GET / HTTP/1.1” 200 3474 “-” “Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; Trident/4.0; .NET CLR 1.1.4322; .NET CLR 2.0.50727; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729; InfoPath.3)”
70.28.78.161 – – [10/Apr/2012:09:55:30 -0400] “GET /wp-content/w3tc/min/85bc4f72.88aa3a.css HTTP/1.1” 200 10388 “https://www.netstatz.com/&#8221; “Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; Trident/4.0; .NET CLR 1.1.4322; .NET CLR 2.0.50727; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729; InfoPath.3)”
70.28.78.161 – – [10/Apr/2012:09:55:30 -0400] “GET /wp-content/w3tc/min/3fe8f48e.5b2675.js HTTP/1.1” 200 47708 “https://www.netstatz.com/&#8221; “Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; Trident/4.0; .NET CLR 1.1.4322; .NET CLR 2.0.50727; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729; InfoPath.3)”
70.28.78.161 – – [10/Apr/2012:09:55:35 -0400] “GET /products/ HTTP/1.1” 200 4924 “https://www.netstatz.com/&#8221; “Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; Trident/4.0; .NET CLR 1.1.4322; .NET CLR 2.0.50727; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729; InfoPath.3)”
70.28.78.161 – – [10/Apr/2012:09:56:43 -0400] “GET /products/ HTTP/1.1” 200 4904 “-” “Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; Trident/4.0; .NET CLR 1.1.4322; .NET CLR 2.0.50727; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729; InfoPath.3)”
96.8.120.21 – – [10/Apr/2012:09:56:43 -0400] “GET /sitemapindex.xml HTTP/1.0” 200 1036 “-” “W3 Total Cache/0.9.2.5b”
96.8.120.21 – – [10/Apr/2012:09:56:43 -0400] “GET /site.xml HTTP/1.0” 200 700 “-” “W3 Total Cache/0.9.2.5b”
96.8.120.21 – – [10/Apr/2012:09:56:43 -0400] “GET /post.xml HTTP/1.0” 200 896 “-” “W3 Total Cache/0.9.2.5b”
96.8.120.21 – – [10/Apr/2012:09:56:43 -0400] “GET /page.xml HTTP/1.0” 200 1236 “-” “W3 Total Cache/0.9.2.5b”
96.8.120.21 – – [10/Apr/2012:09:56:43 -0400] “GET /taxonomy_category.xml HTTP/1.0” 200 1078 “-” “W3 Total Cache/0.9.2.5b”
96.8.120.21 – – [10/Apr/2012:09:56:43 -0400] “GET /?w3tc_preload=1 HTTP/1.0” 200 15181 “-” “W3 Total Cache/0.9.2.5b”
96.8.120.21 – – [10/Apr/2012:09:56:44 -0400] “GET /microsoft-enables-linux/?w3tc_preload=1 HTTP/1.0” 200 22419 “-” “W3 Total Cache/0.9.2.5b”
96.8.120.21 – – [10/Apr/2012:09:56:44 -0400] “GET /site-update/?w3tc_preload=1 HTTP/1.0” 200 21888 “-” “W3 Total Cache/0.9.2.5b”
96.8.120.21 – – [10/Apr/2012:09:56:44 -0400] “GET /wordpress-performance/?w3tc_preload=1 HTTP/1.0” 200 19997 “-” “W3 Total Cache/0.9.2.5b”
96.8.120.21 – – [10/Apr/2012:09:56:44 -0400] “GET /monitoring-tool/?w3tc_preload=1 HTTP/1.0” 200 18878 “-” “W3 Total Cache/0.9.2.5b”
96.8.120.21 – – [10/Apr/2012:09:56:44 -0400] “GET /services/?w3tc_preload=1 HTTP/1.0” 200 18563 “-” “W3 Total Cache/0.9.2.5b”
96.8.120.21 – – [10/Apr/2012:09:56:44 -0400] “GET /products/?w3tc_preload=1 HTTP/1.0” 200 19972 “-” “W3 Total Cache/0.9.2.5b”
96.8.120.21 – – [10/Apr/2012:09:56:44 -0400] “GET /category/netstatz/?w3tc_preload=1 HTTP/1.0” 200 18263 “-” “W3 Total Cache/0.9.2.5b”
96.8.120.21 – – [10/Apr/2012:09:56:44 -0400] “GET /category/industry/vps/?w3tc_preload=1 HTTP/1.0” 200 16137 “-” “W3 Total Cache/0.9.2.5b”
96.8.120.21 – – [10/Apr/2012:09:56:44 -0400] “GET /category/industry/?w3tc_preload=1 HTTP/1.0” 200 15956 “-” “W3 Total Cache/0.9.2.5b”
96.8.120.21 – – [10/Apr/2012:09:56:44 -0400] “POST /wp-cron.php?doing_wp_cron=1334066203 HTTP/1.0” 200 1 “-” “WordPress/3.3.1; https://www.netstatz.com&#8221;
70.28.78.161 – – [10/Apr/2012:09:56:46 -0400] “GET /wp-content/w3tc/min/9a9148a4.c95cfe.js HTTP/1.1” 200 38734 “https://www.netstatz.com/products/&#8221; “Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; Trident/4.0; .NET CLR 1.1.4322; .NET CLR 2.0.50727; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729; InfoPath.3)”
70.28.78.161 – – [10/Apr/2012:09:56:47 -0400] “GET /wp-content/w3tc/min/9a9148a4.c95cfe.js HTTP/1.1” 200 47965 “https://www.netstatz.com/products/&#8221; “Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; Trident/4.0; .NET CLR 1.1.4322; .NET CLR 2.0.50727; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729; InfoPath.3)”

I am going to mess around with disabling the client caching encouragement techniques (various headers set in W3TC browser config)

-unset expires header
-unset cache control header
-review cache-control policy (currently set-with-max-age)
-unset entity tag (eTag)

It seems the browser messes things up on its own, without getting fresh data from the server other than the first 200. I suspect there is something about the headers on that first 200 that prevent proper referral/alignment to the cached data.

I also believe I see this problem on browsers that have never been to the site – which is counter intuitive to the caching configuration issue.

I found that using the HTML Tidy for HTML minification broke all my IE rendering. Using the “Default” built in minify options resolved my IE problems. I noticed that HTML Tidy was actually purging some of the comments-in-code. Even with HTML Tidy selected, and unchecking the comment functions it broke IE (though I could not tell what the root cause was from view source in this particular setup). Bottom line is that I could not make W3TC work with HTML Tidy selected, and minification enabled.

I still have not found out why the agent filter is not working, however I did solve my problem with IE by using the default HTML minifier rather than HTML Tidy (the only choice on the list).

I actually thought that Default=HTML Tidy, since no other options are provided; This is the way it works with JS and CSS, except that one of the choice is the default. Being explicit here is misleading, and led me to this problem. I would suggest changing Default to Built-In (default) to reduce errors in minify config, which can be pretty complex anyways.

Another suggestion is to have the auto JS minification insert itself after CSS fonts. In auto mode, my JS loads before my CSS fonts, with Auto-minify. Gtmetrix degrades me, rightfully so, for not loading all CSS elements before the JS code.

So now I have full minification working on all agents. W3TC is really powerful = awesome. I’m down to 1s load times, mostly static images.

I’ve moved up the food chain to 3.3.1 and 9.2.5a and my problems have gone away

Just about to submit a bug report with my details; (came here to grab the forum link)