[Meta] Plans for 2.x

Created on 28 March 2024, 8 months ago

Problem/Motivation

This issue is for future plans, to collect ideas. As the functionality becomes more complex and more actions are possible with frontend editing, there is room for improvement, make control of elements more flexible and understandable.

Ideas

1. Make frontend editing actions element appear on entity view display, instead of coming from hook_entity_view_alter(). This will allow full flexibility of where to show the element and where not, no need for any complex settings on what entity type, bundle and view mode to show the element. This way the user will have full control of when and where this element should be displayed.
2. Make this new actions element in entity view display configurable. Possible configuration options:
- what buttons to display: edit/delete/clone/move up/down/add paragraph before/after, etc ...
- in what form mode to use when opening the right sidebar, this can be decided inside "formatter" (calling it like this, as frontend_editing is not really a field at the moment and extra fields do not have formatters, but also how to make extra fields configurable?)
3. Add and option (third party setting) to entity reference/entity reference revisions field for "Ajax auto update", so this can be controlled per field formatter and not globally with complex exclude rules
4. Add and option on bundle settings form to enable/disable frontend editing per bundle, so that the element is not even shown in entity view display configuration page. This can be useful for admins to control what entities are allowed to be edited in the frontend, and if there are users with roles like site builder that are allowed to change entity view display can place the element in the view or not, but only if this is allowed at all. Maybe this is not needed, but for more flexible control, would be nice option.
5. Add option to add content items before or after current. This feature works for paragraphs only now, but can be also added for all entity types. Possible this should be done on entity reference (revisions) field level, the same as move up/down, these actions are more entity reference formatter options, not for the entity itself to decide. This can be added like third party option, the same as in point 3.

🌱 Plan
Status

Active

Version

1.0

Component

Code

Created by

🇩🇪Germany a.dmitriiev

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

Comments & Activities

  • Issue created by @a.dmitriiev
  • 🇩🇪Germany a.dmitriiev

    I found these modules https://www.drupal.org/project/extra_field and https://www.drupal.org/project/extra_field_plus that can be used to add frontend editing element to view display and also have configuration for it.

  • 🇩🇪Germany a.dmitriiev

    I have created branch 2.x from current state of 1.x and create proof of concept in MR https://git.drupalcode.org/project/frontend_editing/-/merge_requests/54 . This concept is based on the modules https://www.drupal.org/project/extra_field and https://www.drupal.org/project/extra_field_plus to have frontend editing action links be placed by users to view modes where they need it. It is also possible to select the form mode that will be used for the form that is opened in the sidebar. This can also be a good start for this issue https://www.drupal.org/project/frontend_editing/issues/3421150 Allow editing arbitrary fields in the frontend Active .

    I tried to cover all the ideas that were in issue description. In addition that now user can define for what view displays the frontend editing action links are displayed, it is still possible to define whether they are needed at all for a bundle of content entity type. Every bundle edit form now has "Frontend editing" tab, like for example "Simple sitemap" or "Publishing options" (for nodes). If frontend editing is not enabled for given bundle, "Frontend Editing: Actions" element will not be available in "Manage display".

    Also now changing the order of entity reference field items is not only for paragraphs, any entity reference is allowed, you can change the order of the field that references nodes, media, custom entity type (content entity type), etc. The add buttons are also now for all entity types (content entity types). Move up/down arrows and plus buttons are controlled with field formatter settings, so now it is crystal clear how to make the extra actions appear/disappear.

    I also tried to create update hooks to "migrate" old configuration settings to new format.

    Anyway this needs very thorough testing. When there is some feedback, it will be decided whether proof of concept worth it to be merged to 2.x branch and then the bugs fixing phase will start.

    • a.dmitriiev committed ea55bb11 on feature/3436684-proof-of-concept
      Issue #3436684: Allow editing field reference formatter only when...
  • 🇩🇪Germany a.dmitriiev

    I forgot to mention how to test.

    If you are testing on existing installation where frontend_editing of version 1.6.x is installed:

    1. Pull new dependencies with composer require drupal/extra_field_plus:^3.0 drupal/extra_field:^2.0
    2. Delete folder web or docroot/modules/contrib/frontend_editing
    3. Navigate to web or docroot/modules/contrib folder
    4. Clone the repository `git@git.drupal.org:project/frontend_editing.git` and then checkout this branch feature/3436684-proof-of-concept
    5. Run drupal updates
    6. Check that your previous settings from frontend editing are still working, but in bundle edit form, manage display has "Frontend editing: actions" extra field, ...

    If you install frontend_editing for the first time in the project:

    1. Pull new dependencies with composer require drupal/extra_field_plus:^3.0 drupal/extra_field:^2.0 drupal/paragraphs_edit:^3.0
    2. Navigate to web or docroot/modules/contrib folder
    3. Clone the repository `git@git.drupal.org:project/frontend_editing.git` and then checkout this branch feature/3436684-proof-of-concept
    4. Install the module

  • 🇩🇪Germany breidert

    When testing the feature branch on an existing installation you also need to enable the new modules.

    After replacing the code with the code from the feature branch I had to execute the following commands:

    composer require drupal/extra_field_plus:^3.0 drupal/extra_field:^2.0
    drush en extra_field_plus
    drush updb
    

    After this the update runs without error and the new functionality shows correctly.

  • 🇩🇪Germany breidert

    Here are screenshots of the configuration I have.

    For an existing paragraph with three fields I added a new form mode called frontend_editing that only contains one of the fields. After selecting this form mode in the display, I correctly can only edit the configured field.

  • 🇩🇪Germany breidert

    Configuring reference fields also works.

    Paragraph reference:

    Media reference:

    Make sure the entity types and bundles you are configuring are enabled.

    • a.dmitriiev committed aebf03a3 on feature/3436684-proof-of-concept
      Issue #3436684: Allow editing field reference formatter only when...
  • Status changed to Needs review 7 months ago
  • 🇩🇪Germany a.dmitriiev

    I merged all changes from 1.x branch to 2.x. Brief check was ok, but it might be some more regressions.

  • Status changed to Fixed 7 months ago
  • 🇩🇪Germany a.dmitriiev

    It was decided not to use bundle form for controlling frontend editing status, as not all content entities have bundles. So the setting is still in frontend editing settings in admin UI on a separate page. This allows to use frontend editing on non-bundle entities.

    The changes were merged to 2.x and 2.x-dev release was created.

  • Automatically closed - issue fixed for 2 weeks with no activity.

  • 🇵🇰Pakistan ugintl

    Does it work well with layout builder?

  • 🇩🇪Germany a.dmitriiev

    @ugintl please specify what exactly you would like to do with frontend editing while using layout builder? At the moment, if you use in layout builder the field that references other entity - you can edit that referenced entity, including custom blocks.

    I would like to add the support of layout builder, but it would be nice to know what are the needs of users, what are the requirements. Several questions were asked about this, but till now I have no clear picture what exactly is needed.

    If you are interested, please create a new feature request and described what would you like to have? That would help a lot.

Production build 0.71.5 2024