🇩🇰Denmark @ressa

Have you created an issue about this in the issue queue of the Drupal CMS project?

There's a better chance of getting a qualified answer, if you ask in the issue queue of the project:

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

Add tip about Custom Drush command for managing Twig debugging and CSS/JS aggregation → in Issue Summary.

Great suggestion @jwilson3 and thanks for updating the code so quickly @keshav patel.

I found it: https://themeforest.net/item/martex-software-saas-startup-drupal-10-them...

Maybe you could share a link to the Martex theme?

Ah yes, good catch. I have updated the status and info box, thanks!

I think the most basic steps to use this module should be added. It's not stated on the project page, nor is there a link to a documentation page ... (maybe there isn't one?)

This is pretty crucial information, so maybe someone can review it, so we can get this committed and released?

Since both @jmcintyre and me have updated our versions, it's no longer relevant for us, and we can close it. It can always be revisited, should it happen again.

When I tried to update to the 4.3.10 security release for Search API Solr, I still got the "package is fixed by partial update" message, blocking the update.

I finally just deleted the composer.lock file, ran composer install, and the latest versions were installed of Search API Solr and solarium/solarium.

Odd that this happened ¯\_(ツ)_/¯ ... anyway, fingers crossed, that it won't happen next time.

It would still be great to get a basic set up of Solr Cloud for Drupal on a production server documented.

To avoid the odd non D11-ready module from being a blocker, I still start new projects in Drupal 10, since not all contrib modules are Drupal 11 ready yet -- though it's getting better all the time:

https://dev.acquia.com/drupal11/deprecation_status/projects?next_step=Fi...

Also Drupal 10 EOL is more than a year away:

Drupal 10 end of life

Drupal 10 will reach end of life mid-late 2026, when Drupal 12 is released. The exact date is not yet set. Check out the sample release schedule for estimates.

https://www.drupal.org/about/core/policies/core-release-cycles/schedule#... →

Except of course, if adding Drupal 10 support takes a huge effort ...

ressa → created an issue.

@charles belov: I just tried with the patch and Drupal 11.x-dev which worked well, and I see the new "Require the Description field" option. Maybe simplytest.me was temporarily challenged?

@keshav patel created a Drush command (theme:dev) which toggles Twig debugging, caching and aggregation, included in the latest Drush 13.6 release. See also Drupal Documentation page Disabling and debugging caching > Toggle Twig debug, caching and CSS/JS aggregation with Drush → .

Adding "When enabled" list for theme:dev command.

Add CSS/JS in theme:dev header.

Mention cache under theme:dev Drush command.

Add note that it has been included in Drush.

The theme:dev Drush command was added in Drush 13.6, see Add Drush command to toggle Twig debugging and CSS/JS aggregation #6267.

The new command is mentioned on https://www.drupal.org/docs/develop/development-tools/disabling-and-debu... → and this page can be deleted.

ressa → created an issue.

It's not present in composer.json, like I wrote:

Do you mean the Drupal installation composer.json? Because it is not listed there [...]

$ cat composer.json | grep sol
"drupal/search_api_solr": "^4.2",

@jmcintyre: Do you remember if you have installed solarium/solarium explicitly, by itself, or can you see it in the composer.json of your Drupal installation?

You're welcome @dydave! I am very glad how this feature was re-written by you, and made into a much more complete solution with great care and attention to detail -- and how it turned out in the end. Yet another awesome addition to an already great module! 🎉

I agree that the project page could do with an update, like most project pages could on a regular basis ... I have created 📌 Update the project page Active .

ressa → created an issue.

Maybe we can squeeze this issue in as well?

Thanks for solving yet another issue with thoroughness and attention to detail @dydave, great to get another one completed!

I was also right away missing the menu tabs, when I was trying out another MR, where I had to hover over menu items to switch between the setting pages of the three Admin Toolbar modules. So slow 🙂

ressa → created an issue.

ressa → created an issue.

Give "Toggle Twig debugging and CSS/JS aggregation with Drush" a top level header.

• Add info on new Drush theme:dev command and link to doc page.
• Remove twig:debug section, since it has been removed, and didn't work.

I believe I have not installed solarium/solarium explicitly, by itself, or in a specific version.

Do you mean the Drupal installation composer.json? Because it is not listed there ... Or do you mean composer.lock?

Yes, it's so great, thanks @keshav patel!

Can someone with the right permissions grant credits?

Thanks for the suggestion, I get the same message as @jmcintyre:

$ composer why-not drupal/search_api_solr 4.3.8
drupal/search_api_solr     4.3.8    requires         solarium/solarium (^6.3.7)                 
drupal/recommended-project dev-main does not require solarium/solarium (but 6.3.6 is installed) 
Not finding what you were looking for? Try calling `composer require "drupal/search_api_solr:4.3.8" --dry-run` to get another view on the problem.

Composer [why-not drupal/search_api_solr 4.3.8] failed, composer command failed: exit status 1. stderr=

Here's the result of the suggested --dry-run:

$ composer require "drupal/search_api_solr:4.3.8" --dry-run
./composer.json has been updated
Running composer update drupal/search_api_solr
Loading composer repositories with package information
Updating dependencies
Your requirements could not be resolved to an installable set of packages.

  Problem 1
    - Root composer.json requires drupal/search_api_solr 4.3.8 -> satisfiable by drupal/search_api_solr[4.3.8].
    - drupal/search_api_solr 4.3.8 requires solarium/solarium ^6.3.7 -> found solarium/solarium[6.3.7] but the package is fixed to 6.3.6 (lock file version) by a partial update and that version does not match. Make sure you list it as an argument for the update command.

Use the option --with-all-dependencies (-W) to allow upgrades, downgrades and removals for packages currently locked to specific versions.

Installation failed, reverting ./composer.json and ./composer.lock to their original content.

Composer [require drupal/search_api_solr:4.3.8 --dry-run] failed, composer command failed: exit status 2. stderr=

From composer.lock:

[...]
            "require": {
                "composer-runtime-api": ">=2.0",
                "composer/semver": "^1.0|^3.0",
                "consolidation/annotated-command": "^2.12|^4.1",
                "drupal/core": "^10.2 || ^11.0",
                "drupal/search_api": "^1.37|1.x-dev",
                "ext-dom": "*",
                "ext-json": "*",
                "ext-simplexml": "*",
                "laminas/laminas-stdlib": "^3.2",
                "maennchen/zipstream-php": "^2.2.1|^3.0.2",
                "solarium/solarium": "^6.3.5"

... and:

[...]
        {
            "name": "solarium/solarium",
            "version": "6.3.6",
            "source": {
                "type": "git",

Thanks for keeping track of the changes in Drupal core @quietone, and using the standard template to streamline the process is best.

Thanks for sharing @dydave, I asked about it in that issue.

Perhaps, if the handling of menu items in Drupal core will be moved from Toolbar to Navigation, Admin Toolbar should be rebuild on top of Navigation instead of Toolbar, and offer an administration menu placed at the top of the screen, working much like the current one, with the same features?

Or if Drupal core Toolbar becomes a contrib module, Admin Toolbar could simply carry on, only based on the contrib module Toolbar?

I prefer the administration menu to be at the top of the screen, and it looks like a vertical menu on the left side of the screen is the only option in the new Navigation ... The same position as in WordPress, which I am a not a fan of, since you have to hover, as well as click, and then click some more, to access a common task, such as node display configuration.

Ideally, it should be like Admin Toolbar → , where you hover your way over menu items, all the way to the destination. See 🌱 Usability Review from the UX Meeting (5 Apr 2024) Active for more feedback.

Is there an issue for switching the position of the Navigation menu from the side, to the top?

Also, Admin Toolbar users are uncertain what this means for that project, see 🌱 Future of Admin Toolbar if Toolbar is removed from Drupal core Active . Maybe Admin Toolbar could be restructured, and built on top of Navigation, instead of the Toolbar module? :)

Yes, it does seem not right ... and if there ends up being more than just a few lines of updates, it gets annoying to save and refresh. It's a grayzone.

Fix formatting.

Add Lenient all projects example, update project name to match Github repo.

I remembered this issue today, and realized I had forgot to update it, after it got solved by Drupal Lenient Composer Plugin. Thanks Matt Glaman! 🎉

Have you tried Asset Injector → ? It really shines, when you just need to do minor CSS adjustments, for example to the administration theme, and creating a sub-theme is overkill.

Fantastic work @dydave, thanks! I tried the MR, and it works flawlessly, and the shortcut is enabled after an install. I also tried installing the current dev-version, patch with this MR, and then run database updates, and the new feature was enabled, cool 😎

Nice job with also adding tests, which is always best to have, and refactoring the JavaScript code and its location, so it's only loaded if the feature is enabled. I checked the source, and it works well -- the file admin_toolbar_search.keyboard_shortcut.js is only present, if the Alt + a shortcut is turned on, nice! And it's indeed a cool touch, and very user friendly to show the shortcut tip, when hovering over the search field.

I agree, the changes to the project page can always be handled in another issue as a post 3.6.0 task, in the next release Meta issue, and I have added this under "Remaining tasks".

Also, maybe we could look into adding FunctionJavascript Tests for the added JS code.

Great idea, we should add a follow up ticket for this!

I did a quick, direct correction in the MR's README file (shortcut to "Alt + a") to not stall the issue with a "Needs Work" change, I hope it's all right.

Overall, it looks great and ready to me. Thanks yet again @dydave for another stellar job! 🎉

Just adding a "Remaining task" item about the search shortcut, and moving it into the "Planned" list :)
(Renamed from "Important" ...)

Thanks @tirupati_singh for fixing the case for "Admin Toolbar Search settings", that seems like the right solution :)

Thanks @dydave for looking at the weights and experimenting with a simpler approach. I think your pragmatic choice is better and less invasive, with less weight setting, letting the modules' sort themselves alphabetically, while making sure that of the three Admin Toolbar modules, the main module is always at the top.

My thoughts about having them grouped around a fairly low number, was that they would stay together, even if another module added a low weight. But setting it to -1 is great, and we can always revisit weights, if someone notices that they three Admin Toolbar modules have been separated by another module 🙂

It looks ready to me!

PS. I updated the title, since "local tasks" is so non-descriptive, and I can never remember what they mean ... I hope it's all right?

I don't know that theme, but usually you need to create a sub-theme → or alternatively -- for very small CSS and JavaScript changes -- Asset Injector → works great.

Or maybe ask in the theme issue queue, to get qualified support?

Thanks for a fast reply, and for making the module @apmsooner. I am sorry that I collected so many, and disparate tasks in a single issue, and I have created an issue for each, to deal with them individually.

I tried in Drupal 10 as well, and also get the errors there ...

Thanks for explaining some more details about how the module works, like the schema thing. I did try to map and copy content from a "Body" field to a "Plain text", and got problems -- there were no fields under "Field source" in the "Mapping" page (only "None", "NULL" and "Custom value") ...

Different types of "Source" ...

Fundamentally, there is something about the naming of fields which seemed not intuitive to me ... A video would be all right, but I think it would be a better idea to make the elements in the GUI intuitively understandable.

New users, like myself, who jump into using the module wonder --

How can Source be optional? Or is the "Source" mentioned under "Add field updater" not the same "Source" as on the "Mappings" page?

And now, I went back and actually took the time to read the Quick start, and the penny dropped, and I experimented a bit more ...

If at all possible, I think the "Source field" should only be displayed on the "Add field updater" if it makes sense -- i.e. if the "Target field" is a Paragraph. For a "Plain text" field, it would never be relevant, I would think?

Thinking more about this, how about flipping the order from selecting Target first, to selecting Source first? Then, the allowed Target field schema types can also be limited to only be the same schema types as the Source.

In other words: If the user selects a "Plain text" field as Source, then only fields of type "Plain text" should be offered in the resulting Target drop-down. In the image below, the have already selected "Text1" and "Plain text" schema fields such as "Text2" were made available.

Similarly, if the user select a Paragraph field as Source, the drop-down should only offer Paragraph type fields. Also, where it's relevant a "sub drop-down" with extra value options should be presented as well, in this case, values such as target_id.

Would that be possible?

ressa → created an issue.

I had a limited understanding when I created this issue :) I'll add comments about it in the original issue.

ressa → created an issue.

ressa → created an issue.

ressa → created an issue.

Beautiful, thanks!

Thanks for taking a look at this issue @dydave, I very much appreciate it!

And great updates to the code. Like I wrote in the Issue Summary, I simply lifted the code from the Tour module issue, and here's where the key gets set, which I coped and altered:

https://git.drupalcode.org/project/tour/-/merge_requests/67/diffs#c35c44...

Great find in Project Browser, and good to get confirmation that the method is used several places.

And lucky that your french keyboard acts differently, so we caught this in advance 😅 Your update works equally well, and Alt + a sets focus in the search field.

I think we can never be totally sure that any shortcut is not already in use in some browser. But it looks to me like Alt + a does nothing Firefox and Chromium ...

About other tickets, there is my original issue, which added access key parameter "a", or maybe it's some other issue?

Great suggestions about expanding the scope of this issue! I have added your suggestions in the Issue Summary under "Remaining tasks":

• Remove the accesskey attribute based shortcut alt + shift + a <<<< IN MR ALREADY
• Add a JavaScript based shortcut Alt + a <<<< IN MR ALREADY
• Adding a tooltip over the search with information on the shortcut << NEW TASK
• Providing information on the project page about the shortcut << NEW TASK
• Make the shortcut optional, enabled by default << NEW TASK

Future plans, maybe in a follow up issue?

Allowing users to configure shortcut, either through the interface or at the very least with some kind of override in code.
Ideally, it could be a translatable string so the default value could be changed automatically for certain languages (localize.drupal.org), for example, maybe in Polish "Alt + a" is a combination for a special character (?!) 😅

Making the shortcut configurable would be fine with me. Or, for a start (to simplify things) it could be an optional setting (checkbox) under Admin Toolbar Search, like "Enable search form shortcut Alt + a", and enable it by default? Then, if there is a occasional clash of shortcuts, these few users who experience a problem can disable it. Then later, we can consider expanding the support for configurable shortcuts, in a follow up issue?

Looking forward to your feedback!

Thanks @dydave and @tirupati_singh for creating, reviewing and improving tabs for Admin Toolbar!

(I was never sure what "local tasks" meant in Drupal -- for example in Views, "Tabs" is used, which is universally understood as being the same as a tab in a spreadsheet in Calc/Excel.)

Anyway, naming things like these menu tabs is not easy, since there is a main module, and submodules ... But I think you both reached a good balance, and the page and tab titles make sense intuitively, which is the task here.

And I agree very much with you @dydave, adding tabs is a great idea, which makes navigating between these naturally, closely related modules super easy.

Another GUI thing that I planned on addressing at some point with an issue, was the order of the three modules under "User interface", which has annoyed me for a long time. Perhaps we can take care of it, now that the UI is being worked on?

I have updated the MR, and added weight to the three modules, so that the order is more hierarchic, with "Admin Toolbar" at the top.

Before:

• Admin Toolbar Search
• Admin Toolbar Tools
• Admin Toolbar
• Shortcuts

Better?

• Admin Toolbar
• Admin Toolbar Search
• Admin Toolbar Tools
• Shortcuts

What do you think about this?

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

Thanks @keshav patel, it's very clear now, how the module works. And great that there's also Drupal 11 support.

Perhaps, as a final touch, you could consider setting 1.0.x as the default branch in the GitLab repo, since that's where development takes place?

Add link to the great article Migrating JSON files into Drupal by Mauricio Dinarte (2020).

Of the three formats, JSON is the most used, so maybe let's place it first in the title? Also, referring to Drupal 8 seems dated, so maybe simply use Drupal?

PS. Maybe add Drupal 11 support in *.info.yml? It seems to work fine ...

Thanks, I get it now -- also after re-reading the project page a bit more attentively :)

Maybe you could consider showing two images of how it works, of setting the defining the default value for a field, and then showing the result, when you are creating a field of that type? I think then I would have understood it faster how it works.

Maybe include something like this on the project page?

Set default value for "Text (plain)" field types

Default value already set, when creating a new field of type "Text (plain)"

I am also seeing this ... Search API Solr is stuck at 4.3.7 and won't update to 4.3.8.

All other modules (Search API, Leaflet, Cache Exclude, etc.) got updated fine, except for Search API Solr. This is from my composer.json:

        "drupal/search_api": "^1.29",
        "drupal/search_api_solr": "^4.2",

Like I wrote, Search API was updated fine with composer update drupal/search_api to version 1.38.0 ...

Yet, composer update drupal/search_api_solr reports back "Nothing to install, update or remove".

So there seems to be a problem with Search API Solr. We shouldn't need to give it special treatment with "--update-with-all-dependencies", right? So I'm re-opening this issue.

Thanks everyone for getting this MR over the finishing line, it feels great to have one less patch in composer.json :)

ressa → created an issue.

You can also create a static clone with HTTrack → : Crawl it on your own local installation, and upload it to the server.

Of course, a lot of Drupal features are then not available, like user log in, user comments, sorting Views, search, etc.

I am glad you like the idea, feel free to share your opinion in the Github issue, to also make the Drush maintainers aware. I am not sure if they are active in this Forum ...

If you have time, maybe you could even give it a test ride, and check out the MR created by @keshav-patel?

For anyone who wants to try it, it's very easy: Just add the content of the PR in a new file here:

/vendor/drush/drush/src/Commands/core/CachingAggregationCommands.php

ressa → created an issue.

I created Add Drush command to toggle Twig debugging and CSS/JS aggregation #6267.

You're welcome @dydave, and great to see more issues added, thanks!

And nice that you explained your hopes and plans for the module, and importance of the different issues, it will surely help the community to know where to put their efforts.

I have added an issue under "Nice to have", about updating the shortcut to a more universally supported solution, perhaps it's possible to include that as well? 🤞

Thanks @itamair. Just leaving a note here, that the last release of Drupal 9.5.1 was September 2023, and Drupal 9 reached End of Life November 2023 ... but great support, even for EOL versions :)

• https://www.drupal.org/project/drupal/releases/9.5.11 →
• https://www.drupal.org/about/core/policies/core-release-cycles/schedule#... →

Awesome! 🎉 Thanks @aaron.ferris for kickstarting the solution, and @dydave for carrying the task to completion so tenaciously!

I'll surely share any future ideas with the community -- I actually once had another idea, which got added (shortcut to search). But I since found a better, more universally supported solution, and I'll add it to the version 3.6 Meta issue, and we can see if it's possible. Thanks!

Yes @dydave, I agree we make a good team -- the Admin Toolbar is getting some serious attention 🙂
And it sounds great that the Meta issue is useful, onward towards more improvements!

Ah yes, you're right! Thanks for taking the time to carefully explain the correct method, and steps required to test the MR. I totally missed the crucial first step, as you describe, to start out from version 3.5.3 -- that was the missing piece of the puzzle.

I tried again with the method you describe, and everything worked, just as expected -- no errors or warnings, just a perfect, brand new, beautiful user interface!

It was really great to get this cleared up for me, and we can disregard my last comments, the MR is RTBC!

PS. And no problem at all, that we tried some new stuff out, but that was it was scrapped in the end. It's very much a good thing, as I see it: To experiment, and see if a new feature brings something new to the table -- each of the features could have been fantastic additions. In this case maybe not so much -- but at least some great code was created for potential later re-use, recycling is good 🙂

I added this sentence in the sub-theme intro text, since it could be more explicit, and clarify to new sub-themers, what the point is. Does this help?

The point of sub-theming, is to not touch the parent theme -- except updating it, when there's a new release -- while doing any modifications ("overrides") in the sub-theme. Now, you can update the main theme, without having to re-implement changes.

https://www.drupal.org/docs/develop/theming-drupal/creating-sub-themes →

Expand intro text, to clarify the benefit of sub-theming.

Wondering if this is going to solve my problem or just add another layer to it. 

Well, at least two Drupal users believe that it's the solution, so maybe you should go ahead and try it? :)

Reading this page might answer some of your questions, like how little is actually required for a sub-theme to work:

https://www.drupal.org/docs/develop/theming-drupal/creating-sub-themes →

In your case, it could be as little as a mysubtheme.info.yml file and the Twig file user.html.twig you mention.

About not having to modify the base theme (as you did in your original post) which me and @jaypan answered: That is the point of making a sub-theme -- to inherit everything from the base theme, but don't modify the base theme.

It's then your task to keep an eye on any changes in the original base theme structure or template files -- if they change, you need to update your custom Twig template files accordingly. If you switch to a new theme you most likely need to work over the templates again, since things probably change between themes.

Ok, great to get clarified that it's not possible. Did you all see that Case Studies are shown in the list, if you click the tag, like 11.x?

Anyway, the question is now where you both stand on removing version?

It's so great to get this feature included in the module! 🎉

Thank you as well @dydave for the great co-operation, and also very timely and productive code updates, great suggestions for improvements in functionality and user interface, as well as openness to my suggestions, I very much appreciate it!

And yes, let's add follow up issues, if there seems to be a need for that 🙂

Your plan about including some more issues for the next release is a great idea, and I agree. So I went ahead and created a Meta issue, where we can perhaps gather the relevant issues, to more easily keep track of where an extra effort is needed? Thank you!

ressa → created an issue.

Yes @dydave, I also know very well how the idea of adding a cool feature can lead you down some roads, only to turn out that it may not be very useful after all ... though it was interesting building it. But if it's not adding value or quality to the final result, it's time to Kill Your Darlings 🙂

I agree that it would be too bad to lose all the great code, so great call making a fresh MR to preserve it, in case we might want to resurrect these, or some other features, and make them available as settings via the GUI, or maybe just re-use the code in some other way.

The new MR works perfectly! I agree that the user interface now looks great, and is very simple and intuitively understandable.

A last detail, is that I get this error, if I start with the current dev-version, install the Admin Toolbar module, apply the MR here, and then visit the settings page, and I added a comment about it:

Error message
Warning: Trying to access array offset on null in Drupal\admin_toolbar\Form\AdminToolbarSettingsForm->buildForm() (line 135 of modules/contrib/admin_toolbar/src/Form/AdminToolbarSettingsForm.php).

Also, I can trigger this with the same method, but am not sure how to fix it:

Error message
Warning: Trying to access array offset on null in admin_toolbar_toolbar_alter() (line 38 of modules/contrib/admin_toolbar/admin_toolbar.module).

When these last two details are fixed, it looks ready to me 🙂

Thanks @m_i_c_h_a_e_l, good to hear that you found a solution :) You can always switch over to Bootstrap later, if you feel like it.

Did you create a sub-theme with the standard sub-theme method → , or did you use 📌 [PP-1] Allow starterkit theme generator tool to clone Olivero Postponed ? Though it doesn't look quite ready, yet ... Or maybe https://www.drupal.org/project/drupal_cms_olivero → ?

Many things have changed between Drupal 7 and modern Drupal, so there is a lot to learn. But you are in luck, since you missed out on many of the growing pains during Drupal 8 and 9, like Composer version 1 being extremely slow, many Drupal 7 modules not being ported yet, no GitLab integration for MR's, not to mention no DDEV/Lando ... Drupal 10 in 2025 is a breeze to work with, in comparison.

Did you check out the Drupal User Guide → ? A Drupal 11 version 📌 Update user guide for Drupal 11 Active is very close to getting released ...

Thanks @eojthebrave, I have added this as a completed step in the Issue Summary. I checked the pages where it can be downloaded, but it doesn't seem to be available, but I am looking forward to it.

I am glad to tell you, that there is indeed a straightforward method: Create a sub-theme → :)

Good to hear, I wasn't sure, since I got no reply to my carefully crafted answer to your question, nor to your question about sub-theming back in March. Remember, we are all volunteers here, and even just a "Thanks, I will try that!" means a lot.

Thanks for sharing @avpaderno, but what is the way to do what you describe? ("In a forum post, it could be helpful to filter the posts by Drupal version [...]")

If you mean simply clicking the 10.x or 11.x tag under a post, you get Case studies on page #2 ... (I never clicked on those tags before earlier today)

• Drupal 10: https://www.drupal.org/taxonomy/term/195821 →
• Drupal 11: https://www.drupal.org/taxonomy/term/202774 →

Interesting stats, thanks for digging them up @drumm. With your mention of the minor differences between versions now, I interpret you as leaning towards agreeing that version can be removed, but I could be mistaken. Where do you stand @avpaderno?

We don't have to delete the field right away, it could for a start simply be hidden in the form with CSS, and we can decide later on, if we want to remove it ...

Drupal version, dev environment, and other useful info could be collected by introducing a forum post template, as I suggested in ✨ Add System and versions content template Active .

Awesome work @dydave, perfect!

The "Advanced" section does look perfect now, and the new description text is really good ... But I do appreciate your openness to remove the two settings. I can only say, that I can't see that I would ever feel the need to change the sensitivity or interval values ... so maybe we should remove them?

PS. Great that tests with even big_pipe installed now work!

It looks good @dydave, thanks! Great catch with fixing the JS problem with the focus key to navigate menu elements. I am glad to hear that you like the change to the slide-effect. I did notice that a slight shade was still visible at the top, but setting it at 220% is perfect, to hide it completely 🙂

About support for Vertical mode, I think your suggestion of dealing with that in another issue is the right approach. I think, if someone needs that, they should feel to create it an issue, and we can take it from there.

So this looks good to go, since everything looks fine from my perspective, thanks!

I still think this could be worth considering, in light of the Version field maybe getting removed.

I have revised the format, so that it takes up less space.

Thinking about this another way - is the Drupal version field still useful on forum posts? Removing the field is an option. This would also effectively be data loss.

Thanks for the feedback @drumm, and simply removing the version field may be the solution. I can't think of a single time I have used the version number in the Forum. The only time I have seen any use for it, was to spot spammers, since the bot would often select the first option (at the time "Drupal 4.5.x or older") and thereby reveal themselves :)

I even thought about suggesting combining categories like this in the Issue Summary, since Drupal 8-11 are virtually identical:

• Drupal CMS
• Drupal 8-11
• Drupal 7 or older

But Drupal CMS can be any version (11, 12, etc.), so in that sense, still not very useful ...

So +1 from me, for removing Version field in the Drupal Forum. Case studies can keep a Version field of course, it may be more useful there?

You're welcome, I am glad it was useful :)

You're welcome @hestenet, and that sounds like a great plan -- prudent to wait with development until a stage where it makes more sense, in the new Drupal 11 environment.