Search results

It might be a cosmetic bug, but I will need to consult with our team and get back to you. FWIW, the issue is not present on 18.0.74.1, but I assume that you are not ready to upgrade yet. I will follow-up with more details as soon as possible.

Thank you for reporting the issue, @Kaspar . I was able to replicate the behavior and forwarded the case to our developers. I will follow-up with more details as soon as possible.

@Hangover2 is absolutely right, manual OS upgrades haven't been tested by our team yet and therefore are not officially supported. Currently, the recommended path is to migrate to a fresh Debian 13 server. Regarding the experienced issue, I believe the same could be related to the fact that...

The issue was registered as a bug with ID PPP-70078 and it will be fixed in the upcoming Plesk release (18.0.75).

Hello, @Daveo . Have you already tried the repair utility? If not, could you please try: plesk repair web -y

Thank you for the provided details. There is an open case with Imunify regarding the notifications related to outdated WordPress versions/plugin versions and they are currently working on improving the flexibility of notification management. I asked them to check the relation of the...

Hello, @brother4 . Could you please confirm if by excluded you mean the directory has been added into the Imunify's Ignore list? Also, could you please provide an example of the notification(s) you receive for the disabled domain? Thank you in advance.

@jescayola . do you happen to have HTTP/3 support enabled for the domain name in question? If yes, could you please try disabling it for the sake of testing?

The issue was registered as a bug with ID PPP-70078 and it will be fixed in upcoming Plesk release (18.0.75).

You are probably right. Can you please try reproducing the empty error and monitor what's logged into /var/log/plesk/panel.log at that time?

Thank you for the clarification. I misunderstood that the cron remains rather than the system user. I was able to replicate the behavior now. I will double-check with our team and follow-up with more details.

So far, our developers haven't identified any real impact resulting from the thrown error - MariaDB appears to be operating properly. Still, at this point, I cannot guarantee unexpected issues won't arise. I will follow-up with more details as soon as possible. Thank you for your patience in the...

Thank you for the update and clarification. My point is, that if you do not interact with the scheduled tasks while the subscription is in suspended state, the issue should not occur. Nevertheless, this is just a workaround suggestion until our team introduce an official fix for the issues. They...

If your end goal is to have different system users for the production and staging environments, then, yes, Web Pro Edition is probably your best option as the entry point including subscription management. The other option is to review the command and, if possible, to adjust it so it could be...

Hi, @carlsson . If you have already tried the suggestion of @Bitpalast for settings the threshold to 30% and that did not work, please try setting them to an even higher value, for example 50%.

Hello, @Matt N . This issue is currently under investigation from our team. As far as I understand it is suspected as a MariaDB upstream issue, but I will be able to provide further clarification later on.

I am glad to hear you were able to sort out it out. According to our developers the issue likely occurred because the Laravel toolkit database was locked in the moment the domain was renamed. Unfortunately, since this is conditional event and it cannot be reproduced it is difficult for our team...

Hi, @bigbear67 . Thank you for the report. It is already forwarded to our team for further review. Please refer to the following thread for further updates: Issue - Plesk 18.0.74 too short log page (only 5 lines)

@superfun2k23 , can you please run the following command and confirm if it returns any errors/warnings: named-checkconf

Hello, @RegioOnline . Thank you for the report. Unfortunately, I was unable to replicate the behavior. I tried cloning the website under a subdomain associated with the same domain and with a different one (under the same subscription). In both cases, the cron task remained unaltered. I would...