Search results

OpenSSL 1.1.1h indicates that your PHP supports TLS 1.2 and even 1.3 (from OpenSSL 1.0.1 on, TLS 1.2 is supported) Most likely something else in your environments is responsible for the "downgrade" to TLS 1.0/1.1 of your SMTP connections. That can either be a firewall or the PHP script itself...

If I am not mistaken, this only depends on the PHP version (i.e. the OpenSSL version PHP was compiled against) and not Windows or Apache2. And for the standard PHP binary releases you can download from the official page (PHP For Windows: Home), everything from PHP 5.6 on should support TLS 1.2

Most likely the problem is that your Plesk/Postfix server is configured to run with TLS 1.2 (and newer), but your Windows/Apache/PHP server does support TLS 1.0/1.1 only So you will either need to change your Plesk/Postfix server to support these older TLS versions as well, or you need up...

Plesk is installed on the root ("/") partition As for expanding a disk/partion on Linux, there is no single answer... Most likely ionos.mx does have a control panel for your server and there you can increase this disk of your server. (your server will most likely only have a single disk) These...

Forget about workers and pools, as this is not your problem, unless you have set php-fpm to spawn only one worker (pm.max_children), but you don't have as I can see from the screenshot in #3 Moreover you would then not have the same issue when using FastCGI PHP in a webserver environment is in...

bump, I would like to know as well (as I just have a use case for that right now)

I assume the following works: 1) Open table "ServiceNodeConfiguration" of the "psa" MySQL database, search for the row with "frontendPort" as the name and change the value from "80" to "81" 2) Regenerate all webserver config files via the Plesk Repair Utility ("plesk repair web") 3) Restart...

Maybe there is a way to circumvent the (exec/shell_exec) function restriction of PHP and then using /usr/bin/crontab to create these files? There are/were several ways to bypass PHP's disable_function() as well, though I have no idea how many of them are still working with recent PHP versions.

uhhh, I don't wanna know, how many scripts and cms software no longer run properly, when ini_set is disabled :D Though maybe in combination with display_errors=off, it may not be that bad

If you don't need to allow your customers to use cronjobs at all, you can remove all permissions (chmod 000) on the /var/spool/cron/crontabs directory We use that ourselves on some specific servers, but it will force you to manually create/edit/manage/delete all required cronjobs in...

https://bugs.php.net/bug.php?id=76359 It's a feature, not a bug.