• Plesk Uservoice will be deprecated by October. Moving forward, all product feature requests and improvement suggestions will be managed through our new platform Plesk Productboard.
    To continue sharing your ideas and feedback, please visit features.plesk.com

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! :)
 
Please also see this post:


Hi, I have tried many methods in these threads and other articles to achieve access to a website on my server that has no DNS access as yet as the DNS is still pointing to the "old" server.
PLESK Server
Version: Plesk Obsidian v18.0.71_build1800250729.09 os_RedHat el9
Operating System: AlmaLinux 9.6 (Sage Margay)

Could not get the plesk-site-preview to work as wanted and could not install SSL as Let's Encrypt needs to access the DNS to add a key and this is not active

for the website preview

and

for the wp-admin login

Where xxx.xxx.xxx.xxx is the IP address of the VPS server and DOMAINNAME.org.je is the original domain name of the site that has been copied to the new server

Instead using the local host file and adding the "#" in before the host change to revisit the "old" server still associated with the DNS was the only way forward to server the site correctly. This way I was able to backup the old site and then restore the files to the new site by removing the "#" again

The simple entry therefore to the local ghost file in the case below is for a Windows device

HOST FILE START >>>>
# Copyright (c) 1993-2009 Microsoft Corp.
#
# This is a sample HOSTS file used by Microsoft TCP/IP for Windows.
#
# This file contains the mappings of IP addresses to host names. Each
# entry should be kept on an individual line. The IP address should
# be placed in the first column followed by the corresponding host name.
# The IP address and the host name should be separated by at least one
# space.
#
# Additionally, comments (such as these) may be inserted on individual
# lines or following the machine name denoted by a '#' symbol.
#
# For example:
#
# 102.54.94.97 rhino.acme.com # source server
# 38.25.63.10 x.acme.com # x client host

# localhost name resolution is handled within DNS itself.
# 127.0.0.1 localhost
# ::1 localhost



xxx.xxx.xxx.xxx DOMAINNAME.org.je

# Where xxx.xxx.xxx.xxx is the IP address of the VPS server and DOMAINNAME.org.je is the original domain name of the site that has been copied to the new server
HOST FILE ENDS >>>>

Then simply add the "#" when not wanted and save the item as below:

# xxx.xxx.xxx.xxx DOMAINNAME.org.je

(more help here:
How to Edit Your Hosts File on Windows, Mac, or Linux )

Peter
 
Please also see this post:


Hi, I have tried many methods in these threads and other articles to achieve access to a website on my server that has no DNS access as yet as the DNS is still pointing to the "old" server.
PLESK Server
Version: Plesk Obsidian v18.0.71_build1800250729.09 os_RedHat el9
Operating System: AlmaLinux 9.6 (Sage Margay)

Could not get the plesk-site-preview to work as wanted and could not install SSL as Let's Encrypt needs to access the DNS to add a key and this is not active

for the website preview

and

for the wp-admin login

Where xxx.xxx.xxx.xxx is the IP address of the VPS server and DOMAINNAME.org.je is the original domain name of the site that has been copied to the new server

Instead using the local host file and adding the "#" in before the host change to revisit the "old" server still associated with the DNS was the only way forward to server the site correctly. This way I was able to backup the old site and then restore the files to the new site by removing the "#" again

The simple entry therefore to the local ghost file in the case below is for a Windows device

HOST FILE START >>>>
# Copyright (c) 1993-2009 Microsoft Corp.
#
# This is a sample HOSTS file used by Microsoft TCP/IP for Windows.
#
# This file contains the mappings of IP addresses to host names. Each
# entry should be kept on an individual line. The IP address should
# be placed in the first column followed by the corresponding host name.
# The IP address and the host name should be separated by at least one
# space.
#
# Additionally, comments (such as these) may be inserted on individual
# lines or following the machine name denoted by a '#' symbol.
#
# For example:
#
# 102.54.94.97 rhino.acme.com # source server
# 38.25.63.10 x.acme.com # x client host

# localhost name resolution is handled within DNS itself.
# 127.0.0.1 localhost
# ::1 localhost



xxx.xxx.xxx.xxx DOMAINNAME.org.je

# Where xxx.xxx.xxx.xxx is the IP address of the VPS server and DOMAINNAME.org.je is the original domain name of the site that has been copied to the new server
HOST FILE ENDS >>>>

Then simply add the "#" when not wanted and save the item as below:

# xxx.xxx.xxx.xxx DOMAINNAME.org.je

(more help here:
How to Edit Your Hosts File on Windows, Mac, or Linux )

Peter

Correction to above:

When the hosts file is unhashed so it is using the entry in the hosts file, you only need to use this url to access the website on the New VPS server (the one without any active DNS to the domain)


and this will allows the saving of cookies as needed for PLESK WP-Admin access

you may well get the warning as below that depending on your security settings can be bypassed by choosing advanced

1757870483897.png
1757870529947.png
 

Attachments

  • 1757870397658.png
    1757870397658.png
    17 KB · Views: 0
Back
Top