I'm in the process of upgrading from Drupal 10 to Drupal 11 on a complex site. The only module preventing me from upgrading is Computed Field. Upgrading to Computed Field v4 would be a realy complex and time consuming task.

Would making V3 compatible with Drupal 11 be possible soon?

CommentFileSizeAuthor
#18 3539496-17.patch4.94 KBjunaidpv
#9 computed_field-v3-d11-compatibility_3539496-9.patch3.67 KBrichyu
#6 computed_field-v3-d11-compatibility_3539496-6.patch716 bytesaslaymoore

Issue fork computed_field-3539496

Command icon 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:

About issue forks

Comments

cemproduction created an issue. See original summary.

cemproduction’s picture

cemproduction commented

I'm using v3 on Drupal 11.

So far, there was one issue related to :
New API for defining field type categories - Setting the field type category as a translatable label in annotation is deprecated

I solved it for now by removing "@Translation" from the field type category in the FieldType plugins definitions.

aslaymoore’s picture

aslaymoore commented
Assigned: Unassigned » aslaymoore

aslaymoore opened merge request !23

aslaymoore’s picture

aslaymoore commented
Priority: Major » Normal
Status: Active » Needs review

I've added a merge request that adds D11 to the info file of the 3.x module, and tested it against the site we're in the process of upgrading to D11. Would be good to test it against other sites upgrading to D11 that also need to stay on the 3.x branch.

aslaymoore’s picture

aslaymoore commented
StatusFileSize
new computed_field-v3-d11-compatibility_3539496-6.patch716 bytes

Here's a patch file for the merge request on #4.

aslaymoore’s picture

aslaymoore commented
Assigned: aslaymoore » Unassigned

sean_fremouw made their first commit to this issue’s fork.

richyu’s picture

richyu commented
StatusFileSize
new computed_field-v3-d11-compatibility_3539496-9.patch3.67 KB

A patch that removes "category" from the FieldType plugins definitions.

joachim’s picture

joachim commented

There's already a MR - what's the patch for?

hilly510’s picture

hilly510 commented

We need to add a composer.json to the MR in order to fully support D11. Can someone do that or add me to the repo so I can add it?

joachim’s picture

joachim commented

I've not heard anything about that. Do you have a link to docs about it?

hilly510’s picture

hilly510 commented

It seems like it shouldn't be required, but I just tried to upgrade to Drupal 11 using this MR (23) and composer ended in an error complaining about this module not including a composer.json file.

Here is the doc about it https://www.drupal.org/docs/develop/using-composer/add-a-composerjson-file

joachim’s picture

joachim commented

> If a module does not have any dependencies, or the dependencies are solely other Drupal modules, then a composer.json is not required. However, having a composer.json does not have a negative impact either.

baikho’s picture

baikho commented
Status: Needs review » Needs work

#9

A patch that removes "category" from the FieldType plugins definitions.

Removing is not a good solution, and without dropping older core compatibility the BC layer needs adding https://www.drupal.org/node/3375748#bc

kenwest made their first commit to this issue’s fork.

kenwest’s picture

kenwest commented

I've added a fix for the issue with using @Translation() on a @FieldType's category setting. I borrowed the logic from a similar fix made to the Entity Reference Display module. A quick survey of the modules I'm using indicated a 50:50 split between the category being lower cased or proper cased, so I selected "Computed" rather than "computed" as this seemed like the path of least harm.

This approach addresses @baikho's concerns in #15.

junaidpv’s picture

junaidpv
Location Kannur, Kerala
commented
StatusFileSize
new 3539496-17.patch4.94 KB

Current MR23 in patch form to use in composer based build.

akshay kashyap’s picture

akshay kashyap commented
Assigned: Unassigned » akshay kashyap
akshay kashyap’s picture

akshay kashyap commented
Status: Needs work » Needs review

I tested Merge Request !23 (and the corresponding patch from #17/#18) on a Drupal 10 site running Computed Field 3.x and upgraded the site successfully to Drupal 11.

What I tested:

Installed the patch on Computed Field 3.0.x.

Upgraded Drupal core from 10.5 to 11.3.x.

Verified that existing computed fields still function as expected and recalculate values correctly.

Checked the logs for any @Translation annotation deprecation warnings related to FieldType categories—none were found.

The patch correctly addresses the backward-compatibility concerns raised in #15 by keeping a clean string category (category = "Computed"), which Drupal 10.2+ and Drupal 11 handle seamlessly.

This works perfectly and resolves the upgrade blocker for sites stuck on v3. Ready to commit!

joachim’s picture

joachim commented

Was #20 written with an LLM? It reads a lot like LLM output.

hoporr’s picture

hoporr commented

I installed MR 23, tested it, it seems to work fine:

1) First with the older 10.6 install, and it worked.
2) I then did the upgrade to Drupal 11.3.11, and it seems to also work fine: when I edit and save a content-type, the field updates correctly.

( I used composer lenient to get around the fact that the patch applies after the core install, otherwise there was a version conflict. )

My two cents:

I really think having 3.0 at least initially running in D11 is important, because 1) it does not block the upgrade to D11, and 2) that way the data in the fields (in the DB) stays in the system until I have the new solution in place. Without this, I would have to uninstall computed_fields before the upgrade, and thus would loose all the data, and it would force me to somehow port all this in a pre-step before the update... Given that I now have the data in D11, I can write a hook_n_update or whatnot and port the data over into new fields, etc.

joachim’s picture

joachim commented

If you've reviewed the MR and you think it's fine, please feel free to mark it RTBC and then I'll commit it.

hoporr’s picture

hoporr commented
Status: Needs review » Reviewed & tested by the community

  • joachim committed 064bd469 on 3.x authored by aslaymoore 
    feat: #3539496 Drupal 11 compatibility

By: aslaymoore
By: cemproduction...
joachim’s picture

joachim commented
Status: Reviewed & tested by the community » Fixed

Thanks.

Making a new patch release as per https://www.drupal.org/docs/develop/managing-a-drupalorg-theme-module-or...

Thanks everyone!

Now that this issue is closed, review the contribution record.

As a contributor, attribute any organization that helped you, or if you volunteered your own time.

Maintainers, credit people who helped resolve this issue.

marcellinostroosnijder’s picture

marcellinostroosnijder commented
Status: Fixed » Needs work

I have also tested MR 23 on 11.3.10, but I received the following error:

AssertionError:
"Computed" must be defined in MODULE_NAME.field_type_categories.yml inassert() (line 183 of/var/www/html/web/core/lib/Drupal/Core/Field/FieldTypePluginManager.php).

Looking through the comments in this thread and the MR, nothing has been done about comment #15. Should we not look into this. For me, the patch from #9 works - but is not ideal.

Can someone look into this before the module is marked as Drupal 11 ready?

joachim’s picture

joachim commented

I already committed the MR and made a release. Please start a new issue for this.