Everything

php

Environment Variable based PHP Extension loading

php.internals

Soner Sayakci

354 days ago

Hey,

I would like to load PHP extensions by environment variables in a
containerized environment. All existing solutions are moving files in an
entrypoint and this does not work for read-only containers. Why this?
Extensions like Blackfire/XDebug/OpenTelemetry/Tideways do not like each to
run at the same time, and having to build less containers simplifies a lot.

It's already possible to use environment variables in the php.ini like so:

extension=${PHP_PROFILER}

So it's possible to toggle the extensions already, the only thing that is
not working is passing an empty string (I don't want any profiler). Then we
get warnings like: Warning: PHP Startup: Unable to load dynamic library '"

Therefore I opened a pull request to ignore extension entries with empty
strings, so this works with that case too. Looking for feedback in the pull
request https://github.com/php/php-src/pull/19816

Thanks!

hakre

353 days ago

On Friday 12 September 2025 22:13:04 (+02:00), Soner Sayakci wrote:

> Hey,
>
> I would like to load PHP extensions by environment variables in a
> containerized environment. All existing solutions are moving files in an
> entrypoint and this does not work for read-only containers. Why this?
> Extensions like Blackfire/XDebug/OpenTelemetry/Tideways do not like each

to

> run at the same time, and having to build less containers simplifies a

lot.

>
> It's already possible to use environment variables in the php.ini like

so:

>
> extension=${PHP_PROFILER}
>
> So it's possible to toggle the extensions already, the only thing that

is

> not working is passing an empty string (I don't want any profiler). Then

we

> get warnings like: Warning: PHP Startup: Unable to load dynamic library

'"

A warning is only a warning. You likely want to see it if the parameter is
empty as it is *likely* unexpected.

>
> Therefore I opened a pull request to ignore extension entries with empty
> strings, so this works with that case too. Looking for feedback in the

pull

> request https://github.com/php/php-src/pull/19816

Commented there with the long version + a small nitpick as your report is
wrong for the directive and the extensions you reference above: Those are
all Zend extensions, not just ordinariy extensions. However: If you provie
a non-zero-length-string for an extension you get a much more enhanced
diagnostic message about which files have tried. In your empty string case,
not more files have been tried. So please feel free to add more rationale
what kind of issue is causing you the warning.

Otherwise I'm not really booked on the fact that providing an empty
directive value per an ini file can astute a non-warning on any directive
that configures the PHP runtime.

Especially as you give the use-case of a build procedure here, double check
you're not trying to solve a problem in your build procedure by
(needlessly) suppressing PHP binary diagnostics --- you should be able to
suppress on your end given the SUCCESS exit code.

What do you think=

-- hakre

Ilija Tovilo

353 days ago

Hi Hans

On Fri, Sep 12, 2025 at 11:21 PM Hans Krentel <hanskrentel@yahoo.de> wrote:

>
> On Friday 12 September 2025 22:13:04 (+02:00), Soner Sayakci wrote:
>
>  > It's already possible to use environment variables in the php.ini like
> so:
>  >
>  > extension=${PHP_PROFILER}
>  >
>  > So it's possible to toggle the extensions already, the only thing that
> is
>  > not working is passing an empty string (I don't want any profiler). Then
> we
>  > get warnings like: Warning: PHP Startup: Unable to load dynamic library
> '"
>
> A warning is only a warning. You likely want to see it if the parameter is
> empty as it is *likely* unexpected.

An alternative might be to use a different sentinel for "ignore this
directive" might be "-". This way accidentally empty environment
variables keep warning, while intentionally set ones can skip the
directive. This works with the fallback syntax ${PHP_PROFILER:--}.

>  > Therefore I opened a pull request to ignore extension entries with empty
>  > strings, so this works with that case too. Looking for feedback in the
> pull
>  > request https://github.com/php/php-src/pull/19816
>
> Commented there with the long version + a small nitpick as your report is
> wrong for the directive and the extensions you reference above: Those are
> all Zend extensions, not just ordinariy extensions. However: If you provie
> a non-zero-length-string for an extension you get a much more enhanced
> diagnostic message about which files have tried. In your empty string case,
> not more files have been tried. So please feel free to add more rationale
> what kind of issue is causing you the warning.

I don't understand this paragraph.

Ilija

Derick Rethans

353 days ago

On 12 September 2025 21:13:04 BST, Soner Sayakci <s.sayakci@gmail.com> wrote:

>Hey,
>
>I would like to load PHP extensions by environment variables in a
>containerized environment. All existing solutions are moving files in an
>entrypoint and this does not work for read-only containers. Why this?
>Extensions like Blackfire/XDebug/OpenTelemetry/Tideways do not like each to
>run at the same time, and having to build less containers simplifies a lot.

I'm not aware of any incompatibilities between Xdebug and any of these. If you know of any, please file a bug report at bugs.xdebug.org.

If it is, you can set the XDEBUG_MODE environment variable to off, and then it doesn't set any hooks that could interfere.

cheers
Derick