🇳🇱Netherlands @ifrik

Thanks, that works for me, so I would RTBC it, if it hadn't been already set to Fixed.

I can confirm the same problem: For 6.0.4 and 6.0.5, excluding the text field from auto submit does not work.

The db update when upgrading from 6.0.3 to 6.0.4 also changed the existing BEF configuration in the view where it was used, incl. disabling the autosubmit and removing the default text for the text field - rather then just adding the config for collapsing, which I assume it was supposed to do.

See this config change as an example:

          bef:
-            general:
-              autosubmit: true
-              autosubmit_exclude_textfield: true
-              autosubmit_hide: true
-              input_required: false
-              allow_secondary: false
-              secondary_label: 'Advanced options'
-              text_input_required: 'Select any filter and click on Apply to see results'
-              text_input_required_format: basic_html
-            sort:
-              plugin_id: default
-              advanced:
-                combine: false
-                combine_rewrite: ''
-                reset: false
-                reset_label: ''
-                collapsible: false
-                collapsible_label: 'Sort options'
-                is_secondary: false
             filter:
-              search_api_fulltext:
-                plugin_id: default
+              filter:
                 advanced:
-                  sort_options: false
-                  placeholder_text: 'Search in the text'
-                  rewrite:
-                    filter_rewrite_values: ''
-                  collapsible: false
-                  is_secondary: false
+                  collapsible_disable_automatic_open: false
       access:
         type: none

It's missing the train:

From Northern Europe: Taking a train to Budapest, and then via Craiova and Sofia to Burgas, or with a night train from Budapest to Bucharest and then furtther via Sofia
For time tables: https://www.bahn.de
For routes and tips: https://www.seat61.com/international-trains/trains-from-Berlin.htm#Berli...

stella → credited ifrik → .

I've also created a PR to apply the patch and place the blocks in the Content Management dashboard - but I'm not sure I did everything correctly at the github config.

In order to see content in the list of edited content, the logged-in user has to edit a node created by the other user.

Exporting the changes as a patch as well.

Hi @sahana_n,

sorry that I didn't realize that my comment didn't get posted in time, and we ended up with double work.
I've already added this block in another view 📌 Provide content blocks in one view Needs review

I also had a look at your patch and it looks like you've over-complicated things. In Views you can now use "Content revision: Revision user" as contextual filter to filter for the UID that edited a node.

ifrik → created an issue.

We just discussed this at the contribution sprint and decided to provide this and other content blocks for the Content Management dashboard by one view instead of by several.

Unfortunately this comment didn't get posted for some reason.

I'm working on this today.

Thanks @Rivlar for the patch.

We just discussed this at the contribution sprint and decided to provide this and other content blocks for the Content Management dashboard by one view instead of by several.

ifrik → created an issue.

It's probably easier to discuss this directly at the Contrtibution sprint today, but it put it here as well:

We should provide this block in the same view that provides a block for the latest content of an user. They are very similar and it means less views provided by default.

@sahana_n are you currently working on it? Otherwise I pick this up in the contribution sprint

Thanks, I got stuck on writing tests.

Thank you webchick for all you've done!

Your presence and the way you interact with people and the community made Drupal a welcoming place for me - ever since the DrupalCon in Szeged and a small meeting of women in Drupal.

phpcs is marked as "deprecated because no longer maintained"

ifrik → created an issue.

Using Facets Pretty Paths 8.1.4 and Facets 2.0.5

Patch #13 works when used together with patch #3 from [3268360]

Patch #45 does not work for me, neither with or without the Facets patch

Thank you to all of those who made this happen!

I'm a bit confused with the state of the different patches in here, but #158 works on 9.5.3.

However, when adding a relationship I have a duplication for "Content using [field_name]" and one of them works, while the other doesn't.

Setting this to "Needs work" according to comment 185.

I'm happy to continue working on this. But what is "CR"?

Wow! Thanks so much to everybody who put work into this and pushed it through!

Hopefully that fixed the issue of the text direction.
The changes for the functional test are still underway.

I'm working on this.

Obviously it fails if I only change half of the test..

Thanks, I will do that.

There are some coding standard errors in the branch that I pushed yesterday and I'll fix those myself.

ifrik → created an issue.

I've tested this for the form widgets "Modular: Sierra" (with "Default interpreter"), "Modular: Oscar" and "Modular: Alpha" with the different options in each widget enabled and disabled.

They all work as expected. Dates and their recurrence can be changed and changing the widget also works fine.

This might not be as configurable as a view would be, but it will already help a lot with sitebuilding and with checking module upgrades, by reducing the very long list of fields on more complex sites.

This page is not used by content editor etc. on a production site, but purely a reference used in the development and maintenance of the site, so adding these filters is not breaking any customized functionality.

Patch #43 fails to apply for Drupal 10.1.x

Now I finally found that there already is an issue for this already.
Closing this as duplicate of #2959299

ifrik → created an issue.

Rerolling during Global Contribution Weekend today

ifrik → created an issue. See original summary → .

Whether users are aware of the ID or not depends on how the site is set up.
Where the ID is used in the admin interface it becomes a straight forward way of identifying an entity.

Theming option can indeed help to provide context, but not for all entities it's a straight forward as with taxonomy terms and their hierarchy.

See the following screenshots: That's two images from the same event, where the editor of the site has used the same title (which will be displayed as caption). The editors know the ID because it's displayed in the media library of the site, so they know whether they have chosen the correct one, but it would help them if they would already see the ID number earlier.

I think we have several problems here:

1. Users don't know what those numbers in brackets are. If anything they look like the item count in a search, especially for taxonomy terms where you could have 123 items or so.
2. Users can't always distinguish two entities on their title/name alone: It could be Georgia the country or Georgia the US state, two images can have the same title, or the same band playing at a venue several times... In this cases the ID helps, especially if other admin pages have been configured to display IDs. But users only see the ID after they have already selected an entity, and might need to go through several rounds of picking one to get the correct one.
3. Site builders have no way of configuring the display of title and ID in the list, so they aren't able to exclude or hide the ID if it's appropriate for a specific site.

Adding something in the description text works, but we shouldn't need to rely on site builders to provide explanation to the end users on how the UI works, and on a site with several entity references that's time consuming, and might need translations...

Could we add a span tag around the ID? That way it would be possible to hide the display of the number with CSS at least? Also not very elegant because it would require changing the admin theme.

Thinking much bigger: Ideally I would like to have an option to toggle whether the ID is displayed or not. And I would like users to be able to reference an entity by its ID instead of by its title.