Include a docker-php-ext-disable

I saw that there is no disable script here - ideally, it'd be great to replicate both php5enmod and php5dismod functionality.

I created a disable script based on docker-php-ext-enable and am copying it in my build. The script just looks for the existence of the extension ini file and removes it - but not sure if there is a more ideal way to handle this? Willing to PR it, if there's any interest.

The use case for me was to be able to enable or disable xdebug on the fly when running PHPUnit:

docker exec -ti php sh -c "docker-php-ext-disable xdebug && vendor/bin/phpunit

@kmfk

@kmfk why not add your script as pull request?

I'm honestly a little -1 on adding this. Enabling an extension in a generic way is simple (requires getting extension=xxx.so into the PHP configuration somewhere). Disabling in a fully generic way is not nearly as simple, so I would actually recommend using --ini-name (from #178) to accomplish this more easily.

Yes, furthermore there's no good reason to disable an extension in fact. If you use the same container for tests/dev & production (which is pretty cool), you can imagine running php differently depending on your environment.

It's easier for example to run php php -d 'extension=xdebug.so' myscript.php when developing your app then running just php myscript.php in production.

+1 It is useful if you create your own images for dev/prod. If dev extends the production image, it's great to disable something from production, i.e.

# in dev Dockerfile
FROM my-production-image
RUN docker-php-ext-disable opcache

@kodeart

@kodeart yes... but why not producing a dedicated image for dev and another one for prod? Very easy with automated builds & tags.

@kmfk

@kmfk @tianon I've opened a pull request which introduces docker-php-ext-disable in #270

Given that #178 added --ini-name for explicitly controlling the exact filename docker-php-ext-enable creates (and that the filenames it uses are already trivially deterministic), I'm going to close this with the recommendation that users who need to disable extensions after previously enabling them simply use rm on the appropriate file (or sed, if they've added additional configuration to the file since enabling the extension). Thanks!

Something of note where people may want to specifically disabled xdebug you can set the environment variable XDEBUG_MODE=off and that will turn off xdebug on-the-fly. This was my primary purposed for investigating a docker-php-ext-disable method.

Thanks for sharing this!

Something of note where people may want to specifically disabled xdebug you can set the environment variable XDEBUG_MODE=off and that will turn off xdebug on-the-fly. This was my primary purposed for investigating a docker-php-ext-disable method.

Or xdebug.mode=off
Reference

@tianon

Just to chime in here on an old comment... @tianon

I'm looking for a way to enable / disable an extension after it was already configured / installed etc. It's common to enable/disable xdebug quickly for an image and we currently handle this by utilizing docker-php-ext-enable xdebug vs rm "/usr/local/etc/php/conf.d/docker-php-ext-xdebug.ini"; but this feels clunky having to download the APK everytime. I'd like to keep the actual module after installation but add / delete the .ini only. That would allow far easier on/offline working and keep the xdebug (enabled / disabled) features.

I know i'm almost there, but having the docker-php-ext-enable xdebug conditionally check if the .SO is already there before downloading would suffice for my usecase. Any chance this might be something you'd consider?

I think instead of using docker-php-ext-enable for the "toggling" use case, you might instead rename the file with a .disabled suffix (ie, rename back and forth instead of deleting and recreating).

Navigation Menu

Repository navigation

Include a docker-php-ext-disable #220

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Include a docker-php-ext-disable #220

Description

Activity

isp0000 commented on May 2, 2016

tianon commented on May 2, 2016

shouze commented on May 25, 2016

kodeart commented on Jun 8, 2016

shouze commented on Jun 8, 2016

pproenca commented on Jul 22, 2016

tianon commented on Dec 22, 2017

timnolte commented on Sep 17, 2023

LaurentGoderre commented on Sep 18, 2023

jonpontet commented on Dec 18, 2023

fruitl00p commented on Oct 1, 2024

tianon commented on Oct 1, 2024

cha0s commented on Oct 20, 2025

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions