Problem/Motivation
Part of #2959269: [meta] Core should not trigger deprecated code except in tests and during updates
This issue is related to deprecation errors triggered by Drupal\editor\Plugin\EditorBase
related to this change record: https://www.drupal.org/node/2819753 from this issue: #2326721: EditorPluginInterface should extend PluginFormInterface
EditorBase::settingsForm()
, ::settingsFormValidate()
and ::settingsFormSubmit()
are all deprecated in favor of the other settings-related methods on EditorBase
. These methods call @trigger_error()
.
It's unlikely that a subclass which uses these methods will call the parent method, so the errors will not be triggered.
Further complicating matters, when an editor settings form is displayed, the controller looks for either settingsFormValidate()
(deprecated) or validateConfigurationForm()
(not deprecated), and calls settingsFormValidate()
if it's present. This means any form which subclasses EditorBase
but does not implement validateConfigurationForm()
will always trigger the deprecation error.
In addition, these deprecated methods are marked as {@inheritdoc}, but they don't belong to an existing interface. So their deprecation messages are not present, and don't offer a way to fix the error.
Proposed resolution
Figure it out. :-)
Remaining tasks
User interface changes
API changes
Data model changes
Comment | File | Size | Author |
---|---|---|---|
#11 | 3002933-11.patch | 9.25 KB | alexpott |
#11 | 10-11-interdiff.txt | 589 bytes | alexpott |
#10 | 3002933-10.patch | 9.66 KB | alexpott |
#10 | 5-10-interdiff.txt | 5.42 KB | alexpott |
#5 | 3002933-5.patch | 9.2 KB | alexpott |
Comments
Comment #2
Mile23Super explodey patch.
You can reduce the blast from
CKEditorAdminTest
by implementing a no-opvalidateConfigurationForm()
, but even then, it still implementssettingsForm()
andsettingsFormSubmit()
even though those are supposed to be deprecated.Should
EditorBase
be deprecated? And if so, in favor of what?Comment #5
alexpottHere's what I think @Wim Leers intended... going to ping him this issue.
Comment #6
alexpottAlso I think the CR is not quite right. https://www.drupal.org/node/2819753 says:
Whereas what I think needs to happen is that the plugin should be updated to implement the \Drupal\Core\Plugin\PluginFormInterface methods.
Comment #7
alexpottContrib modules to look at are (from http://grep.xnddx.ru/search?text=EditorBase&filename= ):
Comment #8
alexpottNeeds no changes
Needs changes
So interestingly the only one that's not triggering deprecations atm is ace_editor because it overrides all 3 methods :)
Comment #9
Wim LeersYes and no 🙂
#2326721: EditorPluginInterface should extend PluginFormInterface was probably one of the earliest deprecations. And in #2326721-99: EditorPluginInterface should extend PluginFormInterface I wrote:
Changing subclasses is exactly what #5 is doing. Hence "no, #5's interdiff is not what I intended".
But … since then we've gained a lot more experience on how to deal with deprecations. And that's where the "yes" in "yes and no" comes from.
My only concern is that this means we will have no test coverage proving the old mechanism still works but triggers a deprecation error.
\Drupal\Tests\editor\Unit\EditorBaseTest
doesn't quite do that.Comment #10
alexpottAh I see yeah the code looks like it has half dealt with the deprecation and is triggering it from the wrong place. The patch attached completes the deprecation and properly tests it. We should also update the CR when this is committed to reflect reality.
Comment #11
alexpottAnd now we can get rid of a pointless change too...
Comment #12
Wim LeersThis looks perfect :)
Comment #13
catchFixed this on commit (+ to *), and updated the change record.
Committed 012b0c7 and pushed to 8.8.x. Thanks!
Comment #16
catch