> register_ini_entries(), which is the service function that modules use to
> register their entries, doesn't use alter_ini_entry(). It checks the
> configuration hash (=php.ini) for a default value. If it exists, it uses
> it as the default value (it doesn't use alter_ini_entry()), if it doesn't -
> it uses the built-in default.
Ok, that explains why it does not work properly for
dynamically loaded extensions. If a custom ini entry is
placed after the extension=foo.so line, register_ini_entries
has no chance to see the custom ini entry and hence uses the
default entry.
We could remove that limitation by deferring the load of
extensions (and hence the execution of register_ini_entries)
in php_config_ini_parser_cb() until all ini entries were
properly added to the configuration hash. What do you think?
- Sascha
--
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
