Closed (fixed)
Project:
Drupal core
Version:
9.3.x-dev
Component:
migration system
Priority:
Normal
Category:
Task
Assigned:
Unassigned
Issue tags:
Reporter:
Created:
11 Oct 2019 at 08:07 UTC
Updated:
17 Nov 2021 at 10:54 UTC
Jump to comment: Most recent, Most recent file
Comments
Comment #4
quietone commentedComment #5
quietone commentedComment #6
quietone commentedAdding tag because this is a deprecation.
Comment #10
quietone commentedUpdated the deprecation message and added a comma.
Comment #11
huzookaThe original
__construct()method was inherited from\Drupal\Component\Plugin\PluginBase. I guess this is a copy-paste from MigrationLookup.UrlAliasLanguagedoes not injects the migration plugin instance nor the lookup and stub services.This should look like
I guess
https://www.drupal.org/node/TBAis a placeholder for the missing change record.Comment #12
andypostIn #3039240-106: Create a way to declare a plugin as deprecated there's question about how we should deprecate migrations (it's blocker)
Comment #13
quietone commented@huzooka, thanks for the quick reply. And apologies, I should have, at least made the CR before asking for reviews.
Yikes! The things I am forgetting lately.
CR added and updated the deprecation messages accordingly. I didn't change the trigger_error in the constructor to use sprintf because that is now required on the deprecation policy for plugins.
I have not added an interdiff because of the small size and both messages have been changed.
Comment #14
quietone commentedFortunately, that issue affects the migration plugin. We can, and have, deprecated source, process and destination plugins, For example, #2845483: Rename Iterator process plugin and add documentation.
Comment #15
huzookaWhy we cannot use
{@inheritdoc}?$migration,$migrate_lookupand$migrate_stubaren't passed, but they are completely unnecessary. Note that the process plugin extendsProcessPluginBase.These are completely unnecessary
Why cannot we do what I suggested in #11.2 without
sprintf()?Comment #16
quietone commentedGoodness, this day has been longer that I thought...
#15 1-3. Should be better, hopefully fixed.
11.2 looks like changing TBA to the nid of the change record. That was done. What have I missed? I found that I missed changing the version from 9.2 to 9.3. What else?
And I added a test of the trigger_error message.
Again, no interdiff as this is small and I don't think it will add value.
Comment #17
danflanagan8nit: Everywhere else in core uses all caps for true:
no_ui = TRUEThat's the only "what else" I noticed.
Although at this point maybe it's going to have to be 9.4...
Comment #18
quietone commentedChanged true to TRUE and corrected the filename of the test to end with 'Test'.
Comment #19
danflanagan8Good catch on the file name. I think it looks good...as long as it gets in for 9.3.0. If not that comment/message will need updating.
Comment #20
alexpottAs a plugin we should not be triggering a deprecation error in the main section of the class - this should happen only on construction. This change is currently adding both.
Comment #21
quietone commentedOops. Fixing that now.
Comment #22
daffie commentedThe window for deprecations in D9.3 has passed, they now need to go into D9.4.
Comment #23
quietone commentedUpdated to 9.4.x.
Comment #24
andypostback to RTBC
Comment #25
alexpottDiscussed with @catch and we agreed to backport this to 9.3.x to avoid having to deprecate this in Drupal 11.
Move the deprecations to 9.3.0
Committed and pushed 04f2578519 to 9.4.x and c4debe7012 to 9.3.x. Thanks!