Search results

At this point, the reason for the issue is still unclear. I will follow up with more details.

Hello, @EnriqueR . Unfortunately, there's no way to exclude a particular domain/email address. Does the ISP of the user at least use the same IP range? If yes, what you might do is whitelist the whole range. Although not ideal as imposes risks, it could be a potential workaround. What else you...

Hello, @maximus99 . Does that pop-up appear right upon accessing the page "SSL/TLS Certificates" tool for the domain name or after performing a specific action?

Thank you for the update. If you can also check for the stuck process as well, please. Also could you please confirm: Judging by the logs it looks like the issue persists for two domain names. Are they both under the same subscription? If yes, for the sake of testing, could you please...

On the source server, you can enable remote connections following the instructions here. If the destination server is also Plesk-powered, you can configure the remote server by going to Tools & Settings > Database Servers > Add database server.

The error suggest an issue with the https://ppa.launchpadcontent.net/ondrej/php/ubunturepository. Have you tried disabling it already? If not, I would suggest giving it a try by moving it to the /root folder.

Thank you for your update. Our team is currently reviewing the issue. I will follow up with more details.

Thank you for your update. Our team is currently reviewing the issue. I will follow up with more details.

Hello, @Genisys-Matt . Are you experiencing any issue with log rotation in general? If yes, it could be corruption of the /usr/local/psa/var/logrotate.status, this might be sorted following the instructions here. If not, maybe a stuck daily maintenance task:

With debug mode enabled, the extension causing the issue should be present in the error. Could you please give it a try and confirm if there are additional details in the error? If yes, please re-install the extension following the instructions from this guide.

Thank you for the update. It might have been temporary connectivity issue. Nevertheless, please keep us posted if the issue re-occurs again. I will also follow up if we detect any issues on our end.

The index file should be under httpdocs (unless otherwise specified). Under the git folder should contain the repository data.

Hello, @ivanes82 . Could you please try closing the sessions in Tools Settings > Active Plesk sessions. Also, please also try resetting the Session idle time in Tools & Settings > Session Idle Time to default.

Hello, @moswak . If I understand correctly the issue you are experiencing is not during a WordPress installation, therefore, it is not the same as reported in this thread - if true, please open a new thread and provide more details. If I am wrong, please try the workaround pointed out by Kaspar...

Please double-check if the index.html file is indeed present in the document root of the domain name in question. If yes, please rename the file to something like index.html_old. If that doesn't sort it, please navigate to Domains > example.com > Apache & Nginx Settings. Under "Index files"...

We registered a case identified with ID PPPM-14945 to update the ionCube version shipped with PHP 7.4. At this point, I cannot provide any ETA on when the change will be introduced. You can monitor the change log here. Thank you for bringing our attention to the issue.

Hello, @Ras Alghul . This issue could occur due to websites being compromised. Could you please run a scan on the website(s) in question? Additionally, please do check the WordPress core.

We released an update today which fixes the issue with the “Mail Accounts” page. If you have automatic updates enabled (or already run Plesk Obsidian 18.0.69 Update 3) this update should be installed automatically overnight. Plesk Obsidian 18.0.69 Update 3 :

Hello, @zvangi . Could you please try disabling the repository in question. I believe it should be defined in the /etc/apt/sources.list.d/ubuntu.sources file? If not, please try running:

Yes, that's our mistake. Thanks for pointing it out, Kaspar. It is fixed now.