Come together with the global Drupal community in Rotterdam, 28 Sept – 1 Oct 2026. Sessions, contribution, connection, and Early Bird savings until 8 June.Problem/Motivation
When running Drupal 11 and using Upgrade Status to check for Drupal 12 compatibility, there are ~200 "problems" that are variations of these:
Attribute class Drupal\ai_translate\Attribute\FieldTextExtractor does not exist.
Class Drupal\custom_field_ai\Plugin\FieldTextExtractor\CustomFieldTextExtractor extends unknown class Drupal\ai_translate\Plugin\FieldTextExtractor\FieldExtractorBase.
with various other modules implicated, not just ai_translate.
Steps to reproduce
Run upgrade_status in Drupal 11 and scan custom_field module.
Proposed resolution
Tell phpstan to disregard these optional dependencies so that they don't show as "problems."
Remaining tasks
Make an MR.
Issue fork custom_field-3590695
Show commands
Start within a Git clone of the project using the version control instructions.
Or, if you do not have SSH keys set up on git.drupalcode.org:
changes
Comments
Comment #2
benstallings commentedComment #3
apmsooner commentedNot sure why this would be considered a bug for another module's analysis of compatibility. Drupal 12 is not yet released or therefore supported in this module yet. The plan for Drupal 12 support will be handled in a future custom_field 5.x version that will handle deprecations and such. It seems to me like that module is issuing false warnings since those dependencies like ai_translate are not installed. They are handled already by installing them as dev dependencies in https://git.drupalcode.org/project/custom_field/-/blob/4.0.x/composer.js.... I could consider this a feature request for Drupal 12 compatibility but I believe its not even slated for a release until later this year.
Comment #5
benstallings commentedOK, well since I was already working on this (I had assigned the ticket to myself), here is what I got done while you were dismissing it.
- Moving the AI functionality to submodules fixes a real (if uncommon) runtime bug. Pre-split, custom_field_ai.info.yml declared ai:ai but its plugins referenced ai_translate, ai_automators, field_widget_actions. Drupal would happily let someone enable custom_field_ai with just ai installed; the plugins would be discoverable but fatal on instantiation. Post-split, custom_field_ai_translate literally can't be enabled without ai_translate, etc. That class of bug is gone.
- Finer-grained install. A user who has ai_translate but not ai_automators/field_widget_actions can now enable just the translate integration. Pre-split, they got both plugins or neither.
- Honest dependency manifest. info.yml now matches what the code actually needs — better for any tool (composer, drush, Drupal.org) that reads dep metadata, and better for someone reading the module trying to understand what it requires.
But fine, let's call it a feature request. :)
Unfortunately upgrade_status doesn't respect module level phpstan.neon files, and the optional dependencies (such as graphql) are required by composer, so their files are present even if they're not in use, and as a result the warnings have to be silenced line by line, which is not great. Splitting the graphql functionality into a separate module is a much bigger refactor.
Comment #6
benstallings commentedComment #7
apmsooner commentedThanks for the response. FYI the unit test fail I'm fixing in another issue here so you can probably ignore that as its just timing out: https://git.drupalcode.org/project/custom_field/-/merge_requests/231/dif...
As for the suggested changes, I appreciate the contribution. I've honestly been considering however to move all the custom_field_ai stuff to a completely separate contrib module for the reason that the ai module has so many freaking versions at this point, trying to keep our code compatible as a sub-module is no longer feasible. I need to figure out a way of handling the deprecation & migration without breaking current sites.
Comment #8
apmsooner commented