David

I was having the same problem. It seems like I tried everything under the sun.

I narrowed it down to the database… it was hidden somewhere in there. This was happening on my local machine, whereas the remote version on my VPS worked just fine.

Even reverting back to WordPress 4.x didn’t fix the issue. Using the Classic Editor plugin at least got a new post to semi-load (instead of a white screen), but there were the same errors at the top, and it acted as if I was a contributor instead of an admin (“Submit for Review”), and if I tried to create something, it threw the error that says I don’t have permission to edit this post.

Meanwhile everything else about the site worked. I could edit existing posts, add themes and plugins, change settings, etc.

I have been a WordPress developer for many years and fixed many client sites, but this one really eluding me because I couldn’t narrow it down beyond the DB, and none of the standard fixes worked (change theme, disable plugins, clear cache/cookies, switch browsers, revert version, etc). I looked in the DB for some standard problems and everything looked good. I even tried installing a database backup of my local site from a month before to no avail. Very strange.

I finally “fixed” my site by replacing my local database with my remote version and am using that instead. I have no fixes for someone that wants to address the root issue of this without throwing away their DB, aside from saying that you can eliminate any potential solution that doesn’t change the database.

For me, there was a problem in wp-includes. Downloading a fresh install of WordPress, and replacing my wp-includes folder solved the problem. The .htaccess file wasn’t the problem for me. Maybe there was some glitch when I updated WordPress.

For me, there was a problem in wp-includes. Downloading a fresh install of WordPress, and replacing my wp-includes folder solved the problem. Apparently, sometimes the problem is with wp-includes/.htaccess. That wasn’t the problem for me, but you might want to check that first.

@liomar My solution will probably only help those in the same situation as me: someone with a non-multisite install that is integrating with Cloudflare SSL. I’m sure there are other things that can trigger this problem, which you may be encountering. Things always seem to be less compatible with multisite, so that may be the sole issue for you.

One thing I’d check is how you are implementing SSL, assuming you are. Make sure the certificate is correctly installed on your server. If you are using Cloudflare, deactivate it temporarily to see if that helps. Unfortunately it’s been awhile since I tackled this, so I can’t remember any other steps I took to debug the issue.

I finally figured this out. This was only a problem when the customer logged in through the account page or the checkout page. When I cleared my cookies and then logged in through wp-login.php, I didn’t have this issue.

WooCommerce does some interesting things with login cookies and nonces, which I assume allows them to use WordPress’ user system without giving a basic customer full subscriber access.

Ultimately I needed to remove this code from wp-config.php:

define( 'ADMIN_COOKIE_PATH', '/' );
define( 'COOKIE_DOMAIN', '' );
define( 'COOKIEPATH', '' );
define( 'SITECOOKIEPATH', '' );

I believe I had added that to fix a login redirect loop, which occurred after switching my site to Cloudflare Flexible SSL. I had also added this to wp-config.php to accommodate Flexible SSL, as referenced here and here:

define( 'FORCE_SSL_ADMIN', true );
if ( strpos( $_SERVER['HTTP_X_FORWARDED_PROTO'], 'https' ) !== false ) {
	$_SERVER['HTTPS'] = 'on';
}

I eventually found that WooCommerce is not compatible with Cloudflare Flexible SSL, as mentioned at the bottom of their SSL FAQ page.

I ended up installing a free SSL certificate on my server using Let’s Encrypt, and switched Cloudflare’s setting to “Full (strict)”. Once I had full SSL working, I was able to remove the above lines of code from wp-config.php.

It’s possible that removing the top four “cookie” lines would have solved the issue and I could have continued using Flexible SSL. However, I had installed the SSL cert before discovering that wp-config.php was the issue. Regardless, setting up the full SSL cert is what I should have done in the first place. As Cloudflare says, “Only choose Flexible if your origin webserver cannot accept secure (HTTPS) connections.”

Finally, in debugging this issue, I came across the wc_session_use_secure_cookie filter, which is applied when the login cookie gets set and destroyed in class-wc-session-handler.php. My site seems to work fine no matter which way it’s set, but I added it to functions.php for good measure:
add_filter( 'wc_session_use_secure_cookie', '__return_true' );

Also, in debugging this issue, I came across the wc_session_use_secure_cookie filter, which is applied when the login cookie gets set and destroyed in class-wc-session-handler.php. My site seems to work fine no matter which way it’s set, but I added it to functions.php for good measure:
add_filter( 'wc_session_use_secure_cookie', '__return_true' );

I finally figured this out. WooCommerce does some interesting things with login cookies and nonces, which I assume allows them to use WordPress’ user system without giving a basic customer full subscriber access.

Ultimately I needed to remove this code from wp-config.php:

define( 'ADMIN_COOKIE_PATH', '/' );
define( 'COOKIE_DOMAIN', '' );
define( 'COOKIEPATH', '' );
define( 'SITECOOKIEPATH', '' );

I believe I had added that to fix a login redirect loop, which occurred after switching my site to Cloudflare Flexible SSL. I had also added this to wp-config.php to accommodate Flexible SSL, as referenced here and here:

define( 'FORCE_SSL_ADMIN', true );
if ( strpos( $_SERVER['HTTP_X_FORWARDED_PROTO'], 'https' ) !== false ) {
	$_SERVER['HTTPS'] = 'on';
}

I eventually found that WooCommerce is not compatible with Cloudflare Flexible SSL, as mentioned at the bottom of their SSL FAQ page.

I ended up installing a free SSL certificate on my server using Let’s Encrypt, and switched Cloudflare’s setting to “Full (strict)”. Once I had full SSL working, I was able to remove the above lines of code from wp-config.php.

It’s possible that removing the top four “cookie” lines would have solved the issue and I could have continued using Flexible SSL. However, I had installed the SSL cert before discovering that wp-config.php was the issue. Regardless, setting up the full SSL cert is what I should have done in the first place. As Cloudflare says, “Only choose Flexible if your origin webserver cannot accept secure (HTTPS) connections.”

I am experiencing the same problem. My site is running on Apache on a Digital Ocean VPS, with SSL managed through Cloudflare.

I am having the same issue. I don’t have mod_security installed and never have had it installed. My site is running on Apache on a Digital Ocean VPS. The page works so it’s not a permalink issue.

It seems like I’ve read everything that’s been tried by others on this subject, and nothing has worked. I do see a folder for fail2ban on my server, and I wonder if that could be doing a similar thing as mod_security has done on other sites.

Here’s the solution for using the customer’s real name and allowing them to change it: https://github.com/woocommerce/woocommerce/issues/16015#issuecomment-338519085

I don’t think you can export and then re-import that file with additional data. The import file needs to follow the specific format that’s listed on the import page, and it has fewer columns than the export file has. The import file needs to have the exact number of columns the program expects… for instance, even if you’re not using the Email column, you still need to have it there, or else it will mess all of the other data up. My assumption is that the plugin disregards the content in the header row (i.e. it doesn’t check to make sure that the third column is actually “Email”).

Fortunately, I think the free plugin can do what you want it to do. But you first need to add all custom questions (e.g. Dealer Name) from the plugin itself. Although you cannot import custom questions, you can assign attendees to those questions during the import. As the import page describes, you just have columns for your custom questions, like pq_1, pq_2, etc., and then attendees will be assigned those questions if “Y” is in the cell for those columns.

I had this problem, and it was actually a hosting issue. I had to add this to php.ini:
allow_url_fopen = On

Thanks Pete, that worked perfectly for me. I had switched hosting providers and the new one didn’t have allow_url_fopen on by default. Adding allow_url_fopen = On to php.ini worked for my host, and for my local site on XXAMP, I had to add this extension to php.ini: extension=php_openssl.dll

I also had this issue and wanted to confirm that putting the site into Learning Mode worked for me. I had to try it a couple times, but eventually it allowed me to send mail, and it added a whitelist entry.

It’s probably not W3TC’s fault… they are using is_ssl() to check for SSL pages. Check out the notes in the documentation and try adding this to the bottom of your wp-config.php file (above the require_once call):

if ( isset( $_SERVER['HTTP_X_FORWARDED_PROTO'] ) && 'https' == $_SERVER['HTTP_X_FORWARDED_PROTO'] ) {
  $_SERVER['HTTPS'] = 'on';
}