Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.Problem/Motivation
We have \Drupal\Core\Serialization\Yaml and \Drupal\Component\Serialization\Yaml.
The Core extends the Component class to add the ability to force via a setting yaml_parser_class. The problem is that this setting does not affect all yaml parsing. For example, \Drupal\Component\Discovery\YamlDirectoryDiscovery. This is because YamlDirectoryDiscovery is a component too and therefore shouldn't depend on core code.
Proposed resolution
Remove this unnecessary complexity. At the moment if you the PECL Yaml extension installed it will use it unless this setting is set to use the Symfony class. We should not have set-ability in Drupal. The set-ability should just be determined by whether you have the extension or not.
Remaining tasks
- Create change record
- Add deprecate notice to code
- Replace all usages in core
User interface changes
None
API changes
Deprecating \Drupal\Core\Serialization\Yaml in favour of \Drupal\Component\Serialization\Yaml
Data model changes
None
Issue fork drupal-2880280
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:
- 2880280-deprecate-drupalcoreserializationyaml
changes, plain diff MR !893
1 hidden branch
Comments
Comment #10
bradjones1This class was added in #1920902: Add a Drupal Yaml wrapper so we can default to PECL Yaml component if it is available but the only file touched in that diff is the addition of this class. Core, however, uses the component class in its definition (serialization.yaml)I think there is a use case to be made for being able to set the serializer - which I will lay out in a new ticket. Given the age of this issue, the fact I think this is actually orphaned code from the 8.x development cycle and there may be better ways of doing this - let's see what a straight patch removing it does on tests. I am not sure it would require a CR if it never worked to begin with, but maybe I'm missing something here.
This is all wrong... I was looking for invocations of this method specifically and of course invocations of the core class abound throughout core.
Comment #12
bradjones1Comment #14
bradjones1Comment #15
bradjones1OK, sorry for the noise. I came here in search of a way to override the serializer, and this is possible via the method proposed for deprecation here. I think container parameters or some other such "more modern" way of expressing the override is better than a setting, but that's beside the main point.
Consider the case where you'd like to employ Yaml custom tags or enable Symfony's built-in tags. You must provide these as flags to the Symfony parser, which is called in the serializer. I don't think either of these functionalities will roll into core, but they're helpful to specific site owners willing to implement the logic locally and own the complexity.