Decide whether to move Quick Edit to contrib

One problem here may be many sites may have it turned on but not use it
https://git.drupalcode.org/project/drupal/-/blob/9.2.x/core/profiles/sta...

Maybe we can only remove it from standard profile in D10 and then reconsider full removal for D11?

I agree with this, JS code is complex and isn't really 'extensible' it's more of a "packaged" experience that is starting to get in the way of other core features (it's hard to adapt it because of the lack of flexibility/extensibility).

I would agree that this fits better in contrib nowdays.

QuickEdit was also the most difficult integration point for both Layout Builder and probably up there for CKEditor 5 as well.

One of the primary issues with QuickEdit is that the UX is not good. Itʻs difficult to figure out how to edit in the first place, the UI is slow, floats around in strange ways, and makes it difficult to tell if the content has been saved or not. Itʻs especially problematic with Layout Builder where there are two different interface methods to edit blocks vs. main content. A more complete user interaction solution is needed (and there are initial designs for this work out there).

We might be better off deprecating QuickEdit and working on a new feature based on our modern UI design for content editing in place, comparable to and complementary to Layout Builder, using modern code.

We should probably do user surveys to get an idea of how many sites actually use the feature vs. just never disabled the module.

This is (obviously) anecdotal but in all my years of building Drupal sites I have *never* used Quick Edit. It's on the list of 'stuff I uninstall right away'. The only time I have ever used it was when working on core bugs.

So a big +1 to this from me.

As one of the people who contributed this to Drupal core…

One problem here may be many sites may have it turned on but not use it

💯 — this alone is the top reason to remove it.

We could arguably remove it from the standard profile in 9.3 or 9.4 (since it's not an API, similar to adding a new module to the standard profile happens in minor releases), then from core in 10.x - but it definitely needs to be staged, since we can't deprecate before removing from standard.

+1 to first remove it from the Standard install profile.

JS code is complex and isn't really 'extensible'

I agree it's too complex. I'll add that it's brittle.

I disagree it's not extensible. But it's brittle and complex to extend. #2421427: Improve the UX of Quick Editing single-valued image fields moved a contrib module into Drupal core that added a new Quick Edit "in-place editor". Which is why the number of contrib/custom @InPlaceEditor plugins is extremely tiny (I don't even know of any).

We might be better off deprecating QuickEdit and working on a new feature based on our modern UI design for content editing in place, comparable to and complementary to Layout Builder, using modern code.

💯

Quick Edit was written in a different era:

1. Drupal did not have the ability to write or run JS in tests — which is why Quick Edit shipped with barely any test coverage
2. Drupal did not have a generic API to read/write entities — since ~2 years it has JSON:API (which already has a very rich ecosystem)
3. Drupal did not dare to choose a more opinionated JS library/framework, so we used the most unopinionated one (Backbone.js in #1149866: Add Backbone.js and Underscore.js to core) and then we wrote a lot of custom JS on top of it.
4. Drupal aimed to deliver accessible experiences but shipping D8 was more important so we never finished key accessibility capabilities (#1844220: Make in-place editing keyboard and aurally accessible) despite landing critical infrastructure for it first (#1913086: Generalize the overlay tabbing management into a utility library)

If we were to write something like Quick Edit today, it'd have been written on top of JSON:API with comprehensive test coverage, on top of a JS lib/framework with many more guardrails and fewer NIH-esque approaches and would have to be far more accessible.

And finally … 50 open issues is frankly a pretty impressively low number compared to most core modules. The caveat there is that it's only 50 because it's probably barely being used! 😅

That being said, I feel bad that they aren't getting a response at all from the maintainers (@nod_ and I) 😔, but it's because there's more important things to spend time on in Drupal core than Quick Edit. Which is mostly the case because all data suggests few people actually use Quick Edit.

At this point, Quick Edit is slowing the rest of Drupal core down.

So +1 for moving it into contrib.

Big +1 for moving it to contrib

• Looking through the commit history there has been no work on it outside of updating tests and dependencies since October 2019
• It causes motion sickness for a number of people
• I have also never built a Drupal site that used Quick Edit or even considered using it.

Quickedit is one of a few modules with a BackboneJS dependency. Backbone is effectively unmaintained, and a module can’t remain in core with unmaintained dependencies. There are three other modules using BackboneJS, Contextual, Toolbar, and Tour (Also CKEditor, but that will soon be replaced with CKEditor 5). Removing these module's BackboneJS dependencies is fairly straightforward, as proven by the prototypes in #3145958: [META] Re-evaluate use of Backbone.js in core.
Quickedit’s BackboneJS usage, however, is significantly more complex. Removing Quickedit’s BackboneJS dependency would require hundreds of contributor hours. There are two primary reasons I think this would be a poor use of contributor time:

1. Very few contributors have the skillset required to extract BackboneJS from Quickedit. There is a greater benefit to the Drupal community if those skills are applied to newer, modern initiatives. In some cases this time would be spent providing comparable (and preferable) equivalents to what Quickedit offers.
2. Particularly since Quickedit has limited test coverage, the transition away from BackboneJS will undoubtedly introduce many unexpected bugs. It would be a bumpy transition. Thing is, Quickedit works fine with BackboneJS, and potentially could for years to come. Core’s very strict dependency standards (a good thing!) require Backbone to be removed, but there are many sites willing to accept the (likely minor) risks of using a BackboneJS-dependent module. Moving Quickedit to contrib means sites can continue using the Quickedit they know and love, instead of dealing with a likely-turbulent transition to a Quickedit that doesn’t use BackboneJS.

I would be very happy to see Quickedit moved to contrib. Don't think I've ever found it adding to the experience

Adding some of the points to the IS.

Fixing inaccuracy re: usage.

+1

Before moving to contrib it needs someone to maintain it there

Adding more things to the IS.

I was going to add the subsystem maintainer review tag, but both maintainers for the subsystem have already given their +1. Both release managers have also similarly indicated support, although I do think we might want to consider a simple user survey ("Do you use QuickEdit?") to validate our assumptions about usage for content authors, especially in the long tail. (Or at least maybe promoting this for feedback via the core blog.) The technical and accessibility issues alone might be sufficient to justify this being removed for core, but it'd be good to have more "actually use it" usage data for the product review.

Not quite the core blog, but I tweeted at https://twitter.com/gaborhojtsy/status/1415035764975484931 to gather more feedback. Will still be mostly insider feedback though based on my followers.

Do you use Quick Edit in-place editing in Drupal core or have a better / different solution for faster editing? We are looking for different sources of feedback for https://www.drupal.org/project/drupal/issues/3222947

+1 moving to contrib.

I have always uninstalled this module from all of my drupal sites. Never found any use of this module. Move it to contrib.

+1 for moving this to contrib. Across dozens of projects I’ve only seen maybe one that prioritized getting Quick Edit working correctly (mostly because I like trying to use cool new things), and even then I don’t think it got used.

It's can be useful for things like custom blocks. but I seldom use it.

+1 for moving it to contrib.

We have it in Open Y distro enabled by default and probably there is some usage, but I'm fine with moving it to contrib
We use geysir as a successor

I have never once built or seen a production site that actively uses QuickEdit.

In the real world, no developers would code things twice. (one for standard admin, one for frontend editing)

Quick edit provided something less than half-baked. Site admin must disable it to avoid confusion. (It saved hundred hours to reply to their support tickets)

If we bring the Node Edit setting to Quick Edit UI. It will increase the usage I think.

On the code side,
We always talked about Quick Edit solely (separated). What I think when we start a module like this, we should refactor the EDITOR API (CKEDITOR / formatters things) & Quick Edit to be a single API. Only one single initial way to call out the editors. (and same UI if it's possible). Always use CONFIG to initial things & kick out PHP as much possible as we can.

and killing it will affect Setting Tray?

I posted a non-scientific twitter thread at https://twitter.com/gaborhojtsy/status/1415035764975484931 expecting the responses would be somewhat balanced, but no. Reading this back, its pretty much a

Negative:

@bibliophileaxe: No, we don't use quick edit. We did try it out but geysir was more in line with what we were looking for as we mainly use paragraphs.

@saschaeggi We use(d) it (with paragraphs) on different client sites, but since we moved to build decoupled sites it's of no use anymore

@benji17fisher I do not use it.

@karlshea: Every time I’ve given it another shot it works so inconsistently I can’t leave it enabled for clients to use.

@Stargayte: Always brought more problems than solving them, I usually disable that module on every website.

@MrPaulDriver: I never found a need for it until I started using layout_paragraphs... problem is, it doesn't work with the administration theme.

@joelpittet: It’s a bit too tricky/risky to keep all the edge cases where it doesn’t work well in my head so I uninstall it in most cases.

@agoradesign_at: We never use quickedit. Removed it from our Installation Profile long time ago.

@renebakx: actually never found a good use for it. Contextual links in frontend was less obtrusive to implement in a theme as well. Kinda the same issue as with a full integration of layout builder in bespoke theme.

@DruxtJS: we provide the Decoupled EditBar instead. [paraphrased]

@ashabed: Never used it. Even if it was enabled, clients never used it.

@claybolto: I never use it and have never seen my clients use it either. I also think the in-place edit concept in general goes against the Create Once Publish Everywhere (COPE) principle that Drupal is so good at.

@singularo: I've tried quickedit many times, and it always does weird stuff that users would not cope with. So never even show them or enable it. Move it to contrib imho.

@j_brockbank: We never use it because our content-types typically have a lot of fields that are not shown so the editor needs to edit anyway.

@rinasek Tried a couple of times, always had problems. Do not bother any more.

@beltofte We are using Paragraphs a lot including nested paragraphs, and Paragraphs and Quick Edit are not playing well together. Furthermore are we moving more and more towards decoupled sites and Quick Edit is not really useful in such architecture.

So-so:

@podarok: We have both quickedit and geysir in @openymca distro.

@steviedotboston: Have it enabled on some sites, but its not heavily used.

Positive (although dubious since the video linked is about settings tray not quickedit):

@markconroy: Would it be wrong to say I quite like quickedit module? Though only for very small sites (no paragraphs, layout builder, etc). I can totally see why we should remove it, and agree with removing it for the kinds of sites people normally build with Drupal. https://www.youtube.com/watch?v=ccaN1c7aWXU

No complaints from me, never really used it enough to form an opinion on it. It sounds like we have better options available now compared to when Quick Edit was built: I like the idea of building something on top of JSON:API and a solid JS framework.

Btw the geysir module is better replacement for it

Added a few more orgs/agencies from the Twitter thread and the thread itself to the IS.

Is anyone interested in maintaining the contrib module at least for the next two years, so that we can support the upgrade path from D9 to D10? Edit: I would say "security fixes only" would be a totally okay way to maintain it for those two years as that's essentially what it is now.

+1 to move it to contrib. The main reason we created and use frontend editing instead of quickedit is that you cannot use the styles of the administration theme to provide a consistent editorial experience.

One thing we'll need to consider here, is that formatters define quickedit metadata in their annotation.

We'll need to move that to quickedit module in an alter hook - for formatters we know about in core.

But for other formatters from contrib that integrate with quickedit, they may need additional steps.

FWIW, we have a staff of 30 Staff content editors at the Urban Institute. 1 is a Drupal-specialist. All of them interact with Drupal on a daily or weekly schedule. The Drupal Specialist spends a lot of his time in Drupal 9 Layout Builder working very near Quick Edit.

None of them use Quick Edit.

Editing flow affected the QuickEdit usages also. I believe most editors don't know how to use this tool on draft. Even, editors do not know the existence of this tool.

QuickEdit is the In-Place editing actually. It's different than any Layout builder / Geysir / frontend_editing mentioned above. (I meant some comments we collected expecting different products)

In another word, a perfect deal is a combo of both of them.

If you have a lite site, QuickEdit (can) providing something similar to the medium.com style for you.

We should focus on "Is it worth to keep In-Place editing", not our coding (good or bad) at this point, and not to fulfill all extra features requests.

In-place editing should be boring and simple:
https://ckeditor.com/docs/ckeditor5/latest/examples/builds/inline-editor...

In fact, this tool has no bugs affecting normal usage. (You could call it Zero Maintenance is needed)

Again. Don't make a single tool to fulfill all needs.

@droplet: it is not exactly zero maintenance as we need to revisit and rewrite a significant part of it as apart of the CK5 efforts and removing backbone too.

Even though the decision here hasn't been finalized yet, it might be worth starting an issue with a patch or MR that removes quickedit module to see what tests within other modules start failing as a result, so that we can start refactoring those tests. As an example, yesterday I committed #2993647: Correctly determine when to display fields as inline, despite that including tests that added data-quickedit-* selectors to assertions within a test in node module, because that issue had already been RTBC for a long time and I didn't want to hold it up any longer, and that's not the only example.

Also, I think we've done a good amount of "considering" here already, so retitling the issue to be a bit bolder :)

I'd suggest creating a separate issue to start testing the removal and keep this one MR-less for the policy signoff.

I think in #35 @droplet meant to say that the CKEditor inline editor had no bugs affecting normal usage. QuickEdit absolutely has bugs affecting normal usage, up to and including causing severe nausea in people with motion sickness.

Re: #39: Agreed. Opened #3227033: Remove Quick Edit from core as a child for that. No time to actually try to upload a patch, so anyone else is welcome to do so. ;)

Re: #40: Absolutely.

Re: the proposal here: yes, please. ;) I tried to use quickedit for something, once. Didn't go well. Wasted a few days and still couldn't make it work. I don't think it's worth keeping in core, and there are a ton of good reasons to remove it (which I won't repeat).

Cheers,
-Derek

Fixing issue link in the IS and adding to the listed orgs.

Also posted #3227036: Remove QuickEdit from the Standard profile which should be done in 9.3.x if Dries signs off on this.

I've read the issue and discussed this with some of the Core Committers in a meeting, and all things considered, I concluded that we should remove Quickedit from core.

I think we can also call the policy decision RTBC at this point since we have all the relevant signoffs.

The next thing we will need is someone to maintain it in contrib.

Meanwhile, there is #3227036: Remove QuickEdit from the Standard profile which we can do now and #3227033: Remove Quick Edit from core which will probably surface a number of blockers.

See also #3227161: Stop using Quick Edit data attributes as selectors in tests that are not testing Quick Edit if anyone wants to help pay off the technical debt of relying on data-quickedit selectors in tests that have nothing to do with quickedit itself. ;) Thanks!

I've created a meta issue at #3228986: [Meta] Tasks to deprecate Quick Edit to track the steps of implementing this. Marking the policy issue "fixed" and publishing the change record.

Moving to core ideas issue queue because that is where the recent issues about removing core modules reside.