• If you are still using CentOS 7.9, it's time to convert to Alma 8 with the free centos2alma tool by Plesk or Plesk Migrator. Please let us know your experiences or concerns in this thread:
    CentOS2Alma discussion

Cookies are blocked on wp-admin Wordpress

faroe2k9

New Pleskian
Hello Plesk-experts

This is the scenario

  1. Add a new domain "name.com"
  2. Install Wordpress on this domain.

The domain DNS is pointing to another server (my other, old Plesk server), so I use the "Preview" function in Plesk to see the website, even though the domain is not pointing to this.

All is good.. until.. I enter the /wp-admin area, and then, after smashing the username and password down, I get the: "Error: Cookies are blocked or not supported by your browser. You must enable cookies to use WordPress."

I have tried almost every "solution" on the net. Edited the wp-config - the functions.php file, etc. Nothing is working. Tried Chrome, Firefox, even Internet Explorer !?..., tried to delete ALL caching/content on my browser, not helping..

Is the problem the domain name with a DNS to another server?

I have never had this kind of problem before with previous versions of Plesk.

Please guide me :)
 
I had same issue here, looking a lot in forum see many guys with same issue and no answer.

Somebody can help?
 
Hi,
Bug confirmed EXTWPTOOLK-8991.

The error appears because the site preview is opened via insecure http scheme and the website itself tries to set a cookies with "Secure" flag (see Using HTTP cookies - HTTP | MDN).

The access to WordPress admin dashboard thru site preview works properly when your WordPress is configured to use insecure http scheme (e.g. http://example.tld) and the SEO-safe redirect to httpS is disabled in hosting settings (also it should not exists in .htaccess file). If these conditions are true, then you should ensure that the "http" path part is used in site preview URL (e.g. /plesk-site-preview/domain.tld/http/X.X.X.X/wp-login.php)

I can provide two workarounds for you.

The first one is a simplest way to open your website: add a record into "hosts" file on your PC like "serverIpAddress your-domain.tld" and open website via this domain in browser.

The second is quite complex:
1. Disable SEO-safe redirect to httpS in hosting settings
2. Edit the wp-config.php, you should add two defines with URL pointing to http (without "S"), see Changing The Site URL.
3. Then open site preview again, if you see inside URL the "https" path part, then change it to "http" (e.g. /plesk-site-preview/domain.tld/http/X.X.X.X/wp-login.php)
4. Do not forget to rollback all changes when DNS records are switched to this server
 
Hi,
Bug confirmed EXTWPTOOLK-8991.

The error appears because the site preview is opened via insecure http scheme and the website itself tries to set a cookies with "Secure" flag (see Using HTTP cookies - HTTP | MDN).

The access to WordPress admin dashboard thru site preview works properly when your WordPress is configured to use insecure http scheme (e.g. http://example.tld) and the SEO-safe redirect to httpS is disabled in hosting settings (also it should not exists in .htaccess file). If these conditions are true, then you should ensure that the "http" path part is used in site preview URL (e.g. /plesk-site-preview/domain.tld/http/X.X.X.X/wp-login.php)

I can provide two workarounds for you.

The first one is a simplest way to open your website: add a record into "hosts" file on your PC like "serverIpAddress your-domain.tld" and open website via this domain in browser.

The second is quite complex:
1. Disable SEO-safe redirect to httpS in hosting settings
2. Edit the wp-config.php, you should add two defines with URL pointing to http (without "S"), see Changing The Site URL.
3. Then open site preview again, if you see inside URL the "https" path part, then change it to "http" (e.g. /plesk-site-preview/domain.tld/http/X.X.X.X/wp-login.php)
4. Do not forget to rollback all changes when DNS records are switched to this server
Hi, sorry for the newb question. Do you mean that http will become a permanent protocol?
 
I believe I have the same, if not similar issue. At least in regards to the Cookies part, but whether the cause is as you describe, I'm still a wee bit unsure and wonder if you can guide me please.
You'll see in the short clip when I'm logging into my wp admin, that it doesn't work. The user account and password definitely exists and works, as Server support showed me they can get in. However I can't get in. I've tried playing with cookies, but I just get that issue. It worked once, but when timed out I had to log back in again and then I had the same issue. I cleared Cache repeatedly in a few attempts, and deleted cookies. All I'm trying to do is build a new site to test and replace the main domain later, down at the Sub Domain.

I created a CNAME record on the DNS to point to the url new.registeryourappliance.uk as well, but still have the same issue.

Any ideas if the solution shown above, is the cause of this problem?

Cookies message on sub domain
 
I believe I have the same, if not similar issue. At least in regards to the Cookies part, but whether the cause is as you describe, I'm still a wee bit unsure and wonder if you can guide me please.
You'll see in the short clip when I'm logging into my wp admin, that it doesn't work. The user account and password definitely exists and works, as Server support showed me they can get in. However I can't get in. I've tried playing with cookies, but I just get that issue. It worked once, but when timed out I had to log back in again and then I had the same issue. I cleared Cache repeatedly in a few attempts, and deleted cookies. All I'm trying to do is build a new site to test and replace the main domain later, down at the Sub Domain.

I created a CNAME record on the DNS to point to the url new.registeryourappliance.uk as well, but still have the same issue.

Any ideas if the solution shown above, is the cause of this problem?

Cookies message on sub domain
Sorry for the delay. Unfortunately, the screen cast is not available anymore.

If you trying to make a copy of your production site, perform some changes on it and then replace the original site with modified one, then try to use "Clone" feature in WPT. It will create a copy of your site in subdomain, perform some replacements in WordPress database (e.g. replace the URLs of original site with cloned one) and as a result, you will get a fully working WordPress copy.
If you're not interested in making a copy of original site, then you can just install a fresh WordPress on any subdomain.

For both cases there is no need to use site preview, it still has some problems with cookies since the mentioned bug is not fixed yet
 
In my case, it was a problem with the nginx proxy. Probably the nginx proxy didn't pass well the cookies to the apache server.
To fix it, I just disable and re-enable the nginx proxy. I had this problem after transfer a whole Ubuntu server 18.04 (Plesk 18.0.52) to 22.04 (Plesk 18.0.53)

# /usr/local/psa/admin/sbin/nginxmng --disable
# /usr/local/psa/admin/sbin/nginxmng --status
Disabled

# /usr/local/psa/admin/sbin/nginxmng --enable

and restart the services, of course.

et voilà!

If you remain with the problem, check your apache/nginx header config. Or try only with the apache server ON, without Nginx.

I hope this will help you! :)
 
Back
Top