Search results

Hello, @sialeh. Could you please confirm the full path to the document root of the website in question, e.g. /var/www/vhosts/example.com/httpdocs? Also, can you double-check if there are any mod_rewrite rules? If there's an .htaccess file, please try temporarily renaming it (e.g. .htaccess.bk)...

Hello, Yiorgos. Could you please confirm the version of Site Import? There was a bug that resulted in a similar error, which was fixed in Site Import 1.8.4.

Hello, @naimisar. What you can try is increasing the execution time by navigating to the %plesk_dir%Additional\Scheduler folder and opening fetch_url.ps1. Add webRequest.timeout variable with value of 60000 in the Try block to the script: I hope that helps.

Hello, Luis. Could you please check the logs in /var/log/plesk/install/autoinstaller3.log and provide the entries logged when you attempt to perform the update? Thank you in advance and Happy Holidays.

Hello, @Lordi. Sincere condolences. It looks like a service has not been registered for this PHP version yet. In order to manually create a service for the PHP handler the *.service file from the downloaded source needs to be copied to the local configuration.

Thank you for the report, @The 8th. Our team reviewed the case and they were able to reproduce the error on a test environment with Google PageSpeed insights extension and installing page-speed module from there: Please try applying the workaround from the article linked by @Pavel Zaikin .

I am unable to find any similar cases and unfortunately, not quite sure what is causing the issue. If you have the option, please open a support ticket so our team could log into the server and check what might be triggering the error.

Can you please try enabling debugging in Dovecot and double-check the logs again when the fetching stalls?

Thank you for the update. I am not quite sure what triggered that behavior on your server, but removing a domain name and re-adding it as an alias had no impact on the main domain name during test performed on our end. I would suggest opening a ticket with Plesk support for an investigation of...

Could you please check the logs at /var/log/maillog and confirm if there are entries that indicate fetching failure?

As far as I am aware, the error you are reporting could be caused due to a different value specified in the email client configuration than the server name in the "SSL/TLS certificate" at Tools & Settings > SSL/TLS Certificates > Certificate for securing mail. There might be some issue with the...

Thanks for the confirmation. We were unable to reproduce the described behavior. Adding the domain name as an alias has no impact on the mail service or the SSL certificate for the main domain name. Thus, that does not qualify as a Plesk bug. Likely something else was changed on the server...

That error is code related. It will be best for the website developer to review and address it.

Hello, Vincent. There's a pretty comprehensive guide on migration you could find here. If you have any specific questions, please do let us know.

Thank you for your report. Just to make sure we are on the same page: 1. Have a domain example.com configured on the server with a valid SSL certificate installed on it. 2. Remove domain example.com from the server. 3. Add the domain example.com as an alias to exampleMAIN.com while disabling...

It doesn't really matter which one you will remove as long as there are no duplicates. Maybe the one from the second line to keep it tidy since you have the rest of the debug values defined in lines 65-67.

Thank you for the report, @Azurel. This is a known issue identified with bug ID PPP-45208. Unfortunately, at this point, I cannot provide any ETA on when a fix will be introduced. You may observer our change log here. Thank you in advance for your patience and understanding in the meantime.

AlmaLinux 8 > AlmaLinux 9 dist-upgrade support has not been introduced yet. Unfortunately, I cannot provide any ETA on when a script will be released yet. At this point, you can consider a migration to a fresh AlmaLinux 9 server.

Could you please try ticking the “Upload backup files without a valid signature” checkbox while uploading the backup file? Alternatively, you can try recreating the original reseller user on the new server and attempting the restoration while logged with it.

Hello, @jeffjefferson. Could you please check the Plesk log in /var/log/plesk/panel.log and confirm if you see any errors/entries related to composer.lock?