🇩🇪Germany @a.dmitriiev

Waiting for https://www.drupal.org/project/drupal_cms/issues/3468271 📌 Add recipe for search backend Active to be merged

breidert → credited a.dmitriiev → .

breidert → credited a.dmitriiev → .

a.dmitriiev → created an issue.

I have addressed all the comments in MR and also now there is only 1 recipe for search that combines all the functionality. Facet filters will be added in a separate issue.

a.dmitriiev → created an issue.

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

For testing you need to create a recipe and use the config actions from comment https://www.drupal.org/project/drupal/issues/3305859#comment-15847932 → . The MR also contains tests, you can follow them as well.

As for the problem, are you trying to edit the paragraph or the content type and you don't see the real time updates?

If possible, could you please check the response of the request? The uri should be like `/frontend-editing/form/paragraph/1010?view_mode_id=default&ajax_form=1&_wrapper_format=drupal_ajax`, the method is POST.

In the response there should be an object similar to this:

Object { command: "feEntityPreview", selector: '[data-fe-preview-content="90778e28-1e72-44d1-8807-c5a818288237"]', viewModeId: "default", … }

This object contains ajax command that triggers the preview for the DOM element with selector data-preview="90778e28-1e72-44d1-8807-c5a818288237". Do you see this selector on the page? This data attribute is added to the entity wrapper (in this example is to paragraph wrapper), see here https://git.drupalcode.org/project/frontend_editing/-/blob/1.x/frontend_... . This also needs that attributes be printed in your entity's template. For example:

<div{{ attributes }}>
  {{ content }}
</div>

Status "Needs work" is set for the issues that have some patch or MR that needs work. If there is nothing yet done, it should be just "Active"

I am waiting for BUEditor module (the dependency of Advanced Insert View BUEditor Integration) to be Drupal 11 compatible.

The change from MR fixes the problem. Confirmed with Better Exposed Filters 7.0.2, Facets 3.0.x-dev and Drupal 11.x-dev .

Fixed patch for 1.35

Updated patch

Updated patch for 1.35 to use in Drupal CMS search track recipe

Views config actions patch

Search Track entity display createCopy config action patch

For action method `createCopy` the new optional parameter was added `use_existing`, that allows avoiding the error. The recipe should have this config action:

    core.entity_view_display.node.*.default:
      # Clone the "Default" view display by default.
      createCopy:
        mode: search_index
        use_existing: true

strykaizer → credited a.dmitriiev → .

The tests were fixed.

For me updating to Gin 3.0.0-rc14 fixed the problem. The "Save" button appeared at the bottom of the modal window.

New version was released https://www.drupal.org/project/insert_view_adv/releases/2.0.0-alpha4 → with Drupal 11 support

I have added the test for global default view mode set. The test also includes the override for one bundle. Please review.

I will check what is needed for Drupal 11 support. Yes, definitely there will be a version with D11 compatibility soon.

Thank you for reminding me.

Some update:

Module https://www.drupal.org/project/simple_search_form → now has Drupal 11 support. I have a contact with the module maintainer and I am also co-maintainer now, just in case.

As for Facets, I am also in contact with Jimmy Henderickx (strykaizer), who is in charge of version 3 and the Drupal 11 support is now the highest prio, so I believe this will be added very soon.

The blocking issue for search_api https://www.drupal.org/project/search_api/issues/3483366 ✨ Need a way to populate some config values with list of available entity bundles with config actions Active now only needs tests and can be completed soon, here I am also in contact with module maintainer.

Thank you!

@poker10 the issues mentioned by you are for Facets version 2.x. The recipe includes Facets 3.x that was completely rewritten to "natively" support views exposed filters, there is even a special submodule facets_exposed_form now included in the codebase for that. As it is now just a views filter and not a block as it was before, there are no problems with ajax anymore.

Thank you all for the feedback and review. I will try to add tests and go over all suggestions asap.

There are some tests with blocks that are failing, I assume not related to the tests form MR.

Adding blockers, other issues with patches are optional and probably would need a clean-up in recipe.

I tried to address all the comments from the MR. But now as Drupal CMS requires Drupal 11, there are some more problems with recipe dependencies, as Facets are not yet Drupal 11 compatible, though there is an issue https://www.drupal.org/project/facets/issues/3455217 📌 Automated Drupal 11 compatibility fixes for facets Active already with MR (I will try to push this forward as much as I can). The same is with Simple Search Form module. I have already created a co-maintainer request issue https://www.drupal.org/project/simple_search_form/issues/3486501 💬 Co-maintainer request Active and that module also already have Drupal 11 compatibility issue https://www.drupal.org/project/simple_search_form/issues/3434565 📌 Automated Drupal 11 compatibility fixes for simple_search_form Needs review .

Indeed there are also 3 patches to Search API module included in the recipe as well. I worked on one of them https://www.drupal.org/project/search_api/issues/3483366 ✨ Need a way to populate some config values with list of available entity bundles with config actions Active to allow setting global settings for index and search results view. This is needed as the list of content types is not known for the recipe in advance. I am waiting for the feedback of the maintainer of search_api module. The other 2 patches are not critical but also would be nice to have.

There are also 2 Drupal core patches. Both are with needs review status: https://www.drupal.org/project/drupal/issues/3483353 ✨ Consider making the createCopy config action optionally fail if the entity display already exists Active and https://www.drupal.org/project/drupal/issues/3305859 → (this one has Needs work because of some automated checks, I will check them now).

I have also added the tests, but at the moment pipeline fails because of Drupal 11 compatibiliy.

a.dmitriiev → created an issue.

I have also exposed 2 methods from view entity class: addDisplay and duplicateDisplayAsType as Action Methods to use as config actions.

The MR contains 3 new config actions for view entity type:

1. setDisplayOption - allows to set a display option like filters, fields, pager, etc .
Parameters:
option (required) - the name of the option to manage, can be filters, fields, pager, etc (any option that view display can have)
settings (required) - the option settings. This varies from option type.
display_id (optional) - the display id, if non is provided the default is used.
Example usage:

view.view.my_view:
  setDisplayOption:
    display_id: default
    option: pager
    settings:
      type: mini
      options:
        offset: 0
        pagination_heading_level: h4
        items_per_page: 10
        total_pages: null
        id: 0
        tags:
          next: ››
          previous: ‹‹
        expose:
          items_per_page: false
          items_per_page_label: 'Items per page'
          items_per_page_options: '5, 10, 25, 50'
          items_per_page_options_all: false
          items_per_page_options_all_label: '- All -'
          offset: false
          offset_label: Offset

2. addItemToDisplayOption allows to add the item to views display option. The difference from setDisplayOption is that the existing option settings are preserved and only the new item is added to the option settings.
Parameters:
The same as for setDisplayOption, plus one more item - for the name of the item to add.
Example usage:

    views.view.drupal_cms_search:
      addItemToDisplayOption:
        display_id: default
        option: filters
        item: facets_type
        settings:
          id: facets_type
          table: search_api_index_drupal_cms
          field: facets_type
          relationship: none
          group_type: group
          admin_label: ''
          plugin_id: facets_filter
          operator: '='
          value: ''
          group: 1
          exposed: true
          expose:
            operator_id: ''
            label: 'Content type'
            description: ''
            use_operator: false
            operator: ''
            operator_limit_selection: false
            operator_list: { }
            identifier: type
            required: false
            multiple: true
            remember_roles:
              authenticated: authenticated
          is_grouped: false
          group_info:
            label: ''
            description: ''
            identifier: ''
            optional: true
            widget: select
            multiple: false
            remember: false
            default_group: All
            default_group_multiple: { }
            group_items: { }
          hierarchy: false
          label_display: visible
          facet:
            query_operator: or
            min_count: 1
            show_numbers: true
            processor_configs:
              translate_entity:
                weights:
                  build: 5
                settings: { }

3. removeItemFromDisplayOption allows to remove the item from views display option.
Parameters:
The same as for addItemToDisplayOption, minus one settings as it is not needed for item that is removed.
Example usage:

    views.view.drupal_cms_search:
      removeItemFromDisplayOption:
        display_id: default
        option: filters
        item: facets_type

Uploading patch to use in Drupal CMS for config actions on views, that need to add/remove/update filters/fields and other options of the display.

Please disregard patches and review MR. The patches are just needed to be used with stable 1.35 version.

Patch for version 1.35

Updated patch without strange symbols

Uploading the patch to use in Drupal CMS

I have started a draft MR. At the moment I made the changes only to the "Rendered Item" plugin for index field. Not fully tested yet. I will continue tomorrow, as this feature is really needed for Drupal CMS.

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

The latest dev still doesn't have that update listed, so I guess yes, it is still relevant.

While waiting for stable release, uploading patch for version 3.0.1 (latest stable) with the same code that was in the MR

Uploading the patch that can be used until the new version is not released

a.dmitriiev → created an issue.

Oh, sorry for that. Merged the follow-up

Merged, thank you

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

Should this issue be moved to Drupal project?

I have prepared the first MR for recipe integration https://www.drupal.org/project/search_api/issues/3484304 ✨ Expose Index and Server methods as config actions Active . It exposes only already existing methods as config actions to start this feature rolling.

a.dmitriiev → created an issue.

I think the following methods from Index entity class should be exposed as config actions:

• setOption (without plural support, as there is already setOptions method in the class)
• setOptions
• removeDatasource as only the id is needed for argument
• removeProcessor
• renameField
• removeField

it would be also nice to have the following methods exposed, but some code adjustments will be needed:

• addDatasource, but at the moment the argument is of type Datasource and it can't be used in recipe. Maybe alternatively there could be a method addDatasourceByIdAndConfig that will have datasource id and its config as arguments.
• setTracker has and object as argument so it can't be used as action method, but maybe having a method setTrackerByIdAndConfig with tracker plugin id and config as arguments would make sense
• The same for setServer it makes sense to create setServerById?
• addProcessor has object as argument, but maybe new method addProcessorByIdAndConfig would be ok to add as well
• addField has Field object as argument, but maybe new method addFieldByFieldConfig would be ok to add

Methods that are not in Index class yet, but might be useful:
setServer
setReadOnly

Methods for Server entity:

setBackendConfig

Missing methods on Server entity, that could be useful:

setBackend - as setBackendConfig method assumes that backend property is already set, maybe it is needed to have backend set method as well.

a.dmitriiev → created an issue.

@sirclickalot please create another issue for this. It is getting hard to focus on the problem if you post in the comment of the issue that was obviously a problem of form display in Gin and now you Post a problem with some node save and ECA integration. This has to be in its own issue. This issue is fixed.

Please check the MR. The buttons should be now there.

Uploading the new patch for using in composer. The change was pushed to MR.

The change is in MR https://git.drupalcode.org/project/drupal/-/merge_requests/9944/diffs . I posted a patch just to use it in composer. Ok, I will remove the change from the interface, but the LayoutBuilder complains that its declaration is different, so this has to stay.

Forgot about the interface core/lib/Drupal/Core/Entity/Display/EntityDisplayInterface.php

Updated patch

I think optional parameter bool $use_existing = FALSE would be a nice solution here, so that the method doesn't try to load the copy always, but only when use_existing is TRUE. Nice approach.

Ok, thank you for the feedback. Let's continue in corresponding projects.

Please share the Drupal and Gin Theme versions that you are using.

New features will be added to 2.x branch only, so changing the target version.

The request is very interesting. I will need to investigate the options.

As this is a new feature request, it won't be done in 1.x branch. All the new features will be added only to 2.x branch. So I am changing the target version.

This is an interesting feature request, but it will require a lot of effort to implement.

Thank you for the issue and a patch, but I am not sure that having a checkbox for each action will be good idea. There are a lot of access checks that work properly with Drupal permission system and for other buttons like add/move there are additional events emitted that you can subscribe to.

Probably in your use case it is better to implement form alter hook and remove the "Delete" button if it is confusing for your editors. You can find an example of form alter that targets the form in the sidebar in frontend_editing.module file function frontend_editing_form_alter().

Moreover, there is an event ParagraphAddAccess with which you can modify the result of allowAdd check. And for moving up/down there is another event ParagraphMoveAccess.

I would recommend that you implement event subscribers in the custom module if the permissions granularity is not enough for your use case.

Frontend editing comes with 2 permissions for moving and adding paragraphs: move paragraphs and add paragraphs. The links should not be displayed for the roles that do not have those permissions.

Adding a new configuration will conflict with those permissions, don't you think so?

a.dmitriiev → created an issue.

I have checked the change with Drupal CMS search track recipes and it works as expected.

Uploading patch for composer

a.dmitriiev → created an issue.

The same combination of patches helps in my case as well.

Config action works as expected, by default cloneAs skips the existing items. With option fail_if_exists the recipe application stops with exception:

In Exists.php line 38:

Entity __entity_name__ exists

`createCopy` config action works as expected for Search Track of Drupal CMS recipe.

Thank you all!