Problem/Motivation

#3041924: [META] Convert hook_help() module overview text to topics for the menu_link_content, menu_ui module(s).

Proposed resolution

Take the information that is currently in the hook_help module overview section for the module(s), and make sure the information is in one or more Twig help topic files. Steps:

1. Find the hook_help() implementation function in the core/modules/MODULENAME/MODULENAME.module file(s). For example, for the core Contact module, the module files is core/modules/contact/contact.module, and the function is called contact_help().
2. Locate the module overview portion of this function. This is located just after some lines that look something like this:
   

     switch ($route_name) {
       case 'help.page.contact':
   

   And ends either at the end of the function, or where you find another case 'something': line.

3. We want to end up with one or more topics about the tasks that you can do with this module, and possibly a section header topic. So, read the help and figure out a good way to logically divide it up into tasks and sections. See Standards for Help Topics for information on how to do this.
4. See if some of these tasks are already documented in existing topics. Currently, all topics are in core/modules/help_topics/help_topics. Note that to see existing topics, you will need to enable the experimental Help Topics module (available in the latest dev versions of Drupal 8.x).
5. For each task or section topic that needs to be written, make a new Twig topic file (see Standards for Help Topics) in core/modules/help_topics/help_topics. You will need to choose the appropriate module prefix for the file name -- the module that is required for the functionality. Alternatively, if the information spans several modules or if the information should be visible before the module is installed, you can use the "core" file name prefix. For instance, it might be useful to know that to get a certain functionality, you need to turn on a certain module (so that would be in the core prefix), but then the details of how to use it should only be visible once that module is turned on (so that would be in the module prefix).
6. File names must be MODULENAME.TOPICNAME.html.twig -- for example, in the Action module, you could create a topic about managing actions with filename action.managing.html.twig (and "MODULENAME" can be "core" as discussed above).
7. Make a patch file that adds/updates the Twig templates. The patch should not remove the text from the hook_help() implementation (that will be done separately).

Remaining tasks

a) Make a patch (see Proposed Resolution section).

b) Review the patch:

1. Apply the patch.
2. Turn on the experimental Help Topics module in your site, as well as the module(s) listed in this issue.
3. Visit the page for each topic that is created or modified in this patch. The topics are files in the patch ending in .html.twig. If you find a file, such as core/modules/help_topics/help_topics/action.configuring.html.twig, you can view the topic at the URL admin/help/topic/action.configuring within your site.
4. Review the topic text that you can see on the page, making sure of the following aspects:
   • The text is written in clear, simple, straightforward language
   • No grammar/punctuation errors
   • Valid HTML -- you can use http://validator.w3.org/ to check
   • Links within the text work
   • Instructions for tasks work
   • Adheres to Standards for Help Topics [for some aspects, you will need to look at the Twig file rather than the topic page].
5. Read the old "module overview" topic(s) for the module(s), at admin/help/MODULENAME. Verify that all the tasks described in these overview pages are covered in the topics you reviewed.

User interface changes

Help topics will be added to cover tasks currently covered in modules' hook_help() implementations.

API changes

None.

Data model changes

None.

Release notes snippet

None.

Problem/Motivation

Drupal 9 will come with a new version of Stable. Initially, the plan was to replace the old Stable with a new Stable theme, which essentially would force all themes to upgrade to the next Stable theme as part of the major version upgrade. Upgrading Stable can be cumbersome. Given that upgrading to the next Stable theme comes with very little benefits, it seems unlikely that themes would be interested in upgrading unless they are forced to do so.

Proposed resolution

1. Make base theme a require property in themes: #3065545: Deprecate base theme fallback to Stable
2. Copy current Stable to contrib project so that it can be used with Drupal 9. There's already a namespace reserved for this.
3. Create a new Stable theme with a new name for Drupal 9, following almost the same steps used to create Drupal 8 Stable in #2575737: Copy templates, CSS, and related assets to Stable and override core libraries' CSS
   1. Automated test for library overrides to ensure completeness
   2. Automated test for template overrides to ensure completeness
   3. Copy all the CSS, changing image paths as necessary
   4. Copy all the images, no changes No benefit to this step, they'll get copied when it becomes contrib, though.
   5. Add all the libraries-override needed to stable's .info.yml
   6. Copy all the templates, with appropriate doc changes
4. Deprecate the Drupal 8 Stable theme in Drupal 9 to be removed in Drupal 10.

Remaining tasks

• Agree on maintainers of the contrib project
• Copy code from Stable to the new project
• Decide what happens to Classy which depends on Drupal 8 Stable
• Agree on a name for the Drupal 9 Stable: #3094440: [policy, no patch] Agree on name for Drupal 9's Stable theme
• Create the Drupal 9 Stable theme and copy all the templates and assets to the new theme
• Write change record
• Remove dependency on Stable theme from core themes and tests not specifically testing Stable
• Deprecate Drupal 8 Stable (needs follow-up)

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

If you try to customize autocomplete labels, you're thwarted by autocomplete js, which appends the key rather than the value when an item is selected.

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

1. create a node.
2. open /admin/content on 2 browser tabs.
3. on the 1st tab delete the created node.
4. on the 2nd tab select the node created in step 1.
5. select the "Delete content" action.
6. click the "appy to selected items"

Now, there is an error message:

The website encountered an unexpected error. Please try again later.
Error: Call to a member function access() on null in Drupal\Core\Action\Plugin\Action\DeleteAction->access() (line 96 of core/lib/Drupal/Core/Action/Plugin/Action/DeleteAction.php).

Drupal\Core\Action\Plugin\Action\DeleteAction->access(NULL, Object) (Line: 372)
Drupal\views\Plugin\views\field\BulkForm->viewsFormSubmit(Array, Object) (Line: 132)
Drupal\views\Form\ViewsFormMainForm->submitForm(Array, Object) (Line: 187)
Drupal\views\Form\ViewsForm->submitForm(Array, Object)
call_user_func_array(Array, Array) (Line: 111)
Drupal\Core\Form\FormSubmitter->executeSubmitHandlers(Array, Object) (Line: 51)
Drupal\Core\Form\FormSubmitter->doSubmitForm(Array, Object) (Line: 589)
Drupal\Core\Form\FormBuilder->processForm('views_form_content_page_1', Array, Object) (Line: 318)
Drupal\Core\Form\FormBuilder->buildForm('views_form_content_page_1', Object) (Line: 216)
Drupal\Core\Form\FormBuilder->getForm(Object, Object, Array) (Line: 2206)
Drupal\views\Plugin\views\display\DisplayPluginBase->elementPreRender(Array)
call_user_func(Array, Array) (Line: 378)
Drupal\Core\Render\Renderer->doRender(Array) (Line: 450)
Drupal\Core\Render\Renderer->doRender(Array, ) (Line: 195)
Drupal\Core\Render\Renderer->render(Array, ) (Line: 226)
Drupal\Core\Render\MainContent\HtmlRenderer->Drupal\Core\Render\MainContent\{closure}() (Line: 582)
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) (Line: 76)
Drupal\webprofiler\EventDispatcher\TraceableEventDispatcher->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: 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: 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)

Proposed resolution

Show error message that the node cannot be deleted because it doesn't exist.

Remaining tasks

User interface changes

API changes

Data model changes

Problem/Motivation

If an exposed form is used on the same page with facets, it resets facet's URL parameters on each submit.

Proposed resolution

Add "Preserve query parameters from URL" option for the default exposed form plugin.

Remaining tasks

+ write patch
- write tests
- review

User interface changes

The "Preserve query parameters from URL" setting is added to the "Exposed form style"> "Settings" configuration form.

API changes

None.

Data model changes

The preserve_url_query_parameters option is added to views_exposed_form schema.

On /admin/structure/block/block-content page when no custom blocks are available, then the two UI strings touches each other, which is grammatically incorrect. This is because the block_content core module's Views plugin alters the empty listing by concatenating its own plus string in extra. We could provide some separation before this happening.

Right now, allow_insecure_derivates can only be set for the entire site. Add a new config so that it can be enabled only for certain styles.

Problem/Motivation

HTML classes should be usually added in templates instead of preprocess functions. Also, Drupal core modules shouldn't include represantional HTML classes.

Proposed resolution

Move the HTML classes from the preprocess function to the template. The classes should be added in a template in Classy / Stable but not in the module.

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Getting below error message after updating drupal:

Mismatched entity and/or field definitions
The following changes were detected in the entity type and field definitions.
Custom menu link
The Roles able to see the menu link field needs to be installed.
The Roles not able see the menu link. field needs to be installed.

Please check attached screen-shot for your reference.

Problem:

Using nested paragraphs creates multiple drag handles for sub-paragraph field.

What it looks like:

Steps to reproduce:
1. Create a new paragraph type (sub paragraph) (can be empty without fields)
2. Create two other paragraphs (main paragraphs) (the other one can be empty without fields)
3. Add a Paragraph field to the other main paragraph and include to sub paragraph in the reference type.
4. Add a Paragraph field to basic page and include the two main paragraphs in the reference type
5. Add a basic page and add there the paragraph type which has the sub field. It shows the three drag handles for the sub paragraph

This seems to be an issue in the Claro tabledrag, which has overriden the core tabledrag, because this doesn't happen with Seven administration theme. It seems that the Claro tabledrag.js is adding some wrappers and other divs to the html so that we end up with 3 drag handles. The problem doesn't come up with any other place in admin UI, but the nested paragraphs use the "multiple drag".

The difference seems to be here:

The output for the Seven admin theme:

<td class="field-multiple-drag">
  <a href="#" class="tabledrag-handle" title="Drag to re-order">
    <div class="handle">&nbsp;</div>
  </a>
</td>

And the output for the Claro theme:

<td class="field-multiple-drag tabledrag-cell tabledrag-cell--only-drag">
  <div class="tabledrag-cell-content js-tabledrag-cell-content">
    <a href="#" class="tabledrag-handle js-tabledrag-handle" title="Drag to re-order"></a>
    <div class="tabledrag-cell-content__item">
      <div class="tabledrag-cell-content js-tabledrag-cell-content">
        <a href="#" class="tabledrag-handle js-tabledrag-handle" title="Drag to re-order"></a>
        <a href="#" class="tabledrag-handle js-tabledrag-handle menu-item__link" title="Drag to re-order"></a>
          <div class="tabledrag-cell-content__item"></div>
      </div>
    </div>
  </div>
</td>

It adds the handle three times.

Problem/Motivation

PHP 7.4 was released in November 2019. Drupal 7 is not yet compatible with it.

Proposed resolution

Solution broken down to various smaller issues for easier review (not in priority or dependency order):

• #3084935: element_children() and DrupalRequestSanitizer::stripDangerousValues() should not use integer keys as array
• #3084943: Pass parameters as implode($glue, $pieces); reverse order is deprecated
• #3084945: Trying to access array offset on value of type null in _batch_finished()
• #3084953: Trying to access array offset on value of type null in _drupal_build_css_path()
• #3084955: Invalid characters passed for attempted conversion, these have been ignored in _color_unpack()
• #3084961: Trying to access array offset on value of type null in theme_pager/pager_first/pager_last/pager_previous/pager_next()
• #3084965: Trying to access array offset on value of type bool in search_excerpt()
• #3084980: Trying to access array offset on value of type null in path_delete()
• #3085088: menu_get_item() might return FALSE; calling code should take account of this
• #3085098: PHP Phar Stream Wrapper should be updated (PHP7.4 support, drop fileinfo dependency)
• #3085148: Remove unneeded field_test_field_attach_delete_bundle()
• #3085151: field_ui_display_overview_form() expects to always get an array from field_info_formatter_types()
• #3085163: Comment module incorrectly tries to delete own fields twice upon uninstallation
• #3087121: drupal_hmac_base64() should not blindly cast everything to string causing PHP notices/errors

Remaining tasks

Get all sub-issues to RTBC. Review and commit them all.

User interface changes

None.

API changes

Hopefully none. See sub-issues.

Data model changes

Hopefully none. See sub-issues.

Release notes snippet

This is the first Drupal 7 release to fully support PHP 7.4. Please test and report any bugs in the issue queue.

Problem/Motivation

Adding content is a critical function in Drupal. While we have added a tools block and a default shortcut for this EVERY OTHER MAJOR CMS puts an add or create content link in the MAIN toolbar. This is marked critical because it is a critical usability problem in Drupal that a new user has to hunt around just to find where to do the most fundamental thing that a CMS does; create content.

Content can not only be nodes, but also media items or custom entities

Proposed resolution

(a) The optimal solution would be to make "Add content" a primary toolbar item using hook_toolbar() with a tray for the available types.

(b) Alternatively, we can add another menu that is linked to "Add" and displayed in the tray. Node, Media and other modules can then add menu items to it, and sitebuilders can customize it per site.

Remaining tasks

Write new patch.

For (b)

• Create a menu in the system module (together with other menus).
• Display the menu in the toolbar, themed similar to the admin menu
• Configure Node module to add menu items for the default Add content and/or the default Add article and Add pages.
• In case the Media module provides default media types: add them as well.
• Remove the Add content short cut to avoid too much duplication.
• Change the hook_help text of the Toolbar and possibly of the Shortcut module.
• Fix the tests.

User interface changes

The item 'add content' would appear in the top toolbar.

This is a UI change and therefore the hook_help text and other documentation needs to be changed.

API changes

?

Data model changes

Problem/Motivation

#3086374: Make Drupal 8 & 9 compatible with PHP 7.4 introduces a workaround for easyrdf PHP 7.4 compatibility. We should remove that workaround.

Proposed resolution

Either:
Update easyrdf/easyrdf to a release containing https://github.com/njh/easyrdf/pull/311
OR:
Rewrite \Drupal\Tests\rdf\Traits\RdfParsingTrait to not rely on it

Remaining tasks

Decide on the solution.

User interface changes

None

API changes

TBD

Data model changes

None

Release notes snippet

TBD

Problem/Motivation

Steps to reproduce:

1. Install Drupal (standard profile)
2. Edit the "Content" view (/admin/structure/views/view/content)
3. Add an exposed filter for the "Tags" (field_tags) field. Make sure to "Dropdown" as "Selection type".
4. Change "Exposed form in block" to "Yes"
5. Save the view
6. Go the block layout page for the "Seven" theme (/admin/structure/block/list/seven)
7. Click the "Place block" button next to "Content"
8. Click "Place block" in the "Exposed form: content-page_1" row
9. Restrict the visibility of the block by page: "/admin/content" (not necessary but to avoid confusion)
10. Click the "Save block" button the block configuration modal
11. Navigate to the "Content" page (/admin/content).
12. You will see the exposed block with the "Tags" filter being empty.
13. Add a new term "Test" in the "Tags" vocabulary (/admin/structure/taxonomy/manage/tags/add)
14. Visit the content page again (/admin/content). The "Tags" filter is still empty.

Expected behavior: you can select "Test" in the "Tags" filter.

There is already another issue about terms in the exposed filter not updating @ #2900248: Exposed term filter is not updated when terms are added, deleted, or rearranged (caching issue?). That ticket is specific to the taxonomy term filter when the exposed filters are not displayed in a block. Applying the (working) patch in that issue will not resolve this issue.

Proposed resolution

The \Drupal\views\Plugin\BlockViewsExposedFilterBlock plugin inherits the cache contexts of the views display handler. This doesn't appear to be the case yet for cache tags.

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

On NodeTypeForm, the following description is incorrect:

Users with the Administer content permission will be able to override these options.

see the screenshot..

At least the "Create new revision" is not related to the Administer content permission.

\Drupal\Core\Entity\ContentEntityForm::addRevisionableFormFields()

$form['revision'] = [
  '#type' => 'checkbox',
  '#title' => $this->t('Create new revision'),
  '#default_value' => $new_revision_default,
  '#access' => !$this->entity->isNew() && $this->entity->get($entity_type->getKey('revision'))->access('update'),
  '#group' => 'revision_information',
];

This checkbox can be edited by anyone, as Drupal core does not apply any access restriction on this field (with hook_entity_field_access())