Contrib.social

Paragraphs editing integration with workflow and content moderation

Open on Drupal.org →
Created on 29 January 2025, 2 months ago

I am categorizing this as a support request in case I'm just missing something and need some advice on how to use it properly. However, it could be that what I'm looking for just isn't possible yet, in which case it could become a feature request.

Problem/Motivation

We use Paragraphs extensively in our Drupal sites, such that most pages have no other fields besides the title and paragraphs fields. We have just recently started implementing and trying out this module enabling it only for the appropriate paragraphs and not the node itself. This makes for a really fantastic user experience, providing content admins with a really slick workflow for updating content. It just comes with a major caveat: when editing individual paragraphs, there's no way to preview that live before saving and when you save it doesn't create a new revision of the node itself or have any means to function with content moderation and workflow, if configured for the node.

For some clients just being able to preview first will be sufficient, but in other cases moderation may be enforced, in which case we simply can't use this module and the editors will have to use the standard node edit form in order to create a new draft to go into moderation.

Changing the order of the paragraphs (at least the first level) does cause a new revision of the node, because in that case it's modifying the paragraphs field on the node itself to change the weight of each value. However, the new revision retains the same timestamp and author as the previous revision, so when viewing the revisions for the node it doesn't make sense. You KNOW you just made a change to the page by changing the paragraphs order, yet the latest and previous revisions both have exactly the same date and time on them.

I'd really like to be able to allow individual paragraph editing via this module where doing so will allow previewing AND integration with the node's workflow state. I imagine this may not be easy to implement, given how paragraphs work vs nodes. The paragraphs module itself may not provide what's needed to be able to preview before saving and to integrate workflow could be quite a challenge. I expect it would be particularly challenging with nested paragraphs, which is also something we make use of.

Steps to reproduce

  1. Install this module and enable it ONLY for paragraph types, but not for any node types.
  2. Create a page with a paragraphs field and add a bunch of the paragraphs to that page that have frontend editing enabled for them.
  3. Make sure the node type has revisions enabled and defaults to creating a new revision when edited.
  4. View that page, turn on frontend editing and then use it to make changes to the paragraphs.
  5. Note that even if you enable ajax and previews, there is no preview button to use when editing a paragraph.
  6. Save changes to a given paragraph, then go to the node revisions and see that no new revision was created, but the paragraph was saved.
  7. In the database itself, check the paragraphs_item_field_data table and look for rows for that paragraph type where the parent_id is the node you edited and you'll see that it does not even create a new revision of the paragraph itself.
  8. Change the display order of the paragraphs in the node via frontend editing.
  9. Go to the revisions tab for the node and see that there is a new revision, but it's timestamp and author are the same as the previous revision (change the paragraphs order with a different user account than the node was created with to verify that the author does not update).
  10. If using a Workflow with the node type, set the default moderation state for the workflow to something other than published (eg draft).
  11. Change the display order of the paragraphs on the node again, then edit the node using the standard node edit functionality. Note how the current workflow state will still be published as previously, not whatever you configured as the default state.

Proposed resolution

First, please advise if I am not using the module correctly and it's just a matter of changing the way I have configured it in order to work the way I need. However, if that's not the case then I think a few things need to be done:

First, make sure any changes to paragraphs (editing a paragraph or changing order) properly creates a new revision of the paragraphs, if appropriate, and the parent-most entity, if revisions are enabled. Also make sure that new revisions have the correct current timestamp and current user set as the author.

Once that is addressed, workflows could be addressed in a couple of ways:

  • Automatic based on configured default workflow state for the parent-most entity.
    I would imagine this being the simplest, both from a technical perspective but also from a UI/UX standpoint. That way if the user is just changing the display order, they aren't any janky UI/UX problems to solve. It just saves as whatever the default state normally is and the content admins just need to be aware of that. If you configure the site to default to draft state, you can also configure the node display to show the content moderation field at the top (which is what we normally do anyway). Thus when making the changes with frontend editing and it refreshes the node content (and it should refresh the entire node content) the moderation field then appears at the top and the user understands they are now in a draft state. Editing an individual paragraph's content should do the same thing.
  • Implement a UI to let the user select the new workflow state that it will be in once they make changes.
    I can just imagine lots of issues with this, not only technically but how to make it work well for users. If all they want to do is change the order, then how do you make sure they see and interact with the UI for setting the new workflow state before they apply the change? When editing an individual paragraph, potentially a nested paragraph, the edit form in the sidebar would then also have to somehow incorporate the parent-most entity's moderation field for the user to work with. I think that's probably fine from a UI/UX standpoint, but might still be technically challenging to implement with this module.

Remaining tasks

I think this requires further discussion to determine what is or isn't viable in terms of a solution. Assuming I'm not just being dumb and missing something regarding the configuration of the module.

💬 Support request
Status

Active

Version

2.0

Component

Code

Created by

🇨🇦Canada teknocat

Live updates comments and jobs are added and updated live.
Sign in to follow issues

Comments & Activities

  • Issue created by @teknocat
  • Comment 2 months ago →
    🇨🇦Canada teknocat

    By the way, I have also tried enabling frontend editing for the node types using the paragraphs as well as the paragraphs themselves, AND enabling frontend editing for the Content Moderation State.

    If you enable the hover highlight mode then having both the paragraphs and node editing enabled is fine in terms of the UI, as they don't overlap and interfere. With that you can have a live preview, except that modifications to the paragraphs themselves (their content or display order) is not reflected in the preview.

    I also found that, with the Gin theme, if you do not expand the sidebar then the content moderation and all the other items normally in sidebar tabs on the normal edit page don't show up. If you scroll down in the frontend editing sidebar there's a big space where that would be. But that would be a separate issue to address.

    In any case, editing the entire node is currently the only way to access the moderation state and still doesn't help if you just want to change the display order of paragraphs in the page without editing the whole node.

  • Comment 2 months ago →
    🇩🇪Germany a.dmitriiev

    Hi teknocat,

    Thank you for very detailed description. It really helps to understand your needs.

    Workflow and content moderation has not yet been in scope for this project, but it would be really nice to have it. I would like to check this deeper.

    Let's first discuss what you can do now already to make your experience better:

    1. Install this module https://www.drupal.org/project/all_entity_preview → . There is a nice integration between frontend editing and it. The module allows to have the preview of your changes in the main window, while you are doing the changes in the frontend editing sidebar. This will at least help your editors to see how their changes would look like without saving the entity (paragraph or any other entity). Of course this doesn't solve all your issues but I hope it will be a good start.

    2. Regarding revisions. I am a bit surprised about no revisions for the nested paragraphs even if the node requires the revision to be created every time. This part of the functionality is provided by paragraphs_edit → module, that is the dependency of frontend_editing module. When you save the paragraph there is a service that checks whether the host entity needs revision and if yes, it creates it and then goes up to the root parent (in case of nested paragraphs) and saves the root parent (most of the times it is node). I've heard couple of times about this problem from others, so this would need more attention from my side and probably some more verification to make it more stable.

    3. Regarding wrong timestamp and author of node revision. This is also a bit complicated as it is not a direct feature of frontend_editing module, but paragraphs_edit. There is an issue https://www.drupal.org/project/paragraphs_edit/issues/2914976 🐛 Revisions log does not attribute author or timestamp correctly Needs work that should address this exact problem you have. The patch from the last comment applies cleanly on the latest version of the module, I use it in couple of projects myself. It would be nice if you could also test it and RTBC or give feedback in that issue, so that it is fixed in the upstream faster.

    Please let me know if any of the above hints help in your case. I am willing to fix the revisions problem once and forever as it bothers me a lot. Maybe then it would be good to check the integration with workflow and content moderation as well as a follow up.

  • Comment 2 months ago →
    🇨🇦Canada teknocat

    Thanks so much for the response with all the helpful information.

    I installed the patch for the paragraphs edit module and that has resolved the attribution issue. Having installed that and tested editing and saving a paragraph again, I can see it creating new revisions of the parent entity.

    I think I was just unable to tell if that was happening since it wasn't updating the date and author for the revision. Or, perhaps it was in fact not saving new revisions because of the issue with the date/attribution? I'm not sure, but in any case that one patch seems to fix both those issues for me.

    I even tested with nested paragraphs, where I just changed the order of the sub-paragraphs without editing and even that did indeed create a new revision with the expected author and timestamp on it.

    I also installed the all entity preview module and it works great! So thank you for that.

    Both of these things are needed either way and the ability to preview paragraphs will cover the majority of our use cases. Until workflow/content moderation is properly integrated, we'll just have to disable front end editing for cases where content moderation has to be enforced. At least it's easy to disable access to it for specific user roles.

  • Comment 2 months ago →
    🇨🇦Canada teknocat

    I'd just like to add that this module is AWESOME and just the thing we've been looking for to give content managers more of a WYSIWYG experience.

  • Comment 2 months ago →
    🇩🇪Germany a.dmitriiev

    Thank you @teknocat. It is always pleasant to hear such a good feedback and suggestions. I will try to check the workflow/content moderation integration soonish.

contrib.social Blog FAQ Discussions
Production build 0.71.5 2024