🇸🇰Slovakia @poker10

catch → credited poker10 → .

benjifisher → credited poker10 → .

Indeed, we should add the ability to auto-detect in a follow-up

I still see the auto-detect feature in the MR, is that correct? Can we remove it for now, so that users are not confused how the values get there? If we would like to keep the auto-detect for now, I think we should bring back at least the descriptions to explain, that values were auto-detected and also mention the path which was autodetected. This can also help in case someone moves the site - then there will be the actual auto-detected link in the description and users can use it if needed (they will not need to search it manually). Anyway, the auto-detect feature is not mentioned in the IS in the proposed resolution.

In #36.4 I posted a bug on windows. Since we did not drop windows support yet (#3436617), is this worth exploring further? For example on my testing windows, composer was detected, but rsync not and I was stuck, because the auto-detected composer value did not pass the validation on the submit.

This seems like a (significant) UI change, so I think that even without an option to reset, the current approach still needs to be approved as per Usability core gate →

Based on these, moving this back to NR. Thanks for all the work here!

But if we include the module it eliminates the module selection process by the site template creator and consolidates usage to that module.

I do not think it is a good idea to explicitly select a specific module from a set of similar modules, unless Drupal CMS needs it. We have a big ecosystem of modules and maintainers put a big effort in maintaining these, so we should not make choices for our users, if we do not need (speaking generally, not about this specific case, where @svendecabooter is the maintainer of RoleAssign).

xjm → credited poker10 → .

xjm → credited poker10 → .

xjm → credited poker10 → .

xjm → credited poker10 → .

greggles → credited poker10 → .

poker10 → credited poker10 → .

greggles → credited poker10 → .

greggles → credited poker10 → .

If you download and extract it, the vendor directory contains mostly empty folders, so this looks like a bug.

xjm → credited poker10 → .

Wrong branch was selected when creating the MR. Updated that and moving to NR.

poker10 → created an issue.

poker10 → changed the visibility of the branch 3529392-frontpage-settings to hidden.

quietone → credited poker10 → .

Thanks for reporting and working on this. There is a lot of unrelated changes in the MR because it targets 8.x-1.x branch. We need to have MR against 2.x branch. Also please keep open only one MR, as currently it is not clear, which one is ready for review (!63 or !64).

Thanks for reporting this.

Valid values as per specification (https://www.sitemaps.org/protocol.html) are:

always
hourly
daily
weekly
monthly
yearly
never

There is no "quarterly". Closing this as won't fix.

Thanks for reporting and working on this. There is a lot of unrelated changes in the MR because it targets 8.x-1.x branch. We need to have MR against 2.x branch.

poker10 → created an issue.

This seems to be a related issue: 🐛 Not checking "Allow multiple values" in contextual-filter, with PostgreSQL, results SQL error Active

But the Related blog posts display in the Blog view does not have Allow multiple values checked in the Content: Tags (Default: Taxonomy term ID from URL) contextual filter. Once the option is checked, the error is gone. So I think this can be fixed in Drupal CMS as well with adjusting the view config - if we set Allow multiple values by default.

@hestenet I am curious if there has been any progress with this issue? Thanks!

The list of attendees looks good, thanks!

Adding attendees according to the DST private notes.

benjifisher → credited poker10 → .

pameeela → credited poker10 → .

It seems like the decision may affect Gin toolbar module, which is used on 60k+ sites and offers horizontal and vertical menu. If removed, it will cause upgrade issues for sites which are currently using it. Is there any plan to keep/or add back the possibility to have also the horizontally oriented menu in such case? Navigation itself currently does not support horizontal menu, only vertical, which may be quite restrictive, given the original core's Toolbar module offers both options (see the comment #88 📌 New Toolbar Roadmap: Path to Beta & Stable Active ).

What about existing forks/merge requests, which are associated with d.o. issues? Will these be migrated too?

According to my testing from 🐛 InvalidComponentException when Workspaces UI and Navigation modules are enabled Active , the error only appears if Workspaces UI is enabled. It is not sufficient to enable just Navigation and Workspaces to trigger the error. So I am updating the title and adjusting the priority as it is pretty easy tu run into this.

Yes, it looks like a duplicate. Thanks. Let's continue in the older issue.

Oh, sorry I overlooked this. Maybe I was focused mainly to steps to reproduce and that the issue is still open, so did not read the rest correctly. Created a new issue: 🐛 InvalidComponentException when Workspaces UI and Navigation modules are enabled Active . Thanks!

Sorry, I overlooked the specific error in the #3511374, but originally I meant this new issue: 🐛 InvalidComponentException when Workspaces UI and Navigation modules are enabled Active as a stable blocker in #89.

I think this should be a Navigation stable blocker.

poker10 → created an issue.

I cloned 11.x, installed standard on MySQL, enabled Navigation, enabled Workspaces+UI and still get:

Drupal\Core\Render\Component\Exception\InvalidComponentException: [navigation:toolbar-button/icon] NULL value found, but an object is required. in Drupal\Core\Theme\Component\ComponentValidator->validateProps() (line 234 of /data/test/core/lib/Drupal/Core/Theme/Component/ComponentValidator.php).

Drupal\Core\Template\ComponentsTwigExtension->doValidateProps(Array, 'navigation:toolbar-button') (Line: 106)
Drupal\Core\Template\ComponentsTwigExtension->validateProps(Array, 'navigation:toolbar-button') (Line: 47)
__TwigTemplate_94743d30f511513d29aca6f93557776f->doDisplay(Array, Array) (Line: 402)
Twig\Template->yield(Array) (Line: 151)
__TwigTemplate_3a476adc6e0e556dd3a0a8fb64e407f3->{closure:__TwigTemplate_3a476adc6e0e556dd3a0a8fb64e407f3::macro_menu_items():77}() (Line: 2106)
Twig\Extension\CoreExtension::captureOutput(Object) (Line: 77)
__TwigTemplate_3a476adc6e0e556dd3a0a8fb64e407f3->macro_menu_items(Array, Object, 0) (Line: 54)
__TwigTemplate_3a476adc6e0e556dd3a0a8fb64e407f3->doDisplay(Array, Array) (Line: 402)
Twig\Template->yield(Array, Array) (Line: 358)
Twig\Template->display(Array) (Line: 373)
Twig\Template->render(Array) (Line: 51)
Twig\TemplateWrapper->render(Array) (Line: 34)
twig_render_template('core/modules/navigation/templates/navigation-menu.html.twig', Array) (Line: 380)
Drupal\Core\Theme\ThemeManager->render('navigation_menu', Array) (Line: 493)
Drupal\Core\Render\Renderer->doRender(Array, Object) (Line: 246)
Drupal\Core\Render\Renderer->doRenderRoot(Array, Object) (Line: 142)
Drupal\Core\Render\Renderer->{closure:Drupal\Core\Render\Renderer::renderInIsolation():141}() (Line: 623)
Drupal\Core\Render\Renderer->executeInRenderContext(Object, Object) (Line: 141)
Drupal\Core\Render\Renderer->renderInIsolation(Array) (Line: 168)
Drupal\Core\Render\Renderer->doRenderPlaceholder(Array) (Line: 725)
Drupal\Core\Render\Renderer->{closure:Drupal\Core\Render\Renderer::replacePlaceholders():724}()
Fiber->start() (Line: 733)
Drupal\Core\Render\Renderer->replacePlaceholders(Array) (Line: 258)
Drupal\Core\Render\Renderer->doRenderRoot(Array, Object) (Line: 142)
Drupal\Core\Render\Renderer->{closure:Drupal\Core\Render\Renderer::renderInIsolation():141}() (Line: 623)
Drupal\Core\Render\Renderer->executeInRenderContext(Object, Object) (Line: 141)
Drupal\Core\Render\Renderer->renderInIsolation(Array) (Line: 168)
Drupal\Core\Render\Renderer->doRenderPlaceholder(Array) (Line: 725)
Drupal\Core\Render\Renderer->{closure:Drupal\Core\Render\Renderer::replacePlaceholders():724}()
Fiber->start() (Line: 733)
Drupal\Core\Render\Renderer->replacePlaceholders(Array) (Line: 258)
Drupal\Core\Render\Renderer->doRenderRoot(Array, Object) (Line: 142)
Drupal\Core\Render\Renderer->{closure:Drupal\Core\Render\Renderer::renderInIsolation():141}() (Line: 623)
Drupal\Core\Render\Renderer->executeInRenderContext(Object, Object) (Line: 141)
Drupal\Core\Render\Renderer->renderInIsolation(Array) (Line: 112)
Drupal\Core\Render\Renderer->renderRoot(Array) (Line: 253)
Drupal\Core\Render\HtmlResponseAttachmentsProcessor->renderPlaceholders(Object) (Line: 74)
Drupal\big_pipe\Render\BigPipeResponseAttachmentsProcessor->processAttachments(Object) (Line: 45)
Drupal\Core\EventSubscriber\HtmlResponseSubscriber->onRespond(Object, 'kernel.response', Object) (Line: 246)
Symfony\Component\EventDispatcher\EventDispatcher::{closure:Symfony\Component\EventDispatcher\EventDispatcher::optimizeListeners():241}(Object, 'kernel.response', Object) (Line: 206)
Symfony\Component\EventDispatcher\EventDispatcher->callListeners(Array, 'kernel.response', Object) (Line: 56)
Symfony\Component\EventDispatcher\EventDispatcher->dispatch(Object, 'kernel.response') (Line: 216)
Symfony\Component\HttpKernel\HttpKernel->filterResponse(Object, Object, 1) (Line: 204)
Symfony\Component\HttpKernel\HttpKernel->handleRaw(Object, 1) (Line: 76)
Symfony\Component\HttpKernel\HttpKernel->handle(Object, 1, 1) (Line: 53)
Drupal\Core\StackMiddleware\Session->handle(Object, 1, 1) (Line: 48)
Drupal\Core\StackMiddleware\KernelPreHandle->handle(Object, 1, 1) (Line: 28)
Drupal\Core\StackMiddleware\ContentLength->handle(Object, 1, 1) (Line: 32)
Drupal\big_pipe\StackMiddleware\ContentLength->handle(Object, 1, 1) (Line: 116)
Drupal\page_cache\StackMiddleware\PageCache->pass(Object, 1, 1) (Line: 90)
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: 53)
Drupal\Core\StackMiddleware\AjaxPageState->handle(Object, 1, 1) (Line: 51)
Drupal\Core\StackMiddleware\StackedHttpKernel->handle(Object, 1, 1) (Line: 715)
Drupal\Core\DrupalKernel->handle(Object) (Line: 19)

The same result also on Simplytest.me.

Is this really fixed in 11.2.x?

Dec. 16 is incorrect. The correct date for the 2026 December window is December 9.

I think the intent was to set this to a core security release window, which is usually the third Wednesday of the month and that is Dec 16th 2026.

Personally, I prefer more setting up a fixed date, because that will remove any uncertainties. The currently proposed text seems a bit confusing for me, at least the part

in early December 2026, when Drupal 12 is released

, as Drupal 12 could be released also in June.

I agree that we technically cover all code on git.drupalcode.org, if the project is opted into security advisory coverage and has stable release. So also recipes (https://new.drupal.org/browse/recipes) and general projects ( https://www.drupal.org/project/project-general → ).

We probably need to update the wording in https://www.drupal.org/docs/develop/issues/issue-procedures-and-etiquett... → , but in the SA policy ( https://www.drupal.org/drupal-security-team/security-advisory-process-an... → ), the project types (modules, themes, distributions) are not explicitly mentioned and the policy is not restricted to these types.

This looks good and the link to list all issues by project in the issue description is great, thanks!

One additional question came to my mind - is it possible to use the Advanced search to search also by labels? For example in the Security team triage doc, we are using links to s.d.o. with already filtered issues by project and status (for example all core issues needs review). Is is possible to include label here https://git.drupalcode.org/search?group_id=183118&scope=issues&search=%2... somehow?

yesct → credited poker10 → .

yesct → credited poker10 → .

yesct → credited poker10 → .

yesct → credited poker10 → .

poker10 → credited poker10 → .

yesct → credited poker10 → .

yesct → credited poker10 → .

+1 to set an explicit D10 EOL date, so that it is predictable. I think December is a good idea, regardless of the D12 release date. However, can we make the bold part more specific?

Define early December 2026 as the definite EOL time for Drupal 10.

If the intent is to set explicit date, can we set it to a specific date and not say "early..."? I agree with @damienmckenna, that setting a specific date may be better (whether it will be 2026-12-31 or some other date in December). Otherwise it is still a "moving target" - though less, but still at least until a certain date closer to the release, when a specific date of the D12 release will be published.

@quietone Thanks! I think we still need to update other screenshots (from the SettingsForm), so keeping this at Needs work for this and also for other issues from #36.

@catch I think that if we base the required state on the check done by SymfonyExecutableFinder/PhpTuf , the field will become not required as soon as the executable is detected again (sorry if I used the wrong word was/is). My idea was, that if the specific executable is not auto-detected, then the required flag should be set until it is auto-detected. In case the specific excecutable is auto-detected, it can be kept as is, without the required flag, so that you can set custom path, or revert to the auto-detected value. I just think that resetting the executable path back to NULL (default value) should not be allowed if the auto-detected path is not available at the moment, because it will reset you to the non-working state regarding that specific executable.

It would be also great to update the IS, as the images in User interface changes are outdated (for example there is no (auto-detected) in placeholder, the details element does not contain info that you can clear the value to return back to auto-detect and there are additional status/warning messages).

I tested the MR manually and found some issues:

1. Initially, package manager auto-detected my composer, but not rsync. The rsync field was therefore required. I entered manually the path to the rsync executable and the field was no longer required after saving the form. Therefore I was able to delete the value again - which is probably not what we want, since it was not auto-detected initially? I think it will be better to keep the required flag always, if the executable was not auto-detected to not allow removing the value.

2. When you save the form with a value in a field which was not auto-detected, after the form is submitted, you get duplicate messages, like:

Status message 
    The path to Composer was automatically detected.
    The configuration options have been saved.
    The path to rsync was automatically detected.

Warning message
   The path to rsync could not be automatically detected.

So the info about rsync path was duplicated. The same issues happened when I removed the rsync path (as mentioned in point 1).

3. When I set the path to rsync manually, I see the message:

The path to rsync was automatically detected.

Which is not correct, as I entered the value manually and it was not detected automatically.

4. On windows - composer path was detected as C:\ProgramData\ComposerSetup\bin\composer.BAT. In windows enviroment settings (PATH), there is C:\ProgramData\ComposerSetup\bin and the composer executable file exists physically with a lowercase extension (not uppercase). Not sure if that is a problem (and if this is caused by SymfonyExecutableFinder). What is a bit worse is, that even when the PHP docs mention, that is_executable() function will detect .bat files as executables (see https://www.php.net/manual/en/function.is-executable.php - for BC reasons, files with a .bat or .cmd extension are also considered executable), when I try to save the form with manually entered C:\ProgramData\ComposerSetup\bin\composer.BAT or C:\ProgramData\ComposerSetup\bin\composer.bat, it fails the IsExecutableConstraintValidator ( "C:\ProgramData\ComposerSetup\bin\composer.bat" is not an executable file. ). This is probably not good for windows users.

5. Can we consider adding an info somewhere, that removing the value will "reset" the config to the auto-detected value?

Moving this to Needs work for these. Thanks!

greggles → credited poker10 → .

greggles → credited poker10 → .

poker10 → credited poker10 → .

poker10 → credited poker10 → .

greggles → credited poker10 → .

greggles → credited poker10 → .

@newtoid There is a lot of issues in the site moderators queue aimed at companies or individual contributors, because that is what it this queue for. This issue was to discuss a specific aspect of a specific user (and the behavior), so I do not think the title change is correct here.

@darren oh Most of the time, using AI will not improve comments. It adds unnecessary noise to the text and can introduce errors, if not checked correctly. I am not speaking about tools which fix grammar and similar, but mostly others, which will formulate the sentences for you and so on. I think it should be disclosed, if the comment was written by AI, as per current policy.

Is this causing any error? If I recall correctly, the file was removed intentionally and replaced by inline form - https://git.drupalcode.org/project/commerce_stock_notifications/-/blob/8... . In case you are experiencing any errors, please let me know and we can take a look. Thanks!

Updating numbers for 2023 and 2024

The list of attendees looks correct, thanks.

benjifisher → credited poker10 → .

greggles → credited poker10 → .

greggles → credited poker10 → .

greggles → credited poker10 → .

greggles → credited poker10 → .

poker10 → credited poker10 → .

I am curious why this issue is not considered as a stable blocker: 🐛 Second level menu items can't be reached if they have children Active ? A lot of contribs add new menu items to the Administration menu - for example Scheduler - and due to this Navigation module's limitation, it is not then possible to access some admin pages (see 🐛 Cannot access Taxonomy overview page via Navigation menu Active ).

Also I am not sure if that is a known issue (did not have time to search it yet, as I run into this just today), but on a clean Drupal 11.x, if you enable Navigation and then Workspaces UI, the site will crash with an error:

Drupal\Core\Render\Component\Exception\InvalidComponentException: [navigation:toolbar-button/icon] NULL value found, but an object is required. in Drupal\Core\Theme\Component\ComponentValidator->validateProps() (line 232 of core/lib/Drupal/Core/Theme/Component/ComponentValidator.php).

greggles → credited poker10 → .

greggles → credited poker10 → .

greggles → credited poker10 → .

greggles → credited poker10 → .

greggles → credited poker10 → .

greggles → credited poker10 → .

greggles → credited poker10 → .

poker10 → credited poker10 → .

greggles → credited poker10 → .

poker10 → credited poker10 → .

What about directly referenced files like https://git.drupalcode.org/project/governance/-/blob/main/drupal-core.md? This one is linked on multiple pages, including https://www.drupal.org/about/core/policies/maintainers/core-committer-or... → . Should we set redirects for each old .md file URL as well?

This is now done: https://www.drupal.org/project/xmlsitemap/releases/2.0.0 →

Merged to 2.x, thanks everyone!

This looks good, thanks. Drupal 10 requires minimum PHP 8.1, so I think that it is safe to add the nullable type declarations.

I reviewed the changes and have not found any other places where the deprecation message can be emitted.

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

Linking a similar core issue.

@ivnish Not sure if there is an issue for contribs yet (have not found it), but feel free to create one to discuss it. Thanks.

Message looks good and credits are cleared. +1 from me. Thanks!

poker10 → created an issue.

greggles → credited poker10 → .

greggles → credited poker10 → .

greggles → credited poker10 → .

poker10 → credited poker10 → .

Seems like the 2.0.x is now used by approx. 10k sites. I do not see any new issues or bugs regarding the D11 compatibility, so I will take a look this week a tag a stable release.

Thanks for reporting this. This is a default behavior of the module if base URL cannot be detected. Site URL needs to be set manually here: /admin/config/search/xmlsitemap/settings in Advanced settings -> Default base URL, or use another method to set it.

See: https://www.drupal.org/docs/extending-drupal/contributed-modules/contrib... →

Thanks for working on this. 8.x-1.x branch will not support Drupal 11. There is a 2.0.0-beta1 release, please test that release.

Re #95:
I think that a major issue is that there is no equivalent way (or at least an easy way working generally for all use-cases) to replace the functionality it provided. I think that core can manage it, but for contribs and custom themes/code, it will add a lot of work. If you look at the related issue ( 📌 Remove use of deprecated "spaceless" filter in core templates Active ), not all changes were just removing the filter and adding some whitespace controls. And lot of these changes needs to be tested manually, because it has a potential to disrupt layouts and so. So I see a benefit of providing our replacement until we decide to deprecate and remove it entirely (as proposed in IS), to help the contrib world with the transition (though I am not sure when Twig 4 is planned).

2. Navigation suggests to uninstall toolbar module when navigation is used.

I think Gin already supressed the message in: 🐛 Temporarily suppress toolbar & navigation warning Needs review . It was a workaround, because as per comment #7 from 🐛 Status warning: Toolbar and Navigation modules are both installed Active , it was not possible to uninstall toolbar module yet (not sure if that is still true these days).

However, there was some pushback (#44_) on showing warnings on a standard install, so we need to be sure this is considered.

Yes, I was thinking more about adjusting the existing error messages, which are displayed when .htaccess files are missing, so that these have a different wording when the auto_create_htaccess config is set to FALSE, or hide these messages entirely. I agree that adding a new requirements check with another warning or so is not ideal.