Problem/Motivation

The revision user is not appearing correctly on the /revisions tab when a node author is cancelled and their content assigned to anonymous user.

Steps to reproduce:

1. User A creates a node
2. User B edits that node
3. User C cancels User A's account and assigns their content to the anonymous user (user_cancel_reassign).
4. Go to the Revisions tab created in Step 1: the user for both revisions is Anonymous, where User B is expected for the second revision.

Proposed resolution

node_mass_update with both the uid and the revision_uid set to 0 is called for user_cancel_reassign. Not sure if this is the "root cause" and additional code is needed there instead of the simple assignment.

Remaining tasks

User interface changes

API changes

Data model changes

Problem/Motivation

Problem 1: jQueryUI is going to be deprecated

As part of this deprecation, the jQueryUI datepicker is among the components that need to be removed/replaced.
As mentioned in the parent issue: #3067261: [Plan] Remove jQuery UI components used by Drupal core and replace with a set of supported solutions
The OpenJS Foundation lists jQuery UI as an Emeritus project in https://openjsf.org/projects/ which is described as:

Emeritus projects are those which the maintainers feel have reached or are nearing end-of-life

Some kind of replacement is necessary, be it another library, or relying on native. Relying on native should be a last resort due to problem 2...

Problem 2: Core currently uses native datepickers when browsers support it. This approach introduces accessibility and consistency problems

Some context: Currently, If a browser supports native datepicker, then that is used instead of the jQueryUI datepicker. date.es6.js uses Modernizr to determine native datepicker support, and only applies jQueryUI to the ~9% of browsers that do not support it.

The accessibility capabilities and overall experience of native datepickers vary greatly depending on the browser. For example:
(Win 10) Edge:
- no indication of day of week (not a11y necessarily, but not consistent with other browsers\).
-Can't exit datepicker with escape key, only the close button.
-Testing with NVDA. Datepicker will open with return key if field is in focus. Nothing is announced to make this evident (but unsure if SR users expect this behavior). Once opened, screenreader does not inform the user that it has been opened. Within the datepicker, screenreader does not announce any activity. Tab/Arrow activity has no response from screenreader. The only way to exit is to tab to the close button and hit return. This is unlikely to occur since the screenreader does not inform the user of what element they are on within the datepicker.
- While this technically meets contrast/not color-only requirements, it's awfully difficult to distinguish which column is focused.

(OSX) Opera & Firefox:
-Can't open datepicker with keyboard navigation
-An interactable "clear all" button is provided that can't be accessed via keyboard navigation

(OSX) Opera & Chrome
-Screenreader says that values in the stepper can be increased/decreased with control-option-arrow up/down. This key combination does not change the value. Arrow keys on their own do (which is better than nothing, but contradicts the instructions read to the user)

(OSX) Chrome
-Datepicker not at all usable for screenreader users, and the results too inconsistent to accurately summarize as text.

Because of these inconsistencies and a11y issues, the library that replaces jQuery datepicker should be used in all browsers, not just the 9% that don't provide native datepickers.

Proposed resolution

Determine the accessibility requirements of the datepicker and timepicker (there is no official spec on this - at one point there was...)
Evaluate libraries, first against the agreed accessibility requirements. If more than one option exists after the accessibility evaluation, create comparison tables.
Prototype and manually test
Once a choice has been tested/vetted/signed-off my maintainers/managers, open implementation followup issue

Remaining tasks

Get input/agreement that the reported accessibility issues with native datepickers necessitate using a library in all browsers.
Determine the accessibility requirements, particularly since an official spec is not available.
Get a list of libraries that might meet these requirements and evaluate.

User interface changes

Different datepicker

API changes

...

Data model changes

N/A

Release notes snippet

...

Problem/Motivation

https://github.com/symfony/symfony/pull/32435 improved the Symfony Constraint violation message for the 'range' constraint. Previously the constraint would report 'This value should be %limit or more.' or 'This value should be %limit or less.' if the value was below the minimum or above the maximum. Now it will provide a 'This value should be between {{ min }} and {{ max }}.' message, unless either min or max is omitted.

I think this message is more helpful and should probably be adopted at some point, but will need the proper localization, and bc considerations.

Proposed resolution

For now, lets override the validator and force the current logic to continue in SF4

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Once you allow each content item to be customized, you get a Layout tab and, even before you make changes, there’s a “Revert to defaults” button, which doesn't change anything in the layout if your node is already in default. Once you customize, there’s no indication that you’re not using the default anymore.

Some kind of message would be helpful once the node is overridden, e.g., “This content item has been overridden and no other layout templates may not be applied until you Revert to defaults. (The “no other layout templates” part would also help address an issue in the Layout Library contrib: https://www.drupal.org/project/layout_library/issues/3074948.) It might also be clearer if the "Revert to defaults" button was not available until the content had been overridden.

Problem/Motivation

Symfony 4.4 began throwing deprecation warnings on extending classes and methods that do not provide return typehints.

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

The current implementation for DatabaseQueue::claimItem catches all exceptions while trying to communicate with the database server. Which probably was put into place to not fail on a missing table. This error handling though causes problems if you are using Drupals Queue to serve long running workers. If the database fails, communication to the database fails or anything else related on that stack this generic catch all will continue to report no items to be left in the queue which is not intended behavior.

DatabaseQueue::createItem has a solution for the underlying problem already (missing table):

      // If there was an exception, try to create the table.
      if (!($try_again = $this
        ->ensureTableExists())) {

        // If the exception happened for other reason than the missing table,
        // propagate the exception.
        throw $e;

Problem/Motivation

The media library allows a user to upload a new file to create (but not yet save) a new media item. After the media item has been created (but not yet saved), the form presents a 'Remove' button. Pressing the 'Remove' button however, does not actually remove the uploaded file. This is inconsistent with adding a media item from /media/add/image where the Image widget actually removes the file from the file system.

Proposed resolution

Immediately delete a media's file when pressing 'Remove' in the media creation modal.

Remaining tasks

1. Write a patch
2. Review
3. Commit

User interface changes

None.

API changes

None.

Data model changes

None.

Problem/Motivation

The help system needs search capability.

Proposed resolution

Probably, using the existing Drupal core Search module to build the search functionality would make the most sense. But build it in such a way that Search API contrib module, or other search modules, could easily grab the help text to index and make it searchable.

A note about caching:
- We're really only concerned here about caching for the search results page.
- The Search module already puts cache tags in based on the search index (which we have a test assert for). So that means whenever the search index changes (i.e. for whatever reason we have decided to add, delete, or update an entry for a help item), the search results page cache is invalidated. That should be sufficient to take into account the idea that if the list of (and contents of) help topics that are searchable changes for any reason, we should invalidate the search results page (because you would get different search results potentially).
- We do also want to let each item in the results, as it renders itself, to declare cache stuff (this is also in the patch/test).
- We also need a cache context for user permissions, because which items can be searched depends on user permissions.
- We should also restrict the search to only look for topics in the current page language, and add a context for the interface language.

Remaining tasks

1. [Done] Implement search indexing and searching, using the core Search module. The latest patch (#54) has this working. Here is what the search results look like:
   
2. [Done] Once it's finalized, we'll need to update its hook_help, and also add a Help Topic for it. NOTE: The help topic could use some links to help topics that don't yet exist about creating search pages and block placement. We'll have to do those later when we clean everything up in the topics on #2687107: Reorganize topics into sensible outline, and/or write more topics so I'll add a note to that issue.
3. [Done] Add a search box to the main Help page. This depended on #3067943: Add capability for search blocks on non-default search and looks like this:
   
4. [Not doing at least now] Possibly add search block to other admin pages?
5. [Not doing at least now] We discussed having a keyword functionality -- a field added to the HelpTopic plugin that would define keywords that could be emphasized in the search, but decided that would not be part of this patch.
6. [Done] Write a test. Things to test:
   - [Done] If you enable Seven theme, you get the search block present on the help page.
   - [Done] Search works for some keywords. Probably best to use the test module HelpSection plugin for that.
   - [Done] Search permissions -- both the overall permission and the one that is used for a given help section. The existing help tests verify this with a section that has permissions, so we could make that HelpSection plugin searchable for further testing.
   - [Done] Internationalization of search -- again with that test plugin... the HelpSection plugins have control over how to render items for indexing/results in a given language, so it would not be too hard to fake the internationalization bit in the test.
   - [Done] Also add tests in the Help Topics module that verify that searching works with Help Topics in particular, and the internationalization of search works for Help Topics. But best to have the main tests independent of Help Topics I think?
   - [Done] Cache tags/contexts/etc.

User interface changes

Help topics provided by the Help Topics module will be searchable. There is a new block on the main Help page that lets you search help.

API changes

No changes to existing APIs.

New API: HelpSection plugins that also implement the new interface \Drupal\help_topics\SearchableHelpInterface will make their topics searchable. So far, only the HelpTopicsSection in the help_topics module implements this interface.

Data model changes

A new database table help_search_items is added to keep track of the IDs of help topics that are searchable.

Release notes snippet

We have added a new search type (that is, a new @SearchPlugin plugin) to Core, to go along with the Node and User search types that already existed. This search type is for searching help, and its plugin is called \Drupal\help_topics\Plugin\Search\HelpSearch (it is in the experimental Help Topics module). Using this type of search, administrators can define search pages that will provide help search to site users with permission to view help.

Modules that provide @HelpSection plugins (which define sections for the admin/help page) can make their help text searchable by implementing a new interface \Drupal\help_topics\SearchableHelpInterface on their HelpSection class, which requires implementing two methods: listSearchableTopics() to list the IDs of help topics that should be searchable, and renderTopicForSearch(), which renders a single ID for either help indexing or help search results. As an example, see the \Drupal\help_topics\Plugin\HelpSection\HelpTopicsSection plugin, which is currently the only HelpSection plugin that implements this interface. (So, currently if you search help, you are only searching Help Topics managed by the Help Topics experimental module.)

I'm getting the following error on a taxonomy term layout that appears to have started after the 8.6.15 update. It looks like it's trying to load a block that's been deleted.

https://git.drupalcode.org/project/drupal/blob/8.8.x/core/modules/layout...

Error
[error] 8#8: *167 FastCGI sent in stderr: "PHP message: Error: Call to a member function getEntityTypeId() on null in /var/www/html/public/core/modules/layout_builder/src/Plugin/Block/InlineBlock.php on line 206 #0 /var/www/html/public/core/modules/layout_builder/src/EventSubscriber/BlockComponentRenderArray.php(93): Drupal\layout_builder\Plugin\Block\InlineBlock->build()
#1 [internal function]: Drupal\layout_builder\EventSubscriber\BlockComponentRenderArray->onBuildRender(Object(Drupal\layout_builder\Event\SectionComponentBuildRenderArrayEvent), 'section_compone...', Object(Drupal\Component\EventDispatcher\ContainerAwareEventDispatcher))
#2 /var/www/html/public/core/lib/Drupal/Component/EventDispatcher/ContainerAwareEventDispatcher.php(111): call_user_func(Array, Object(Drupal\layout_builder\Event\SectionComponentBuildRenderArrayEvent), 'section_compone...', Object(Drupal\Component\EventDispatcher\ContainerAwareEventDispatcher))
172.22.0.2 - - [19/Apr/2019:09:10:12 +0000] "GET /admin/structure/taxonomy/manage/related_links/overview/display-layout/default HTTP/1.1" 500 85 "-""Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:66.0) Gecko/20100101 Firefox/66.0""192.168.218.1" [error] 8#8: *167 FastCGI sent in stderr: "PHP message: Error: Call to a member function getEntityTypeId() on null in /var/www/html/public/core/modules/layout_builder/src/Plugin/Block/InlineBlock.php on line 206 #0 /var/www/html/public/core/modules/layout_builder/src/EventSubscriber/BlockComponentRenderArray.php(93): Drupal\layout_builder\Plugin\Block\InlineBlock->build()
#1 [internal function]: Drupal\layout_builder\EventSubscriber\BlockComponentRenderArray->onBuildRender(Object(Drupal\layout_builder\Event\SectionComponentBuildRenderArrayEvent), 'section_compone...', Object(Drupal\Component\EventDispatcher\ContainerAwareEventDispatcher))
#2 /var/www/html/public/core/lib/Drupal/Component/EventDispatcher/ContainerAwareEventDispatcher.php(111): call_user_func(Array, Object(Drupal\layout_builder\Event\SectionComponentBuildRenderArrayEvent), 'section_compone...', Object(Drupal\Component\EventDispatcher\ContainerAwareEventDispatcher))
172.22.0.2 - - [19/Apr/2019:09:10:12 +0000] "GET /admin/structure/taxonomy/manage/related_links/overview/display-layout/default HTTP/1.1" 500 85 "-""Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:66.0) Gecko/20100101 Firefox/66.0""192.168.218.1"

Backtrace

#0 /var/www/html/public/core/modules/layout_builder/src/EventSubscriber/BlockComponentRenderArray.php(93): Drupal\layout_builder\Plugin\Block\InlineBlock->build()
#1 [internal function]: Drupal\layout_builder\EventSubscriber\BlockComponentRenderArray->onBuildRender(Object(Drupal\layout_builder\Event\SectionComponentBuildRenderArrayEvent), 'section_compone...', Object(Drupal\Component\EventDispatcher\ContainerAwareEventDispatcher))
#2 /var/www/html/public/core/lib/Drupal/Component/EventDispatcher/ContainerAwareEventDispatcher.php(111): call_user_func(Array, Object(Drupal\layout_builder\Event\SectionComponentBuildRenderArrayEvent), 'section_compone...', Object(Drupal\Component\EventDispatcher\ContainerAwareEventDispatcher))
#3 /var/www/html/public/core/modules/layout_builder/src/SectionComponent.php(100): Drupal\Component\EventDispatcher\ContainerAwareEventDispatcher->dispatch('section_compone...', Object(Drupal\layout_builder\Event\SectionComponentBuildRenderArrayEvent))
#4 /var/www/html/public/core/modules/layout_builder/src/Section.php(80): Drupal\layout_builder\SectionComponent->toRenderArray(Array, true)
#5 /var/www/html/public/core/modules/layout_builder/src/Controller/LayoutBuilderController.php(208): Drupal\layout_builder\Section->toRenderArray(Array, true)
#6 /var/www/html/public/core/modules/layout_builder/src/Controller/LayoutBuilderController.php(104): Drupal\layout_builder\Controller\LayoutBuilderController->buildAdministrativeSection(Object(Drupal\layout_builder\Plugin\SectionStorage\DefaultsSectionStorage), 1)
#7 [internal function]: Drupal\layout_builder\Controller\LayoutBuilderController->layout(Object(Drupal\layout_builder\Plugin\SectionStorage\DefaultsSectionStorage), false)
#8 /var/www/html/public/core/lib/Drupal/Core/EventSubscriber/EarlyRenderingControllerWrapperSubscriber.php(123): call_user_func_array(Array, Array)
#9 /var/www/html/public/core/lib/Drupal/Core/Render/Renderer.php(582): Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}()
#10 /var/www/html/public/core/lib/Drupal/Core/EventSubscriber/EarlyRenderingControllerWrapperSubscriber.php(124): Drupal\Core\Render\Renderer->executeInRenderContext(Object(Drupal\Core\Render\RenderContext), Object(Closure))
#11 /var/www/html/public/core/lib/Drupal/Core/EventSubscriber/EarlyRenderingControllerWrapperSubscriber.php(97): Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->wrapControllerExecutionInRenderContext(Array, Array)
#12 /var/www/html/vendor/symfony/http-kernel/HttpKernel.php(151): Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}()
#13 /var/www/html/vendor/symfony/http-kernel/HttpKernel.php(68): Symfony\Component\HttpKernel\HttpKernel->handleRaw(Object(Symfony\Component\HttpFoundation\Request), 1)
#14 /var/www/html/public/core/lib/Drupal/Core/StackMiddleware/Session.php(57): Symfony\Component\HttpKernel\HttpKernel->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#15 /var/www/html/public/core/lib/Drupal/Core/StackMiddleware/KernelPreHandle.php(47): Drupal\Core\StackMiddleware\Session->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#16 /var/www/html/public/core/modules/page_cache/src/StackMiddleware/PageCache.php(99): Drupal\Core\StackMiddleware\KernelPreHandle->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#17 /var/www/html/public/core/modules/page_cache/src/StackMiddleware/PageCache.php(78): Drupal\page_cache\StackMiddleware\PageCache->pass(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#18 /var/www/html/public/core/lib/Drupal/Core/StackMiddleware/ReverseProxyMiddleware.php(47): Drupal\page_cache\StackMiddleware\PageCache->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#19 /var/www/html/public/core/lib/Drupal/Core/StackMiddleware/NegotiationMiddleware.php(52): Drupal\Core\StackMiddleware\ReverseProxyMiddleware->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#20 /var/www/html/vendor/stack/builder/src/Stack/StackedHttpKernel.php(23): Drupal\Core\StackMiddleware\NegotiationMiddleware->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#21 /var/www/html/public/core/lib/Drupal/Core/DrupalKernel.php(693): Stack\StackedHttpKernel->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#22 /var/www/html/public/index.php(19): Drupal\Core\DrupalKernel->handle(Object(Symfony\Component\HttpFoundation\Request))
#23 {main}

This is a D7 back-port of #1681832: Password reset form has no flood protection. The last D7 patch there is #7.

Problem/Motivation

Currently, User X can request a new password an infinite amount of times. This can be confirmed by the logs at admin/reports/dblog.

Proposed resolution

Create flood event and enforce it.
Create/modify tests in order so that this patch can pass. Since the flood protection takes action after a while the user will not be able to login after too many tries, and this the way it should work. The tests should let this pass.

Remaining tasks

Review, ideally write tests.

User interface changes

New error messages.

API changes

None.

Problem/Motivation

When sorting by post date in a taxonomy term view, duplicates are returned. This is caused by the 'created' column from the taxonomy_index table being added to the SELECT statement of the query.

Here is an example of my taxonomy_index table:

mysql> select * from taxonomy_index where tid = '267';
+-----+-----+--------+--------+------------+
| nid | tid | status | sticky | created    |
+-----+-----+--------+--------+------------+
| 703 | 267 |      1 |      0 | 1556900391 |
| 621 | 267 |      1 |      0 | 1536762360 |
| 606 | 267 |      1 |      0 | 1533758079 |
| 514 | 267 |      1 |      0 | 1524601353 |
| 513 | 267 |      1 |      0 | 1524601137 |
| 512 | 267 |      1 |      0 | 1524600793 |
+-----+-----+--------+--------+------------+

Note that there are multiple entries for this tid because it appears on multiple nodes.

My views query is as follows:

SELECT DISTINCT taxonomy_index.created AS taxonomy_index_created, taxonomy_term_field_data.tid AS tid
FROM taxonomy_term_field_data taxonomy_term_field_data
LEFT JOIN taxonomy_term__field_initiatives taxonomy_term__field_initiatives ON taxonomy_term_field_data.tid = taxonomy_term__field_initiatives.entity_id AND taxonomy_term__field_initiatives.deleted = '0'
LEFT JOIN taxonomy_index taxonomy_index ON taxonomy_term_field_data.tid = taxonomy_index.tid
WHERE ((taxonomy_term__field_initiatives.field_initiatives_target_id = '222')) AND ((taxonomy_term_field_data.vid IN ('project')) AND (taxonomy_term_field_data.status = '1'))
ORDER BY taxonomy_index_created ASC

This query produces the following results:

+------------------------+-----+
| taxonomy_index_created | tid |
+------------------------+-----+
|                   NULL | 268 |
|                   NULL | 270 |
|                   NULL | 284 |
|             1524600793 | 267 |
|             1524601137 | 267 |
|             1524601353 | 267 |
|             1533758079 | 267 |
|             1536762360 | 267 |
|             1556900391 | 267 |
+------------------------+-----+

You can see that tid 267 is retrieved multiple times. The DISTINCT has no effect because the taxonomy_index_created field is included in the SELECT statement.

Proposed resolution

When a sort is added to the view. I don't think it's necessary to add that column to the SELECT statement. For example, the following query, which omits taxonomy_index_created from the SELECT, returns without duplicates:

SELECT DISTINCT taxonomy_term_field_data.tid AS tid
FROM
taxonomy_term_field_data taxonomy_term_field_data
LEFT JOIN taxonomy_term__field_initiatives taxonomy_term__field_initiatives ON taxonomy_term_field_data.tid = taxonomy_term__field_initiatives.entity_id AND taxonomy_term__field_initiatives.deleted = '0'
LEFT JOIN taxonomy_index taxonomy_index ON taxonomy_term_field_data.tid = taxonomy_index.tid
WHERE ((taxonomy_term__field_initiatives.field_initiatives_target_id = '222')) AND ((taxonomy_term_field_data.vid IN ('project')) AND (taxonomy_term_field_data.status = '1'))
ORDER BY taxonomy_index.created ASC

The above query correctly returns without duplicates:

+-----+
| tid |
+-----+
| 268 |
| 270 |
| 284 |
| 267 |
+-----+

When a field with a machine name is filled out, you can inadvertently change the machine name with no indication that you have changed it.

Steps to reproduce:
- Go to /admin/people/roles/add
- Type "Default" in the Role name field
- Hit the tab key twice
- Type "notdefault"
- Press edit like you were going to change the machine name.

The machine name is now "notdefault," instead of "Default," like it should be. The preview next to the role name field does not update, and continues to say "default." This has been tested on Chrome, Firefox, Firefox Developer Edition, Brave, Opera and Microsoft Edge.

I propose we change the machine name field to have a on_change ajax callback to change the machine name preview field to whatever is in the machine name field. This would allow the user to see what the machine name really is without actually checking the field. Alternatively, we could remove the visually-hidden tag on the machine name field via an ajax callback, to have the effect of pressing edit when someone edits the field on the form.

If i'm not sure if this is a core issue or ds, but i get this error if hidden label formatter is used on disabled field, the move it to the content area, please see gif image below:

The full error message:

Drupal\Component\Plugin\Exception\PluginNotFoundException: The "hidden" plugin does not exist. in Drupal\Core\Plugin\DefaultPluginManager->doGetDefinition() (line 52 of core/lib/Drupal/Component/Plugin/Discovery/DiscoveryTrait.php).
Drupal\Core\Plugin\DefaultPluginManager->getDefinition('hidden') (Line: 56)
Drupal\Core\Field\FormatterPluginManager->createInstance('hidden', Array) (Line: 81)
Drupal\Core\Plugin\DefaultLazyPluginCollection->initializePlugin('hidden') (Line: 80)
Drupal\Component\Plugin\LazyPluginCollection->get('hidden') (Line: 148)
Drupal\Component\Plugin\LazyPluginCollection->getIterator() (Line: 114)
Drupal\Core\Plugin\DefaultLazyPluginCollection->getConfiguration() (Line: 320)
Drupal\Core\Config\Entity\ConfigEntityBase->preSave(Object, 1) (Line: 266)
Drupal\Core\Entity\EntityDisplayBase->preSave(Object) (Line: 434)
Drupal\Core\Entity\EntityStorageBase->doPreSave(Object) (Line: 389)
Drupal\Core\Entity\EntityStorageBase->save(Object) (Line: 259)
Drupal\Core\Config\Entity\ConfigEntityStorage->save(Object) (Line: 364)
Drupal\Core\Entity\Entity->save() (Line: 637)
Drupal\Core\Config\Entity\ConfigEntityBase->save() (Line: 469)
ds_field_ui_layouts_save(Array, Object)
call_user_func_array('ds_field_ui_layouts_save', Array) (Line: 111)
Drupal\Core\Form\FormSubmitter->executeSubmitHandlers(Array, Object) (Line: 51)
Drupal\Core\Form\FormSubmitter->doSubmitForm(Array, Object) (Line: 585)
Drupal\Core\Form\FormBuilder->processForm('entity_view_display_edit_form', Array, Object) (Line: 314)
Drupal\Core\Form\FormBuilder->buildForm(Object, Object) (Line: 74)
Drupal\Core\Controller\FormController->getContentResult(Object, Object)
call_user_func_array(Array, Array) (Line: 123)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}() (Line: 574)
Drupal\Core\Render\Renderer->executeInRenderContext(Object, Object) (Line: 124)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->wrapControllerExecutionInRenderContext(Array, Array) (Line: 97)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}()
call_user_func_array(Object, Array) (Line: 144)
Symfony\Component\HttpKernel\HttpKernel->handleRaw(Object, 1) (Line: 64)
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: 99)
Drupal\page_cache\StackMiddleware\PageCache->pass(Object, 1, 1) (Line: 78)
Drupal\page_cache\StackMiddleware\PageCache->handle(Object, 1, 1) (Line: 47)
Drupal\Core\StackMiddleware\ReverseProxyMiddleware->handle(Object, 1, 1) (Line: 50)
Drupal\Core\StackMiddleware\NegotiationMiddleware->handle(Object, 1, 1) (Line: 23)
Stack\StackedHttpKernel->handle(Object, 1, 1) (Line: 656)
Drupal\Core\DrupalKernel->handle(Object) (Line: 19)

Temporary solution is not to select hidden as label before moving the field into content area

content_translation_page_attachments() adds alternate links to the html head, which is fine. However these links also end up in the response headers (I honestly don't really understand why we do that). Now, when there are too many languages (in our case, we're working with 47), varnish will crash with a 503.

-   BogoHeader     Too many headers: Vary: Accept-Encodin
-   HttpGarbage    "HTTP/1.1%00200%00OK%00%0aDate: Fri, 28 Apr 2017 12:54:20 GMT%00%0aServer: Apache/2.4.12 (Ubuntu)%00%0aX-Powered-By: PHP/5.6.20%00%0aCache-Control: must-revalidate, no-cache, private%00%0aLink: <http://127.0.0.1:6081/en/handbook>; rel="alternate"; hreflang="en"%00%0aLink: <http://12%00"
-   BerespStatus   503
-   BerespReason   Service Unavailable
-   FetchError     http format error
-   BackendClose   17 default(127.0.0.1,,80)
-   Timestamp      Beresp: 1493384064.185137 3.703384 3.703163
-   Timestamp      Error: 1493384064.185146 3.703393 0.000010
-   BerespProtocol HTTP/1.1
-   BerespStatus   503

I've altered out these alternate links for now with hook_module_implements_alter(). But we shouldn't send those to varnish IMO.

/**
 * Implements hook_module_implements_alter().
 */
function module_module_implements_alter(&$implementations, $hook) {
  if ($hook == 'page_attachments') {
    unset($implementations['content_translation']);
  }
}

For the last two days I have been trying to discover the reason for a strange bug in a custom theme that I am currently developing.

Basically, I created a subtheme of a subtheme that simply wouldn't allow me to "install" it: I always got the "theme was not found" error message, although the theme appeared to be there and all required files were present. (Similar to what is described here, but not restricted to Install and set default, but also appearing on hitting Install.)

I found out how to circumvent this bug only by investigating the code in ThemeInstaller.php: Turns out the reason for this was a dependency that I had set on the parent theme (using the feature introduced here): When I removed this dependency, the subtheme could be installed without problems.

Steps for reproducing the bug:

• Create a simple theme parent (can be a subtheme of another theme) and declare a dependency on some module in parent.info.yml.
• Create a simple subtheme child of theme parent with only a basic setup in child.info.yml.
• Click Install on the /admin/appearancepage.

This results in an error message: "The child theme was not found." I haven't done a through investigation, but I think, this is caused at this point in ThemeInstaller.php:

        foreach (array_keys($theme_data[$theme]->requires) as $dependency) {
          if (!isset($theme_data[$dependency])) {
            // The dependency does not exist.
            return FALSE;
          }

          // Skip already installed themes.
          if (!isset($theme_list[$dependency]) && !isset($installed_themes[$dependency])) {
            $theme_list[$dependency] = $dependency;
          }
        }

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

Right now AjaxResponse doesn't implement CacheableResponseInterface. And as a result we can't set cacheability metadata.
Need to improve drupal and add Cacheable Ajax response class.

Layout Builder emits an "undefined index" PHP notice when overriding a bundle layout for an individual entity.

Steps to reproduce:

1. Enable both Layout builder and Field layout modules.
2. Go to the "Manage display" page of a particular bundle.
3. Go to the "Full content" view mode secondary tab and check both "Use Layout Builder" and "Allow each content item to have its layout customized."
4. On a particular entity, go to to the "Layout" tab.
5. See the PHP notice.

Original report:

I have and PHP Notice every time I open node (not bundle) layout settings.

Notice: Undefined index: region in Drupal\field_layout\FieldLayoutBuilder->buildForm() (line 109 of core/modules/field_layout/src/FieldLayoutBuilder.php).

And stackstrace:

Drupal\field_layout\FieldLayoutBuilder->buildForm(Array, Object) (Line: 64)
field_layout_form_alter(Array, Object, 'node_page_layout_builder_form') (Line: 539)
Drupal\Core\Extension\ModuleHandler->alter('form', Array, Object, 'node_page_layout_builder_form') (Line: 835)
Drupal\Core\Form\FormBuilder->prepareForm('node_page_layout_builder_form', Array, Object) (Line: 29)
Drupal\webprofiler\Form\FormBuilderWrapper->prepareForm('node_page_layout_builder_form', Array, Object) (Line: 277)
Drupal\Core\Form\FormBuilder->buildForm('node_page_layout_builder_form', Object) (Line: 93)
Drupal\Core\Controller\FormController->getContentResult(Object, Object)
call_user_func_array(Array, Array) (Line: 123)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}() (Line: 582)
Drupal\Core\Render\Renderer->executeInRenderContext(Object, Object) (Line: 124)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->wrapControllerExecutionInRenderContext(Array, Array) (Line: 97)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}() (Line: 151)
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: 38)
Drupal\webprofiler\StackMiddleware\WebprofilerMiddleware->handle(Object, 1, 1) (Line: 52)
Drupal\Core\StackMiddleware\NegotiationMiddleware->handle(Object, 1, 1) (Line: 23)
Stack\StackedHttpKernel->handle(Object, 1, 1) (Line: 693)
Drupal\Core\DrupalKernel->handle(Object) (Line: 19)
require('/var/www/drupal/app/index.php') (Line: 4)

I just created new node type and enable layout builder for it. Then I created a node with layout override.

My env:

Installation profile: Minimal (minimal-8.7.1)
Database updates: Up to date
Entity/field definitions: Up to date
PHP: 7.2.13
It's not clean drupal setup.

Problem/Motivation

Automated tests greatly increase the size of a bare Drupal installation on disk. (As of 609912bced (8.8.x, July 15, 2019), they accounted for 43M of 94M (46%).) And they provide no benefit to end users in production. Indeed, they can contribute to security vulnerabilities and other problems. The number and size of files can also be a problem for users of shared hosting (c.f. #2338671: Create a smaller Drupal core download, removing tests, for production sites.), and they needlessly increase download and transfer times and disk usage for everyone, including drupal.org.

Proposed resolution

Use the approach documented in Use gitattributes to keep your tests out of other people’s production to exclude all tests/ directories from release packages. Since the Drupal.org packaging system already uses git-archive to create releases, the change would involve nothing more than the addition of a few lines to our .gitattributes file and would take effect immediately. Note: This would have no effect on Git clones, so neither the testbot nor core contributors would be affected.

Remaining tasks

• Consider possible unintended consequences.
• Review/test (forthcoming) patch.
• Probably write a change notice.
• Decide when to commit/release the change.

User interface changes

If tests can be considered to belong to the user interface in any sense, the change is that they will disappear from tarballs.

Release notes snippet

TBD.

Problem/Motivation

This is a follow-on to #2745123: Simpletest module crashes on cleanup, uninstall which will, we hope, find non-disruptive solutions to the problem of class loading classes under core/tests during runtime. This includes the problem of simpletest_clean_environment() needing to access TestBase.

In this issue we can refactor the simpletest cleanup code to be more maintainable and clear, with inversion of control, in a somewhat more disruptive way for 8.3.x.

simpletest_cleanup_environment() is used by both the Simpletest UI and run-tests.sh. This makes it a good candidate for refactoring to improve the testing system moving forward.

Proposed resolution

Refactor the following functions into a helper class called something like EnvironmentCleaner:

• simpletest_clean_environment()
• simpletest_clean_database()
• simpletest_clean_temporary_directories()
• simpletest_clean_results_table()

Mark these functions as deprecated.

Remaining tasks

Turn the EnvironmentCleaner class into a proper service. This would involve turning the TestDatabase class into a service or parameter service as well which might be outside the scope of this issue.

User interface changes

API changes

Data model changes