Fix #1157: Load PHP extensions from .bp-config/php/php.ini.d during composer#1216
Open
Fix #1157: Load PHP extensions from .bp-config/php/php.ini.d during composer#1216
Conversation
…omposer Parse extension= and zend_extension= directives from user .ini files and add them to the buildpack context so extensions are available during both composer install (build-time) and application runtime. Implementation: - Add loadUserExtensions() method to composer extension (composer.go) - Add loadUserExtensions() method to supply phase (supply.go) - Parse .bp-config/php/php.ini.d/*.ini files for extension directives - Extract extension names (strip .so suffix, quotes) - Add to context PHP_EXTENSIONS and ZEND_EXTENSIONS lists - Use uniqueStrings() helper to prevent duplicates This approach integrates with the buildpack's existing extension loading mechanism, avoiding duplicate loading and ensuring consistency between build-time and runtime configurations.
Add test case that verifies PHP extensions specified in .bp-config/php/php.ini.d/*.ini files are loaded during both composer install (build-time) and application runtime. Test fixture includes: - .bp-config/php/php.ini.d/custom.ini with extension=apcu.so - composer.json requiring ext-apcu with verification scripts - index.php displaying loaded extensions at runtime The test validates that: - APCu extension loads during composer install - Extension is available at application runtime - Build logs show successful extension configuration
Add user-facing and technical documentation for the new feature that allows loading PHP extensions via .ini files in .bp-config/php/php.ini.d. README.md changes: - Add 'PHP Extension Configuration' section - Explain .ini file syntax with examples - Compare with .bp-config/options.json alternative - Document built-in vs PECL extension categories - Clarify which extensions require explicit loading ARCHITECTURE.md changes: - Add detailed implementation documentation - Document extension parsing flow in both supply and composer phases - Explain rationale for parsing approach (no duplicate loading) - Include extension loading flow diagram - Reference key source files and line numbers - Document composer build-time PHP installation architecture
72bafc8 to
4207aea
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Fixes #1157 - PHP extensions specified in
.bp-config/php/php.ini.d/*.inifiles are now loaded during both build-time (composer install) and runtime.Problem
Previously, when users specified PHP extensions using standard
.inifile syntax in.bp-config/php/php.ini.d/, these extensions were ignored during the composer phase. This caused issues when:ext-apcu,ext-redis)The root cause was that the buildpack installed a separate PHP instance for composer but didn't process user
.inifiles for extension directives.Solution
This PR implements extension loading from
.inifiles by:Parsing user
.inifiles - Bothsupply.goandcomposer.gonow include aloadUserExtensions()method that:.bp-config/php/php.ini.d/directory.inifiles forextension=andzend_extension=directives.sosuffix, quotes, etc.)PHP_EXTENSIONSandZEND_EXTENSIONSlistsIntegrating with existing mechanism - Extensions are added to the same context lists used by
.bp-config/options.json, ensuring:Working in both phases:
supply.go) - Loads extensions for runtime PHPcomposer.go) - Loads extensions for build-time PHP used by composerExample Usage
Users can now create
.bp-config/php/php.ini.d/custom.ini:These extensions will be available during:
composer installexecution (build-time)This is equivalent to specifying extensions in
.bp-config/options.jsonbut uses the more familiar PHP.inifile format.Changes
Core Implementation
src/php/extensions/composer/composer.go- AddedloadUserExtensions()method for build-timesrc/php/supply/supply.go- AddedloadUserExtensions()method for runtimeTests
src/php/integration/composer_test.go- Added integration test casefixtures/composer_with_extensions/- Test fixture with APCu extensionDocumentation
README.md- User-facing documentation with examplesARCHITECTURE.md- Technical implementation detailsTesting
.bp-config/options.jsonunaffectedBackward Compatibility
This change is fully backward compatible:
.bp-config/options.jsoncontinues to work.inifiles are not presentRelated
Fixes #1157