Skip to main content

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:

  1. Check for updates and patches: The maintainers of contrib modules may release updates or patches addressing these deprecations
  2. Manually patch the modules: Updating function signatures to comply with PHP 8.4 would resolve the immediate issue
  3. 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.

Related articles

Andrew Fletcher04 Apr 2025
Managing .gitignore changes
When working with Git, the .gitignore file plays a critical role in controlling which files and folders are tracked by version control. Yet, many developers are unsure when changes to .gitignore take effect and how to manage files that are already being tracked. This uncertainty can lead to...
Andrew Fletcher26 Mar 2025
How to fix the ‘Undefined function t’ error in Drupal 10 or 11 code
Upgrading to Drupal 10.4+ you might have noticed a warning in their code editor stating “Undefined function ‘t’”. While Drupal’s `t()` function remains valid in procedural code, some language analysis tools — such as Intelephense — do not automatically recognise Drupal’s global functions. This...
Andrew Fletcher20 Feb 2025
Handling duplicate records in Drupal
Duplicate records in Drupal can cause significant issues, particularly when they lead to integrity constraint violations in the database. These errors often occur due to duplicate UUIDs in the `node` table, which can result from programmatic imports, migrations, or unintended database...