Search results

I get where you're coming from, and you make a good point about the visibility of the protection and vulnerability statuses in the WordPress Toolkit. I’ve taken your suggestion and posted it on the Plesk forum as a feature request. I’m asking them to separate the links for the Vulnerability and...

Recently, Plesk added a vulnerability status feature to the WordPress Toolkit, which is a great step forward. However, both the vulnerability status and the protection status are currently accessed through the same link, making it harder to quickly find the protection details. It would benefit...

I understand your concerns regarding WordPress security—it's an inevitable part of running one of the most widely used CMS platforms, which makes it a popular target for attacks. Plesk has integrated several security measures through the WordPress Toolkit that help mitigate many vulnerabilities...

Hi, Please refer to the official Plesk Support articles for managing Plesk: https://support.plesk.com/hc/en-us/articles/12388091703703-How-to-upgrade-MySQL-5-5-to-5-6-5-7-or-MariaDB-5-5-to-10-x-on-Linux Regarding the output of the # journalctl -xe -u mariadb command, it seems you're not...

You don't need to create a Fail2ban rule to block xmlrpc.php attackers. The xmlrpc.php protection is already included in the WP Toolkit: https://docs.plesk.com/en-US/obsidian/reseller-guide/website-management/wordpress-toolkit.73391/#securing-wordpress To enable this protection, follow these...

Many Plesk users are still running outdated operating systems and unsupported versions of MySQL/MariaDB. This often leads to issues such as non-functional repositories, failed updates, or even database errors. Plesk only supports LTS versions of MySQL/MariaDB, but this isn’t always immediately...

AWStats uses the access logs based on the retention period set in Tools & Settings → Server Statistics Settings → "Retain web and traffic statistics for." If this setting doesn't resolve the issue, you can try recalculating the statistics as explained in this article...

WordPress is known to generate false positives with ModSecurity. If it happens again, click on "Error Log File" on the same page and search for ID's. They look like this: [id "210492"]. Add that number in the "Security rule IDs" field and ModSecurity will ignore it.

Have you tried using Plesk Repair? If that doesn't work, please contact Plesk Support so they can investigate the issue directly on the server. To sign in to support please go to https://support.plesk.com If you bought your license from a reseller, your reseller should provide support for you...

That's where Plesk should have added the extra configuration, but it couldn't because of your openbase_dir settings. I didn't know that either so we both learned something today ;)

Please don't allow root login on your server. That's a huge security risk. Instead, add another user on the command line and add the user to the sudoers: # adduser peter # passwd peter # usermod -aG wheel peter Now, log on using the new user and switch to root: $ ssh peter@myserver...

As I understand from the first screenshot, you have to reset the open_basedir values for those domains to make this work:

You seem to have logged in as a user, not as an administrator. Is this your server?

I still miss the "Disk space" graph on the new dashboard. Hopefully, that gets added in the future.

You don't have to, as soon as we see that someone replies with "It works", we mark it as resolved :)

Only the Guru's and the forum moderators can change the status of the posts to resolved.

It looks like there's an issue with a corrupted or missing package (alt-python311-setuptools-wheel). You can try the following steps to fix it: First, try to remove the package: $ sudo dpkg --remove --force-remove-reinstreq alt-python311-setuptools-wheel After removing it, update your package...

Have you checked with your provider if root login is enabled? It's usually disabled for security reasons. If that's the case, you can try logging in with another user and use sudo for administrative tasks.

The IP address of your server is probably blocked by iCloud etc. You can check the IP address using these: https://mxtoolbox.com/blacklists.aspx https://whatismyipaddress.com/blacklist-check

Have you seen this guide? https://talk.plesk.com/resources/how-to-run-magento-2-on-plesk-obsidian-18-without-docker.59/