🇩🇪Germany @a.dmitriiev

Re-rolled patch for Drupal 10.3, still tests are not fixed.

@rsnyd, I think multiplier is a leftover of my custom code, as the module was copied from solution where there is also people count and quantity is multiplied in case it is a ticket for couples, family, etc.

MR was merged

For product type that should have the stock per product you should have these fields:

Manage form display page has these 2 fields with corresponding widgets:

On Stock configuration page the settings are:

See setting for product variation "Side event".

As stock management is local, you need also to create location here `/admin/commerce/commerce_stock_location` of any type from here `/admin/commerce/config/commerce_stock_location_type`

No settings on product variation type are needed.

Then you can manage stock on product page (not product variation):

And when you fill the field "Stock level adjustment (all languages)" with 10, to increase the stock on 10 items, and save the product, it will be displayed like this afterwards:

a.dmitriiev → created an issue.

In version 1.x there is no way to control in UI for what view displays the frontend editing is shown and for what it is not. You can only do it with a hook, like it is described here https://www.drupal.org/project/frontend_editing/issues/3428005#comment-1... 💬 Hiding the Front End Editing containers on particular blocks in v1.60x Fixed . If your widget uses special view mode for the preview you can exclude it in the same hook as for ptoc view mode.

If not, in the same hook you can check whether the page has admin context or not with condition like:

function YOUR_MODULE_fe_allowed_bundles_alter(array &$bundles, array $context) {
  if (\Drupal::service('router.admin_context')->isAdminRoute()) {
      unset($bundles[$key]);
    }
}

When you edit media through frontend editing, it is not opening the node form with referenced media, it opens only the media edit form. It is the same as if you would open the media/123/edit page (where 123 is the media id, that you are editing). Of course in this case there is no way to update the parent entity, as if you go to media/123/edit and do changes to it, it doesn't update all the nodes, that reference that entity (and not create revisions too).

When you edit paragraph, it is a bit differently, as paragraph itself on its entity level has the reference to the host entity that contains this paragraph, that is why it is possible to trigger the update for the host (parent) entity as well, when paragraph is updated.

It could be a feature request, to trigger the revision creation for parent entity, when media is updated (in case media reference is a direct child of node via entity reference field). I will check if this is possible to implement. But for the article that is referenced through view reference, that might be not possible at all.

if having a content type let's say 'page' , having a paragraph entity ref field, having a view ref field displaying a list of content, let s say 'articles' with their respective fields.
when using front editing here to edit the article, the article is revisioned, but the page is not.

The parent page is not connected with the article that is revisioned by view reference field in any way, so it is not possible that frontend editing knows that parent page needs revision. I am not sure that this is also possible when using the backoffice in normal Drupal UI. Parent page has its own revisions, article referenced with view has its own revisions, and those both revisions are not connected in any way. Please explain how you see this connection? If in your case the backoffice creates revision anyway, please describe what widgets are you using?

if having a content type , lets say 'article', having a media ref field
when using front editing here to update the media, the article is not revisioned

Media entity reference field normally uses entity reference field type, this type doesn't support revisions. So it is always referencing the latest revision. This is limitation of field type, not frontend editing. The paragraph entity type in contrary uses entity reference revisions field type. This type supports referencing specific revision, that is why when you update paragraph it creates new revision (if necessary) and also creates the revision to the host entity of the paragraph, but not in case of media, that uses normal entity reference field type. Once again, this is not limitation of frontend editing module, this is how entity reference field from core works.

If you still have different bevavior in your admin UI backoffice, please give more details of what widgets are you using and what field types.

Are you using the standard paragraphs widget, or maybe you paragraphs are added with help of Layout builder or any other tool?

No, there are no ECA module installed, and as far as I know no other module that manages revisions. The text "Shorten text" is the revision log message of previous revisions, I guess Drupal adds the message of the previous revision, if none is provided.

Referenced issue in menu_select module was fixed.

Here is screen recording of proof that revision for node is created, when paragraph is saved. Could you please do the same video? This will help to understand the problem better.

Thanks for reporting the bug. The patch was added to 8.x-2.x

To be honest, I am shocked myself. I have no idea how it was working before like that :) Thank you for reporting this.

Hi, thank you for your feedback. To understand your problem better I would need more details: what entity type are you saving and not getting new revision? Does that entity type supports revisions?

In most common use case of frontend editing, you edit the paragraphs that are part of node entity type. If your node bundle requires the revision to be created, then every time you save a paragraph, the new revision will be created (this is also a part of functionality that paragraphs_edit → module provides). Check the edit form of your node bundle:

Do you have that checkbox enabled? (if your problem is with node bundle, of course)

Frontend editing itself doesn't provide at the moment any instruments to create revisions, it only uses what Drupal core or any other module that provides entity type have. Normally the forms, that are opened in sidebar are taken as they are provided by corresponding entity types. If that form consists of revision fields, that should also be displayed (this needs confirmation, not 100% sure).

Regarding automated revision log message, that can be a good improvement, but that should be configurable per entity type/bundle. Could be a good feature request.

The operation label was changed and the tab "Templates" was added to /admin/content page. MR is merged.

This was ported to 2.x branch. Probably will not land in 1.x as 1.x will need to be in feature freeze state.

I have added new column to templates list and adjusted display of existing columns, please check again.

Unfortunately, it is not so easy to add the shadow to a circle inside SVG. I have added in MR, but the shadow has a gap to circle like 3-4 px.

I have added the new setting to the formatter of entity_reference_revisions field type:

When this settings is enabled, frontend editing can display the link to add new items even if field is empty and is not displayed.

a.dmitriiev → created an issue.

The same problem exists in version 3.0.x. Attaching the patch for it as well.

Automatic preview is in the module since version 1.5.1 https://www.drupal.org/project/frontend_editing/releases/1.5.1 → , the preview feature is since 1.5.0 https://www.drupal.org/project/frontend_editing/releases/1.5.0 → .

It turned out that https://www.drupal.org/project/all_entity_preview → module doesn't support nodes, because it is part of core functionality. So I assume your screenshot is for node? and "Preview" button is hidden somehow? Because the checkbox is displayed only if the form actions have "Preview" button.

I have removed all link templates for content_template entity type, so that it is not possible to view, edit, delete it directly. Everything is done only through node/<nid>/template and node/templates pages.

I have added new route node/<nid>/overview (and tab "Created from this template") that has the list of content that was created from this template:

Also now the template node from which content was created is stored in the field 'template' that is part of node entity storage now, no key_value storage is used anymore, as it is not possible to create overview page from it. The update is provided to copy the data from key_value collection content_templates to newly created field template

a.dmitriiev → created an issue.

Great improvement! Thank you for the contribution. I have added one more breakpoint to show 6 boxes in a row and for 1024px display 4 items.

Here is how the confirmation page looks like with the changes from MR:

a.dmitriiev → created an issue.

Thank you for the screenshot. It is still weird to me that the value for accordion is still passed instead of the empty array. Have you tried the fix from the MR? Does it help?

a.dmitriiev → created an issue.

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.

Small adjustments to the patch and MR because of this issue https://www.drupal.org/project/group_content_menu/issues/3417879 🐛 Can't create group menu link after upgrade to 10.2.2 - Error: Call to a member function label() on null Closed: duplicate and related core issue https://www.drupal.org/project/drupal/issues/3411384 🐛 Error: Call to a member function label() on null in Drupal\menu_link_content\Form\MenuLinkContentForm->form() (line 99 of /var/www/html/docroot/core/modules/menu_link_content/src/Form/MenuLinkContentForm.php). Fixed . Interdiff https://git.drupalcode.org/project/group_content_menu/-/merge_requests/2...

Also attaching patch for using in composer based projects.

a.dmitriiev → changed the visibility of the branch 3444500-use-inner-service to active.

a.dmitriiev → changed the visibility of the branch 3444500-use-inner-service to hidden.

a.dmitriiev → created an issue.

Also attaching the patch for easier usage in composer based projects.

a.dmitriiev → created an issue.

Ahmad Aziz, could you please make a screenshot of the whole page for field settings of this field_left, where you are trying to add the paragraph.

Normally on that line 560 in Drupal\frontend_editing\Controller\FrontendEditingController the variable $allowed_paragraphs should be always an array. But I have never tested with "Reference method" that is not "Default". It seems that you have some other method selected, or some more paragraph related modules enabled. Your settings page would be interesting to see and it might help to include your use case to avoid the problems in the future.

For now I will just add the check for type, to ensure that condition in query works properly, but it would be nice to see your settings.

Thank you.

a.dmitriiev → created an issue.

This was a regression from this issue https://www.drupal.org/project/frontend_editing/issues/3427666 🐛 Paragraphs on the page all collapse to nothing after an edit Active . It should be fixed now in MR, please check

a.dmitriiev → created an issue.

SirClickalot, it would be nice if you would provide steps to reproduce this problem. Please report what browser are you using, its version, what OS and its version as well. At the moment I see no issue with SVG on Safari Version 17.4.1 (19618.1.15.11.14), Chrome Version 124.0.6367.60 (Official Build) (arm64) and Firefox 125.0.1 (64-bit) on MacOS 14.4.1 (23E224)

The screenshot from each browser are attached.

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

Fixed, is part of 2.x, see related issue for more details.

I found that sometimes loadMultiple is missing 1 item. This causes search_api to return error message like:

Could not load the following items on index : "elasticsearch_document:external:/entity:node/92610:en".

When the range is extended, this message is not there anymore, and I can confirm in xdebug, that loadMultiple returns all items.

Interdiff is attached, MR is also updated.

Make this first page of the guide

Add information about user permissions.

Added link to page about preview

Patch helped to fix the issue in my project too.

Merged, will be part of next release (1.7.0)

Maybe it would be a good idea that for paragraphs that are higher than some selected value, the action links become "sticky" and follow the scroll to the bottom? Not sure that it is easily possible to do though :)

I have checked this issue again. Before the view mode of the field was not taken into account. Now everywhere where content is updated automatically the view mode is respected. So, if like in your case, there is the same paragraph on the same page rendered in different view modes, the update will replace the paragraph with the view mode that was edited or moved up/down.

Please check MR

MR was merged, SirClickalot please verify if this helps. You can use 1.x-dev version of the module to check that, no release was done yet.

Ok, it seems that it happens, because you have the same paragraphs rendered on the same page in 2 different view modes.

This was not part of 1.6.3 and was not mentioned in release notes. I will check this again.

Actually, svg file is now in the HTML markup, and not added via CSS. See the screenshot:

Rebase was finished, bbruno, please apply colour scheme changes.

Needs rebase and inclusion of color schema from Issue #3439916 by bbruno, a.dmitriiev, breidert: Introduce Color Customization Options and Neutral Colors for Frontend Editing UI Elements

I have added some changes to the module code, because Drupal already has built in functions to convert hex to rgb

a.dmitriiev → made their first commit to this issue’s fork.

I have the patch and this hook in a custom module.

/**
 * Implements hook_image_style_uri_alter().
 */
function MY_MODULE_image_style_uri_alter(&$uri, array $context) {
  $image_style_name = $context['image_style']->id();
  if (in_array($image_style_name, ['watermarked', 'watermarked_other'])) {
    $path = $context['path'];
    // Low resolution, watermarked images are available in the public readable
    // stream wrapper.
    $uri = "public://styles/$image_style_name/public/$path";
  }
}

a.dmitriiev → made their first commit to this issue’s fork.

I have checked and it is now fixed. MR is merged and will be part of next release

Looks like it was the problem, I have merged the MR and it will be added to the next release.

Is this issue now fixed? Taking into account that this issue is fixed now https://www.drupal.org/project/frontend_editing/issues/3428005 💬 Hiding the Front End Editing containers on particular blocks in v1.60x Fixed ?

Uploading a patch also for those who have patch from this issue https://www.drupal.org/project/elasticsearch_connector/issues/3102388 ✨ Add Search API data source implementation Needs work applied

I have just realized that $field variable is not available in FilterFactory class in filterFromCondition. It is available only when the patch from this issue https://www.drupal.org/project/elasticsearch_connector/issues/3102388 ✨ Add Search API data source implementation Needs work is applied

a.dmitriiev → created an issue.

I have applied all the changes from my patches, one by one and created MR https://git.drupalcode.org/project/elasticsearch_connector/-/merge_reque... . Please review

I have updated the tests, please review once again. I saw here https://filamentgroup.github.io/tablesaw/demo/stack.html that "persist" also could be set for "stack" mode, so I have also slightly modified the filter class.

Added to 1.6.2 release

Ok, I have installed ptoc module. The example of alter hook usage was wrong, it of course should be like this:

function YOUR_MODULE_fe_allowed_bundles_alter(array &$bundles, array $context) {
  if ($context['entity_type'] == 'paragraph' && $context['view_display']->getMode() == 'ptoc') {
    $key = array_search($context['entity_type'] . '.' . $context['bundle'], $bundles);
    if ($key) {
      unset($bundles[$key]);
    }
  }
}

Please confirm, then I will merge MR