The upgrade from PHP 8.3.14 to PHP 8.4.4 presents challenges for Drupal 10.4 websites, particularly when dealing with contributed modules. While Drupal core operates seamlessly, various contrib modules have not yet been updated to accommodate changes introduced in PHP 8.4.x. This has resulted in multiple deprecation warnings and potential compatibility issues.
Understanding the issue
The primary issue stems from the deprecation of implicitly nullable parameters in PHP 8.4. This means that any function parameter that previously accepted `null` implicitly must now be explicitly marked as nullable using `?Type`. Without this modification, PHP throws deprecation warnings, which may lead to unexpected behaviour in the future.
A review of the contrib modules currently in use revealed several warnings related to this change, including:
- Devel module: Errors in functions like `backtrace_error_handler()`, `devel_message()`, and `dpm()`
- Field Group module: Issues with `field_group_form_process()`, `field_group_fields_nest()`, and other related functions
- Flysystem Stream Wrapper: Problems with `Twistor\FlysystemStreamWrapper::register()`
- Metatag module: Issues with `MetatagToken::replace()`, `MetatagManager::form()`, and related interfaces
Assessing the options
The logical next step when facing such issues would typically be to:
- Check for updates and patches: The maintainers of contrib modules may release updates or patches addressing these deprecations
- Manually patch the modules: Updating function signatures to comply with PHP 8.4 would resolve the immediate issue
- Fork and maintain a separate version: If official maintainers are slow to respond, forking the modules to apply fixes could be an option
However, given the number of affected modules and the potential for additional regressions, this approach is not ideal.
Why patching is not the way forward
While addressing each issue individually through patches may offer a temporary fix, it is not a sustainable solution. The key reasons for this include:
- High maintenance overhead: Maintaining patches for multiple modules increases complexity and requires ongoing effort with each new update
- Lack of upstream support: If the module maintainers do not adopt the necessary changes, local fixes may break when future updates are applied
- Potential for further issues: Patching one issue does not guarantee that other compatibility problems will not arise, especially as PHP continues to evolve
- Drupal's roadmap: The Drupal community and module maintainers will eventually address these compatibility issues. Applying local patches risks divergence from officially supported versions
A pragmatic path forward
Instead of manually patching modules, a more effective approach would be:
- Reverting to PHP 8.3: Until contrib modules catch up with PHP 8.4, sticking with PHP 8.3.14 ensures stability
- Engaging with module maintainers: Reporting issues to module maintainers and contributing to official fixes where possible helps accelerate updates
- Monitoring for updates: Keeping track of new releases and patches for affected modules will help identify when it is safe to proceed with PHP 8.4
- Testing extensively: When upgrading PHP, performing comprehensive testing in a staging environment is essential before applying changes to a live site
The wrap
Upgrading to PHP 8.4 is an important step for future-proofing Drupal projects, but contrib modules must also be prepared for these changes. Instead of attempting to patch numerous modules independently, a more strategic approach involves waiting for official updates, engaging with the community, and ensuring compatibility through controlled testing. This approach minimises risk and ensures a smoother transition to PHP 8.4 when the ecosystem is ready.