When modifying php.ini directly, Zend Server will prompt the user in the Admin UI to match the modified ini to the backend "blueprint". The options are:
"Revert", which will rewrite the ini according to the saved blueprint, when you made a mistake or simply needed to edit the ini for a temporary fix (Single server or Single node on a cluster).
"Apply", which will apply the changes back to the blueprint when they are needed for the long run.
When manually adding sections to php.ini, Zend Server will remove the sections, keeping their content directives only.
See this example, which is a special use case of setting different PHP directives per [HOST=] or [PATH=], normally allowed in php.ini.
[PATH="C:\Program Files (x86)\Zend\Apache2\htdocs\myapp"]
auto_prepend_file="C:\Program Files (x86)\Zend\Apache2\htdocs\myapp\prepend.php"
Other sections in php.ini can be added, but will eventually be removed by Zend Server ini modifier. Unless those sections are parsed by a 3rd party tool, removing them by Zend Server has no effect on PHP runtime, and the directives in them will be parsed and active.
The problem with [PATH=] and [HOST=] sections is, that it is mainly used to make different scripts, or hosts, to load different values for the same directives.
For example, error reporting on [HOST=dev.local] will be maximum, while on [HOST=production.domain] will be very slim, and most errors will be evident only in the logs and on Zend Server Monitoring Events.
Thus - When Zend Server removes the sections, you are left with multiple lines of the same directives, so only first one will be parsed and the others filled with the same value - probably not what you wanted to do with [PATH=] and [HOST=] sections, however it does the job and PHP does not break or act strangely.
Due to the limitation of Zend Server ini modifier, removing the php.ini sections, there can be a few solutions.
1. add “.user.ini” with PHP directive(s) for the website where you place the special ini file (in the root folder). This might not work in all environments, experiment to verify.
2. add PHP directives to .htaccess under Apache, vhost configuration, or Apache conf for specific locations (going from light to heavy, where .htaccess is the most light option which can be used if Apache allow override is enabled).
3. add PHP configuration conditional to the HOST/PATH in the application config itself (or the PHP framework configuration)