Problem/Motivation

Follow-up to #3339710: Disallow passing route objects to UrlGenerator methods to remove the deprecations.

Proposed resolution

Remove deprecattions from:
- #3151017: Deprecate UrlGenerator::supports() and UrlGenerator::getRouteDebugMessage()
- #3151019: Only allow route names, deprecate support for route objects in UrlGenerator methods

Add string type to $name argument of \Drupal\Core\Routing\UrlGeneratorInterface

Remaining tasks

- remove deprecations
- patch&review&commit

User interface changes

API changes

Data model changes

Release notes snippet

This is our plan to move the code in the `sdc` module to the core namespace while maintaining backwards compatibility with the experimental module.

Merge Request Strategy

We have this META issue to move all the core from the current location in the experimental module into the Drupal\Core namespace. This meta issue will have a **draft** MR associated against HEAD (currently 11.x).

We will break tasks to move the code into smaller issues which will contain any potential discussion on the implementation. This will allow us to make more sense of the conversations, and to parallelize tasks with other contributors. Each one of these smaller issues will contain an MR against the branch for the META issue. As we merge these MRs for the smaller issues, the bigger diff will start to build up in the draft MR associated to the META issue.

Once we have all the smaller issues merged, we will work to clear the release manager and commit manager tags from the big MR, in order to get it merged. We also plan on requesting validation from core committers in these smaller issues, in order to raise any concerns early on.

Backwards Compatibility

The `sdc.module` file contains the following:

// Set class aliases for the classes that will go into core.
// See the experimental modules policy https://www.drupal.org/core/experimental
// @todo: remove class aliases in #3354389
@class_alias('Drupal\sdc\Element\ComponentElement', 'Drupal\Core\Render\Element\ComponentElement');
@class_alias('Drupal\sdc\Exception\ComponentNotFoundException', 'Drupal\Core\Render\Component\Exception\ComponentNotFoundException');
@class_alias('Drupal\sdc\Exception\IncompatibleComponentSchema', 'Drupal\Core\Render\Component\Exception\IncompatibleComponentSchema');
@class_alias('Drupal\sdc\Exception\InvalidComponentDataException', 'Drupal\Core\Render\Component\Exception\InvalidComponentDataException');
@class_alias('Drupal\sdc\Exception\InvalidComponentException', 'Drupal\Core\Render\Component\Exception\InvalidComponentException');

All classes in sdc are marked as @internal. We understand that the Drupal core backwards compatibility policy includes classes and services marked internal. All classes in sdc are also final (with the exception of Drupal\sdc\Element\ComponentElement) which will make it impossible to extend them. However, we acknowledge that manual instantiation and execution of static public methods still require backwards compatibility.

In order to provide backwards compatibility, we propose to use class_alias. This will handle the namepace changes. A deprecation notice will be thrown because the module itself is deprecated. In order to clear the deprecation the user will need to change their use statements using the list of class_alias in sdc.module as a reference.

Additional Considerations

We will not merge this until feedback from experimental users is done in regards to the other issues in our roadmap to stability. Therefore, we will keep this updated during the process and then merge as a last step.

Remove deprecated twig functions declared in #3409456: [PP-1] Remove SDC deprecated twig functions before 11.0.0

Issues

FileIssue

Component\ComponentMetadata.php

#3365467: Move SDC Component namespace to Core namespace

Component\ComponentValidator.php

#3365467: Move SDC Component namespace to Core namespace

Component\SchemaCompatibilityChecker.php

#3365467: Move SDC Component namespace to Core namespace

ComponentNegotiator.php

#3365686: Move SDC ComponentNegotiator to Core namespace

ComponentPluginManager.php

#3365690: Move SDC ComponentPluginManager namespace to Core namespace

Element\ComponentElement.php

#3365693: Move SDC Element\ComponentElement to Core namespace

Exception\ComponentNotFoundException.php

#3365468: Move SDC Exceptions to Core namespace

Exception\IncompatibleComponentSchema.php

#3365468: Move SDC Exceptions to Core namespace

Exception\InvalidComponentDataException.php

#3365468: Move SDC Exceptions to Core namespace

Exception\InvalidComponentException.php

#3365468: Move SDC Exceptions to Core namespace

ExtensionType.php

#3365695: Move SDC ExtensionType to Core namespace

Plugin\Component.php

#3365699: Move SDC Component to Core namespace

Plugin\Discovery\DirectoryWithMetadataDiscovery.php

#3365700: Move SDC Discovery namespace to Core namespace

Plugin\Discovery\DirectoryWithMetadataPluginDiscovery.php

#3365700: Move SDC Discovery namespace to Core namespace

Plugin\Discovery\RegexRecursiveFilterIterator.php

#3365700: Move SDC Discovery namespace to Core namespace

Twig\ComponentNodeVisitor.php

#3365702: Move SDC Drupal\sdc\Twig to Core namespace

Twig\TwigComponentLoader.php

#3365702: Move SDC Drupal\sdc\Twig to Core namespace

Twig\TwigExtension.php

#3365702: Move SDC Drupal\sdc\Twig to Core namespace

Utilities.php

#3352858: Move isRenderArray from SDC to Drupal\Core\Render\Element

metadata-full.schema.json

#3365711: Move SDC *.schema.json to Core namespace

metadata.schema.json

#3365711: Move SDC *.schema.json to Core namespace

sdc.module

#3365714: Move SDC sdc.module functions to Core namespace

sdc.services.yml

No issue necessary, it will be handled in the issues moving each of the service classes.

tests/*

#3406356: Move SDC tests/* to Core namespace

Release notes

The single directory components module is now deprecated. The functionality has been moved to Drupal core.

Problem/Motivation

In Drupal\Core\Image\Image::construct(), filesize() is being used to determine the size of file, but if for example files are on s3, filesize() returns FALSE and there is a warning that can't be suppressed.

Also, \Drupal\Core\Image\ImageInterface::getFileSize() expects this to be NULL not FALSE if the file is invalid, so we should handle that too.

Proposed resolution

We should suppress the warning, and check if @filesize() returns FALSE.

Remaining tasks

1. Review MR
2. Merge

User interface changes

N/A

API changes

N/A

Data model changes

N/A

Problem/Motivation

See #3396165: [meta] Convert all core plugin types to attribute discovery.

Steps to reproduce

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

Currently, the media library can only be searched by file name. This assumes that media creators use meaningful file names when creating images or other media. In real life that is often not the case. I regularly see file names like 1.3.1.png, 13867453.jpg or 1254175589_3c4a4466d4_b.jpg, which website editors are unlikely to know to be able to search on.

It would be useful to also be able to search the alternative text, which will typically include meaningful search terms.

Steps to reproduce

1. Go to simplytest.me
2. In the form field, type core
3. Choose Drupal core
4. Click to create the website with the latest version of Drupal core
5. Once the site is created, login as admin
6. In the administrator menu, click Extend
7. In the form field, type media
8. Enable Media and Media Library
9. Click Configure
10. Choose text formats and editors
11. On the row for basic HTML click Configure
12. Drag the media icon from Available Buttons to the Active Toolbar
13. Under Enabled filters, check Embed media
14. Under Filter settings, click Embed media
15. Check Image
16. Click Save configuration
17. In the administrator menu, click Content
18. Click Add content
19. Click Basic page
20. Click in the body WYSIWYG
21. Click the media icon
22. Click Choose files
23. Navigate to a file that has a meaningless file name and click Upload
24. Type alternative text for the image
25. Click save
26. Repeat this activity for an additional 100 images (I don't expect you to actually do this, but consider it closer to a real life situation)
27. Now imagine trying to find one of those 100 images by just the meaningless file name using the Name search field
28. Try to find one of those 100 images by the alternative text

Desired result: There is an alternative text field that you can use to put in one or more words that are meaningful that can be searched against the alternative text of those 100 images

Actual result: There is no way to search on alternative text. Attempting to use meaningful words to search meaningless file names does not provide useful results.

Proposed resolution

Option one: Provide a unified search field that searches both name and alternative text.
Option two: Provide an additional search field that searches alternative text.

Remaining tasks

User interface changes

Option one: Replace the Name label with a label reading "Name or Alternative text"
Option two: Add a field with a label "Alternative text"

API changes

Data model changes

Release notes snippet

Problem/Motivation

In #3252386: Use PHP attributes instead of doctrine annotations we added support for attribute based plugin discovery.
As part of that issue we converted block and action plugins.

This issue is to convert \Drupal\media\Annotation\MediaSourceplugins to use Attributes.

Proposed resolution

1. Add a class to represent the new Attribute - Example
2. Update the plugin manager constructor to include both the attribute and annotation class names - example
3. Convert all plugins that use the annotation to use the new attribute - example

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

Follow-up of #3252386: Use PHP attributes instead of doctrine annotations, once that is in, we need to convert all the remaining plugin types, likely an issue per plugin type, *maybe* sometimes grouped together, like all the tests and maybe views as well, although there will be a lot there.

Once that is done, the old discovery as well as calling DefaultPluginManager with old arguments should trigger deprecation messages, either then in this issue or another child issue.

#3400458: AttributeClassDiscovery fails while trying to include non valid plugin class is about to fix some critical regressions in the attribute discovery at least when using the BC layer. There are some remaining questions about whether or not we want to support such cases (classes that can not be loaded due to missing traits, base classes, interfaces, ...)

Another step that is needed is updating plugin system documentation, issue for that: #3401822: Document attribute-based discovery in the handbook.

Steps to reproduce

Proposed resolution

Convert all plugin types and provide Rector rules via https://github.com/palantirnet/drupal-rector/pull/257

Remaining tasks

#3265945: Triggering deprecations for plugins using annotations when core plugin type has been converted to attributes

Plugin conversions

• CKEditor5AspectsOfCKEditor5Plugin, CKEditor5Plugin, DrupalAspectsOfCKEditor5Plugin: #3399036: CKEditor5PluginManager: use PHP attributes instead of doctrine annotations
• EntityType, ContentEntityType, ConfigEntityType: #3396166: Convert entity type discovery to PHP attributes
• FieldType: #3420981: Convert FieldType plugin discovery to attributes
• Layout: #3420983: Convert Layout plugin discovery to attributes
• MediaSource: #3420997: Convert MediaSource plugin discovery to attributes
• MigrateDestination: #3421015: Convert MigrateDestination plugin discovery to attributes
• MigrateField: #3421020: Convert MigrateField plugin discovery to attributes
• MigratePluginManager:#3424509: Update MigratePluginManager to include both attribute and annotation class
• MigrateProcessPlugin: #3421016: Convert MigrateProcessPlugin plugin discovery to attributes
• MigrateSource: #3421014: Convert MigrateSource plugin discovery to attributes
• ViewsArgumentDefault: #3421003: Convert ViewsArgumentDefault plugin discovery to attributes
• ViewsPager: #3421004: Convert ViewsPager plugin discovery to attributes
• ViewsWizard: #3421000: Convert ViewsWizard plugin discovery to attributes

Done

• #3425568: Block attribute class expecting wrong ContextDefinition
• #3426217: Fix @param docs for $deriver on plugin attribute classes
• #3427388: Update Drupal\Component\Annotation\Doctrine\StaticReflectionParser::hasClassAttribute() to allow attribute subclasses
• Archiver: #3420985: Convert Archiver discovery to attributes
• CKEditor4To5Upgrade: #3399036: CKEditor5PluginManager: use PHP attributes instead of doctrine annotations
• Condition: #3420986: Convert Condition plugin discovery to attributes
• Constraint: #3420990: Convert Constraint plugin discovery to attributes
• ContextDefinition: #3420989: Convert ContextDefinition plugin discovery to attributes
• DataType: #3420987: Convert DataType plugin discovery to attributes
• DisplayVariant and PageDisplayVariant: #3420984: Convert Layout DisplayVariant, PageDisplayVariant discovery to attributes
• Editor: #3421011: Convert Editor plugin discovery to attributes
• EntityReferenceSelection: #3420982: Convert EntityReferenceSelection plugin discovery to attributes
• FieldFormatter: #3420980: Convert FieldFormatter plugin discovery to attributes
• FieldWidget: #3420978: Convert FieldWidget plugin discovery to attributes
• Filter: #3421012: Convert Filter plugin discovery to attributes
• HelpSection: #3420993: Convert HelpSection plugin discovery to attributes
• ImageEffect: #3420996: Convert ImageEffect plugin discovery to attributes
• ImageToolkit: #3420991: Convert ImageToolkit plugin discovery to attributes
• ImageToolkitOperation: #3420992: Convert ImageToolkitOperation plugin discovery to attributes
• LanguageNegotiation: #3421017: Convert LanguageNegotiation plugin discovery to attributes
• Mail: #3420977: Convert Mail plugin discovery to attributes
• QueueWorker: #3420988: Convert QueueWorker plugin discovery to attributes
• RenderElement and FormElement: #3421439: Convert form and render element plugin discovery to attributes
• RestResource: #3420994: Convert RestResource plugin discovery to attributes
• SearchPlugin: #3421013: Convert Search plugin discovery to attributes
• SectionStorage: #3421019: Convert SectionStorage plugin discovery to attributes
• ViewsAccess: #3421001: Convert ViewsAccess plugin discovery to attributes
• ViewsArea: #3426959: Convert ViewsArea plugin discovery to attributes
• ViewsArgument and ViewsArgumentHandlers: #3425359: Convert ViewsArgumentHandlers plugin discovery to attributes
• ViewsArgumentValidator: #3421010: Convert ViewsArgumentValidator plugin discovery to attributes
• ViewsCache: #3421009: Convert ViewsCache plugin discovery to attributes
• ViewsDisplayExtender and ViewsPluginAnnotationBase: #3421006: Convert ViewsDisplayExtender plugin discovery to attributes
• ViewsExposedForm: #3421008: Convert ViewsExposedForm plugin discovery to attributes
• ViewsField: #3426955: Convert ViewsField plugin discovery to attributes
• ViewsFilter: #3426957: Convert ViewsFilter plugin discovery to attributes
• ViewsDisplay: #3421002: Convert ViewsDisplay plugin discovery to attributes
• ViewsJoin: #3426958: Convert ViewsJoin plugin discovery to attributes
• ViewsSort: #3426961: Convert ViewsSort plugin discovery to attributes
• ViewsQuery: #3421007: Convert ViewsQuery plugin discovery to attributes
• ViewsRelationship: #3426956: Convert ViewsRelationship plugin discovery to attributes
• ViewsRow: #3420999: Convert ViewsRow plugin discovery to attributes
• ViewsStyle: #3421005: Convert ViewsStyle plugin discovery to attributes
• WorkflowType: #3421018: Convert WorkflowType plugin discovery to attributes

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

At DrupalCon Seattle, we were testing the new keyboard navigation feature in Layout Builder. When using table drag to reorder items, we tab to an item that we want to drag, but the background color does not change to indicate the item is selected until you move the item with the up or down arrow, or else tab away.

Steps to reproduce (and see screenshots):
1) Core 8.8.x
2) Enable Layout Builder
3) Structure->Basic Page->Edit->Layout Options : Check "Use Layout Builder"
4) Manage Display -> Manage Layout
5) Use mouse or keyboard to activate the contextual menu and select "Move"
6) Now use keyboard-only techniques.
7) Use tab to navigate to one of the items in the table that you want to "tabledrag" to a different position. The tabledrag icon indicates the selection, but not the item background.

8) Now tab to the next item. Upon focus change, suddenly the previous item has its highlighted background set to the active color. This color change came too late and is actually incorrect since the active item is now the item below.

Proposed resolution

Make sure the "active" background color is set on the actual active item.
Change the background color at the same time / with the same event as is used by the tabledrag icon?

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

If an image has been added to the media library without alternative text, then subsequent attempts to insert that image into page content do not force supplying the missing alternative text.

I recognize that this would not normally happen on a manual image upload in the default Drupal configuration, but it could happen inadvertently as a result of a data upload or a temporary site misconfiguration.

Steps to reproduce

These steps are intended to create a testable case with minimal effort, so testers don't have to intentionally create a faulty data upload.

1. Go to simplytest.me
2. In the form field, type core
3. Choose Drupal core
4. Click to create the website with the latest version of Drupal core
5. Once the site is created, login as admin
6. In the administrator menu, click Extend
7. In the form field, type media
8. Enable Media and Media Library
9. Click Configure
10. Choose text formats and editors
11. On the row for basic HTML click Configure
12. Drag the media icon from Available Buttons to the Active Toolbar
13. Under Enabled filters, check Embed media
14. Under Filter settings, click Embed media
15. Check Image
16. Click Save configuration
17. In the administrator menu, click Structure
18. Click Media types
19. On the row for Image, choose Manage fields from the drop-down
20. On the row for image, click Edit
21. Uncheck Alt field required
22. Click save settings
23. In the administrator menu, click Content
24. Click Add content
25. Click Basic page
26. Click in the body WYSIWYG
27. Click the media icon
28. Click Choose files
29. Navigate to a file and click Upload
30. Do not type alternative text for the image
31. Click save
32. Click the X in the upper right corner to close the Add or save media dialog
33. In the administrator menu, click Structure
34. Click Media types
35. On the row for Image, choose Manage fields from the drop-down
36. On the row for Image, click Edit
37. Check Alt field required
38. Click save settings
39. In the administrator menu, click Content
40. Click Add content
41. Click Basic page
42. Click in the body WYSIWYG
43. Click the media icon
44. Check the checkbox for the image you just uploaded

    Option one:
    Expected result: A dialog box opens containing the Alternative text field, which is highlighted as being required.
    Actual result: Nothing happens.

    This is the issue filer's preferred option because it solves the issue for all future uses of this image.

45. Click insert selected
46. Type a page title
47. Click save

    Option two:
    Expected result: Get error message that the image is missing alternative text. The editor would need to use the slashed eyeball icon to add the alternative text for that image on this page only.
    Actual result: Nothing happens.

    This is the issue filer's second choice because it solves the issue for this page only.

I would expect a similar solution for an image field that uses the media library.

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

TODO

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

Configuration synchronization page is broken due to error.

Steps to reproduce

Remove the file core.extension.yml in config/sync directory.

Visit syncronise tab at: /admin/config/development/configuration

Get the below error:

TypeError: Argument 1 passed to Drupal\field\ConfigImporterFieldPurger::getFieldStoragesToPurge() must be of the type array, bool given, called in /modules/field/field.module on line 323 in Drupal\field\ConfigImporterFieldPurger::getFieldStoragesToPurge() (line 111 of core/modules/field/src/ConfigImporterFieldPurger.php).

Proposed resolution

Improve handling of empty config/sync in the field module in hook field_form_config_admin_import_form_alter.

Problem/Motivation

If I enable the "Access the taxonomy vocabulary overview page" permission for Anonymous users, the Vocabulary names appear; they also have access to the /admin/structure/taxonomy path, which I don't wish to allow. I don't see any other permission for allowing access to the Vocabulary name.

This also occurs if I am not using grouping - if I want to list a term in a row with its Vocabulary name, the name does not appear without the user having the above permission.

Steps to reproduce

I have a Taxonomy term view which groups several terms by their Vocabulary name. For example:

- Vocab 1
-- Term 1
-- Term 2
- Vocab 2
-- Term 3
-- Term 4

However, if I am not logged in, the Vocabulary names are not shown. The output is instead like this:

-- Term 1
-- Term 2
-- Term 3
-- Term 4

Proposed resolution

There are two solutions proposed for this issue.
#29 where we can add access for `view label` operation. (Added in issue's PR)
#37 This patch is adding access for `view` operation.

Remaining tasks

• Needs discussion about solution approach.
• Sub-system maintainer review

User interface changes

N/A

API changes

N/A

Data model changes

N/A

Release notes snippet

If I 'wrap' my element into text_format element, the original description_display has no effect anymore. I think this is because text-format-wrapper.html.twig (and maybe the preprocess function) does not take it into account.

See #314385: Make position of #description configurable via the API

Conditions:

Drupal core with Client-side Hierarchical Select

1. Taxonomy vocabulary with 2 depths.
2. Node type with taxonomy term reference field.
2.1 Set to unlimited. NO default value.
2.2 On form display settings, check "Force selection of deepest level"

Actions

1. Create a new node, the field works correct, no default value is set.
2. Select a taxonomy term from the deepest value and save (testterm AND testterm 2).
3. Edit the created node: Now a default value is set:

This is wrong and it's tedious because you always have to deselect it when saving.

Problem/Motivation

Following on from #3358248: [policy, no patch] Drop support for IIS in Drupal 11. It is recommended to read that issue and the comments.

Windows has added full support for running Linux distros within Windows. There's also docker (and ddev which runs on docker) that make it easy to set up development environments in using containers. Actual manual configuration of apache for local development is very optional these days.

Additionally, it's also hard to find reviewers for issues with windows issues - for example filesystem bugs. Also, we have no way to add automated testing for Windows environments.

Note that there's an issue to move example nginx configuration into core, but that would only be an example #2937161: Provide documentation/default server block for Nginx server., not 'live' config, it's also not anywhere near RTBC.

Proposed resolution

Stop supporting running Drupal directly on Windows on production. We would still accept bug reports for Windows on development environments. One example is something like not using DIRECTORY_SEPARATOR correctly.

Sites wanting to use Windows servers in production would need to run Drupal on Linux on Windows, which should not result in additional surface area for security reports against Drupal, since as far as Drupal's concerned it would still be running on Linux.

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

IIS support was added in 2010 to support developers running Windows XP Pro et al: #567072: Ship Drupal 7 with a configuration file for IIS 7

Since then, Windows has added full support for running linux distros within Windows. There's also docker (and ddev which runs on docker) that make it easy to set up development environments in using containers. Actual manual configuration of apache for local development is very optional these days.

Issues like #2895002: Extend IIS web.config to allow colons in URLs sit around for years waiting for reviews and manual testing, presumably because very few people actually use IIS. We're also never likely to add an IIS configuration to DrupalCI/Gitlab CI either.

There are open issues mentioning IIS: https://www.drupal.org/project/issues/search/drupal?text=IIS&project_iss...

Sometimes Apache security improvements get delayed because we want to provide parity with IIS, which then gets blocked on the IIS implementation (and reviews, testing of that).

There are presumably some people still running IIS, since we occasionally get IIS issues opened, but those users are capable for copying and pasting an example web.config from Drupal.org - which is the same level of support we currently offer for the much more widespread nginx.

Additionally, it's also hard to find reviewers for issues with windows issues that aren't specific to IIS - for example filesystem bugs, and we have no way to add automated testing for those either.

Note that there's an issue to move example nginx configuration into core, but that would only be an example #2937161: Provide documentation/default server block for Nginx server., not 'live' config, it's also not anywhere near RTBC.

Usage data

We don't have any data on how many Drupal sites are running Windows on production, but there are wider trends we can look at:

IIS has gone down from 14.3% in 2012 to 5.3% in 2022 according to w3techs.

https://w3techs.com/technologies/history_overview/web_server/ms/y

Windows server has gone down from 36.5% in 2012 to 18% in 2022.

https://w3techs.com/technologies/history_overview/operating_system/ms/y

Microsoft Azure no longer supports PHP on windows server at all, and recommends linux on azure instead, this has been the case since PHP 8.0:
https://github.com/Azure/app-service-linux-docs/blob/master/Runtime_Supp...

RFC

RFC Remove support for Windows in production in Drupal 11 published on 16 February 2024.

Proposed resolution

Stop supporting running Drupal directly on Windows on production. We would still accept bug reports for Windows on development environments (for example something like not using DIRECTORY_SEPARATOR correctly.

Sites wanting to use Windows servers in production would need to run Drupal on linux on windows (via docker or a similar solution), which should not result in additional surface area for security reports against Drupal, since as far as Drupal's concerned it would still be running on linux.

• Add documentation in the Security Team handbook saying we don't cover Windows-only issues, but encourage reporters who discover an issue on windows to report it privately first so it can be evaluated for other environments.
• Remove the shipped web.config file from core, move the contents to a page on Drupal.org similar to nginx examples [needs issue]
• Create issue to update https://www.drupal.org/docs/user_guide/en/install-requirements.html

1.Which versions are supported?

Current text

See Which versions are supported?

Proposed text

Add the following sentence to the section.

As of April 2024 Drupal does not support the use of Microsoft IIS.

2.Microsoft IIS

Current text

See Microsoft IIS

Proposed text

Add the following sentence at the end of the section.

As of April 2024 Drupal does not support the use of Microsoft IIS.

Remaining tasks

RTBC
Update security docs with a conclusive statement about what is or is not being supported by the security team.
Update documentation per #43, #44.

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

If required config values are not set, errors will occur later on and are difficult to trace. For example, if $field_prefix is not set, then:

modules/field_ui/src/Form/FieldStorageAddForm.php
'#maxlength' => FieldStorageConfig::NAME_MAX_LENGTH - strlen($field_prefix),

will fail when NULL to strlen.

Proposed resolution

From comments #11 and #13

>>> \Drupal::config('some_module.non_existent')
=> Drupal\Core\Config\ImmutableConfig {#6251}

Should this throw an exception instead, and we need a separate explicit call to create a new config? This would warn users earlier that expected config is missing.

>>> \Drupal::config('field_ui.settings')->get('non_existent_key')
=> null

Maybe also this should throw an exception, if the config exists but the key does not, instead of falling back to NULL?

Remaining tasks

1. Agree on an approach. Per #14, the proposed solution would require a deprecation first. But per #15 there are other things to consider.
2. Write a patch with tests
3. Review
4. Commit

User interface changes

N/A

API changes

TBC

Data model changes

TBC

Release notes snippet

TBC

Original report by [username]

I had the case that $field_prefix was not set and therefore I got the issue with passing NULL to strlen.

modules/field_ui/src/Form/FieldStorageAddForm.php
'#maxlength' => FieldStorageConfig::NAME_MAX_LENGTH - strlen($field_prefix),

Problem/Motivation

In #3118147: [meta] Set Drupal 10 platform and browser requirements six months before the release we're setting Drupal 10 platform and browser requirements.

Due to release cycles, the MySQL and sqlite version requirements are unlikely to change much for Drupal 10, however it already looks more clear what we should raise them to in Drupal 11.

If any RFCs are needed for community consultation publish them early for an sufficiently long consultation time. Three weeks may not have been long enough for #3358248: [policy, no patch] Drop support for IIS in Drupal 11 (see comment #59).

Proposed resolution

Define some 'not less than' minimum version requirements for Drupal 11.

• PHP #3330874: [11.x] [policy] Require PHP 8.3 for Drupal 11
• Mysql 8 and MariaDB 10.4: #3215207: [11.x] [policy] Require MySQL 8.0 and MariaDB 10.6
• sqlite 3.26 (RHEL 8) or sqlite 3.34 (RHEL 9)?: #3346338: [11.x] [policy] Set the SQLite minimum requirement to at least 3.45 AND/OR #3266764: [11.x] [policy] Treat SQLite as a dev (rather than prod) requirement and allow it to be raised in Drupal minors
• PostgreSQL? #3357409: [11.x] [policy] Require PostgreSQL 16 for Drupal 11
• Drop support for Windows on production #3358248: [policy, no patch] Drop support for IIS in Drupal 11
• Composer requirements #3421111: [11.x] [policy] Set Composer requirement for Drupal 11
• Browser requirements - #3421252: [11.x] [policy] Set Browser requirement for Drupal 11

API page: https://api.drupal.org/api/drupal/includes%21database%21schema.inc/group...

See this comment: https://api.drupal.org/comment/42608#comment-42608

Ever time I run the composer to install a module or update one, it seems that permissions get reset for the sites folder and also for index.php file in web folder.

Index.php permissions get reset to 664, so I have to change it to 644 after any composer operation. If I don't reset permissions, the site will not load. It just shows.

The server encountered an internal error or misconfiguration and was unable to complete your request.

Please contact the server administrator at webmaster@domain.com to inform them of the time this error occurred, and the actions you performed just before this error.

More information about this error may be available in the server error log.

Additionally, a 500 Internal Server Error error was encountered while trying to use an ErrorDocument to handle the request.