Problem/Motivation

Related to https://www.drupal.org/sa-core-2026-005.

There are no core usages of serialized_field_property_names however it requires to support serialized PHP.

I can only find one contrib usage via https://search.tresbien.tech/search?q=serialized_field_property_names&nu...

Let's deprecate support, and also provide a killswitch so that modules can skip the logic if they're confident they don't need it.

Originally was going to open this purely as a performance issue, but then when the security report came in, it makes sense to do it for that reason too - actual code change should be the same.

Steps to reproduce

Proposed resolution

Remaining tasks

User interface changes

Introduced terminology

API changes

Data model changes

Release notes snippet

Issue fork drupal-3603923

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

catch created an issue. See original summary.

catch’s picture

catch
he/him
Primary language English
commented
Status: Active » Needs work

catch opened merge request !16095

catch’s picture

catch
he/him
Primary language English
commented
Status: Needs work » Needs review

One unit test was using fake serialized properties purely to avoid a static ::schema() call on a mocked object (which is illegal). Addressed that by using a real object with mocked dependencies instead of the mock, which can then do the static schema() call because it's the actual class. The test itself has nothing to do with this feature.

Also kernel tests for this actual functionality now need to become deprecation tests.

heddn’s picture

heddn
Primary language English
Location Illinois
commented
Status: Needs review » Needs work

Seems like a reasonable thing to do. I've never heard of the feature, so it must not be well documented. We still mention it in https://git.drupalcode.org/project/drupal/-/blob/main/core/lib/Drupal/Co... though.

berdir’s picture

berdir
Primary language German
Location Switzerland
commented

Not sure I get this. It's not possible to handle serialization "manually"? The reason it's there is to *not* set a possibly serialized string as-is on the affected field.

Note that there are two different keys, one set on the entity type level for fields and one on field types, that one is used a lot more: serialized_property_names.

And yes, certainly, it should use json and this would be a non-issue, but it's not like core managed to get anywhere on that topic in the last 10 years, link options and so on are still stored as serialized string?

And while it is only one contrib module using it, that one module is paragraphs, and I'd love to switch to json, but doing so is honestly a bit of daunting task considering sites with millions of paragraphs and paragraph revisions out there. metatag did it, but often metatag fields aren't, so it wasn't as much for most sites.

What's the performance aspect of this?