Problem/Motivation
\Drupal\filter\Plugin\FilterInterface declares constants for each of the following filter types: TYPE_MARKUP_LANGUAGE, TYPE_HTML_RESTRICTOR, TYPE_TRANSFORM_REVERSIBLE, TYPE_TRANSFORM_IRREVERSIBLE. They happen to be integers because constants need a value, but since they are never serialized or written to a database we don't need them to be backed, except probably for BC.
Steps to reproduce
Proposed resolution
- Create a new enum
FilterTypewith cases forMarkupLanguage,HtmlRestrictor,TransformReversibleandTransformIrreversible. - Update references to these constants to get the enum instead
- Add BC layer to find these by their former integer value
- Remove integer backing in a later version
Remaining tasks
User interface changes
API changes
Data model changes
Release notes snippet
Issue fork drupal-3424769
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:
Comments
Comment #2
mstrelan commentedComment #4
mstrelan commentedFirst pass, see what the test bot thinks. Still a few references to the legacy consts and some deprecation to do.
Comment #5
mstrelan commentedHave put in some @todos where I think we can trigger deprecations. We should also have a test module using the old constants in the plugin annotations.
Also adding #3421012: Convert Filter plugin discovery to attributes as related.
Comment #6
wim leersYes, please!
This looks fantastic!
I posted an idea for how to deal with the
getFilterType()return type conundrum. Not 100% sure yet if it'll work, but it's a start :DComment #7
wim leers#3421012: Convert Filter plugin discovery to attributes landed, let's push this forward again?
Comment #8
mstrelan commentedRebased on 11.x and updated the attribute to expect the enum instead of int. Hopefully we don't have to deprecate passing an int to in the attribute if we can get this out before a 10.3 release? Needs work to address the feedback from Wim.