Also add that Ignore characters and Ignore case need to be disabled for the field as well.
Add a note to check whether the HTML filter is enabled for the new field, because that will strip out all the HTML out of the "storage_only" field.
penyaskito → credited ifrik → .
I can translate the menu item of the group content when I translate the node itself.
But when I use the contextual link "Edit menu" and then try to translate a menu item, then I got (1) an error message, (2) a status message that the menu link has been edited, and (3) the menu item is deleted from the menu.
This is the case for menu items that link to nodes as well as to the group itself.
Deprecated function: explode(): Passing null to parameter #2 ($string) of type string is deprecated in Drupal\menu_link_content\Form\MenuLinkContentForm->buildEntity() (line 114 of core/modules/menu_link_content/src/Form/MenuLinkContentForm.php).
Drupal\menu_link_content\Form\MenuLinkContentForm->buildEntity(Array, Object) (Line: 186)
Drupal\Core\Entity\ContentEntityForm->validateForm(Array, Object)
call_user_func_array(Array, Array) (Line: 82)
Drupal\Core\Form\FormValidator->executeValidateHandlers(Array, Object) (Line: 275)
Drupal\Core\Form\FormValidator->doValidateForm(Array, Object, 'menu_link_content_menu_link_content_form') (Line: 118)
Drupal\Core\Form\FormValidator->validateForm('menu_link_content_menu_link_content_form', Array, Object) (Line: 593)
Drupal\Core\Form\FormBuilder->processForm('menu_link_content_menu_link_content_form', Array, Object) (Line: 325)
Drupal\Core\Form\FormBuilder->buildForm(Object, Object) (Line: 48)
Drupal\Core\Entity\EntityFormBuilder->getForm(Object, 'default', Array) (Line: 394)
Drupal\content_translation\Controller\ContentTranslationController->add(Object, Object, Object, 'menu_link_content')
call_user_func_array(Array, Array) (Line: 123)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}() (Line: 580)
Drupal\Core\Render\Renderer->executeInRenderContext(Object, Object) (Line: 124)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->wrapControllerExecutionInRenderContext(Array, Array) (Line: 97)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}() (Line: 169)
Symfony\Component\HttpKernel\HttpKernel->handleRaw(Object, 1) (Line: 81)
Symfony\Component\HttpKernel\HttpKernel->handle(Object, 1, 1) (Line: 58)
Drupal\Core\StackMiddleware\Session->handle(Object, 1, 1) (Line: 48)
Drupal\Core\StackMiddleware\KernelPreHandle->handle(Object, 1, 1) (Line: 106)
Drupal\page_cache\StackMiddleware\PageCache->pass(Object, 1, 1) (Line: 85)
Drupal\page_cache\StackMiddleware\PageCache->handle(Object, 1, 1) (Line: 48)
Drupal\Core\StackMiddleware\ReverseProxyMiddleware->handle(Object, 1, 1) (Line: 51)
Drupal\Core\StackMiddleware\NegotiationMiddleware->handle(Object, 1, 1) (Line: 23)
Stack\StackedHttpKernel->handle(Object, 1, 1) (Line: 718)
Drupal\Core\DrupalKernel->handle(Object) (Line: 19)
Some more thoughts after having discussed this with some people at DevDays:
- If the items are not grouped then they would need to be listed alphabetically - rather then having them sorted by type but without disclosing that to the content creator. Without headings to group them, that just looks like a scrambled random list. And as in the issue description: some are used so rarely that it looks more like clutter..
- Grouping them by type and using that as a heading (node/content, media, user, taxonomy term etc.) provides some structure, and a way to break down long lists. But does the content creater need to know what is what entity type?
- On many sites, different types of content might belong together. For example, on a site that displays information about conferences, the content creator might need to create a node for the event, several speaker profiles, a taxonomy term for the city and a custom geo entity for the venue. Grouping them together would improve the UX for the content creator, and as site builders we can configure that for them. It can't be standardized, but grouping by type looks and works nicely out of the box, then we can just change it for the individual site. (Even if it requires some content export for the new menu items.
Note: this is not for the look and feel but an example, how menu items could end up on specific website if grouped for the content creater UX.
Screenshot of a site with Commerce module installed.
I had the same problem on Drupal 10.3, on a site that didn't have Minifyhtml installed anymore for a long time, but the lines
minifyhtml:
minify_html: 0
did not get removed from system.performance.yml whenever the module was uninstalled. As a result the perfomance page could not be saved until I edited the yml file directly and imported the config.
This looks much cleaner, but the order of the fields still has no recognizable structure, thereby making it difficult to find the right field type.
For example, if you install Commerce module in addition to core. In the previous dropdown all Commerce fields were grouped together but now they are random scattered over the grid.
Also even with the decluttered cards, the grid is difficult to scan especially when you have contrib modules (like Commerce) installed and you end up with some 30 field types, spread over 3 or 4 columns
Changes that would make it easier to find field types could be
- to add a filter field (similar to on the modules page),
- grouping fields by again (at least if they are provided by a contrib module),
- and allowing users to switch to displaying the fields in a list rather then an a grid, because that's easier to scan.
This idea had come up previously as issue 📌 Add "Add" item to toolbar. Needs work including input from the UX team.
Some questions that had come up with that:
- Do content creators need to know what entity type they are creating? Or do they just need to know how it's called on their site?
- How does it look if there are so many items that list is longer then the screen?
- Contrib and custom modules should also be able to add their links into the list.
The new Navigation module in 10.3.x that came out of the work on the Admin UI, probably superseeded this because it allows site builders to configure admin menus.
For example by placing several menus in the vertical menu bar, visible by role.
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...
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.
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.
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"
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.
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
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:
- 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.
- 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.
- 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.