🇩🇰Denmark @ressa

ressa → created an issue.

After trying many things, I went for a more systematic approach, using the wonderful Search API Solr Devel to debug the requests and responses. Looking at a node translated into two languages (da and en), which had a Views block attached (using Contextual filters > Content datasource: ID (Default: Content ID from URL)), I noticed that both languages were being requested, which puzzled me -- all nodes showed the block twice, in both languages. I thought I had set up the "Language (with fallback)" filter in my view correctly, by selecting "Danish" and "English", but apparently not ...

Because this request was sent to Solr, under a /da/node/123 page:

(+ss_type:"municipality" +sm_language_with_fallback:("da" "en"))'

I tried some other options in the Views "Language (with fallback)" filter, and when I finally selected "Content language selected for page" it worked, and only either da or en were requested, as desired. Now this was sent to Solr, under example.org/da/ pages:

'(+ss_type:"municipality" +sm_language_with_fallback:"da")'

So just to spell it out, to get data pulled from Search API Solr, using "Language (with fallback)" as a Views filter, you should add the field as a filter in your View, and then select "Content language selected for page", for example if you are using "Path prefix" under "URL language detection configuration". Search API will use the context of the page as a filter, so that when pages under example.org/da/ is accessed, Solr will only return items with "sm_language_with_fallback":["da"],. Likewise, if pages under example.org/en/ are accessed, Solr will only return items with "sm_language_with_fallback":["en"],:

Configure filter criterion: Search: Language (with fallback)

Operator
x Is one of
  Is not one of

Language
  Select all
  Site's default language (Danish)
  Interface text language selected for page
x Content language selected for page
  Danish
  English
  Not specified
  Not applicable

I wonder if calling that option something else like "Content language of page" would work better, or something else? The current wording make it sounds like the user is doing something actively ("selected for") which the user isn't ...

Just a tip that I managed to get it to work in Search API Solr, and how to:

• Index translated labels in rendered content using the patch in 🐛 Rendering is not changing the current content and string translation language Closed: duplicate
• Set up "Language (with fallback)" correctly in a View

I have posted more details in the other issue, and updated the MR.

Thanks @hchonov and @drunken monkey, I tried the patch in the other issue (#3035977), but the MR here is actually the only one, which gets translated labels in a "Rendered HTML output" (rendered_item) field correctly indexed in Search API Solr, so thanks very much for sharing.

Otherwise all rendered field labels use the original value, not both the original as well as translated label. So I have added the patch as a GitLab MR, in case it's useful. Perhaps some of the code which results in translations could get transferred to #3035977?

However, I still cannot get my View to filter correctly ... it seems to ignore the filter "Language (with fallback)", I added as a Search API field. Also, I don't see "Language (with fallback)" as an option on the "Processors" page (/admin/config/search/search-api/index/solr_index/processors) I wonder if that's a bug, or the expected behaviour?

It would be fantastic if the minimum steps required to get data pulled from Search API Solr and Language (with fallback) as a Views filter with "Detection and selection" (/admin/config/regional/language/detection) configured correctly was documented somewhere, or maybe it already is?

Perhaps I should create a dedicated issue to this problem, or is it so connected to the task solved here, that it should be handled here as well?

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

Sorry about the noise, I just wanted to remove two modules from composer.json, which I think should not be there, and failed ...

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

Thanks for updating the documentation, though I think the current example is misleading:

 * process:
 *   field_foo:
 *     plugin: entity_value
 *     source: field_noderef/0/target_id
 *     entity_type: node
 *     langcode: es

From that example, I get the impression I can simply add a language code, like es, en or da. But then I got this error:

[error] SQLSTATE[23000]: Integrity constraint violation: 1048 Column 'langcode' cannot be null: UPDATE "node" SET "vid"=:db_update_placeholder_0, "type"=:db_update_placeholder_1, "uuid"=:db_update_placeholder_2, "langcode"=:db_update_placeholder_3

I needed instead to set the hardcoded value with default_value like this:

  langcode:
    plugin: default_value
    default_value: da

So I believe this assumption is wrong, since it looks to me like it needs a reference:

I would say set it to an actual language code so it's clear.

Should we reopen, or fix in a new issue?

If Redirect module is installed, its checkbox will also be checked and there will be a "Redirect (Translation is not supported)." message.

Perhaps the page can be added to the menu?

Thanks @kalkbrenner for maintaining Solr in Drupal. @murz: Your suggestion about adding support for indexes as well is great. I added a documentation page a while ago, and was reminded that the command works on Solr server, not index, and added a note about this.

https://www.drupal.org/docs/8/modules/search-api-solr/search-api-solr-ho... →

Add tip to remember that server, not index id should be used.

Thanks @dydave for all the great work here in Admin Toolbar, you're doing a stellar job! And yes, that was a bit of an abrupt merge ... 😅

It would have been great to be able to do the final small tweaks in this MR, but it's a good idea to include them in the next MR

Thank you for the nice words about my suggestions, I just try to approach it from up above, and see it from the perspective of a regular user (such as myself) -- like, are the headings and features easily understood at a glance, is the interaction user friendly, etc.?

I know how you can easily focus on getting the code working, while forgetting about the user interface. In 📌 Add date formats without time Active , it was only at the last minute, after @penyaskito luckily noticed that the order of dates could be improved, with better sorting, that it got fixed ... I had overlooked that they were jumbled up, since my focus was on navigating the GitLab UI, writing (unused) updates_hooks, etc. 🙂

So building Drupal is a team effort, where we all take on different roles at different times, and help each other out, however we can.

I like your idea about merging the shortcut issue into a "Meta" issue, where we can deal with both "Admin Toolbar Search" and the new "Hide Toolbar" feature. I have updated the shortcut issue, so it is now aimed at both the Search and Hide Toolbar features. It's great that there are new features in the pipeline for future versions of Admin Toolbar!

Thanks @sascha_meissner for sharing your idea and code, and @grevil and @thomas.frobieter for pushing this feature forward! It's very encouraging with the friendly and positive approach from for example DROWL.de developers and @dydave, where the tone can occasionally be a bit too focused on efficiency in some issues, with hardly a thank you or gratitude. So I really appreciate the positive tone in the many projects you are maintaining, and issues you are involved in.

Thanks @quietone, that improved the shortcuts in the right side a lot, making them easily understandable at a glance.

I want to change the default language, and it's not easy. These three issues seem most relevant, with useful tips (I shared my method in the first issue):

• 📌 Allow default_langcode field value to be changed Active
• 🐛 Configuration language is not adjusted after changing the site default language Active
• 🐛 Importing config on a newly installed site with non-english default language gives error because of default language overwrite Needs work

It's a bit of an edge case, but I'll share it here, since this issue pops up when searching for changing default language.

I have originally started my web site in the standard English language, but now want to change to Danish as the default language, because I want to translate block titles and other user interface elements, with a base in Danish. What makes this case special, is that all content is migrated into Drupal from JSON-files, so there is no existing content to change language for, only configuration.

I updated and renamed these configuration files, to change from English to Danish:

sed -i "s|langcode: en|langcode: da|g" *.yml
sed -i "s|en: ''|da: ''|g" language.negotiation.yml
mv language.entity.en.yml language.entity.da.yml
sed -i "s|id: en|id: da|g" language.entity.da.yml 
sed -i "s|label: English|label: Dansk|g" language.entity.da.yml

I then installed a fresh instance of Drupal in Danish, importing the config:

drush site:install minimal --config-dir=../assets/config --locale=da -y

I installed the language modules, to allow adding English language, as an additional language:

drush install content_translation locale config_translation

Before finding this method, I tried to create Danish language, set it as default, and delete English. But in the exported config files, there were still many lingering langcode: en strings in the config files (maybe ~50?), so I thought it better to switch all instances manually. It seems to work well, so far ...

No problem @dydave, I am only glad I can help, and thank you @ericmulder1980 for creating this issue and MR in the first place :)

I installed Admin Toolbar dev-version in Drupal 10.4.6, applied this issue's patch, installed the Admin Toolbar Links Access Filter module, and got the warnings you shared in comment #13 🐛 Warn site owners about the removal of Admin Toolbar Links Access Filter Active .

I went to the Status page and got this Error message (HTML copied form that page):

Status Details

Errors found

Admin Toolbar Links Access Filter

The features of the Admin Toolbar Links Access Filter module are included in Drupal core since version 10.3 and therefore it should be uninstalled.
Since the module is no longer needed, it will be removed in future releases of Admin Toolbar when support for versions lower than 10.3 is dropped.

See issues: #3463291 → and #3487246 → .

The wording is spot on, and users who read it, have been informed that the module will be removed in the future, when support for versions lower than 10.3 is dropped. So this issue is RTBC.

And it will be great to eventually be able to remove this module, and continue adding marginal gains in Drupal :)

You're welcome @dydave! And thanks to you as well, for committing yet another improvement, however small -- it all adds up, to making Admin Toolbar a leaner and more manageable unit, since there are fewer elements to keep track of.

Eventually, all these seemingly marginal gains coalesce into having a large cumulative effect, allowing Drupal to really take off 🚀

It does look unrelated, @sandip you can always try to run that specific failing test again, to make it go green?

Also, adding the GIF's in the Issue Summary, to show visually what this issue is about.

@jatingupta40 The patch applied fine when I tried it, as it should do, when it says "MR !146 mergeable". That literally means that the patch applies with the latest dev-version of the module ...

This is the method I use, and as the last command shows, there are no error messages, showing that the patch was applied:

$ composer require drupal/admin_toolbar:3.x-dev@dev
$ cd web/modules/contrib/admin_toolbar/
$ wget https://git.drupalcode.org/project/admin_toolbar/-/merge_requests/146.diff
$ patch -p1 < 146.diff 
patching file admin_toolbar.install
patching file admin_toolbar.libraries.yml
patching file admin_toolbar.module
patching file config/install/admin_toolbar.settings.yml
patching file config/schema/admin_toolbar.schema.yml
patching file css/admin_toolbar.disable_sticky.css
patching file css/admin_toolbar.toggle_shortcut.css
patching file images/icons/collapse.svg
patching file images/icons/expand.svg
patching file js/admin_toolbar.sticky_behavior.js
patching file js/admin_toolbar.toggle_shortcut.js
patching file src/Form/AdminToolbarSettingsForm.php
patching file tests/src/Functional/AdminToolbarSettingsFormTest.php

Nice, removing CHANGELOG.txt was low-hanging fruit for easy picking, so great to get included!

I moved 🐛 Warn site owners about the removal of Admin Toolbar Links Access Filter Active under a new "Possibly postponed" header, since 21 may is getting closer ... isn't that the right thing to do? Also, it allows the users to have a few days, trying the latest dev-version, and report back if they find anything. If the Link Access issue does get done in time, it can always get included.

A release is planned soon (21 May), so this issue needs a review fairly soon, for it to be included ...

I agree @dydave, it seems redundant and not adding much value, so great idea with some spring cleaning! The patch works perfectly, and CHANGELOG.txt is deleted.

Hi @dydave and right back -- thanks for implementing the feedback so fast, 21 May is getting closer 😅

Your updates look great, and the shortcut is disabled on install by default. Nice touch that the icon is now also sticky, if "Disabled" is selected. And great with the clean up, it is always a good idea to remove unused code, and that tests are still green!

I think the current shortcut is fine, it's a custom one I defined myself. At some point in the future, it could be considered to offer a predefined list of shortcuts in a drop-down, so that it would be selectable, where "Alt + p" could be the default, for example these?

Alt + p
Alt + h
Ctrl + Alt + p
Ctrl + Alt + h
Shift + Alt + p
Shift + Alt + h

But a drop-down feature is probably best saved for next version, so this feature is RTBC 🚀

PS. A tiny detail, which perhaps could be fixed here as well when committing, is that perhaps "Toolbar: sticky" could be updated to just "Toolbar sticky" (or something like that) without the colon symbol, in this string?

The following settings mostly provide advanced configuration of the JavaScript behavior of the Toolbar: sticky and hoverIntent.

Thank you all for weighing in with feedback so fast, it's really great. The concerns aired are justified, and strong arguments that I agree with, so I am closing the issue.

Still, I learned more details about how the theming layer, so it was a win after all, for me personally :)

Thanks @dww for all your hard work with cleaning up Drupal core, keeping it lean and future proof, I very much appreciate it 🙂

Drupal is like a train departing the station, steadily gaining momentum, day-by-day becoming an even better tool for building advanced web sites. And since everything can be connected, it's easy to add new features, clicking it together like LEGO.

You're welcome, I was also positively surprised when I discovered how many strings can be changed with that method -- though there are some you can't.

Updating Issue Summary after switching to a template preprocess variable and Twig-based solution.

ressa → created an issue.

You can also insert each role into the Body field of the current user. The result is something like this (extra classes in bold):

Anonymous user:

<body class="path-node page-node-type-page anonymous-role">

Logged in user:

<body class="path-node page-node-type-page authenticated-role developer-role editor-role user-logged-in">

Insert this code in my_theme.theme file (replace my_theme):

function my_theme_preprocess_html(&$variables) {
  $current_user = \Drupal::currentUser();
  $roles = $current_user->getRoles();
  foreach ($roles as $role) {
    $variables['attributes']['class'][] = \Drupal\Component\Utility\Html::cleanCssIdentifier($role . '-role');
  }
}

Warning:

From https://api.drupal.org/api/drupal/core%21includes%21theme.inc/function/t...

By the way @smustgrave:

Also we are now mixing a form of things that will and won't be saved to config.

It seems to me like aggregation is changed from configuration to states, streamlining everything, and isn't that an improvement?

I just realized that this MR not only moves CSS/JS aggregation to the Development settings page, but also changes from using configuration to using states, which is another great improvement, so I really hope this can happen.

In an attempt to get the ball rolling again, I re-applied the changes manually in the latest Drupal 11.x version ... sadly I don't have the skills to git commit the changes to GitLab (I always work in the GitLab UI/Web IDE).

So I am attaching the updated patch, and maybe someone can pick it up from there? Thanks!

ressa → changed the visibility of the branch 3368033-move-cssjs-agg-may-2025 to hidden.

Thanks @dydave, for fast updates! The update label reads great now, it's immediately clear what it does.

To update toggle, or not: It's totally fine as it is then. The config variable is a minor detail, and probably understandable by most users. So let's keep toggle behind the scene :)

Behaviour with Sticky: I am fine with the current behaviour, but you could argue that it should slide away as well, if "Disabled, show on scroll-up" is selected. But I think it is fine as it is, especially if it takes a lot of work to tweak just right.

Enabled/Disabled/hook_update: This feature could be considered fairly niche (I will probably never use it) so maybe it should actually be disabled by default? This would also mean that there is no need for a hook_update. I believe this is the last outstanding task to consider. (As a side note, the shortcut conflicts with a browser add-on I use.)

Thanks @chhavi.sharma and @dydave for fixing this so fast, with lightning speed! ⚡

Awesome to get another little improvement included, before release. Thanks!

Thanks @dydave, for a speedy reply and update as always!

The path is fixed and the tests are green (I agree, tests really are great, when they catch these small, easily overlooked details) so let's ship it! 🚀

Pure awesomeness @dydave, that's much better!

How about slimming down the label to this?

[ ] Hide or show the toolbar with shortcut (Alt + p)

I think, that toggle can stay "behind the scene" for example in variable names, it's the user facing part that's important

Though the config names perhaps should perhaps be updated from enable_toggle_shortcut to enable_hide_show_shortcut, since you could argue that config is also a sort of user facing component ... Or is it easier to update everything from xyz_toggle_var to xyz_hide_show_var? I'll let you be the judge :)

About case, since we are using "Alt + key" everywhere else, I think we should also use "Alt+p" here.

I tried settings.php string overrides and it worked well (remember to clear caches):

$settings['locale_custom_strings_en'][''] = [
  'Choose a role' => 'Define your main activity'
];

From settings.php:

/**
 * String overrides:
 *
 * To override specific strings on your site with or without enabling the Locale
 * module, add an entry to this list. This functionality allows you to change
 * a small number of your site's default English language interface strings.
 *
 * Remove the leading hash signs to enable.
 *
 * The "en" part of the variable name, is dynamic and can be any langcode of
 * any added language. (eg locale_custom_strings_de for german).
 */
# $settings['locale_custom_strings_en'][''] = [
#   'Home' => 'Front page',
#   '@count min' => '@count minutes',
# ];

It's not entirely clear what happens, if admin approval for new users is required. Like, who wins -- this module, or Drupal?

This is from the project page:

Admin can configure roles need to display on registration form as well as can set roles need for admin approval.

I just tried, and it looks like a new user is blocked, if:

• Admin approval is enabled under /admin/config/people/accounts
• And no roles are selected under "Approval Roles (Select roles that need admin approval.)" under /admin/people/select-registration-roles-setby-admin

... which is the expected result.

But maybe this could be clarified in the project page text? Thanks!

Would an option to disable the "Show row weights" / "Hide row weights" toggle button, either completely or on a role-basis via Permissions fit in this issue as well, or maybe it is already handled in another issue, or need a new issue?

Hide vs. Toggle

About renaming from "Toggle" to "Hide", maybe it's too much work? I think we should at least visit the subject, and then decide if it's too much effort ...

My reasoning is this: "Toggle" means changing the state of something (like I already commented, see #63 ✨ Hide admin toolbar completely (on non-admin-routes) Needs review ).

Think about the Link weight button. It is using these words in the GUI:

• "Show row weights"
• "Hide row weights"

.. in the code you see this: tabledrag-toggle-weight-wrapper

But the button doesn't say "Toggle", right?

Advanced

Also, I do think moving it up a level from "Advanced" could be considered (again, see #63 ✨ Hide admin toolbar completely (on non-admin-routes) Needs review ).

Well, you certainly deserve the nice words @dydave, with all the work you have done recently, getting Admin Toolbar in tip top shape :)

And thanks @adriancid, that's great! My nomination for Maintainer role for @dydave does still stand. But it's not so important, as long as there are no obstacles for @dydave to perform the required tasks to work on Admin Toolbar -- more or less being functionally "Maintainer", all but by role.

Big thanks to both of you for graciously donating your time to maintain this essential Drupal tool, and expanding it with new functionalities.

Thanks @chhavi.sharma that looks much better. It looks like the test needs to be updated as well :)

It's this one:

admin_toolbar_search/tests/src/Functional/AdminToolbarSearchSettingsFormTest.php

You're welcome @m_i_c_h_a_e_l, it's great that we got to the bottom of this. I don't only answer in the Drupal Forum to help out, but also to learn some things along the way, or be reminded of stuff I haven't looked at for a while.

In this case I was confirmed that fields do get deleted completely, and the machine name released (if there is no content in it). But most importantly, I was reminded that the Fields page exists, which is actually a very useful tool.

Have a nice day!

I see ... So you also tried with for example $params['subject'] = 'My test subject'; ?

Because hard coded values should probably work, before proceeding with adding variables, and complicating stuff ...

Then, after all, it might be best to ask in the project :)

You're welcome @tonyknibb, I hope you get it working. Still, if there's no luck here in the Forum, then the project issue queue is probably better. But let's see, maybe it gets solved here in the Drupal Forum :)

My best guess is that (like the error message says) that the problem is that the $subject variable is empty.

Maybe test by updating the 6th line to the below, see if it's goes through, and take it from there?

$email_subject = "Testing the form;

Yes @stefan lehmann, users such as @jaypan and @wombatbuddy (often sharing complete solutions) and all the other nice volunteer supporters from the Drupal community are doing a great job, offering fast replies to Drupal support questions.

I already shared my opinion about the Forum in the issue about the new drupal.org, but I am adding it as related issue, just in case you or other users haven't seen it.

If a "password-hash.sh to SQL in phpMyAdmin" method gets working in https://www.drupal.org/forum/support/post-installation/2025-05-11/d11-ad... → it would be nice to add it to this page.

The source should get attribution, when added: https://dev.to/shriaas2898/resetting-admin-password-in-drupal-using-sql-...

I tried in DDEV and failed, with these steps:

Generate:

ddev php web/core/scripts/password-hash.sh 'pw'
password: pw         hash: $2y$10$CgEPpYcJk5LLkZFdavmwlO70bxWoE.Dxa6Lr.HCHWcWRfzzRW3SIy

Update:

drush sql:query "UPDATE users_field_data \
SET pass='$2y$10$CgEPpYcJk5LLkZFdavmwlO70bxWoE.Dxa6Lr.HCHWcWRfzzRW3SIy' \
WHERE uid = 1;"

Clear caches:

drush sql:query "DELETE FROM cache_entity WHERE cid = 'values:user:1';"

I looked for a Drupal core issue at https://www.drupal.org/project/issues/drupal → ... but didn't find any, so maybe you can create one @ryanbuckley@gmail.com and share a link here when it's ready? It would be great to get it working, and eventually included on this new doc page:

https://www.drupal.org/docs/administering-a-drupal-site/security-in-drup... →

Thanks!

The "Drupal 7 solution: When other methods don’t work" section at the end needs to be either updated, or deleted.

Thanks @drumm, I ported the page to modern Drupal at https://www.drupal.org/docs/administering-a-drupal-site/security-in-drup... →

Perhaps it can be added to the menu?

I kept the code example at the end ("Drupal 7 solution: When other methods don’t work"), with a warning that it's for Drupal 7. Maybe it should just be deleted?

You have a better chance of a qualified answer, by asking directly in the project. Please share a link here, when you have created an issue. Thanks!

https://www.drupal.org/project/sendgrid_integration →

I just remembered, you can also see all fields under the Field list at /admin/reports/fields, maybe useful?

Great, thanks @adriancid!

I would like to nominate @DYdave to get the "Maintainer" role, since it would make his job maintaining Admin Toolbar easier, and allow him to be more efficient. I hope you and @romainj would consider this. Like I wrote he has proven himself to be:

[...] a very diligent and thorough Drupal contributor, and it would be a natural progression to grant you the "Maintainer" role, so you don't have obstacles, allowing you to update the project page, and other important tasks, such as documentation.

I added a comment in 📌 Please put link to "Forums" back in the "Community" pulldown menu Active suggesting to restore links to the Support page and the Drupal Forum from the menu, since there are few roads to the Forum.

It should get cleaned up ... I just tried creating a field called "Subtotal" and it automatically got the machine name field_subtotal. I then deleted the field, and created a new field, again called "Subtotal", and it got the same machine name field_subtotal as well ...

I recommend that you get a test install up and running, to quickly run experiments in with situations like these, and DDEV is great for that. Or you can use https://simplytest.me/.

I think linking to the "Support" page (drupal.org/support) and Drupal Forum (drupal.org/forum) would be really nice, under "Get support" in the mega menu on https://new.drupal.org:

Drupal CMS User Guide
Learn how to set up your site with Drupal CMS

Drupal User Guide
Learn to build with Drupal

Drupal Support <<< Add this menu item
See all help options for Drupal

Drupal Forum <<< Add this menu item
Ask the Drupal community for support

Training
Upskill your Drupal team

Drupal Slack
Get support and collaborate with the community

I assume you are on Windows since you mention Powershell, perhaps try following this guide?

https://www.drupal.org/docs/develop/local-server-setup/windows-developme... →

And if something is still not clear, please create an issue, to clear it up and document it, and help improve Drupal and DDEV.

Remember that this is a community effort by volunteers, and we all need to do our part, thanks in advance:

https://github.com/ddev/ddev/

I just ran into this odd behaviour, and agree that it's Major, and would be awesome to get fixed, since many users can spend a long time, trying to understand why the titles suddenly vanished in their Views :)

In the meantime, thanks for suggesting a pragmatic workaround until this gets fixed @darkodev. For example, you can add two page title blocks, like this:

• "Page title Content types" using Visibility: Content type
• "Page title Views" using Visibility: Pages

It works well, and I have added it as workaround in the Issue Summary.

You're welcome! And great catch, the order is much better now.

Thanks for clearing that up @catch, and that's totally all right @quietone. As a side effect I realized what a useful feature the ddev snapshot command is, to quickly roll back changes. I also learned a bit or two about making a hook_update and running phpcs, so it turned out to be a gain after all. I am pasting the end result below, just in case someone else needs to do something similar in the future. Thanks for the Doc page link @penyaskito!

Unused hook_update code:

use Drupal\Core\Datetime\Entity\DateFormat;

/**
 * Add date-only date formats.
 *
 * @see https://www.drupal.org/project/drupal/issues/3498980
 */
function system_update_11202(): string {
  $message = NULL;
  $date_formats = [
    'long_date_only' => [
      'label' => t('Long date (date only)'),
      'pattern' => t('l, j F Y', [], ['context' => 'PHP date format']),
    ],
    'medium_date_only' => [
      'label' => t('medium date (date only)'),
      'pattern' => t('D, j M Y', [], ['context' => 'PHP date format']),
    ],
    'short_date_only' => [
      'label' => t('short date (date only)'),
      'pattern' => t('j M Y', [], ['context' => 'PHP date format']),
    ],
  ];
  foreach ($date_formats as $id => $date_format_info) {
    if (!DateFormat::load($id)) {
      $date_format = DateFormat::create([
        'id' => $id,
        'locked' => FALSE,
        'status' => TRUE,
        'pattern' => $date_format_info['pattern'],
        'label' => $date_format_info['label'],
      ]);
      $message .= "Date format " . $date_format_info['label'] . " was created.\n";
      $date_format->save();
    }
  }
  return $message;
}

Thanks @thomas.frobieter and @dydave! I agree with the solution in the latest MR, to include the feature inside Admin Toolbar module, and not as a separate module, to keep things simpler.

I also noticed the Gin-specific code, and handling Gin-specific solutions in a follow up issue seems like a good idea.

Perhaps the new feature could be placed on same level as "Toolbar sticky behavior" and "Toolbar hoverIntent behavior", below them, and not under "Advanced settings"?

Instead of "Toggle", it could be branded as the less ambiguous "Hide shortcut" to make it immediately clear what the feature does. "Toggle" is ambiguous, and could mean for example switching between a Light and Dark mode. The option could then be something like [ ] Enable Hide shortcut (Alt + p) ... But if everyone agree that "Toggle" is best, that's also totally all right :)

Just updating the title, since the Announcement date update will also get done here.

@penyaskito Thanks, that sounds good, and I have updated the MR in the other issue, adding the new short date format in the announcement feed template.

And I just now realize that there actually already was an MR in this issue created by you, when I created the new issue about adding three new date formats ... I am really sorry, and feel bad now. I truly didn't intend to take over the task. I don't know how, but I totally missed it.

Thank you very much @penyaskito for fast and thorough review, I greatly appreciate it.

I have made the changes you suggested, and your new method for setting the date formats were spot on, so that made it a lot easier. I also restored olivero_medium format.

As you suggested in the original Announcement issue, I have updated the date format to short_date_only in this MR as well.

I have updated Remaining tasks, and added the upgrade path test task as well. I wonder if there is a documentation page on how to write upgrade path tests, going from Drupal 10 to 11 (I guess)?

Add --extensions tip.

Thanks for adding another option with drupal/recommended-project, but that is already covered on the DDEV Quickstart page, linked to here:

Go to the Drupal section of the CMS Quickstarts and follow the instructions.

So I think these new lines are not necessary and can be removed:

If you do want to develop a project on top of Drupal core:

composer create-project drupal/recommended-project my-project

I do think this issue is still relevant for resolving this part of the issue: "... and start using in announcements feed", so maybe it should be reopened ("Postponed"?), and an MR made for date format in the announcement feed, when the shorter date format is ready?

I somehow managed to make an update hook for existing installations, so they now also get these date only formats. But only if there aren't pre-existing date formats with the same machine names.

I also removed Olivero Medium data format. It is replaced with the new Short date format, in the Olivero theme. Luckily, if for some reason a date format cannot be found, the fallback date format is used.

PS. I had to close the original branch, and start fresh, since rebasing was not possible. Oh, and Nightwatch had to be re-run three times, before it finally went green :)

That's great news, thanks @hongpong!

A helper text like the one you suggested would work great.

I ran into a minor problem while trying to document a complete process in DDEV in How to generate WordPress content and import into Drupal → , and added an issue (have to run drush migrate:import --all twice). Making the "Import everything" button here will probably also fix that challenge with drush migrate:import --all, by correcting the requirements between the migrations, and getting the right order of the process set in stone, to get the button working.

ressa → changed the visibility of the branch 3498980-add-date-formats to hidden.

Restoring "Needs discussion" tag, sorry @Grevil :)

I thought it was a left over tag, but now see it was added yesterday ...

It is a degradation in my opinion, and loss of a fundamental feature in Drupal core, to not offer an administration menu, which supports horizontal orientation.

The current Toolbar is flexible, and offers both a horizontally oriented menu at the top, while allowing the user to switch to a vertical orientation, in the left side, by clicking the arrow icons.

The new Navigation only has a menu in the left side, like in WordPress.

I think the new Navigation likewise should offer both a horizontally oriented menu at the top, as well as a vertical orientation. Where has this decision to shoehorn the user into using a left side menu been discussed, and on what basis was it decided?

Is there an issue?

PS. Yes, I know that contrib modules can extend Drupal core modules :)

Thanks for clearing that up so quickly @penyaskito, if you have time, feel free to update the MR with your suggestions. Maybe the update hook is safe to add, as a first step?

That sounds great, thanks for the update :)

I can still use a grouping feature, so it's still relevant. Do you think a native solution, built into the module will be possible, or is your opinion the same as in August 2022?

[...] I think this can't work, setting this won't fix for that reason. Proof me wrong otherwise and I'll reopen this.

... or perhaps this has become more feasible in version 5?

Thanks for the feedback @quietone, I have updated to use "(date only)" from "(without time)".

About "Olivero Medium" I am not sure, so I have updated the Issue Summary, with these Remaining tasks:

• Figure out what to do with "Olivero Medium", since it has the same format as "Short date (date only)".
• Should existing installations also get these date only formats, via an update hook?

Update links to shortcut examples.

Thanks for all the efforts here! I have a few comments:

• In Firefox, Alt + h opens the Help menu item, so maybe Alt + Ctrl + h is necessary?
• Instead of "Toggle", could it be branded as a "Hide shortcut"? It is then immediately clear what the feature does. "Toggle" is ambiguous, and could mean for example switching between a Light and Dark mode.
• Since this affects the entire Admin Toolbar, and to keep things simple (I am not sure the maintainers prefer a new module ... @dydave: What do you think?), maybe -- instead of in a new module -- we can instead add it as an option on the Admin Toolbar settings page (/admin/config/user-interface/admin-toolbar) below the new "Toolbar sticky behavior" and "Toolbar hoverIntent behavior" settings, which were just added ... Perhaps something like this?
  

  [ ] Enable Hide shortcut
  Adds a keyboard shortcut (Ctrl + Alt + h) to hide and show the Admin Toolbar.

• Could we use capitalized function keys, like we do for Admin Toolbar Search shortcut (i.e. Alt + Ctrl + h) and on the Module shortcuts → page?

I don't have any comments about the code challenge (check your post, there is a domain in there ...)

About a link to the Forums, yes -- there ought to be a link to the Drupal Forums → above the "Drupal Slack" link under "Get Support" menu ...

See also https://www.drupal.org/forum/general/general-discussion/2025-02-20/about... →

Adding one more small improvement, if possible? :)

ressa → created an issue.

Thanks for finding a good place for this proposal @quietone.

Updating link to an active example of a public internet Kiosk solution for libraries (https://www.magenta.dk/en/solutions/os2borgerpc-en/ and https://www.os2.eu/os2borgerpc).

You're welcome @dydave 🙂

And great that you checked the contrast. But, as I see it #000000 (black) would give the optimal contrast, being black text on white background, and don't we want maximum contrast?

But #333333 also works well, since it's not blue, so that's an improvement, and totally fine. Also aesthetically, it could be more pleasing -- so I'll RTBC it!

Switching to CSS variables is a good idea, if it makes development and maintenance easier, going forward. Though I do also see advantages in keeping it simple -- there are pros and cons for each method, as always. For example, looking at the Klaro CSS you shared, I get an "eyes glaze over" feeling -- it looks very complicated to me 😅

Nice! Thanks as always for a fast and efficient response and solution @dydave, I am looking forward to the next release!

Update Issue Summary, to cover ongoing support sentence as well.

Thanks @cilefen, that's a great suggestion, and I have updated the MR.

Thanks for weighing in @mortona2k, and sharing your thoughts.

Though, please don't focus too much on CiviCRM ... I only used that in the Issue Summary, since that's the only "Customer Relationship Management" system I have tried :) I could just as well have used one of the other systems, which collectively share the trait, that they handle data for individuals or businesses, and offer relevant tools.

My point is simply that, like you also stated: CRM is well established as meaning "Customer Relationship Management", so we should use that as well in Drupal, to make it clear for outsiders what it is, and also to make it discoverable, if people search for "drupal crm" or "drupal customer relationship management".

Clarify that this issue is about a generic Customer Relationship Management system, not Drupal contacts.

If this Member Platform project is aimed at managing Drupal contacts, maybe this issue does not belong here?

You need to follow the instructions very methodically:

https://www.drupal.org/docs/getting-started/installing-drupal/install-dr... →

If at any point you meet an obstacle, please create an issue, and help improve Drupal and DDEV:

https://github.com/ddev/ddev/

Please add a link here, when you have created the issue, so that others can also be helped. This is a community effort, and everyone here is volunteering their spare time. Thanks in advance.

That link does not explain the change.

This issue is not about managing Drupal contacts, it's about creating a Customer Relationship Management system in Drupal.

"CRM" is universally understood to be an abbreviation for "Customer Relationship Management", and someone looking for a CRM is much more likely to use the word "Customer" not "Contact" ... so I wonder why the title was changed?

I created 📌 place link to Drupal's PHP requirement first on PHP too old install error Active .