gbbgadmin

Wow. I don’t know how I missed your relevanssi_do_not_index filter when I was reading the documentation. Thank you for pointing this out. This is MUCH cleaner and global. It works perfectly! Thank you.

OK. I have now worked for 2 days around the clock on this issue and cannot seem to find a solution. Maybe if I post enough info here, someone can see something I am missing.

After trying over and over again to get this working, I decided to move our entire wordpress installation to 1 server. This way, I can be sure it is not an issue with a load balancer, proxy, or multiple app servers out of sync. After migrating all WP instances to 1 server, the problem persists.

Here is exactly what is happening:

1. User comes to the site.
2. User signs in.
3. Sometimes user is redirected to our backend dashboard, sometimes not. If not, they are redirected to our homepage (because our functions file is set to redirect non-logged-in users to our homepage).
4. If a user is allowed into our backend, they can normally click 3 or 4 links as usual surfing around in our logged in areas. Then, suddenly, they are redirected to our homepage when they click another link, button, etc. They are treated as if they are not signed in.

NOTE: When you are signed in, sometimes our homepage shows you the sign in option (as if you are not signed in). Other times, it shows you our custom dashboard link (as if you are signed in). If you refresh the page over and over, you will see either links as if you are signed in, or are not. It is as if WP is ignoring it’s own “wordpress_logged_in_” cookie and other cookies that identify you as signed in.

NOTE: Sometimes WP sets an ssl only set of cookies, sometimes it does not. However, 100% of actions made on the site are from SSL connections. And, I have verified that 100% of the time our connection is fully SSL (not mixed) and has the full “green bar” on various browsers with zero errors or mixed content on the page. So, I have no idea why WP randomly chooses SSL and non-SSL cookies.

My setup at the present moment is MUCH simpler than before. Instead of multiple WP servers behind an Nginx load balancer, 100% of traffic is being sent to 1 single WP server, listening on 80 and 443.

Now for the configs:

Traffic comes into the site at a single Nginx server. This is a multisite install with tons of sub-domains. So, we have a Nginx server block enabled for “sub_domains” that essentially catch all 80 requests for any sub-domain and rewrite them to 443. Example of one is here:

server {
listen 80;
server_name sub1.example.com;
return 301 https://sub1.example.com$request_uri;
}

In addition, we have a catchall 80 server block for the main domain:

server {
listen 80;
server_name example.com www.example.com;
return 301 https://example.com$request_uri;
}

In my opinion, and a great deal of research, these should be ok. They should not be causing any issues because essentially, they are just making sure all requests to the server for any sub-domain, or the primary domain, are being redirected to their https versions.

Now, we handle all the https traffic at nginx with a server block like this:

include global/cache.conf;
add_header X-Cache $upstream_cache_status;
server {
listen 443 ssl;
server_name example.com *.example.com;
ssl on;
ssl_certificate /path/to/example.com.chained.crt;
ssl_certificate_key /path/to/example.com.key;
add_header Strict-Transport-Security "max-age=31536000";
ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
ssl_prefer_server_ciphers on;
ssl_ciphers 'ECDH+AESGCM:ECDH+AES256:ECDH+AES128:DH+3DES:!ADH:!AECDH:!MD5';
root /path/to/wordpress;
index index.php index.html index.htm;
include global/restrictions.conf;
error_page 404 /404.html;
location = /404.html {
root /path/to/wordpress/wp-content/themes/exampletheme;
internal;
}
error_page 500 501 502 503 504 /5xx.html;
location = /5xx.html {
root /path/to/wordpress/wp-content/themes/exampletheme;
}
set $skip_cache 0;
# POST requests and urls with a query string should always go to PHP
if ($request_method = POST) {
set $skip_cache 1;
}
if ($query_string != "") {
set $skip_cache 1;
}
# Don't cache uris containing the following segments
if ($request_uri ~* "/dashboard/|/restore-sign-in-credentials/|/sign-in/|/recover-account/|/join-now/|/advertiser-sign-in/|/publisher-sign-in/|/advertiser-registration/|/publisher-registration/|/site-views-creator/|/site-tester/|/video-tester/|/wp-admin/|/xmlrpc.php|wp-.*.php|/feed/|index.php|sitemap(_index)?.xml") {
set $skip_cache 1;
}
# Don't use the cache for logged in users or recent commenters
if ($http_cookie ~* "comment_author|wordpress_[a-f0-9]+|wp-postpass|wordpress_no_cache|wordpress_logged_in") {
set $skip_cache 1;
}
location / {
try_files $uri $uri/ /index.php?$args;
}
location ~ \.php$ {
try_files $uri =404;
include fastcgi_params;
fastcgi_pass unix:/var/run/php5-fpm.sock;
fastcgi_index index.php;
fastcgi_cache_bypass $skip_cache;
fastcgi_no_cache $skip_cache;
fastcgi_cache WORDPRESS;
fastcgi_cache_valid 30m;
}
location ~ /purge(/.*) {
fastcgi_cache_purge WORDPRESS "$scheme$request_method$host$1";
}
location ~* ^.+\.(ogg|ogv|svg|svgz|eot|otf|woff|mp4|ttf|rss|atom|jpg|jpeg|gif|png|ico|zip|tgz|gz|rar|bz2|doc|xls|exe|ppt|tar|mid|midi|wav|bmp|rtf)$ {
access_log off; log_not_found off; expires 3d;
}
}

NOTE: included restrictions file is pretty standard file to restrict people trying to directly access php files, etc.

I have reviewed the nginx blocks extensively and cannot find any issues with Nginx serving the site incorrectly or failing to write/rewrite any requests properly. So, I really don’t think it is an issue with Nginx.

NOTE: We are behind Cloudflare, and we use Full SSL with them. Our certificates are up to date and valid.

Now, for WP Config file, we have the following settings that should correctly control https behind cloudflare:

if ($_SERVER['HTTP_X_FORWARDED_PROTO'] == 'https') $_SERVER['HTTPS'] = 'on';
if (isset($_SERVER["HTTP_X_FORWARDED_FOR"])) {$_SERVER['REMOTE_ADDR'] = $_SERVER["HTTP_X_FORWARDED_FOR"];}
define('FORCE_SSL_ADMIN', true);

In the db, the home_url and site_url for all subdomains and primary domain are like:
https://example.com
https://sub1.example.com

Also, I have gone through the db and code and verified that 100% of page guid (in db) are https://example.com/?page=xxx as they should be.

It is driving me crazy. Everything was working perfectly until this forced 4.5.1 update on the 28th. Now, WP seems to ignore it’s own user logged in cookies, or session controls.

One thing interesting is that with Google dev tools I seem to see that there is some WP javascript redirect happening when the user is not recognized as logged in. Even though the WP cookies are set, the site still treats you as if you are not signed in about 90% of the time.

Anyone have any clue what else I can do?

We have solved this issue by reverting our entire infrastructure back to MySQL 5.6 (not Percona) and rolling back to PHP-FPM V. 5.6. Now HyperDB works as expected. So, apparently you are correct. The issue is in PHP 7.0 or versions above 5.6 as we can see in our testing.

After nearly 24 hours working on this issue, I am beginning to think there are serious problems between HyperDB and WordPress 4.4.1 version. I am going to downgrade to WordPress 4.3.2 version (latest that says HyperDB works with on the plugin page) and see what happens. Will post results here. If it works on 4.3.2 we will know it is a WordPress version incompatibility issue.