Problem/Motivation

Currently, only the key of a List (Text) (or List (Integer) or List (Float)) field is available as a field property. This issue seeks to make an option's label available, as well, as a computed property.

Proposed resolution

Look at Drupal\text\TextProcessed as an example.

Create a 'option_label' field property for the three field types provided by the Options module.

Remaining tasks

• Submit patch.
• Review.

User interface changes

None.

API changes

For 'list_string', 'list_integer', and 'list_float', field types a new 'label' property will be added.

Data model changes

For 'list_string', 'list_integer', and 'list_float', field types a new 'label' property will be added.

Release notes snippet

TBD

When linking the name of a media file to the media (see screenshot) in manage display, I cannot access layoutbuilder and get:

The website encountered an unexpected error. Please try again later.

Drupal\Core\Entity\EntityMalformedException: The "media" entity cannot have a URI as it does not have an ID in Drupal\Core\Entity\EntityBase->toUrl() (line 192 of core/lib/Drupal/Core/Entity/EntityBase.php).

Drupal\Core\Field\Plugin\Field\FieldFormatter\StringFormatter->getEntityUrl(Object) (Line: 127)
Drupal\Core\Field\Plugin\Field\FieldFormatter\StringFormatter->viewElements(Object, 'en') (Line: 89)
Drupal\Core\Field\FormatterBase->view(Object, 'en') (Line: 263)
Drupal\Core\Entity\Entity\EntityViewDisplay->buildMultiple(Array) (Line: 267)
Drupal\layout_builder\Entity\LayoutBuilderEntityViewDisplay->buildMultiple(Array) (Line: 351)
Drupal\Core\Entity\EntityViewBuilder->buildComponents(Array, Array, Array, 'event_files') (Line: 293)
Drupal\Core\Entity\EntityViewBuilder->buildMultiple(Array) (Line: 250)
Drupal\Core\Entity\EntityViewBuilder->build(Array)
call_user_func_array(Array, Array) (Line: 100)
Drupal\Core\Render\Renderer->doTrustedCallback(Array, Array, 'Render #pre_render callbacks must be methods of a class that implements \Drupal\Core\Security\TrustedCallbackInterface or be an anonymous function. The callback was %s. Support for this callback implementation is deprecated in 8.8.0 and will be removed in Drupal 9.0.0. See https://www.drupal.org/node/2966725', 'silenced_deprecation', 'Drupal\Core\Render\Element\RenderCallbackInterface') (Line: 781)
Drupal\Core\Render\Renderer->doCallback('#pre_render', Array, Array) (Line: 372)
Drupal\Core\Render\Renderer->doRender(Array, ) (Line: 200)
Drupal\Core\Render\Renderer->render(Array) (Line: 501)
Drupal\Core\Template\TwigExtension->escapeFilter(Object, Array, 'html', NULL, 1) (Line: 138)
__TwigTemplate_f162914866e1cb2807b4f0c587486e61449700187d2856026e39cf19d03e4bce->doDisplay(Array, Array) (Line: 455)
Twig\Template->displayWithErrorHandling(Array, Array) (Line: 422)
Twig\Template->display(Array) (Line: 434)
Twig\Template->render(Array) (Line: 64)
twig_render_template('themes/custom/showcaseplus/templates/field--entity-reference.html.twig', Array) (Line: 384)
Drupal\Core\Theme\ThemeManager->render('field', Array) (Line: 431)
Drupal\Core\Render\Renderer->doRender(Array, ) (Line: 200)
Drupal\Core\Render\Renderer->render(Array) (Line: 501)
Drupal\Core\Template\TwigExtension->escapeFilter(Object, Array, 'html', NULL, 1) (Line: 101)
__TwigTemplate_e7ccb531163dd570637d.....e3c105a5f7a7f32ee843a9472->block_content(Array, Array) (Line: 216)
Twig\Template->displayBlock('content', Array, Array) (Line: 86)
__TwigTemplate_e7ccb531163dd570637d11b....19a3f24e3c105a5f7a7f32ee843a9472->doDisplay(Array, Array) (Line: 455)
Twig\Template->displayWithErrorHandling(Array, Array) (Line: 422)
Twig\Template->display(Array) (Line: 434)
Twig\Template->render(Array) (Line: 64)
twig_render_template('themes/custom/showcaseplus/templates/block.html.twig', Array) (Line: 384)
Drupal\Core\Theme\ThemeManager->render('block', Array) (Line: 431)
Drupal\Core\Render\Renderer->doRender(Array) (Line: 444)
Drupal\Core\Render\Renderer->doRender(Array, ) (Line: 200)
Drupal\Core\Render\Renderer->render(Array) (Line: 501)
Drupal\Core\Template\TwigExtension->escapeFilter(Object, Array, 'html', NULL, 1) (Line: 104)
__TwigTemplate_8e7d8e2898e403a235c00....05797b9525dda30b5af4617ddf->doDisplay(Array, Array) (Line: 455)
Twig\Template->displayWithErrorHandling(Array, Array) (Line: 422)
Twig\Template->display(Array) (Line: 434)
Twig\Template->render(Array) (Line: 64)
twig_render_template('core/themes/stable/layouts/fourcol_section/layout--fourcol-section.html.twig', Array) (Line: 384)
Drupal\Core\Theme\ThemeManager->render('layout__fourcol_section', Array) (Line: 431)
Drupal\Core\Render\Renderer->doRender(Array) (Line: 444)
Drupal\Core\Render\Renderer->doRender(Array) (Line: 444)
Drupal\Core\Render\Renderer->doRender(Array) (Line: 444)
Drupal\Core\Render\Renderer->doRender(Array) (Line: 444)
Drupal\Core\Render\Renderer->doRender(Array, ) (Line: 200)
Drupal\Core\Render\Renderer->render(Array, ) (Line: 226)
Drupal\Core\Render\MainContent\HtmlRenderer->Drupal\Core\Render\MainContent\{closure}() (Line: 573)
Drupal\Core\Render\Renderer->executeInRenderContext(Object, Object) (Line: 227)
Drupal\Core\Render\MainContent\HtmlRenderer->prepare(Array, Object, Object) (Line: 117)
Drupal\Core\Render\MainContent\HtmlRenderer->renderResponse(Array, Object, Object) (Line: 90)
Drupal\Core\EventSubscriber\MainContentViewSubscriber->onViewRenderArray(Object, 'kernel.view', Object)
call_user_func(Array, Object, 'kernel.view', Object) (Line: 111)
Drupal\Component\EventDispatcher\ContainerAwareEventDispatcher->dispatch('kernel.view', Object) (Line: 156)
Symfony\Component\HttpKernel\HttpKernel->handleRaw(Object, 1) (Line: 68)
Symfony\Component\HttpKernel\HttpKernel->handle(Object, 1, 1) (Line: 57)
Drupal\Core\StackMiddleware\Session->handle(Object, 1, 1) (Line: 47)
Drupal\Core\StackMiddleware\KernelPreHandle->handle(Object, 1, 1) (Line: 106)
Drupal\page_cache\StackMiddleware\PageCache->pass(Object, 1, 1) (Line: 85)
Drupal\page_cache\StackMiddleware\PageCache->handle(Object, 1, 1) (Line: 47)
Drupal\Core\StackMiddleware\ReverseProxyMiddleware->handle(Object, 1, 1) (Line: 52)
Drupal\Core\StackMiddleware\NegotiationMiddleware->handle(Object, 1, 1) (Line: 23)
Stack\StackedHttpKernel->handle(Object, 1, 1) (Line: 708)
Drupal\Core\DrupalKernel->handle(Object) (Line: 19)

Unsetting the link makes the error go away.

Steps to reproduce

Copied from #5:

1. Go to the admin site.
2. Go to admin/modules.
3. Enable the Layout builder and click on install.
4. Go to admin/structure/media/manage/image/display/default , against the name field , there is a settings icon , click it and enable the checkbox against Link to the Media and click on update.
5. In the Layout options -> enable Use Layout Builder -> Save.
6. Go to reports/dblog
7. Verify if any of the error and warning(such as "The field "name" failed to render with the error of "The "media" entity cannot have a URI as it does not have an ID".") shouldn't appear after applying the patch.

Problem

• Star is missing in IE 11
• Star doesn’t meet contrast requirements in Firefox
• Star doesn’t meet contrast requirements in Edge

Steps to reproduce

Enable High Contrast mode in Windows

Just crash testing patches

Problem/Motivation

Looks like we missed fixing this one.

Steps to reproduce

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Hello all,

We tried to do security update on Drupal 8.9.1 Core.
When we try to update any modules with this command

composer update drupal/core --with-dependencies

we had following error on terminal;

In Cache.php line 76:
                          
  Undefined index: extra  

Could you please help about this issue ?

Thanks

Problem/Motivation

It is easy to create a Media entity with a non-existent type (see below). I came across this when defining a migration, when I used the incorrect bundle name.

In this case, $this->bundle->entity is NULL. Since Media::getSource() is simply

  public function getSource() {
    return $this->bundle->entity->getSource();
  }

$entity->getSource() leads to an error something like this:

Call to a member function getSource() on null in Drupal\media\Entity\Media->getSource() (line 137 of /var/www/html/web/core/modules/media/src/Entity/Media.php)

Steps to reproduce

$entity = \Drupal::entityTypeManager()
  ->getStorage('media')
  ->create(['name' => 'foo', 'bundle' => 'does_not_exist']);
$entity->save();

Proposed resolution

Check that $this->bundle->entity is not empty before trying to access its getSource() method.

Remaining tasks

User interface changes

None.

API changes

None.

Data model changes

None.

Release notes snippet

N/A

This meeting takes place every Tuesday, usually at 14:00 UTC (10:00am ET, 7:00am PT). See Time.is to see what that is in your timezone.

The meetings are held using Zoom, and a link is posted in the #ux Slack channel just prior. Agenda is first come, first serve and set by attendees. Use Needs usability review tag for issues that need review and/or suggest issues in comments here.

Recording of this week's meeting: TODO

We discussed the following issues: TODO

Problem/Motivation

Under PHP 8 installing Drupal results in errors because \Drupal\Core\Database\StatementInterface::fetch(), ::fetchAll() and ::setFetchMode() do not match their \PDOStatement::* counterparts.

Ref https://github.com/php/php-src/pull/6220

Proposed resolution

Introduce a PHP 7 compatible interface and trait for these three methods, as well as PHP 8 compatible interface and trait. Use the right one based on the PHP version identified.

interface Php7StatementInterface {
  public function fetch($mode = NULL, $cursor_orientation = NULL, $cursor_offset = NULL);
  public function fetchAll($mode = NULL, $column_index = NULL, $constructor_arguments = NULL);
  public function setFetchMode($mode, $a1 = NULL, $a2 = []);
}

interface Php8StatementInterface {
  public function fetch(int $mode = \PDO::FETCH_BOTH, int $cursor_orientation = \PDO::FETCH_ORI_NEXT, int $cursor_offset = 0);
  public function fetchAll(int $mode = \PDO::FETCH_BOTH, ...$args);
  public function setFetchMode(int $mode, ...$params);
}

Remaining tasks

Review.

User interface changes

None.

API changes

When using PHP 8, the three methods will have a different signature. Given that the interface is already based off of \PDOStatement which became more strict in PHP 8, we cannot go around this. The default values of the methods also changed from NULL to integer constants defined by PDO. Callers that wish to use some of the default values and specify some other values will encounter problems when running on PHP 8.

Data model changes

None.

Release notes snippet

The signatures of \Drupal\Core\Database\StatementInterface::fetch(), ::fetchAll() and ::setFetchMode() changed when running on PHP 8 due to the underlying changes in PHP's built in \PDOStatement signatures for the respective methods.

Problem/Motivation

You cannot create a view and try to list rendered entities using relationship.

Steps to reproduce (based on Standard profile):

1. Add an entity reference field named "field_content" to the "page" content type. Allow content > article references.
2. Create and edit a content view.
3. Add a relationship for "Content using field_content." or "Content referenced from field_content."
4. The row style plugin is "Content" by default.
5. Click on "Teaser" in order to change the view mode, nothing happens.
6. You can't choose a view mode even if you don't want to actually use a relationship, just having one on your view triggers this.

The problem is a fatal AJAX error triggered when RowPluginBase::buildOptionsForm() calls RelationshipPluginBase::init() while providing a wrong argument type (Array instead of DisplayPluginBase).

Argument 2 passed to Drupal\views\Plugin\views\relationship\RelationshipPluginBase::init() must be an instance of Drupal\views\Plugin\views\display\DisplayPluginBase, array given, called in /app/web/core/modules/views/src/Plugin/views/row/RowPluginBase.php on line 93

Proposed resolution

Fix it, by passing along the relationship as needed and using it.

Remaining tasks

None.

User interface changes

None

API changes

None

Problem/Motivation

The current book module allows for multiple enabled content-types for books but only a single content-type for child pages. The problem is that if you want to use the book construct but have different requirements depending on the application then a series of problems arise. For example: two different sets of users that only have access to create and edit specific content-types by role or if different path patterns are required depending on the type of book content.

Steps to reproduce

1. Enable book
2. Configure book settings

Proposed resolution

There are modules in the contrib space to help deal with things like access control, but it gets complicated fairly quickly. In looking at it the easier solution is to remove the constraint of a single content-type for all book children and allow each enabled book content-type to have its own child content-type.

Remaining tasks

Address D6/D7 migration related code and config.

User interface changes

Conditional settings per content-type on the book settings admin page.

API changes

None.

Data model changes

None.

Release notes snippet

Enhance book module settings to allow users to configure the add child link content-type per book content-type.

Problem/Motivation

Two problems:

1) Unit test requires a database

Running TestSiteApplicationTest in isolation reveals that it errors out.

That's because it uses the SIMPLETEST_DB environmental variable, which is intended for use by KernelTestBase tests.

$ ./vendor/bin/phpunit -c core/ --testsuite unit --filter TestSiteApplicationTest
PHPUnit 6.5.8 by Sebastian Bergmann and contributors.

Testing 
EEESS.                                                              6 / 6 (100%)

Time: 17.01 seconds, Memory: 136.00MB

There were 3 errors:

1) Drupal\Tests\Scripts\TestSiteApplicationTest::testInstallWithNonExistingFile
InvalidArgumentException: Minimum requirement: driver://host/database

/Users/paulmitchum/projects/drupal8/core/lib/Drupal/Core/Database/Database.php:460
/Users/paulmitchum/projects/drupal8/core/tests/Drupal/Tests/Scripts/TestSiteApplicationTest.php:267
/Users/paulmitchum/projects/drupal8/core/tests/Drupal/Tests/Scripts/TestSiteApplicationTest.php:47

This can be mitigated by setting the SIMPLETEST_DB variable in phpunit.xml, but this ruins the isolation between unit and kernel tests.

2) This test is never run by run-tests.sh

Since it lives in core/tests/Scripts, the test is not discovered when run-tests.sh runs tests.

You can see evidence of this in this recent HEAD test. See the actual tests that were run which does not include TestSiteApplicationTest: https://dispatcher.drupalci.org/job/php7_mysql5.5/5506/artifact/jenkins-...

Versus the test list generated for that same build which lists TestSiteApplicationTest: https://dispatcher.drupalci.org/job/php7_mysql5.5/5506/artifact/jenkins-...

Here's an issue about fixing that discrepancy: #2878269: Modify TestDiscovery so the testbot runs all the tests

Proposed resolution

#2878269: Modify TestDiscovery so the testbot runs all the tests is in, so the test has been running.

Convert the test to the new build test framework. This takes it out of the unit testsuite, which helps avoid the need for a database. Also, this test case is much better suited to a build test which can modify the file system to perform site installs in isolation.

Remaining tasks

User interface changes

API changes

Data model changes

Problem/Motivation

In August 2019 Fabian Potencier announced at https://symfony.com/blog/symfony-maintenance-changes-for-standard-releases that

As of Symfony 5.0, we are changing the way we manage security issues for standard releases. A standard release is any minor version that is not a LTS release: so, versions X.0, X.1, x.2, and x.3.

For these standard releases, we will align the EOM (end of maintenance) date with the EOL (end of life) date. So, instead of having 14 months of security fixes, we will only have 8 months.

For instance, Symfony 4.3 EOM date is January 2020 and EOL date is July 2020. With the new rules, EOL would have been January 2020. Symfony 5.0 will be the first release to implement the change: EOM and EOL dates will be July 2020.

Therefore, to be able to support Drupal minor releases for 12 months, Drupal 9 choose to rely on Symfony 4.4. That said, Symfony 5 is already out and it may be possible to make Drupal 9 both Symfony 4.4 and Symfony 5 compatible. This issue is to explore to do that as much as possible. This will be very useful in the transition to Drupal 10 as well, which is planned to be released on Symfony 5.4 Long Term Support.

See #2976394: Allow Symfony 4.4 to be installed in Drupal 8 for prior art with Symfony 4 on Drupal 8.

Additionally, Drupal's test dependencies are not yet compatible with Symfony 5, see

https://github.com/minkphp/MinkBrowserKitDriver/issues/139
https://github.com/minkphp/MinkBrowserKitDriver/pull/151
https://github.com/minkphp/MinkBrowserKitDriver/pull/142

Proposed resolution

See children issues.

Remaining tasks

• #3172537: Passing a command as string when creating a "Symfony\Component\Process\Process" instance is deprecated since Symfony 4.2, pass it as an array of its arguments instead, or use the "Process::fromShellCommandline()" constructor if you need features provided

User interface changes

None.

API changes

TBD

Data model changes

TBD

Release notes snippet

TBD

Problem/Motivation

The inline variation was recently added to form elements and wasn't taken into account on the initial implementation of form elements.

Proposed resolution

Implement inline variation of form elements. We should ensure that the new styles are compatible with radios, checkboxes, text inputs and selects. This doesn't include any work related to prefix/suffix.

This image is just a reference. Please use Figma to check spacing and other definitions:

• Text field
• Text area
• Select
• Radios/Checkboxes

Remaining tasks

Implement it for:

• Text field
• Text area
• Selects
• Radios/Checkboxes

User interface changes

Inline form elements will implement a common solution.

Release notes snippet

Problem/Motivation

We deprecated most jQuery UI library definitions, and removed these from Drupal 9.x

Some library definitions were not deprecated though, because they're dependencies of core JavaScript - drupal.dialog, drupal.autocomplete etc. which have not been refactored yet. This includes jquery.ui.button jquery.ui.mouse jquery.ui.resizable jquery.ui.widget, and jquery.ui itself.

However, those core libraries like drupal.autocomplete don't have to depend on jQuery UI libraries specified in core.libraries.yml, they could instead depend directly on the components themselves, essentially merging the library definitions together.

The big advantage of this is it allows us to avoid adding to the skipped deprecation list, see #3098489: Remove deprecated jQuery UI library definitions which is where this idea developed.

This doesn't reduce our dependency on the components themselves, but it prevents new dependencies on them being added in contributed and custom modules during the 9.x cycle.

Proposed resolution

1. Where an actual core library like drupal.autocomplete depends on jQuery UI components, add the components as direct javascript and CSS file dependencies, removing the dependency on the library definition.

2. Deprecate all of the remaining jquery.ui library definitions in core, ensuring that contrib replacements exist (true for most but not all as I type this).

Remaining tasks

1. Should we do a late deprecation for 9.x removal in 8.8 and 8.9? An argument in favour is that jQuery UI is already abandoned, and we already made a big announcement about this, we're just adding more to the same change record. If not, we'd need to decide whether to add an early 10.x deprecation (since we actively want to discourage dependencies on jQuery UI) or wait until 9.1.x

2. Views UI uses jquery.ui.dialog directly, instead of drupal.dialog. This makes it harder to deprecate jquery.ui.dialog. One option is to have Views UI declare its own views.jquery.ui.dialog library that's a clone of the jquery.ui.dialog definition. Another is to rely on the skipped deprecation list for jquery.ui.dialog

User interface changes

None.

API changes

Yes, more jquery.ui library definitions deprecated.

Data model changes

Release notes snippet

The core jquery.ui, jquery.ui.autocomplete, jquery.ui.dialog, jquery.ui.draggable, jquery.ui.menu, jquery.ui.mouse, jquery.ui.position, jquery.ui.resizable, and jquery.ui.widget library definitions have been deprecated. Modules and themes with a dependency on these library definitions should use the contributed module versions.

Modules that override these library definitions, or the definitions of libraries that depend on them (such as drupal.autocomplete, drupal.dialog, and drupal.tabbingmanager) may need to update their overrides to ensure the same changes to the resulting JavaScript and CSS are applied.

Problem/Motivation

I noticed this problem while working on #3089525: Sort options should correspond to bundles selected for entity reference field settings.

Using the Standard profile,

1. Visit /admin/structure/types/manage/article/fields
2. Click the "Add field" button.
3. Select Content under the Reference group.
4. Enter a label, then "Save and continue".
5. On the next screen, click the "Save field settings" button.
6. In the "Reference type" section, select at least one content type. This will expose the "Sort by" select list.
7. Select a "Sort by" field. The "Sort direction" select list should appear.
8. De-select all content types.
9. The "Sort by" option is hidden, but the "Sort direction" option is still there.

We have to be careful that the fix for this problem does not break reference fields for entity types, like User, that do not have bundles.

Proposed resolution

TBD

Remaining tasks

User interface changes

When no bundles are selected, the "Sort direction" option is hidden as well as the "Sort by" option.

Current behavior:

API changes

None

Data model changes

None

Problem/Motivation

Vertical tabs have the following accessibility issues:

1. Drupal.verticalTab doesn't take care of the right aria attributes. Whatever happens, every details summary element (of a single VerticalTabs) are described with aria-expanded="false" and aria-pressed="false".
2. Drupal.verticalTab marks active vertical tab menu items with an element that text is active tab. The element has a non-unique CSS id #active-vertical-tab. Sadly, this will be very wrong on the filter format and editor configuration form where multiple vertical tabs may appear (e.g. /admin/config/content/formats/manage/basic_html).

   Fearing the duplicated id, if the user changes the active tab, this marker will be removed from every other vertical tab's of the page as well

3. Auto-focus bug: When a vertical tab is activated (triggered to be shown) by pressing Enter on the tab menu link Drupal.verticalTab tries to focus the first visible :input element in a vertical tab content. But the implementation is wrong: on the Filter format and editor form (/admin/config/content/formats/manage/basic_html), if the user presses the Enter key on the last vertical tabs element's menu link (Filter settings), the focused element will be the first vertical tabs (CKEditor plugin settings) visible input, and not the expected one. This is because the focus trigger happens globally; it isn't limited to the current vertical tabs.
4. The label of a vertical tabs element has invalid for attribute value.

   From #3023310-85: Vertical Tabs style update.2:

   (...) the for attribute is looking for an ID that is not present on the page. The value it is looking for does appear in a div's data-drupal-selector attribute, an element that can't receive focus.

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

@todo

In a custom page if we will use the status report template the general info section is rendered by default as there is no check added in

/core/themes/seven/templates/status-report-general-info.html.twig (It is overridden in seven) but the same code is available in the stable theme.

Hardcoded values are passed there which is not a correct way.

I tested this with adding condition in the template and now it's working fine.

It's required on the Status Report page only not everywhere.

Problem/Motivation

Autocreate a is a great UX option for Entity Reference fields. Currently it is not available if you choose "Views" as the "Reference method", which is necessary if you want to filter the available choices.

Proposed resolution

Offer autocreate. So far this seems to require
- adapting the ViewsSelection EntityReferenceSelection plugin to offer autocomplete.
- removing a (probably unintended) characteristic of the getAutoCreateBundle method of the EntityReferenceAutocompleteWidget that makes it only work with selection handlers that have a target_bundles property, which ViewsSelection does not.

Remaining tasks

Tests needed.

User interface changes

"Autocreate" Checkbox in the entity reference field settings, and a "Store new items in" dropdown if it checked. These are identical to those for the default reference method.

API changes

None.

Data model changes

None.

Problem/Motivation

In https://www.drupal.org/project/drupal/issues/3114079, the minimum supported Apache version was upgraded to >= 2.4.7, on the premise that Apache 2.4.6 and below are ancient, unsupported, and those versions contain a number of known vulnerabilities.

The only version of Apache certified for use on Red Hat Enterprise Linux 7 (RHEL7) is 2.4.6, and upgrading beyond this version on RHEL7 servers is strongly discouraged (unlike PHP and other requirements). Apache 2.4.6 in neither ancient not unmaintained, as it is actively updated and maintained by RedHat, who has back-ported all security updates (through version 2.4.34) into the release.

While many users of RHEL7 can upgrade to RHEL8, please note that RHEL8 is not approved for use on U.S. federal government servers (see https://access.redhat.com/articles/2918071 for compliance status), meaning that the latest version of RHEL that Federal users can upgrade to us RHEL7. Requiring Apache 2.4.7 will effectively block all U.S. Federal web sites running RedHat Enterprise Linux from upgrading from Drupal 8 to Drupal 9.

Even if RHEL8 gains approval for use on U.S. Federal government servers today, many of these sites will not be able to upgrade to RHEL8 before Drupal 8's EOL in November 2021 and will be forced to consider a different CMS.

Furthermore, the "setifempty" directive is not actually used in .htaccess in Drupal 9, making the premise of the requirement for Apache 2.4.7 or greater irrelevant.

Proposed resolution

Reduce the the D9 requirements to require at least Apache 2.4.6, not 2.4.7.

Remaining tasks

- Discuss if changing the requirement is acceptable;
- Update the documentation/requirements

User interface changes

None

API changes

None

Data model changes

None

Release notes snippet