If you download and extract it, the vendor directory contains mostly empty folders, so this looks like a bug.
Wrong branch was selected when creating the MR. Updated that and moving to NR.
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.
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?
+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 → .
@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!
The list of attendees looks correct, thanks.
benjifisher → 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 → .
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.
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!
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.
When doing this, do we want to update also this part, to include general committers?
The roles of Project Lead, product manager, framework manager, and release manager have commit access and are collectively referred to as "core committers" (or "branch maintainers" for a specific major Drupal version).
It seems to me like a duplicate of the "Leadership Team: Core Committers" part, but given the roles are explicitly mentioned here, then it is probably not ideal to keep it as is.
Thanks for working on this. Should this be postponed on 📌 "Promoted to front page" for new content types should default to Un-Checked Needs work ? Because the default value for new content types is still promote=1. If this patch is applied and a new content type is created, it is set to promote automatically, but the field is hidden in form display, so it cannot be unchecked easily for content editors, unless brought back. I am not sure this is ideal.
There is still one @todo in the MR - do we need to discuss that? I do not see it mentioned anywhere in this issue. Thanks!
Sorry for asking, maybe it is obvious, but when we added webp format and possible conversion to core and image styles ( 📌 Add webp image conversion to core's install profile's image style Fixed and 📌 All core install profile image styles should include webp conversion Active ), we have not added any fallback. Was webp available in all PHP installations at that time? If not, are we sure that now when avif will not be available, webp will be?
This seems to be caused by changes from 📌 Improve FormattableMarkup documentation Fixed . Tagging as novice.
I think that this probably does not need tests, as it is a simple typo from a previous issue (see this commit). Checking by https://www.drupal.org/about/core/policies/core-change-policies/core-gat... → :
1. The issue has clear ‘Steps to reproduce’ in the Issue Summary. - YES
2. The fix is 'trivial' with small, easy to understand changes. - YES
Questions
1. Is the fix is easy to verify by manual testing? - YES
2. Is the fix in self-contained/@internal code where we expect minimal interaction with contrib? Examples are plugins, controllers etc. - YES
3. Is the fix achieved without adding new, untested, code paths? - YES
6. If this fix is committed without test coverage but then later regresses, is the impact likely to be minimal or at least no worse than leaving the bug unfixed? - YES
What do you think?
I reviewed the MR and added some comments.
I also think this still needs an issue summary update, because these parts from IS are not implemented:
- When Apache is reported as the web server, automatically create .htaccess files. Otherwise, do not create them and warn the user about the possible implications of this
- New warning message in File System section of Status Report.
When manually tested this, I was unable to find the warning entry in the log (Auto-creating htaccess disabled.), as the file creation is blocked in the parent function (HtaccessWriter::ensure()), so if the auto_create_htaccess config is set to FALSE, it will never reach the code in HtaccessWriter::write(). Not sure it was the intent. Personally I think that we do not need this logging at all and it will be sufficient to create a follow-up to sort-out the errors in the status report, which are displayed if .htaccess files are missing and the auto_create_htaccess config is set to FALSE:
Private files directory - Not fully protected
See https://www.drupal.org/SA-CORE-2013-003 → for information about the recommended .htaccess file which should be added to the private:// directory to help protect against arbitrary code execution.
I think it does not make sense to have it as errors anymore, when you use this new switch and disable it's creation on purpose.
Moving to NW for these.
Thanks!