Deprecate EditorLinkDialog, EditorImageDialog and EditorMediaDialog in Drupal 10.1 for removal in Drupal 11

Based on 📌 [policy, then docs] Change how we deprecate classes Fixed , I think we should be triggering the deprecations in these classes' constructors rather than at the top of the file. Tagging for RM review to confirm with others.

I think the changes proposed in 📌 [policy, then docs] Change how we deprecate classes Fixed make sense, but (at least) I also think that we can't expect people to make patches/MRs that are based on the official policy → , which then are being put back to NW because of something that isn't an official policy (yet).

Then again, n=1.

@Spokje This might be the first issue where we adopt it. I did leave the issue RTBC for a reason though.

📌 [policy, then docs] Change how we deprecate classes Fixed was indeed adopted today, so let's move the instantiated classes' deprecations to their constructors. (Don't worry, there's another issue that was NW on this too.)

Thanks @xjm

#2935897: [policy, then docs] Change how we deprecate classes was indeed adopted today, so let's move the instantiated classes' deprecations to their constructors.

Not sure if I should check my feet for bullet wounds, but at the very least we got an improvement on the deprecation policy. :)

(Don't worry, there's another issue that was NW on this too.)

I gave up worrying about d.o. issues quite a while ago, so we're all good here.

Do we still need a Release Manager review?

Updated CR for 10.1.x/11.0.x

Thanks @Wim Leers!

The route and deprecation message skipping is a bit tricky.

Ideally we'd want to deprecate the route, but this depends on 📌 Support route aliasing (Symfony 5.4) and allow deprecating the route name Needs work .

Also even if we deprecate the route, it wouldn't would help us remove the deprecation skipping. The one thing it might mean is that we've got an un-suppressed deprecation for the route, which would be another way to alert contrib/custom code. Either way that should be a follow-up.

The only other thing I can think of would be moving the deprecation out of the constructor and into EditorImageDialog::buildForm() and EditorImageDialog::skipForm(), this would (probably?) mean it could be non-skipped, but that'd be an even further change to policy and not necessarily more useful.

Then after all that I realised controllers/forms are @internal anyway meaning anything we do here is 'best effort', so if the skipping does mean some custom or contrib code doesn't catch this, well we did our best.

So I think we should open a PP-1 follow-up to deprecate the routes once 📌 Support route aliasing (Symfony 5.4) and allow deprecating the route name Needs work is in, but otherwise agreed this is the best we can do here and untagging for RM review.

Thanks @catch, opened 📌 [PP-1] Properly deprecate routes editor.image_dialog, editor.link_dialog and editor.media_dialog Postponed to address #45 📌 Deprecate EditorLinkDialog, EditorImageDialog and EditorMediaDialog in Drupal 10.1 for removal in Drupal 11 Fixed .

Committed d6988e5 and pushed to 10.1.x. Thanks!

Spokje → closed merge request !2969

Automatically closed - issue fixed for 2 weeks with no activity.