• If you are still using CentOS 7.9, it's time to convert to Alma 8 with the free centos2alma tool by Plesk or Plesk Migrator. Please let us know your experiences or concerns in this thread:
    CentOS2Alma discussion

Resolved disable_function= being overridden since enabled Performance Booster

GuiltySpark

New Pleskian
Server operating system version
Ubuntu 22.04.4
Plesk version and microupdate number
18.0.58 #2
I've recently switched on all available performance boosters in Plesk, namely:
  • Speed up web server static file
  • Speed up web server compression
  • Optimize PHP (enabled Jit)
My disable_functions setting in my php.ini is now being overwritten.

What I have in the php.ini (exec, shell_exec) is replaced with just one entry opcache_get_status.

Anyone help?
 
Have you tried putting disable_functions into the "additional PHP directives" field?
That's where I originally had them. But I couldn't switch on the booster "Optimize PHP settings" (JIT compiler) because that's were Plesk put's its directives, so had to move them into the php.ini.

Plesk then put the JIT compilation settings into the "additional PHP directives", this is what is says at the top:

; Additional directives added by Plesk Optimization Settings
; DO NOT MODIFY THIS FIELD BECAUSE IT WAS GENERATED AUTOMATICALLY
; SO ALL YOUR CHANGES WILL BE LOST THE NEXT TIME THE BLOCK IS GENERATED.
I tried putting the settings under this block, but like it says they were removed when the block was regenerated.
 
It should not be happening as one of the main requirements for developing this functionality was to respect any customization. The team will check how this can happen here soon.
 
It should not be happening as one of the main requirements for developing this functionality was to respect any customization. The team will check how this can happen here soon.
Ok thanks,

In the meantime I'll have to switch the PHP optimisation off and put disable_function back into "additional PHP directives"
 
Here is the result of the checks:

The behavior is logical, but this thread here helped us to realize that the "Show details" link in Performance Booster needs are more prominent placement or explanation. Solution:

1. Initially, the customer had the directives at Additional PHP Directives
2. We detected it and told the customer that we cannot apply our customizations as the field is already customized
  • a) Here, customer went in the direction of moving the custom directives to another place to be able to enable the checkbox in the performance booster
  • b) However, using the domain's php.ini file is not expected by us, we tell about it in the header of the file (ALL YOUR CHANGES WILL BE LOST THE NEXT TIME THE FILE IS GENERATED.)
3. What we was expecting the customer to do is to handle the PHP optimization on customers' own. The logic is that 'the filed is already customized, so most probably you know what you are doing. Check the details of our optimizations here and include it into your customization.

See the image attached. Customer should do the following things:
  1. Have his custom directives at Additional PHP Directives
  2. Click 'Show details' on the performance booster near PHP optimization
  3. Grab the directives from there and paste them into Additional PHP directives
All is transparent, nothing extra is done on the background when the checkbox is enabled in the performance booster, so copying the directives it will have the same effect as enabling the checkbox.

1709042918623.png
 
Thanks Peter,

I was going to do this originally but what stopped me was the statement that all changes would be lost with the optimisation on, so I assumed Plesk was varying the JIT parameters to perhaps tune performance.

From the explanation above, this is not the case.

I'll do what has been suggested, thank you so much for coming back to me.
 
Back
Top