[META] Integrate more nicely with quick edit

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

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

https://www.drupal.org/project/paragraphs_edit

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

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

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.

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?

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.

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.

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.

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

Metaizing this issue for the Quick edit part.

Note that we discussed Quick edit at the recent sprint.
http://www.md-systems.ch/en/blog/2016-05/the-future-of-paragraphs

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

• Quick editing items that are processed while rendering, pollutes the source with rendered text.
• No add button
• We would like to see a more interactive dragging support, see also #2658694: Move a nested Paragraph across fields and nesting

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.

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.

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.

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.

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.

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.

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.

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
ResponseText:
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.

Theres another promising Module here :
https://www.drupal.org/project/geysir

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 :)

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.

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?

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.

Uploading the image from our presentation.

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

I have created the individual issues identified until now.

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.

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 https://drupalmountaincamp.ch/ and it would be awesome if we have an expert join for mentoring? Are you available? :-)

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.

@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.

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

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)

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

Attaching another patch with namespace inclusion.

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.

What's the general priority of this plan?

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.

I am wondering if the work at https://www.drupal.org/project/paragraphs_edit 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.

@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.

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

Hi
I am still having this issue with latest release?
Has there been any update?
Thanks

Maybe folks are leaning more towards Layout Builder these days? I use it where I can but I've only found it to work with really simple layouts. The paragraphs_edit module only seems to work very selectively, if at all in Drupal 9 (9.35).