Mark Quick Edit deprecated

Let's do this.

As far as I know this is still blocked on four issues; see IS of #3228986: [Meta] Tasks to deprecate Quick Edit.

@dww it looks like it got renamed but now I don't think it was meant to. There was a similar class that moved from LB to QE though.

https://git.drupalcode.org/project/drupal/-/commit/9423cae#de90f4354ad6d...

🌅

Postponed on #3266476: Ensure that quickedit does not get special core treatment per Slack discussion here: https://drupal.slack.com/archives/C014CT1CN1M/p1655750184381089

The contrib module needs some updates for changes to quickedit in HEAD (see #3291700: new subtree split of core Quick Edit into contrib (v2)) and then some testing, but I think all the core blockers are done per #3228986: [Meta] Tasks to deprecate Quick Edit

Latest on manual testing: https://drupal.slack.com/archives/C014CT1CN1M/p1658772338310209

I wrote manual test steps at #3303780: Manually test QuickEdit module removal - these work for me so I'm going to mark this as RTBC as I think we are ready to deprecate Quick Edit and the patch here is straightforward.

I don't think we can actually commit this until #3291700: new subtree split of core Quick Edit into contrib (v2) is merged but I've just marked that RTBC.

Yay!

I tweaked the change record so that all instructions are on the wiki page.

Shouldn't we remove the code that integrates with Quickedit from core field formatter plugin definitions before doing this? See quickedit_field_formatter_info_alter, \Drupal\Core\Field\Plugin\Field\FieldFormatter\BasicStringFormatter, and \Drupal\Core\Field\Plugin\Field\FieldFormatter\StringFormatter.

Also noticed that the Quickedit is relying on core internal libraries, and those might break in the future.

@lauriii See #3304893: Add Quick Edit metadata to core field formatters which re-adds that code back to Quick Edit contrib version. I think it's fine to leave that in while the module is deprecated - users on the core version will still need it - and finally remove it from core when the module is removed.

Detangling from core's internal libraries will have to be done by whoever is maintaining the contrib module, I guess?

Shouldn't we remove the code that integrates with Quickedit from core field formatter plugin definitions before doing this

I have a patch against the contrib module to add this back #3304893: Add Quick Edit metadata to core field formatters.

We could make the same change in the 9.5.x version of the module too to keep them inline. Could maybe just do that in here even since it's a small change?

Also noticed that the Quickedit is relying on core internal libraries, and those might break in the future.

IMO this is fine - part of the reason we're trying to deprecate quickedit is to make it easier to remove the core dependency on backbone during the 10.x cycle. If we made quickedit removal dependent on removing the backbone dependency from quickedit, then there's absolutely no reduction in the amount of work involved to remove backbone from core. Contrib modules depending on backbone will probably also switch to the internal versions of the libraries for Drupal 10 before refactoring away from it too.

Could maybe just do that in here even since it's a small change?

That seems fine since it's a very small change. Moving NW for this.

IMO this is fine - part of the reason we're trying to deprecate quickedit is to make it easier to remove the core dependency on backbone during the 10.x cycle.

Sorry for the confusion, definitely did not try to say we should block Quickedit on Backbone removal. It was more of an FYI for the maintainers. Quickedit could always directly depend on Backbone.

Rebased and moved the Quick Edit metadata to quickedit_field_formatter_info_alter().

While suspiciously QE-related, the test fail occurs in HEAD once every couple weeks:

1) Drupal\Tests\quickedit\FunctionalJavascript\LayoutBuilderQuickEditTest::testQuickEditIgnoresDuplicateFields
Failed asserting that two arrays are equal.
--- Expected
+++ Actual
@@ @@
 Array (
     'node/1/title/en/layout_builder-default-non_component-868b6a3975e4e05e73f0e68903ab093ac7b5db85d5bab37718f4f8eba92f2b6c' => 'inactive'
+    'node/1/body/en/layout_builder-default-0-36822d63_c693_4753_a42f_3f0e83f0f72c-1-868b6a3975e4e05e73f0e68903ab093ac7b5db85d5bab37718f4f8eba92f2b6c' => 'inactive'
 )

E.g:

• https://www.drupal.org/pift-ci-job/2455164
• https://www.drupal.org/pift-ci-job/2443833
• https://www.drupal.org/pift-ci-job/2432686

Therefore, requeuing it.

#38 thank you for that info. Was going nuts on another ticket with that random failure.

MR doesn't seem to break anything and code was simple to review. I don't mind marking RTBC.

Committed 6379200 and pushed to 10.1.x. Cherry-picked to 10.0.x and 9.5.x. Thanks!

🌅 👋

👋🏻