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!
I think there is nothing special required for the use-case mentioned in the IS, so it seems like that if we fix this this directly in the _user_mail_notify() (see
🐛
_user_mail_notify() doesn't handle accounts without an email address
Active
), no other changes will be needed here.
Thanks for working on this. I think that it is a good idea to check the existence of the email address in the _user_mail_notify(), instead of in all calling functions (see the related issues in the IS).
I reviewed this and added some comments to the MR. Moving it to NW.
@w01f have you tried running the SQL query mentioned here: https://www.drupal.org/node/3486109 → , to check, what is causing the warning message?
I propose these changes:
Add something like we have on s.d.o, which clearly mention not to commit anything and to read the policy. I think this is beneficial and the link is also very important. So I suggest to add:
Maintainers, please do not commit any code until directed to do so. Please review http://drupal.org/node/101497 for more information.
---------------------
The message is great. I found that we have some additional information in the current message on s.d.o., which is probably worth considering:
As soon as you make the releases, update this issue with the URLs to the releases. - I asked in
📌
Decide which labels are needed for
Active
, if we can automate this somehow and add a comment to the gitlab issue, when a private release is created. If yes, then I think we do not need this part of the message added back. If not, then I would probably add it, as it seems valuable to track progress (at least for me).
Commit the code and create the release nodes between 16:00 UTC Tuesday and 16:00 UTC Wednesday - We have part of this in the new message (16:00 UTC Wednesday). Can we update the new message to include also the starting time (so to inform they, that they can start commiting from 16.00 UTC on Tuesdays)? If this message will be added on 8:30 UTC on Tuesdays, there is still a gap until the commit window for maintainers opens. So maybe we can update this part of the new message and add it somehow (but sorry, can't think of any good wording now): Maintainers - before the release window opens, commit the fixes to the public, ...
My thoughts regarding the missing statuses:
Reviewed & tested by the community - I think that we discussed to use milestones to schedule releases. So adding an issue to a milestone can be probably considered as RTBC?
Ready for SA to be Published - We used this status when maintainers actually committed the fix and created release. Can this be automated somehow, so that we are notified about new private releases in the Gitlab issue? If so, then web probably do not need this?
Postponed - Not sure how to label such issues. Probably need to add this?
Closed (duplicate) - We can link another issues in Gitlab, but there are only three options: relates to, blocks, is blocked by. If it will be sufficient to mark it as "relates to" and close it with a comment that it is a duplicate, then we probably do not need this label.
Closed (won't fix) - Not sure how to label such issues. Probably need to add this?
In D6 issues, we added the following comment:
Automatically closed because Drupal 6 is no longer supported → . If the issue verifiably applies → to later versions, please reopen with details and update the version.
So I suggest to use slightly modified message here, something like this (added the part what to do if the issue still applies to D10+):
Automatically closed because Drupal 7 security and bugfix support has ended → as of 5 January 2025. If the issue verifiably applies → to later versions, please reopen with details and update the version.
The link to all currently open D7 issues should be this: https://www.drupal.org/project/issues/drupal?status=Open&version=any_7 → .
greggles → credited poker10 → .
As now also closed issues can get credits ( ✨ Grant credit for all closed issues, not just fixed issues Active ), do we need to make an exception here and disable all credits for old D7 issues which will be auto-closed by this script? I think we probably do not want credits added as there will be a lot of issues with pre-filled credits field from the past and that is not verified.
The list of attendees looks correct.
benjifisher → credited poker10 → .
In the last table, pgsql module is 4%. Reading the proposed resolution, seems like that the module would qualify for removal, even if it is a DB driver. Can we exclude DB drivers modules explicitly, as I suppose we do not want to remove PostgreSQL support even if the module usage will be under the treshold?