Only the site owner can manage shipping label payment methods. Please contact lkswlzmy (lkswlzmy) to manage payment methods.

The site is hosted at bluehost. They say I have to get support from WC since I’m the owner, so I’m stuck.

The ownership of the portal https://prodalet.ru has been changed. How can the new owner take over this plugin as well? The original author doesn’t respond

In my initial setup of wordpress, I first change the set the Nginx user (www-data) recursively (and insecurely) as the owner of the WordPress root directory by using the following command:

sudo chown www-data:www-data /var/www/example.com/ -R

This effectively gives the nginx user ownership of all of my wordpress files and folders.

Next, (as recommended by the “hardening-wordpress” guide) I change the permissions of all folders to 755, and all files to 644.

find /var/www/example.com/ -type d -exec chmod 755 {} \;
find /var/www/example.com -type f -exec chmod 644 {} \;

In the wordpress “Changing File Permissions” article, it says that secured permissions for the wp-config.php file are 600. However, in the “hardening-wordpress” guide, it says that secured permissions for wp-config.php files are 400 or 440 (i.e. it generally means a 400 or 440 permission). Which is it and does it depend on who owns wp-config.php and who owns the rest of the wordpress files?

It doesn’t say if files ownership for wp-config should be www-data:www-data, root:root, root:www-data, or www-data:root. The hardining guide and change file permissions guide have now mention of proper ownership for the wp files, and the wp-config.php/.htaccess. They only discuss permissions, not ownership.

This leaves things confusing. To experiment with my specific configuration (everything owned by www-data:www-data so far), I have tried the following to secure my important wordpress file such as wp-config.php:

EX:1

sudo chown root:root wp-config.php
sudo chmod 400 wp-config.php

This breaks my wordpress installation and give me a blank white screen when I navigate to my homepage.

EX:2

sudo chown root:root wp-config.php
sudo chmod 444 wp-config.php

This successfully allows me to see my wordpress homepage, and seems to work.

EX:3

sudo chown root:root wp-config.php
sudo chmod 404 wp-config.php

This also successfully allows my wordpress installation to work and I can get to the homepage just fine. However, It also indicates that in order for wordpress to work, it needs the wp-config.php file to allow world readable permissions. WHY IN THE WORLD IS THAT? Isn’t that insecure? Shouldn’t www-data be the only user that should be able to read this file?

To prove this theory of world readable permissions required I proceeded to example 4.

EX:4

sudo chown root:root wp-config.php
sudo chmod 004 wp-config.php

These permissions with root ownership still allow my wordpress installation to work, even though the group root can’t read/write/execute, and the user root can’t read/write/execute.

Next, I tried something different to understand how group permissions are used.

EX:5

sudo chown root:www-data wp-config.php
sudo chmod 040 wp-config.php

Again, with the group being owned by www-data, and giving www-data read permissions only, this allowed my wordpress installation to work as well. My homepage works just fine with this configuration. This seems like it might be the winner for the most secure permissions/ownership configuration. But I’m not sure I fully understand what the “Group” access allows with these permissions. Can the group www-data override the user root in this configuration by any means? Can wordpress, or my root user write to this file? If not (which I assume is what the permissions dictate), then why can I edit this file with nano using my root account on linux? For example, If a file has ---------- (no permissions whatsoever) permissions on it, then why can my root user use the nano editor to access and write to this file? Shouldn’t ---------- permissions lock the file into the operating system permanently and render it immutable because nobody is allow to access or change it? I’m not sure I fully understand or grasp how the root account can override permissions for files that have limited permissions, and I’m not sure the repercussions of giving wp-config.php group access to www-data, and user access to root.

Could someone please explain to me how all of this works, by answering some of these questions, and the with all things considered with my setup (LEMP SERVER), could you please recommend what user ownership/ group ownership/ permissions, I should be using on my wp-config.php, .htaccess, and then the rest of my wordpress installation, for my setup to be as restricted and secure as possible without impacting the usability of the wordpress installation itself?

Any help is much appreciated. Thanks for any explanations, examples, and gained understanding.

Most absurd is one can see from my avatar and username here that it is my account!

I am reaching out to you because I need help removing the ownership token HTML code from my website. I have tried searching my website’s theme files, including header.php and footer.php, but I cannot locate the leftover code. I believe it may have been added by the Google Site Kit plugin, but I am not sure where to find it.

Could you please provide me with some guidance on where to locate and remove the ownership token HTML code? I have already removed one person’s ownership from my Google Search Console account, but the code is still present on my website (I saw it thought the Inspect option).

Thank you for your help in advance. I look forward to hearing back from you soon.

Best regards,

Ana.

"There is a pending change of your email to [email protected]"

No email ever comes to me. How can I fix this? It looks like the email [email protected] is the final authority of my website, not me.

The ownership model is good for new customers, but not for returning one. In other word, I install this plugin after we had customers, and most of us do. It doesn’t make sense to them that they cannot purchase product A anymore unless purchase B. For example B is a Sign-up fee.

We have spent the last few weeks reading through many of your honest thoughts and reviews, and now have a better understanding of your frustrations at the change in ownership and the effect it’s had on your managed sites.

Before we dive into the specifics, we would like to note that the current banner (v3.0) is and will remain free to use indefinitely. The plugin contains all of the pre-existing features found in v2.4 in addition to enhancements such as domain scanning, automated categorization of cookies, and prior script blocking.

With that in mind, we would like to address the major frustrations seen across the forum:

1. Version 2.4 Consent Banner
The version from the previous developers (v2.4) that many of you had installed, was deprecated and no longer being supported by the time Termly assumed ownership. What this means, is that despite the banner existing on your websites, legally it is invalid for protecting you and your visitors.

It was and continues to no longer be compliant under GDPR (EU), ePrivacy Directive (EU), CCPA (California), and broader data regulations around the world which can be updated multiple times per year.

2. Page View Limitations
We hear your frustrations about the 100 visitor limit that we had originally imposed on our free plan and recognize that we should have revised our free tier before updating the plugin. To address this, we have increased the limit of consent banner views on our free tier to better reflect your needs.

3. Subscription Costs
For each visitor that interacts with your banner, their consent records must be tracked, stored, and updated on our servers so that you stay compliant with global data regulations. This means that every banner costs us some amount to maintain. We believe that the value of a managed product is the peace of mind knowing that we are constantly working to uphold the protection of your site.

That said, our free version is always available and with no limits to how long you may stay on it. Our intention is to protect all our customers regardless if they’ve paid for additional functionalities.

Looking ahead
Should you prefer to stay on the previous version (2.4), we understand and refer you to [this post] that describes the rollback process. However, we do advise against this, as indicated earlier the v2.4 consent banner does not meet the requirements for a business to comply with GDPR and other legislation.

We hope you’ll give Termly a try as we continue to develop a robust platform for peace of mind when it comes to legal compliance. We are committed to global data privacy and have hired some of the best in-house experts to keep your consent banners, legal policies, and feature sets updated to the latest regulations around the world.

Should you have additional questions or concerns about the product or us, we invite you to check out our FAQ and chat with our team at [email protected]. We will continue to monitor the situation in these support threads as well.

Thank you,
Termly