🇩🇪Germany @a.dmitriiev

Here is the proof that I have contacted the maintainers in Slack https://drupal.slack.com/archives/C1BMUQ9U6/p1734422515626019

There are also at least 3 messages in Slack #contribute channel from Ivnish:
https://drupal.slack.com/archives/C1BMUQ9U6/p1736425954066919
https://drupal.slack.com/archives/C1BMUQ9U6/p1732684301373429
https://drupal.slack.com/archives/C1BMUQ9U6/p1733723989226619

And from other people:

https://drupal.slack.com/archives/C1BMUQ9U6/p1735935169012749
https://drupal.slack.com/archives/C1BMUQ9U6/p1733935783496769

Unfortunately, there is no proof for contact form request, as I didn't set the copy to be sent to me.

I understand that there are rules, but having 13 maintainers and no one is responding and the module that has a lot of installations and people are waiting for Drupal 11 support. I think here could be some help from d.o admins to solve this problem.

At some point this module was considered to be added to Drupal CMS, but because of lack of Drupal 11 support, it was not added there too.

Here is a nice issue with examples from group module https://www.drupal.org/project/group/issues/2797845 💬 How to migrate content into group and group content Active . Be aware of the last comment in that issue, there is a difference between versions of group module

You need first migrate your groups, then media and then create another migration for group media relation. Media is attached to the group via the GroupContent entity type that is a group module functionality. Basically it is another content entity that has reference to a group and to the content that you want to attach to the group. So the third migration needs to create content items of entity type group_content with reference to your media item and group, and the bundle of this group content items will be the name of the plugin that corresponds to the bundle of the media.

I have updated the description of the issue. Are there any examples of how change record for new config action should look like? What should be included? Is content of comment https://www.drupal.org/project/drupal/issues/3305859#comment-15896386 📌 Add config actions for views Active would be enough?

Thank you, the MR was merged

There are also other public methods in src/FloodUnblockManagerDatabase.php class that query the same flood table. I think they also need this check.

a.dmitriiev → created an issue.

The fixed 1.x version was released https://www.drupal.org/project/frontend_editing/releases/1.8.8 →

Fixed for 1.x and 2.x versions. Now the "Cancel" button redirects back to the paragraph edit form.

Search recipe sets the items to be indexed immediately for "Content" index. But for content that was already there of course this doesn't help. Maybe some dashboard message should be added instead of setting the last cron run to 0? This will notify the user that the cron needs to be run in order to have all the items indexed. Or maybe the message can lead to the index page where the user needs to click on "Index" button even.

As dieterholvoet confirmed that he wants to maintain the module, can this move forward? A lot of users are waiting for the module to be updated to support Drupal 11, but this blocks it.

Thank you in advance.

The warning was added in version 2.x in this issue https://www.drupal.org/project/frontend_editing/issues/3473762 📌 Add warning when leaving form and changes would be lost Active . Also in that same issue there is a nice integration with "All entity preview" module found, that the changes can be kept in the form.

But yes, I agree, that there is a confusion that the preview displays the changed content, but form doesn't. This needs a second thought for version 1.x, but I wanted also to have only bug fixes there and have all new features in 2.x.

Thank you for reporting the bug, I will try to check it soon.

Added the fix to https://www.drupal.org/project/all_entity_preview/releases/1.0.0-alpha5 →

Adding the Change Record link for the reference https://www.drupal.org/node/3404140 → .
Thank you for the fix. I have modified the MR a bit, to make sure that the form works also for Drupal versions before 10.2, even if they are not officially supported anymore.

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

I have added backwards compatibility for Drupal < 10.3 and merged.

Thank you!

Adding a change record for the reference https://www.drupal.org/node/3450770 →

Thank you for the fix. I have modified the MR a bit, to make sure that the form works also for Drupal versions before 10.2, even if they are not officially supported anymore.

Adding the Change Record link for the reference https://www.drupal.org/node/3404140 →

a.dmitriiev → changed the visibility of the branch 3489217-node-title-is to active.

1.8.7 release contains this fix

Thank you for the fix, it was merged also to 2.x branch.

Merged

MR is merged. Thank you everyone

lostcarpark → credited a.dmitriiev → .

Yes, unfortunately the situation in the mentioned extra_field module issue is very strange and not likely to be moved forward easily :(

Please provide more details, if possible with links to the page and your version of Chrome at least. Also, are you checking as logged in user or anonymous user. Are there any logs with errors in "Recent log messages" in Drupal admin UI?

Delete confirmation page was also fixed. Please review

Updated patch with empty line at the end of the file

Also uploading patch for usage in composer based projects.

a.dmitriiev → created an issue.

Now this piece of code needs to be added to all default content items:

moderation_state:
    -
      value: published

Because now all of them are unpublished

a.dmitriiev → created an issue.

a.dmitriiev → created an issue.

I have also mentioned two of the maintainers in Slack #contribute channel https://drupal.slack.com/archives/C1BMUQ9U6/p1734422515626019

Added descriptions

I have fixed composer and recipe dependencies and also bumped the Drupal version to 10.4 and higher as Drupal CMS is based on 11.1 even, but supports 10.4 in terms of recipes, as they are identical.

Follow up issue for tests was also created https://www.drupal.org/project/drupal_cms/issues/3493492 📌 Add end to end test for search results page with filters by content type Active

a.dmitriiev → created an issue.

I have updated MR with the new modules. After running the command there were more changes to MODULES.md file than I have expected, so I left the changes that were for Search recipe only (others were reverted).

Done. Now the recipe requires user input.

MR is merged

I have updated the MR, now facet filters are part of the main recipe and not a separate on anymore. This also allows to skip patching of the core, as no config actions are needed for views, but facet filters are also enabled by default without any confirmation.

There is a problem with the input for the recipe to enable facets exposed filters based on it. There is no config action yet to target the specific setting of a filter in the view. I have updated this issue https://www.drupal.org/project/drupal/issues/3305859 📌 Add config actions for views Active but still it sets the settings, but doesn't merge the existing ones with partially provided settings from the recipe. I am not sure about merging settings approach, should it be like this?

I have removed config action that removes display option items from MR. I have also combined setDisplayOption with addItemToDisplayOption config actions. Here is the updated usage documentation:

setDisplayOption config action has following 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.
override (optional, default FALSE) - allows to override the display option (make it only for the current display)
item (optional) - in case of fields and filters, it is possible to add/update the individual field/filter providing the name of the field/filter here. The settings parameter will be applied to this individual item instead of the display option itself.
allow_update (optional, default TRUE) - this is optional parameter to forbid of field/filter (individual item of a display option) update in case the item already exists in a view.

Example usage:

1. Change the pager

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. Add a field to a view:

  view.view.my_view:
    setDisplayOption:
      display_id: default
      option: fields
      item: my_field_id
      settings:
         alter:
            alter_text: false
            ellipsis: true
            html: false
            make_link: false
            strip_tags: false
            trim: false
            word_boundary: true
          empty_zero: false
          field: name
          hide_empty: false
          id: name
          table: entity_test
          plugin_id: standard
          entity_type: entity_test
          entity_field: name

3. Add multiple fields:

  view.view.my_view:
    setDisplayOption:
      -
        display_id: default
        option: fields
        item: my_field_id
        settings:
           alter:
              alter_text: false
              ellipsis: true
              html: false
              make_link: false
              strip_tags: false
              trim: false
              word_boundary: true
            empty_zero: false
            field: my_field_id
            hide_empty: false
            id: my_field_id
            table: entity_test
            plugin_id: standard
            entity_type: entity_test
            entity_field: my_field_id
      -
        display_id: default
        option: fields
        item: my_another_field_id
        settings:
           alter:
              alter_text: false
              ellipsis: true
              html: false
              make_link: false
              strip_tags: false
              trim: false
              word_boundary: true
            empty_zero: false
            field: my_another_field_id
            hide_empty: false
            id: my_another_field_id
            table: entity_test
            plugin_id: standard
            entity_type: entity_test
            entity_field: my_another_field_id

I have opened the new MR with correct target branch

The comments from MR were addressed.

And also submodule facets_exposed_filters (that is needed for facets to be used in exposed filters) depends on BEF https://git.drupalcode.org/project/facets/-/blob/3.0.x/modules/facets_ex...

The MR was rebased on 1.x branch.

I have created MR to 3.x branch. Attaching the patch for 3.x as well.

Paragraph is not a re-usable entity, because it has a parent and a parent field defined in the base fields of paragraph itself, so theoretically it can't be added to another entity. I am not sure how paragraphs library works, though. This needs to be confirmed.

It was only unlinking the paragraph from the host (parent) entity. If you check the class ContentEntityDeleteForm in submitForm there is a line $entity->delete(). But ParagraphDeleteForm overwrites this method but doesn't implement delete(), so the paragraph is still there.

a.dmitriiev → created an issue.

I am not sure whether the question is still relevant, but here is the module https://www.drupal.org/project/user_expire → that does exactly what is described.

I have added the suggestions to MR, but the problem with core search module is still there. It seems my changes in beforeEach do not work, as the core search module is still installed and that is why the test fails, as instead of Search API search page with views, the core search page is displayed.

Is there already Cypress command to uninstall the module?

Merged, thank you

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

Merged

I have created new MR with 0.x as target branch.

I have added one more instance of search block to primary_menu region.

Also the label was added to the views exposed form (search keywords). There is no option in views to set the label display options, so it was just added above the input.

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

a.dmitriiev → created an issue.

a.dmitriiev → created an issue.

As far as I remember, it is the default behavior of views exposed filter reset button for anonymous users. It just redirects to the page that is defined by the view. As a quick solution it might help if you create the same view as a block, not as a page.

But this issue definitely needs some more attention.

+1 for Drupal 11 release. It seems that this MR fixes BC and the 2.0.x-dev branch is already Drupal 11 compatible. Are there any other blockers?

+1 for adding Drupal 11 support and creating a new release.

The patch and MR are very basic and straightforward. Are there any chances, that this can be merged and the new release created with Drupal 11 support?

Thank you.

Now I remember what was the problem with authenticated users and exposed form, the problem is in BigPipe module. In case your main audience of the website are anonymous users, big pipe is not much of a benefit. Please try to disable the bigpipe module. In case of course you have a high number of authenticated users that use your site, then this is a problem. I remember once I have already tried to fix it, but it was in Drupal 8-9 times. Probably something has changed since then. I will try to check bigpipe+exposed filters problem.

There is a known problem with exposed filters that work for anonymous users but not working with authenticated users. As anonymous user I see the hierarchical select:

Regarding the other views that are displayed like this [view:lucentezza=default] instead. Please make sure that the views with the corresponding names exists and have proper access settings.

Also in your text format, there are settings for Insert view filter:

Make sure that your views are selected, or the list is empty, so all views are allowed.

Maybe you also have any logs available? From Drupal or from browser console?

I will close this issue, as it was fixed in other issues that are listed in the comments

I can confirm that AI CKEditor logs the response correctly now when using MRs https://git.drupalcode.org/project/ai/-/merge_requests/295 and An OpenAI implementation is here: https://git.drupalcode.org/project/ai_provider_openai/-/merge_requests/4