Support separate paragraph item editing with contextual links

Nice!
Can you change paragraphs_item_access("update",$paragraphs_item, $user, 'paragraphs_item'); to paragraphs_item_access("update", $paragraphs_item, $user, 'paragraphs_item');?
Can you also use single quotes everywhere?

Also, I think you should also update the host entity to point to the new revision?

I think it's good to use the same behaviour as in the normal widget.
See: http://cgit.drupalcode.org/paragraphs/tree/paragraphs.module#n607

This reminds me to the issue that happened when we tried inline editing yesterday...

As a user you would expect that inline editing allows you to edit a single paragraph. Instead you edit the entity reference, showing all paragraphs at the same time as editable widget. OK, a separate issue, but feels kindof related to this contextual editing.

Hope there are no clashes of these two functionalities here?

1. +++ b/paragraphs.module
   @@ -9,6 +9,7 @@ define('PARAGRAPHS_DEFAULT_TITLE', 'Paragraph');
   +define('PARAGRAPHS_DEFAULT_SEPARATE_EDIT', false);
   

   I'm struggling here...

   If the contextual links are an appreciated concept that fit well, we should have them enabled by default.

   But it completely changes edit experience as of now. So default is no option.

2. +++ b/paragraphs.module
   @@ -315,6 +316,24 @@ function paragraphs_menu() {
   +  $items['paragraphs/%paragraphs_item/edit'] = array(
   

   This is bringing us much more near to having routes per paragraph. For now this was avoided including the fact that a paragraph can not be displayed on its own.

3. +++ b/paragraphs.module
   @@ -1264,3 +1290,88 @@ function paragraphs_bundle_copy_info() {
   +function paragraphs_separate_edit_access($paragraphs_item){
   

   We might want to allow access this edit URI only in case the setting in the field is enabled.

4. +++ b/paragraphs.module
   @@ -1264,3 +1290,88 @@ function paragraphs_bundle_copy_info() {
   +  if(!is_object($paragraphs_item)){
   +    if($paragraphs_item){
   ...
   +    }else{
   

   Codestyle... Please check all code with coder.

The attached patch improves on the patch in comment 6 above in the following ways, as raised above:

1. Code style issues fixed
2. Removed unnecessary/unwanted menu router item 'paragraphs' and related code
3. Access to the separate form is only granted if the setting is enabled.
4. PHP notices on submission of the separate form fixed ($form_state was not being modified by reference so field state data was not set)

To address some of the remaining issues...

@jeroen.b (comment 7) ... the normal widget behaviour is determined by whether the editor has decided to create a new revision or not for the host entity. But if they are editing a paragraph on its own in this separate page, $entity->revision does not itself exist. Nodes have a default setting for whether that would be set to true/false initially (and permissions to determine whether editors can override it for a certain edit). But that can then be different for every entity type, so it's not so simple.

@miro_dietiker (comment 8) ... Since contextual links could start appearing all over the place, I don't think it's a bad thing to default this new setting to be initially disabled. In core, there would usually only be a few contextual links on any page. But paragraphs increases the potential quite significantly, possibly crowding the UI too much for editors. Plus enabling it by default might require updating existing field instances in an update hook so that they would be consistent with new field instances, which feels unnecessary.
Routes per paragraph can continue to be avoided for now - which is why I've removed the 'paragraphs' item in paragraphs_menu() in the patch, and implemented the contextual links in a more bespoke way, since they would normally rely on a root path. If a root path is explicitly to be avoided (at least for now), then 'normal' contextual links wouldn't make sense. Hopefully that explains why I've gone down that route (no pun intended!) in this patch.

@StryKaizer (comment 9) ... are there specific issues you could list? I've done what I can to fix what I could see, as I wanted to use this functionality. I'd be very keen to know if there are other issues you're aware of?

Sorry, I got an access check wrong after re-factoring, this patch is better :-)

Hej, thanks for the Patch! I Just did some first tests, I needed to add

print render($title_prefix);
print render($title_suffix);

to the paragraophs_item.tpl.php to get the contextual menu working, as the html for it is injected via $title_suffix. Did you use a custom template or is there a better way to get the html injected?

Attached you can find a patch which works with vanilla drupal7. I'm going to test more in the next days.

Patch works fine for me!

Since we are now checking the host entity inside paragraphs_item_access we can change the following line:

return !empty($instance['settings']['separate_edit']) && entity_access('update', $host_entity_type, $paragraphs_item->hostEntity()) && entity_access('update', 'paragraphs_item', $paragraphs_item);

to:

return !empty($instance['settings']['separate_edit']) && entity_access('update', 'paragraphs_item', $paragraphs_item);

When editing a paragraph using a contextual link and you have workbench moderation enabled, there are couple of issues:

Editing a paragraph of the currently published node

1. You shouldn't be able to to that, is it breaks the workflow set up
2. OR a message should appear saying a new revision will be created upon editing the paragraph

Editing a paragraph in general

When saving changes, the host entity gets unpublished.

Found the solution to the problem with the host entity being unpublished. In the function paragraphs_form_submit(), the call of the save() method has to have parameter one set to TRUE ($skip_host_save). Will attach new patch ASAP.

Here's a re-rolled version of the patch from comment 11 above, since the access callback on the separate form page no longer worked after the latest commit to paragraphs, which stopped loading host entity details.

I did not make any changes to the template, since I was trying to be conservative in what I changed, and it's quite possible for themes to do that themselves. I could believe I'm being too conservative there, I'm not sure.

I created a new patch starting from comment 18, including the fix discussed in comment 17.

@james.williams, I think you re-rolled from the wrong comment: comment 12 has the addition of title_prefix and title_suffix in the paragraphs-item.tpl.php file. This is necessary for the contextual links to work. I created a new patch containing the changes made in comment 12.

I'm am currently working on extending the patch to also support the deletion of separate paragraph items + insertion of new paragraphs in between existing paragraphs using contextual links. Will post these extensions to the patch ASAP.

@vollepeer I think @james.williams was going for minimal UI changes, as we're adding the contextual links in a theme, but yeah, you're right, this really should be in the module itself, especially as there's a way to hide the links anyway on each field's config.

Additional contextual links for delete and insert sounds amazing!

It makes sense that if, when our host entity has revisioning enabled by default, we save a new revision of our host entity. To make that happen, we need to replicate the 'Create new revision' option as used on the Node form, set its default value according to our host entity's default value, and then make sure that we revision accordingly.

Here's a patch that achieves that :)

On the way, I've also corrected some whitespace and changed one of the access callbacks to use the new paragraphs_paragraphs_item_access check.

I have finished a first (highly experimental) addition to the patch allowing both deletion + adding paragraphs (like described in comment 21). The new patch does not contain yet the changes from comment 23 -> TODO.

The code still needs a lot of refactoring and testing at this point, but it would be nice to get some early feedback already about the concepts in there.

Caveat emptor: I'm no Drupal expert... but I was a bit impatient so I just gave patch #24 a roll. I found the following problems:

1) Some content on my website vanished as soon as I enabled the patch. I found this is due to "if (!isset($item[0]['value']))" in "paragraphs_field_prepare_view". Some of my items only have $item["und"][0]["value"] for some reason. Couldn't figure out if this is due some i18n stuff or due to some paragraphs contain image fields or even sth. else. Perhaps you might want to reconsider this check, though.

2) I somehow cannot create new paragraphs. The whole process (contextual menu => Following page appears => Save => Back to original page) works but no new paragraph appears :-(

3) The following warnings appear on every page:

Notice: Undefined property: ParagraphsItemEntity::$type in paragraphs_contextual_links_add() (Zeile 1801 von /var/www/developer/epos-services.com/htdocs/sites/all/modules/paragraphs/paragraphs.module).
Warning: Invalid argument supplied for foreach() in paragraphs_contextual_links_add() (Zeile 1802 von /var/www/developer/epos-services.com/htdocs/sites/all/modules/paragraphs/paragraphs.module).

Tried the patch #23 - so far so good! Getting an error on the field manage display though:

Notice: Trying to get property of non-object in paragraphs_paragraphs_item_access() (line 264 of /var/www/act/www/sites/all/modules/contrib/paragraphs/paragraphs.module).
Notice: Trying to get property of non-object in paragraphs_paragraphs_item_access() (line 282 of /var/www/act/www/sites/all/modules/contrib/paragraphs/paragraphs.module).
Notice: Trying to get property of non-object in paragraphs_paragraphs_item_access() (line 287 of /var/www/act/www/sites/all/modules/contrib/paragraphs/paragraphs.module).
Notice: Trying to get property of non-object in paragraphs_paragraphs_item_access() (line 288 of /var/www/act/www/sites/all/modules/contrib/paragraphs/paragraphs.module).
Notice: Trying to get property of non-object in paragraphs_paragraphs_item_access() (line 299 of /var/www/act/www/sites/all/modules/contrib/paragraphs/paragraphs.module).
Notice: Trying to get property of non-object in paragraphs_paragraphs_item_access() (line 264 of /var/www/act/www/sites/all/modules/contrib/paragraphs/paragraphs.module).
Notice: Trying to get property of non-object in paragraphs_paragraphs_item_access() (line 282 of /var/www/act/www/sites/all/modules/contrib/paragraphs/paragraphs.module).
Notice: Trying to get property of non-object in paragraphs_paragraphs_item_access() (line 283 of /var/www/act/www/sites/all/modules/contrib/paragraphs/paragraphs.module).

I think this would be great for the Drupal 8 version as well. Content editors who usually work from the front-end of a website (using contextual links or quick edit), are somewhat stuck with Paragraphs as they have to edit the page and dive into a (deeply) nested paragraph to alter a single line of text.

It would be much easier if they could just edit a certain paragraph directly from the front-end. Either through contextual links and seperate edit pages for paragraphs, or through an improved quick edit (there's already an issue for that I saw).

(+1) I'm currently working on our first D8 website for a customer and the experience so far has simply been nothing but great. Almost no bugs, decent object orientation, many things that IMHO were not so great in D7 (like menu system etc) are solved and/or cause much less unwanted surprises than in the previous version. Big kudos to everyone involved!

The only thing I'm really missing very, very much is the separate item editing patch. I think this should even be a default feature one day without any patching. It is so important if you want to offer your customers (i.e. content editors) a usable UI. Keeping my fingers crossed this will be implemented soon...

#24 works flawless. But I think Edit should go first, and Delete after. Like in contextual links for nodes.

+1 For getting this into the Drupal 8 version as well, it's a great feature!

#24 doesn't work for me.

I have a quite complex paragraph system with paragraphs inside paragraphs, don't know it it can enter into consideration but I don't see any contextual links.

I can confirm that patch #24 works.
However "Add paragraph" contextual links do not show up if no paragraph bundles are selected. The quick fix is to select any/all the paragraph types in the paragraph field settings. The following code covers this case. I can update the patch if needed.

    // paragraphs.module line 1796
    $field_info = field_info_instance($entity_type, $field_name, $host_entity->type);

    $selected_bundles = array();
    // Check the selected paragraph bundles and create an array with them.
    foreach ($field_info['settings']['allowed_bundles'] as $selected_bundle_key => $selected_bundle_value) {
      if ($selected_bundle_value == $selected_bundle_key) {
        $selected_bundles[] = $selected_bundle_value;
      }
    }
    
    // If no bundle is selected, all the bundles will be available.
    if (empty($selected_bundles)) {
      $selected_bundles = array_keys($field_info['settings']['allowed_bundles']);
    }
    
    foreach ($selected_bundles as $allowed_bundle) {
      if ($mode == 'scratch') {
     // bla bla and the code goes on

We should also fix this :

    // paragraphs.module line 1624.
    // Overwrite the paragraph field + save the host entity
    $host_entity->field_paragraphs['und'] = $paragraphs;
    entity_save($host_entity_type, $host_entity);

with something like this :

    // Overwrite the paragraph field + save the host entity
    $field_name = $paragraphs_item->field_name;
    $host_entity->{$field_name}[LANGUAGE_NONE] = $paragraphs;
    entity_save($host_entity_type, $host_entity);

But we also have this https://www.drupal.org/node/2452675
So depending on how language is handled, we'll have to correctly set the paragraph field values.

A merged patch of the patches in comments 23 and 24 is coming very soon, I'm told, so work can pick up again, to incorporate changes since then. Go Nathan! ;-)

I also just wanted to point out that the patch in comment 23 has some code specific to nodes, whereas other revisionable entity types (e.g. beans) should probably be handled too. We could have some more entity-type-generic code that handles that...

Here's the aforementioned patch, smushing #23 and #24 together. (Interdiff based from 20 + 24, adds 23)
Hopefully I'll have time to make some of the other suggested changes soon, too.

Here's #35 with the additions suggested in #32 and #33.
Still need to handle #33 super-properly though.

That's a huge amount of code ad the paragraphs widget are already so much spaghetti due to all the variants and settings. I would prefer to maintain this complexity in a separate module if it is easily possible?

@miro_dietiker - I see your point, yes, it would be ideal to keep it simpler & more maintainable. If I'm following what you said, I think you feel there would be too much complexity introduced to the field formatter? (There are no changes to the field widget form, so I'm guessing that's what you meant by 'widget'? The following may be going off in the wrong direction if I've misunderstood you, sorry!)

However, the original intention of the ticket appeared to be just allowing editing paragraphs in their own form, via contextual links. Doing just that would also achieve feature parity with field collection. That's not worth doing just for the sake of it, but it is well worth doing given how paragraphs are being used in the real world; as individual building blocks, for example (among many others):

http://www.webwash.net/drupal/tutorials/how-create-powerful-container-pa...
https://www.computerminds.co.uk/drupal-code/building-site-content-paragr...
https://www.commercialprogression.com/post/paragraphs-are-drupals-answer... (which even refers to a separate paragraphs_formatters module

So that in itself would be a very strong piece of functionality to have in core paragraphs. That corresponds to what was done in the patch in comment 23.

The patch in comment 24 added functionality for inserting paragraphs in-place, which is where the complexity to the formatter was introduced. I would suggest that that part, as useful as it is, is the part that may be better to keep out of core paragraphs, keeping that more maintainable. That is very useful functionality, but goes above & beyond the original intention of this ticket and beyond feature parity with field collection. The patch in comment 24 also allowed deleting paragraphs in-place, which is much simpler, doesn't involve changes to the formatter, and is also supported by field collections, so I'd suggest having that in the core of paragraphs.

So, in summary, what about having contextual links & forms for editing & deleting paragraphs in the core paragraphs module? Then the inserting paragraphs in-place functionality could go in a separate module (perhaps the paragraphs_formatters module linked to above, if that got moved onto d.org)? That ensures the key functionality is added without introducing further complexity to the already-complex part of the module that you were concerned about.

What do others think? I don't want to just be suggesting purely due to my own interest & use case, I hope it's a sensible suggestion for everyone! (And to allow this issue to advance rather than getting stuck on trying to do everything, as it already covers more than one piece of functionality.... maybe a different way forward would be to split out each part of functionality into child tickets and decide which parts should go into core paragraphs separately?)

Oops, broke a couple of things in that merge. This should rectify things.

BUT it would be good to clarify #38 before moving on too much further.

Regardless of how issue queue is organised, I just want to point out the huge impact this features will have on content editors.

As soon as we'll have a direction, code could be better organised. For example all this new forms should be included in separate file.

Thanks both for your responses. It's been two weeks, so I've made a start to get this unblocked. #2715833: Delete/insert paragraphs with contextual links has been opened to represent the good work started by vollepeer from comment 24, in order to restrict the spaghetti complexity of the change. As suggested in comment 38 above, this will then allow the original intention of this ticket to be advanced here instead, without the 'above & beyond' of handling inserting/deleting paragraphs. So the basics of contextual links and editing paragraphs on a separate form can be handled here, which does not add to the complexity of the existing formatter widget. Hopefully that addresses miro_dietiker's concern in comment 37!

I've updated the issue summary too to reflect the current state of things, including a list of things to address that have been raised. So, patch to follow here, based on the one from comment 39, with all other concerns raised so far included, but now keeping to the original issue.

OK, here's a revised patch, which:

• Contains the separate edit work from patch 23
• Does not contain the separate delete or separate insert work from patch 24
• Has the new reform placed in the admin.inc file, as suggested

Things remaining:

• Handle other revisionable entity types (e.g. beans) by making our revisioning code more generic.
• Check nested paragraphs work okay.
• Check we've handled language sufficiently.

Setting to "needs review" so it'll go through patch review.

Didn't we have this discussion recently in a different issue around 8.x-1.x?

Totally fair enough. The work that's been done for 7.x-1.x has been great so far, it's nearly there so just needs a little push to get over the line, it's not far off.

So as we (Nathan & I) are working on it here anyway, we'll look to finish the 7.x patch, even with the expectation that it won't be committed to the module, but that it ensures we're all happy with the workflow/UX/approach, as much of the work that's been done so far is already in use on production websites anyway. That also ensures a fully working patch will be available sooner, as it will take longer to make progress for 8.x.

Then once the 7.x patch has been finished off, all our effort can go into making an 8.x version.

Unless anyone else has resource to get going straight away on 8.x of course, as they would be very welcome! We just haven't had too much 8.x experience yet, so are trying to limit our unknowns where we can. We're looking forward to jumping in!

Nested paragraphs working OK with patch #43
Crossed off some to-dos from the summary.

I think what @miro_dietiker might be remembering in #47 is that there is already a 8.x paragraphs_edit contrib module which aims to offer contextual links for editing. The module's page does not explain its purpose, but we discussed it with the maintainer here: #2698449: Missing save button in quick edit

Ooh! So, could paragraphs_edit (once standardised and tested etc.) be included in paragraphs module as the D8 solution for this issue? Where/how might we best discuss that?

A good start would be for someone to document how to use paragraphs_edit. The creator gives a hint about how the module works in the issue i linked to, but there's no full explanation of features or setup and no screenshots.

@amoebanath and we will not simply include the module paragraphs_edit. If you read the individual related issues, you see that we need clean minimalistic solutions per problem we want to solve. We need to agree about each approach and implementation. And we need nice test coverage for everything we add.

This is a lot of work, but UX and UI improvements will be the major focus once a first stable release is out. I'm pretty sure we will progress quickly with all the help from the community. :-)

Hi @miro_dietiker - thanks for the clarification, that's understandable. So even if we did get to having a completed patch for D8, with full test coverage, would you actually want any of this functionality in the 'clean minimalistic' core paragraphs module? If not, then we're clearly heading in the wrong direction and we need to move our focus over to paragraphs_edit anyway.

Sorry that we've skipped that more conceptual discussion around what the vision for paragraphs is and jumped straight into just trying to implement the ideas! Is this the place to have that discussion, in order to agree about approach and implementation?

By reading the title, you ask for support of contextual links. Also i see the patch is limited to the relevant pieces and not a full clone of the paragraph_edit complexity.

Note that i won't commit this to Drupal 7 as i'm not maintaining that branch. You would need feedback from jeroen.
For Drupal 8, i would like to add an equivalent as part of paragraphs main module once we have it and test coverage is provided.

remove

wrong manipulation :/

#43 did not apply cleanly to latest Paragraphs dev. I had to manually add in the code that did not apply correctly.

I have edited each paragraph field and made sure the checkbox to allow it to be edited via the contextual menu is enabled.

I checked that there were no required permissions, cleared my cache and ran update.php but I still dont see contextual edit links for each paragraph when I view a node on the frontend.

Can anyone tell if I am missing a step or has anyone had a similar experience trying to use this?

Thanks
Gregg

After replicating this on a clean drupal 7 site - it seems there are still issues with the contextual links showing on nested paragraphs and in particular when there is more than one paragraph field on a content type it seems to break. I had a column one paragraph field and a column two paragraph field and the items in column one showed contextual edit links while the items in column 2 did not.

Drupal 8 module (experimental) which allows managing paragraphs from the front-end: https://www.drupal.org/project/geysir.

@iaminawe I had the same problem where the patch failed, and I manually patched it, and then I used replace on the '+'es which deleted a bunch of pluses it shouldn't have in paragraphs_contextual_links_view_alter changing several "+=" into "=".

For example:

$links[$class] += $item['localized_options'];

was turned into

$links[$class] = $item['localized_options'];

which of course meant the link didn't have a title or href attribute anymore so it never showed up.

Patch in #43 works.

Sidenode: When the paragraph is overwritten with entity-views-attach the dropdown let's only edit the view but not edit the paragraph. But other than set: great stuff! thx!

Just a re-roll of patch in #43 so it applies to the latest 7.x-1.x

On that, I notice this issue is still marked as for 8.x, but the patches are all for 7.x… am I missing something?

@stevetweeddale - see comments 47 & 48. Patches are supposed to be for 8.x, but the work had originally been done for 7.x and no-one has provided any attempt at a 8.x patch yet.

Thanks, this is really useful! I found this issue right now and this module came to my mind

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

I like the approach of ajax_form_entity, is not a contextual link, work like a field so you can place the link anywhere in the display and edit inline without leave the page, I don't know if is possible and ease add Paragraphs to make it to work like Field Collections.

The patch #63 work fine at a glance

hi @RAFA3L

Deos what you explain can work for D7 ? , with Panel ?

I have been finding since long time howe to , from a node display , add more item of paragraph without leaving the page ?

Something similar to what we do with comment ..

thanks

Hello @delacosta456, yes I use ajax_form_entity but with Field Collection, not with Panels.

Check this to add Paragraphs https://www.drupal.org/node/2715833

hello @RAFA3L

thanks for that .. but still looks that the patch is not yet ok.. right?

thanks

@RAFA3L ,

Also i just found this too Field Collection Ajax but haven't tried it

Am i going to get the same Features as if i was using Field collection + Ajax form Entity

Solution in progress :
https://www.drupal.org/node/2807125

If your paragraphs are multi language add this to show the fields in the current language when edit

function MODULE_form_alter(&$form, &$form_state, $form_id) {

  if ($form_id == 'paragraphs_form_edit') {

    $entity_type = 'paragraphs_item';
    $entity = $form['#entity'];

    list($id, , $bundle) = entity_extract_ids($entity_type, $entity);

    foreach (field_info_instances($entity_type, $bundle) as $instance) {
      $field_name = $instance['field_name'];
      $field = field_info_field($field_name);

      if ($field['translatable'] && isset($form[$field_name])) {
        global $language;
        $form_langcode = $language->language;
        $default_lang = $form['paragraphs_item']['#value']->translations->original;

        if ($default_lang != $form_langcode) {
          $element = &$form[$field_name];
          $element['#entity_type'] = $entity_type;
          $element['#entity'] = $entity;
          $element['#entity_id'] = $id;
          $element['#field_name'] = $field_name;
          $element['#source'] = $form_langcode;
          $element['#previous'] = NULL;
          $element['#form_parents'] = $form['#parents'];
          $element['#language'] = $form_langcode;
          unset($element[$default_lang]);

          if (!isset($element['#process'])) {
            $element['#process'] = array();
          }
          array_unshift($element['#process'], 'entity_translation_prepare_element');
        }

      }
    }
  }
}

latest patch doesn't work for a paragraph that has its own tpl. The setting is available in the paragraph field settings but the gear icon simply doesn't appear when viewing the node.

@Nchase add to your template :

  <?php print render($title_prefix); ?>
  <?php print render($title_suffix); ?>

I use Display Suite pretty heavily, and like with the node template this has to be present to make them appear, might work for you too.

I confirm #43 works for me using 7.x-1.0-rc5

Is there any version for drupal 9? I need the same functionality there...