Paragraphs currently works with quick edit, but it sees the field as a whole, meaning using quick edit will show the full paragraphs field in the popup. It would be better if it would see the embedded fields as actual fields like it does with direct added fields in a node.

Proposed resolution

Extend the quickedit functionality, if possible, to support the full powers of quick edit.

Remaining tasks

User interface changes

Backend: none
Frontend: quickedit will show the embedded fields as normal fields which should fully empower quick edit.
Possibly something like will be used for adding paragraphs if possible.

API changes


Members fund testing for the Drupal project. Drupal Association Learn more


jeroen.b’s picture

Issue summary: View changes
jeroen.b’s picture

Hmm, actually, on D8 HEAD, quick edit seems completely broken...

<em class="placeholder">LogicException</em>: The database connection is not serializable. This probably means you are serializing an object that has an indirect reference to the database connection. Adjust your code so that is not necessary. Alternatively, look at DependencySerializationTrait as a temporary solution. in <em class="placeholder">Drupal\Core\Database\Connection-&gt;__sleep()</em> (line <em class="placeholder">1300</em> of <em class="placeholder">/home/vhosts/jeroen/drupal/d8/core/lib/Drupal/Core/Database/Connection.php</em>).

jeroen.b’s picture

Issue summary: View changes
miro_dietiker’s picture

There's a fix for the core problem: #2475483: Cannot quickedit an image or date field

jeroen.b’s picture

Ah, bug in core. Patch from #2475483 fixes that.

jeroen.b’s picture

I'm currently doing some work in the 8.x-1.x-quickedit branch trying to get set up my own QuickEdit editor.
Currently not loading my paragraphs editor though, not sure why.

yobottehg’s picture

i just wanted to let you know that someone made a module for this and more.

jonathanshaw’s picture

Paragraphs Edit definitely seems like a step forward with quick edit, although not fully usable yet when I test it.

jeroen.b’s picture

That module allows you to directly edit/clone/delete paragraph items. It does not seem to contain anything to support QuickEdit?

yobottehg’s picture

i tried it on simply test me and was able to quickedit paragraphs

jeroen.b’s picture

Yes, but that should also work without that module.
It's just not really nice.

jonathanshaw’s picture

Without that module, quickedit only brings up the whole of the node's paragraph field with all the paragraphs. With the module, quick edit is aware of each (top-level) paragraph within the paragraphs field, there's a pencil icon for each one, and clicking it produces a more sane result confined to just that paragraph.

jeroen.b’s picture

Ah okay, cool. Didn't know it was that simple.

miro_dietiker’s picture

Sounds awesome.

Quickly checked the code, did no UI test yet. It "only" covers the case of a paragraph field on a node. Not general content entities.
I would love to see individual issues to cover these steps forward.
We need to check what the status of JS test coverage is of testbot now. We really need this.
Also there is zero test coverage. Even if we don't do JS tests there are things we can easily cover.

Is there anyone who can pick the task and start bringing some stuff back to Paragraphs?
I think if it's just native support for quick edit, we don't need it to be a separate module. Any opinions on that?

jeroen.b’s picture

I think it should be in the Paragraphs, no good reason to have a weird quick-edit experience in a default Paragraphs install.

jonathanshaw’s picture

Paragraphs_edit doesn't support nested paragraphs at the moment, just gives a quick edit icon for the top-level paragraphs. Given that quick edit is likely to be a part of future UI improvements, we probably want to make sure that the architecture adopted at least leaves the way open to cleanly extend quick edit to nested paragraphs in the future.

rgpublic’s picture

Hm, don't know if anything changed since @jonathanjfshaw tested this, but I'm currently using paragraphs_edit with nested paragraphs and it seems to work perfectly. It is indeed showing me a pencil icon for the "inner" (i.e. deeper-nested) paragraphs. paragraphs_edit is really great BTW. I've only discovered the module today, unfortunately, reading the comments here. The user-experience is just so much better than without it. A huge step forward. This is why I'd second the idea to integrate this in the main paragraphs module.

jonathanshaw’s picture

Strangely, when replying to #2698449: Missing save button in quick edit the creator of Paragraphs_edit mentioned that he didn't even have quick edit in mind when creating the module. He must have unknowingly fixed quick edit as a side effect of something else.

miro_dietiker’s picture

Issue tags: +Usability
Alexandre360’s picture

Any progress about nested paragraphs support ? Cause it's one of the most useful feature of paragraphs...

jeroen.b’s picture

@Alexandre360 did you test it? Since it's working according to @rgpublic.

miro_dietiker’s picture

Title: Integrate more nicely with quick edit » [META] Integrate more nicely with quick edit
Priority: Normal » Minor

Metaizing this issue for the Quick edit part.

Note that we discussed Quick edit at the recent sprint.

None of the participants use quick edit in production.
Quick edit has some real life problems that really hurt and limit its usabe:

So while this would be an awesome WOW demo, we decided not to make it a priority, thus lowering the issue severity.

I'm still happe to move forward here if someone takes the lead.

jonathanshaw’s picture

The quickedit docs say that"Formatter definitions can use 'disabled' to explicitly opt out of in-place editing."

If it's frequently something sitebuilders want editors to not use, one possibility is for the paragraphs formatter to disable quickedit; or have it as a configurable opt-in.

miro_dietiker’s picture

I'm not saying we want to disable it. We would want to integrate more nicely with it.
But it's not on our priority list.

If you think disabling is best until we have better integration, we can also do that.

jonathanshaw’s picture

My suggestion would be leave it as it is. If someone really dislikes having it available for their editors, let them be the one to make a simple patch that creates a formatter setting that allows disabling it.

Wim Leers’s picture

Quick editing items that are processed while rendering, pollutes the source with rendered text.

This is not true. See _getUntransformedText in core/modules/editor/js/editor.formattedTextEditor.js.

No add button

Well, you can change that: write your custom in-place editor plugin that provides a nicer experience: \Drupal\quickedit\Annotation\InPlaceEditor.

miro_dietiker’s picture

Thank you for your response. I'm happy to receive feedback of quickedit supporters and i really hope we can improve it and proof that quickedit can be helpful. :-)

This is not true.

We tested this and i'm reporting the facts of our results here. So it seems it needs some integration. Reproduction was as simple as enabling URL filter to the filtered HTML text format.

Add button: I'm happy we have some direction and i still hope someone gives it a shoot.

Wim Leers’s picture

We tested this and i'm reporting the facts of our results here. So it seems it needs some integration. Reproduction was as simple as enabling URL filter to the filtered HTML text format.

Can you then please file a bug report against quickedit.module? :)

Quick analysis: \Drupal\editor\EditorController::getUntransformedText() does:

$editable_text = check_markup($field->value, $field->format, $langcode, array(FilterInterface::TYPE_TRANSFORM_REVERSIBLE, FilterInterface::TYPE_TRANSFORM_IRREVERSIBLE));

i.e. it performs all filters except those of those two types. However, \Drupal\filter\Plugin\Filter\FilterUrl has as its type type = Drupal\filter\Plugin\FilterInterface::TYPE_MARKUP_LANGUAGE… which means it doesn't get skipped. This was introduced in #1886566: Make WYSIWYG editors available for in-place editing. There hasn't been any discussion about that, so either nobody understood it, or it was deemed correct.

So I think you're right, this is broken, but it's not yet clear to me what the correct fix is.

alozie’s picture

I'm testing Paragraphs with Quick Edit and encountered the "missing save button" issue. Opening the browser's inspection console while attempting to use quick edit with a paragraph field I got the following javascript error message:

Uncaught AjaxError:
An AJAX HTTP error occurred.
HTTP Result Code: 200
Debugging information follows.
Path: /quickedit/form/node/1/field_test_parafield/en/full
StatusText: OK
Fatal error: Call to undefined method Drupal\quickedit\Form\QuickEditFieldForm::getEntity() in /Users/alozie.nwosu/projects/afndev/docroot/sites/all/modules/contrib/paragraphs/src/Plugin/Field/FieldWidget/InlineParagraphsWidget.php on line 1115

The "offending" line in the InlineParagraphsWidget.php file defines the $entity variable below:

public function massageFormValues(array $values, array $form, FormStateInterface $form_state) {
  $entity = $form_state->getFormObject()->getEntity();

It looks like paragraph does not expect to invoke getFormObject() in the context of the QuickEditFieldForm leading to the fatal error above.

yobottehg’s picture

Theres another promising Module here :

mortendk’s picture

its a real real big shame that paragraphs isnt supporting core functionality like quick edit. Right now imho paragraphs biggest issue is that its hard to edit after the content is build in. If you look at if from the perspective of the enduser (not developer, sitebuilder or themer) then the edit experience is moving fast towards "your locked in you can now just edit your content" - but unfortunately paragraphs isnt supporting this atm :(

i dunno what i can do to help out with this as my expertice is on the theming end but lemme know how i can help out pushing for this to happen :)

... and nope quickedit isnt a "demo" its a game changer for users of drupal :)

DamienMcKenna’s picture

Drupal core 8.2 now has a third UI of editing something - the Settings Tray. So now we have:

  • The normal entity Edit functionality
  • Quick Edit
  • System Tray
  • 3rd party options like Geysir that provide a modal dialog.
killua99’s picture

Why we don't merge the Casey code into Paragraphs?

Someone has contact Casey and expose that would be nice to merge his code into paragraphs (as a sub-module or main feature) and add support for entities that contains paragraphs, not only Nodes.

Would be that a good idea?

miro_dietiker’s picture

If i remember right, i was in contact with Casey and provided feedback about how this best could end up in Paragraphs.
First, we need full test coverage of all relevant processes.

Keep in mind, everything we add to our repo adds duty for maintenance and stability as many people build on top of what we provide.
That's why we proposed to bring in the functionality step by step. Lots of the things it introduces should be default behavior and not a separate module.

miro_dietiker’s picture

Issue summary: View changes
91.92 KB

Uploading the image from our presentation.

We should create individual issues for the doable non-meta items.

miro_dietiker’s picture

Issue summary: View changes

I have created the individual issues identified until now.

Wim Leers’s picture

Adding a new field type-specific in-place editor is totally possible. That's exactly what we did for image fields in #2421427: Improve the UX of Quick Editing single-valued image fields. Note we're (FINALLY!!!!) adding functional JS test coverage for Quick Edit at #2828528: Add Quick Edit Functional JS test coverage. Once that's in, writing test coverage will be a whole lot easier.

miro_dietiker’s picture

Awesome, Wim, we please keep us updated about this progress and how we can best build on top of it.

On our side, we have no resource directly dedicated to these steps, but it would be great to find someone that can focus on it and offer mentoring to guide through this process.

@Wim We could pick it up in february and make it a milestone goal for the Sprints at and it would be awesome if we have an expert join for mentoring? Are you available? :-)

miro_dietiker’s picture

Been testing paragraphs_edit and the reason why quickedit works better is that the each paragraph entity gets its editable context. This allows exposing a quick edit action on every paragraph entity.

However, this doesn't allow us to edit the host entity with quickedit and then edit fields inside a paragraph.
Also, nesting is not covered.

What we want instead is enabling quickedit in context of the host and having all children fields (including nested ones) editable.

muranod’s picture

@alozie I just encountered the same issues as in #29 - opened content in quick edit and the paragraphs expanded to cover the save button so it could no longer be accessed. Nothing would happen by clicking the X in the paragraphs display either. Fortunately, I had only made a minor change which was easy to do again. My new site is only in staging while I decide how to incorporate Paragraphs for future content.

nonAlgebraic’s picture

Here's a patch that (crudely) fixes the issue raised in #29

TrevorBradley’s picture

Patch #41 didn't work for me, because ParagraphsWidget.php similarly needs to be patched. (Not just InlineParagraphsWidget.php). I was still getting AJAX errors on node edit pages. I copied @nonAlgebraic's code into the head of ParagraphsWidget::massageFormValues and it seems to work there too.

This isn't the right patch either, but it moves the ball further down the field.

(I notice that the patch doesn't allow me to create new Paragraphs in QuickEdit, for instace)

RajeevK’s picture

I wasn't able to apply patch of comment #42. Attaching a clean patch for same code.

Status: Needs review » Needs work
RajeevK’s picture

Status: Needs work » Needs review
3.04 KB

Attaching another patch with namespace inclusion.

miro_dietiker’s picture

Status: Needs review » Active

This is a meta issue. Please don't upload patches here.
If you try to solve specific problems, create an issue with clear limited scope.
The meta issue will list the individual step-by-step issues and once all are solved, we can close the meta.
A meta is typically parent issue to all those step issues.

Also please note that we need test coverage for each step to proof achievements and keep them safe with continuous improvement.

Anybody’s picture

What's the general priority of this plan?

miro_dietiker’s picture

As you can see from the priority it's "minor". People like the idea, but the amount of needed (minimum) work turned out to be way more than anyone wanted to invest in time and money.

Happy to change priority here if it turns out this situation changed.

nikathone’s picture

I am wondering if the work at shouldn't be ported here or close this issue in favor of using/improving that module. I tested it and it seems to do the trick.

miro_dietiker’s picture

@nik please carefully read the thread about this topic, maybe update the issue summary if it is not clear. Specifically checkout my comment #2476863-14: [META] Integrate more nicely with quick edit and all the related replies in thread.

Simply said: yes please. Let‘s do it, but if you want to bring functionality into Paragraphs, there is so much more to care than „i tested it and it seems to do the trick.“. It‘s about many days of missing work, the scope is pretty clear since 1.5 years, and as long as no one is addressing it / investing into a fully mature solution, there is no progress at all. Even worse, the more discussion, the more time is wasted.

miro_dietiker’s picture

It seems there is some overlap of quickedit with the settings tray. Let's investigate first how we use the settings tray:
#2942364: [META] Investigate adoption of outside-in settings tray