Problem/Motivation

This issue supports #2807237: PHPUnit initiative

It's a child of #2863044: [plan] Remove simpletest dependencies from PHPUnit-based tests

We have a long-standing issue about removing the caching of results in TestDiscovery: #1667822: Remove caching of test classes in TestDiscovery

We also have a need to remove TestDiscovery from the simpletest module context. Currently it's a service defined by simpletest module, but is only used as a service by simpletest module's test list form, which we want to phase out. It's used as a class by behaviors we want to keep, such as TestSuiteBase and run-tests.sh.

TestDiscovery also declares a dependency on ModuleHandlerInterface which is used to support hook_simpletest_alter(). chx wants to remove that hook, do YOU? #2460521: Deprecate hook_simpletest_alter()

Proposed resolution

Turn TestDiscovery into a lean, mean, test discovering machine, with few external dependencies.

Keep a deprecated semi-stub Drupal\simpletest\TestDiscovery class which subclasses the new one. This allows BC for code which passes the dependencies. This simpletest subclass is also responsible for invoking simpletest module's hooks and performs caching for consistent behavior.

Have the new class not cache results beyond static, because developers are adding and moving tests all the time, and will need to invalidate the cache every time they do. The cache system is also a dependency which TestDiscovery currently manages as a special case, so this amounts to removing that special case. Work underway here: #1667822: Remove caching of test classes in TestDiscovery

Move TestDiscovery outside of the simpletest module context, so it's not dependent on the module. Also move MissingGroupException which it depends on. Move them to core/tests.

Remaining tasks

User interface changes

API changes

Data model changes

Problem/Motivation

debug() can be helpful from time to time. Sadly its throwing an error which phpunit converts to an exception, which stops the processing of anything.

Proposed resolution

Allow Symfony's VarDumper component's dump() function to be used in tests.

Remaining tasks

User interface changes

API changes

Data model changes

Problem/Motivation

As a spin-off from #3037228: Add more test coverage to Help Topics, we would like to ensure that all topics written for the new Help Topics Core module have proper syntax, for all non-test modules in Core.

Proposed resolution

Add checks for the following syntax issues:
- Meta tag for the title (label) must be present (help_topic:label)
- Topic must be either top-level or related to a top-level topic
- HTML syntax is valid (without the Twig stuff and meta tags)
- All text in the topic is wrapped in Twig translation tags.
- No H1 tag
- If there is an H3, there should be an H2, and so on
- The topics can be viewed at their URL

Things we are not explicitly testing in this test:
- The discovery process already reads label, related, and top-level from the meta tags, so this test can use the result instead of verifying the meta tags itself.
- The discovery process throws an exception if any other meta tags are encountered
- We are only testing Core. It would be desirable to also test Contrib but I'm not sure how we could accomplish this... but as a note, if a particular contrib module is in the file system when you run these tests, it will be discovered and tested.

Remaining tasks

Add the checks.

User interface changes

None

API changes

None

Data model changes

None

Release notes snippet

Added new checks to ensure Help Topic Twig files have proper syntax.

ISSUE CREDIT

This was spun off from #3037228: Add more test coverage to Help Topics and a patch there was the starting point:
https://www.drupal.org/files/issues/2019-07-08/core-add-more-test-covera...

Please credit scott_euser on this issue, who created that patch, and jhodgdon, who reviewed it.

While creating a NODE, MENU SETTINGS section to have a 'Enabled' checkbox like it has at /admin/structure/menu/manage/, to prevent landing to unpublished node (if node is been NOT published while creating it).

There is a default_value variable in the doc comment
* - #default_value: Must be NULL or not set in case there is no value for the
* element yet, in which case a first default option is inserted by default.
* Whether this first option is a valid option depends on whether the field
but it doesn't work.

Problem/Motivation

If you have a jQuery UI dialog modal (a dialog having the modal configuration set to TRUE) and a Off canvas rendered at the same time (i.e. the dialog is opened via the Off canvas), the modal is repositioned incorrectly when resizing the window.

Here is an example using Layout Builder and the contrib. module Layout Builder Modal:

(thanks to kevinfunk for providing the GIF in #3074302)

The expected behaviour here would be that the modal keeps being centered on window resize.

You can also reproduce this behaviour in Drupal core:

<a href="/node/add/page" class="use-ajax" data-dialog-options='{"width": 500,"modal": true,"autoResize":true}' data-dialog-type="dialog">Dialog</a>

            <a href="/node" class="use-ajax" data-dialog-renderer="off_canvas" data-dialog-type="dialog">Off canvas</a>

If you only would open the Dialog, it would resize and the position would be as expected. But if you first open the off canvas, and then the dialog the same behaviour as with Layout Builder Modal.

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

In Views, it’s currently not possible to filter File Usage fields (module, type, id, and count) by either ‘Is empty (NULL)’ or ‘Is not empty (NOT NULL)’.

Proposed resolution

Add ‘allow empty’ => TRUE to these definitions for Views.

For example:

    $data['file_usage']['module'] = [
      'title' => $this->t('Module'),
      'help' => $this->t('The module managing this file relationship.'),
      'field' => [
        'id' => 'standard',
       ],
      'filter' => [
        'id' => 'string',
+        'allow empty' => TRUE,
      ],
      'argument' => [
        'id' => 'string',
      ],
      'sort' => [
        'id' => 'standard',
      ],
    ];

Remaining tasks

• Submit patch
• Do we need to update some tests for this?

User interface changes

None

API changes

None

Data model changes

None

Problem/Motivation

Whenever possible, responsive images should be built with srcset rather than the <picture> tag (more). Also, Stage File Proxy is a very common development tool. Unfortunately, when relying on SFP for image files that are being rendered through an image style that will output a srcset image tag, an exception is thrown that breaks the entire page.

Steps to reproduce

1. Install Drupal with the Responsive Images (core) module.
2. Create a responsive image style that will output a srcset image tag using this technique. The image styles used within the responsive image style should scale only by one dimension.
3. Create a content type with an image field.
4. Set that image field's formatter to be a "responsive image" using the style created in Step 2.
5. Create a piece of content and upload an image that will use that formatter.
6. Download and enable the Stage File Proxy contrib module and configure it to point to another origin if a file in the file system does not exist.
7. Move the image file from Step 5 outside of the current environment's file system, and into the place where the SFP origin points to, in such a way that when using SFP as designed, it would find and download this image file when it realized the current environment's file system didn't yet have it.
8. Navigate to the node page that should output the image using the responsive image formatter.

Expected result: Upon realizing the file isn't in the current environment's file system, Stage File Proxy should grab it from the origin (assuming it exists there) and should be able to use it when rendering the responsive image.

Actual result: An exception is thrown that breaks the entire page:

LogicException: Could not determine image width for 'public://image-name.jpg' using image style with ID: responsive_image_style. This image style can not be used for a responsive image style mapping using the 'sizes' attribute. in responsive_image_build_source_attributes() (line 391 of core/modules/responsive_image/responsive_image.module).

Notes: This error is not thrown when the responsive image style is configured to output a <picture> element. SFP will work as designed and the page/image will be displayed as expected.

Proposed resolution

Unfortunately, I don't know. Looking for guidance here from those more familiar with this functionality...

I assume that a bug that so heavily relies on a contrib module would normally be that module's problem, but this doesn't quite seem to be the case because the exception never gives SFP a chance to fetch the image. I suppose I could have framed it this way: if the image doesn't exist in the file system, an exception is thrown that breaks the whole page, but I would expect only a broken <img> tag on an otherwise OK page. I didn't because that seems more like a "fix your image" problem than a "developers are going to rely on this to work without issue and it won't" problem.

Remaining tasks

TBD

User interface changes

N/A

API changes

N/A

Data model changes

N/A

Problem/Motivation

Imagine an organisation WidgetCo with editors and users in a variety of different time zones. They commonly face 2 problems trying to use the Date module. Support for some of this was present in D7's date but lost as it went to D8 core.

A. When creating session entities as part of their annual conference in New York, the times of the sessions as input by the editor are interpreted by Drupal in terms of the time zone of the editor who is creating or updating it, not New York. In this case their sitebuilder needs to be able to control the time zone used by the widget to interpret the times the editors input.

B. When creating meeting entities to describe meetings held at various locations across the world, the same problem happens. But in this case the intended time zone needs to specified for each meeting by the editor, and that preference needs to be stored with the date/time.

Proposed resolution

• Refactor datetime formatters to simplify the logic.
• Give settings to the datetime widgets (shared in common with the formatters, and date_range) that allow sitebuilders to control the time zone used to interpret input.
• Add a new (optional) property to the date field (and date_range) that stores the preferred time zone.
• Create thorough tests to verify that all this arcane time zone handling is working correctly everywhere.

Remaining tasks

• Add tests for the widget and formatter settings forms
• Extend tests to cover date range
• Extend tests for the full range of formatters and widgets
• Debug the date_range formatter
• Various minor cleanups, debugging and testing per #105.
• Upgrade path tests
• Finish/reroll the datetime element once #2799987: Datetime and Datelist element's timezone handling is fragile, buggy and wrongly documented gets fixed
• Add constraint test coverage if #2847041: Add a format and start/end validation constraints to DateRangeItem to provide helpful REST/JSON:API error message gets resolved before this issue does
• Address deprecated tests per #242.1
• Resolve issue with JSON:API's handling of datetime data structure as described in #242.2
• Add migration-related test coverage per #245.1

User interface changes

A timezone handling configuration drop down on field storage configuration, and if configured for per-date storage, a timezone selector on the date widget.

API changes

• The datetime form element will have an optional #expose_timezone boolean, that if TRUE, will add a timezone selector to the element.
• Date time widgets and formatters will have various new methods. Possibly getDefaultValue() should be public.
  

  Data model changes

  Datetime storage will store a timezone per date.

  Screenshots

Hello all, it’s time for the weekly migration initiative meeting. The meeting will take place in slack in various threads

This meeting:
➤ Is for core migrate maintainers and developers and anybody else in the community with an interest in migrations
➤ Usually happens every Thursday and alternates between 1400 and 2100 UTC.
➤ Is done over chat.
➤ Happens in threads, which you can follow to be notified of new replies even if you don’t comment in the thread. You may also join the meeting later and participate asynchronously!
➤ Has a public agenda anyone can add to here.
➤*Transcript will be exported and posted* to the agenda issue. For anonymous comments, start with a :bust_in_silhouette: emoji. To take a comment or thread off the record, start with a :no_entry_sign: emoji.

Problem/Motivation

These functions in the simpletest module deal with the TestDatabase:

• simpletest_insert_asssert()
• simpletest_last_test_get()
• simpletest_log_read()
• simpletest_schema()

If we want to turn the simpletest module into a contrib module, we'll need to make sure their behavior is still in core so the test runner can use them.

Proposed resolution

Move the behavior of these functions to be methods on the Drupal\Core\Test\TestDatabase class.

Deprecate the functions for removal.

The special case is simpletest_schema(), which is an implementation of hook_schema(). This function is used by both the simpletest module (in a hook context) and the run-tests.sh script (not in a hook context).

Since it's used this way, it can also be a method on TestDatabase, which is then called by simpletest_schema().

Since simpletest_schema() is a hook, it won't be deprecated.

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

In #3057420: [meta] How to deprecate Simpletest with minimal disruption we are contemplating making simpletest a contrib module.

That issue has many steps involved in decoupling run-tests.sh (the test runner) from simpletest module. This issue is one of those steps.

run-tests.sh uses logic like this in order to figure out how to run tests it discovers:

          foreach ($matches[1] as $class_name) {
            $namespace_class = $namespace . '\\' . $class_name;
            if (is_subclass_of($namespace_class, '\Drupal\simpletest\TestBase') || is_subclass_of($namespace_class, TestCase::class)) {
              $test_list[] = $namespace_class;
            }
          }

We want to make \Drupal\simpletest\TestBase a soft dependency, so that run-tests.sh can operate completely independently of the simpletest module.

Similarly, run-tests.sh uses Drupal\simpletest\Form\SimpletestResultsForm::addResultForm(), so that it can build the results form for its --browser option. This should be turned into a lightweight form element builder somewhere within the Drupal\Core\Tests\ namespace, so that it can be used by both run-tests.sh and simpletest as contrib.

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

The dependency system in drupal is lacking certain features that we need going forward to support several desired use cases.

Current dependency management is handled in two ways:

• There is a 'core' key in the info.yml files that expresses whether or not an extension should be able to be used on an existing drupal core installation.
• There are 'dependency' keys in info.yml files that expresses whether or not an extension has all of its required dependencies in order to be installed.

We would like to be able to support the following use cases:

1. A drupal 8 extension, that is not using any deprecated code, should be able to be used with both drupal 8 and 9. (or 10/11 etc)
2. An extension should be able to express specifically which version of core it requires. i.e. A module taking advantage of an api's introduced in drupal 8.7.0, and bugfixed in 8.7.2, should be able to say it requires *at least* drupal 8.7.2.
3. An extension maintainers should be able to use semantic versioning for their modules, and should be able to express dependencies on other modules using semver constraint syntaxes.
4. Drupal should prevent users from installing modules that do not have all of their dependencies available, including 3rd party composer libraries.

Proposed resolution

There are several issues in the queue attempting to tackle these problems somewhat independently, but they are all interlinked, and an overall strategy has emerged.

Option 1.

Deprecate dependency management inside of .info.yml files, and move dependency related functionality to composer.json. The core key, dependencies, and test-dependencies would all move to composer.json. All other keys would stay in the .info.yml files. Deprecate in 8.8.x and remove before 9.0.0.
Much work and discussion has happened here:

• #1398772: Replace .info.yml with composer.json for extensions
• #3005229: [PP-3] Provide optional support for using composer.json for dependency metadata

Option 2.

Enhance what our .info.yml files are capable of so that they can support multiple core versions, as well as allow the dependency specifications to use semver so that contrib maintainers can start using semver.
Many issues. Much work:

• #2313917: Core version key in module's .info.yml doesn't respect core semantic versioning
• #2641658: Module version dependency in .info.yml is ineffective for patch releases
• #3004459: [PP-1] Fold in dependency parsing wisdom from project_composer
• #2807145: [policy no, patch] Allow contrib projects to specify multiple major core branches
• #3001344: ModuleHandler::parseDependency() can deal with beta1 but not beta
• #1322890: Add a property to .info files to allow modules to specify required php extensions
• #92233: Modules in conflict - conflicts[], breaks[], brokenby[] field in modules .info file
• #328932: Modules and partial dependencies - enhances[] and enhancedby[] field in modules' .info.yml files

Option 3.

Enhance .info.yml files to allow for multiple versions of core, and add *optional* support for composer.json
Allowing for multiple versions of core:

• #2313917: Core version key in module's .info.yml doesn't respect core semantic versioning

And take most of the work from the following issue, and adapt it to work in parallel with the existing system.

• #3005229: [PP-3] Provide optional support for using composer.json for dependency metadata

In various discussions with release managers and other core contributors, the was a general sense that the deprecating dependency management in .info.yml files in favor of composer.json seemed unlikely to happen before drupal 9, and is a fundamentally structural change that affects all existing d8 modules. Option 1 seemed unlikely and/or risky.

The second option has several limitations, and essentially duplicates a lot of the functionality that we get with composer by default, and still cannot solve some other longstanding issues like "should a user be able to enable a module if its 3rd party dependencies are not there"

The third option emerged as a potential best possible scenario, given the timing and goals.
We would enhance our core key in .info.yml files to allow maintainers to have their modules work with both drupal 8 and 9, with very little effort on their part. At the same time, we would add in *optional* support for using a composer.json as the source of dependency metadata.

This would allow users to continue to do what they were doing before, however, if they needed any of the more advanced features of dependency management (semver requirements, third party libs, conflicts, ~/^ operators etc) then they would be able to use the more feature rich option of having a composer.json.

Remaining tasks

Confirm with release mangers and other stakeholders preferences for this path.

Problem/Motivation

While working on JSON:API Schema, which iterates over data types to derive a schema, this error occurs when comment module is installed:

[error] The "entity:comment:comment" plugin does not exist. Valid plugin IDs for Drupal\Core\TypedData\TypedDataManager are: {long list of data types...}

After some digging, it appears it's because EntityDeriver.php has this guard:

if ($bundle !== $entity_type_id) {
  $this->derivatives[$entity_type_id . ':' . $bundle] = [ ...

This is a problem because bundles can have the same ID as their associated entity type ID. This happens in core when the comment module is installed because of the "Default comment" bundle which has a machine name of comment.

Proposed resolution

Change the guard to check that the entity type does not have a bundle entity type and also to check that a bundle has not been defined by hook_entity_bundle_info(_alter) rather than the simple check that the bundle ID does not equal the entity type ID.

Remaining tasks

Supply a patch.
Write a test.
Review

User interface changes

None.

API changes

None.

Data model changes

None.

Release notes snippet

None.

Problem/Motivation

format_size() is still a procedural function. Convert it to a object oriented code.

Proposed resolution

• Add a ::toString method to the \Component\Utility\Bytes class. It returns an untranslated string with the byte size converted to IEC, moving the calculation part of the code from format_size.
• Add a ::formatSize() method to TranslationInterface and its TranslationManager implementation, that using the new method provided in \Component\Utility\Bytes::toString to get the untranslated string and to translate it as appropriate.
• Add a ::formatSize() method to StringTranslationTrait as a helper to access TranslationManager::formatSize.
• Deprecate and remove usages of format_size().
• Add related PHP unit tests.

Remaining tasks

• reviews

User interface changes

none

API changes

See proposed resolution.

Hangouts on Air was officially decommissioned on August 1. :(

https://www.peggyktc.com/2019/06/hangouts-on-air-now-shows-going-away-in... lists some alternatives.

A recurring Zoom meeting looks like it will work (and remove the 10 participant cap—yay!) but requires downloading a desktop client, and:

1) At least @jhodgdon was having problems connecting from Linux (but this may just be a "need to download the desktop app" problem)

2) It doesn't automatically stream/archive to YouTube. (Though @mlhess thought he might be able to work around that with a Zapier account.)

RocketChat apparently also has in-browser video conferencing options, but requires all users to create and maintain a separate identity on an unofficial server and there may be privacy concerns with that.

@mlhess also looked into Zoom's webinar functionality, which is nice, in that it'll let you stream to YouTube and let people join (read-only) from a browser. But the main thing we need is archive to YouTube so that we can go back and revisit decisions. (Zoom will let you record to a .mp4 file, but then you need to put it somewhere.)

@hestenet offered DA's official Zoom if we decide that could work, and that might be the best option since it doesn't rely on a company. He and @mlhess are getting together at MWDS this week so hopefully something can work there.

Requirements

• Cross-platform (including Linux + mobile)
• Meeting can start without one specific person having to be able to start it
• Meeting can be recorded without one specific person having to record it
• Recording ideally archives automatically to YouTube so it can be later referenced in issues
• Random people who we may or may not know are allowed to join
• Some subset of those random people are allowed to share their screen

When I try to install Fields UI alongside with the Configuration Translation module, I get an error:

Error: Call to a member function getPath() on null in Drupal\config_translation\ConfigNamesMapper->getOverviewRoute() (line 247 of /var/www/html/web/core/modules/config_translation/src/ConfigNamesMapper.php) #0 /var/www/html/web/core/modules/config_translation/src/Routing/RouteSubscriber.php(39): Drupal\config_translation\ConfigNamesMapper->getOverviewRoute() #1 /var/www/html/web/core/lib/Drupal/Core/Routing/RouteSubscriberBase.php(37): Drupal\config_translation\Routing\RouteSubscriber->alterRoutes(Object(Symfony\Component\Routing\RouteCollection)) #2 [internal function]: Drupal\Core\Routing\RouteSubscriberBase->onAlterRoutes(Object(Drupal\Core\Routing\RouteBuildEvent), 'routing.route_a...', Object(Drupal\Component\EventDispatcher\ContainerAwareEventDispatcher)) #3 /var/www/html/web/core/lib/Drupal/Component/EventDispatcher/ContainerAwareEventDispatcher.php(111): call_user_func(Array, Object(Drupal\Core\Routing\RouteBuildEvent), 'routing.route_a...', Object(Drupal\Component\EventDispatcher\ContainerAwareEventDispatcher)) #4 /var/www/html/web/core/lib/Drupal/Core/Routing/RouteBuilder.php(184): Drupal\Component\EventDispatcher\ContainerAwareEventDispatcher->dispatch('routing.route_a...', Object(Drupal\Core\Routing\RouteBuildEvent)) #5 /var/www/html/web/core/lib/Drupal/Core/ProxyClass/Routing/RouteBuilder.php(83): Drupal\Core\Routing\RouteBuilder->rebuild() #6 /var/www/html/web/core/lib/Drupal/Core/Extension/ModuleInstaller.php(322): Drupal\Core\ProxyClass\Routing\RouteBuilder->rebuild() #7 /var/www/html/web/core/lib/Drupal/Core/ProxyClass/Extension/ModuleInstaller.php(83): Drupal\Core\Extension\ModuleInstaller->install(Array, true) #8 /var/www/html/web/core/modules/system/src/Form/ModulesListConfirmForm.php(173): Drupal\Core\ProxyClass\Extension\ModuleInstaller->install(Array) #9 [internal function]: Drupal\system\Form\ModulesListConfirmForm->submitForm(Array, Object(Drupal\Core\Form\FormState)) #10 /var/www/html/web/core/lib/Drupal/Core/Form/FormSubmitter.php(111): call_user_func_array(Array, Array) #11 /var/www/html/web/core/lib/Drupal/Core/Form/FormSubmitter.php(51): Drupal\Core\Form\FormSubmitter->executeSubmitHandlers(Array, Object(Drupal\Core\Form\FormState)) #12 /var/www/html/web/core/lib/Drupal/Core/Form/FormBuilder.php(589): Drupal\Core\Form\FormSubmitter->doSubmitForm(Array, Object(Drupal\Core\Form\FormState)) #13 /var/www/html/web/core/lib/Drupal/Core/Form/FormBuilder.php(318): Drupal\Core\Form\FormBuilder->processForm('system_modules_...', Array, Object(Drupal\Core\Form\FormState)) #14 /var/www/html/web/core/lib/Drupal/Core/Controller/FormController.php(93): Drupal\Core\Form\FormBuilder->buildForm('system_modules_...', Object(Drupal\Core\Form\FormState)) #15 [internal function]: Drupal\Core\Controller\FormController->getContentResult(Object(Symfony\Component\HttpFoundation\Request), Object(Drupal\Core\Routing\RouteMatch)) #16 /var/www/html/web/core/lib/Drupal/Core/EventSubscriber/EarlyRenderingControllerWrapperSubscriber.php(123): call_user_func_array(Array, Array) #17 /var/www/html/web/core/lib/Drupal/Core/Render/Renderer.php(582): Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}() #18 /var/www/html/web/core/lib/Drupal/Core/EventSubscriber/EarlyRenderingControllerWrapperSubscriber.php(124): Drupal\Core\Render\Renderer->executeInRenderContext(Object(Drupal\Core\Render\RenderContext), Object(Closure)) #19 /var/www/html/web/core/lib/Drupal/Core/EventSubscriber/EarlyRenderingControllerWrapperSubscriber.php(97): Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->wrapControllerExecutionInRenderContext(Array, Array) #20 /var/www/html/vendor/symfony/http-kernel/HttpKernel.php(151): Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}() #21 /var/www/html/vendor/symfony/http-kernel/HttpKernel.php(68): Symfony\Component\HttpKernel\HttpKernel->handleRaw(Object(Symfony\Component\HttpFoundation\Request), 1) #22 /var/www/html/web/core/lib/Drupal/Core/StackMiddleware/Session.php(57): Symfony\Component\HttpKernel\HttpKernel->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true) #23 /var/www/html/web/core/lib/Drupal/Core/StackMiddleware/KernelPreHandle.php(47): Drupal\Core\StackMiddleware\Session->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true) #24 /var/www/html/web/core/lib/Drupal/Core/StackMiddleware/ReverseProxyMiddleware.php(47): Drupal\Core\StackMiddleware\KernelPreHandle->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true) #25 /var/www/html/web/core/lib/Drupal/Core/StackMiddleware/NegotiationMiddleware.php(52): Drupal\Core\StackMiddleware\ReverseProxyMiddleware->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true) #26 /var/www/html/vendor/stack/builder/src/Stack/StackedHttpKernel.php(23): Drupal\Core\StackMiddleware\NegotiationMiddleware->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true) #27 /var/www/html/web/core/lib/Drupal/Core/DrupalKernel.php(669): Stack\StackedHttpKernel->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true) #28 /var/www/html/web/index.php(19): Drupal\Core\DrupalKernel->handle(Object(Symfony\Component\HttpFoundation\Request)) #29 {main}.

Both module installs but then cache clear command does not work, the same error appears. If I uninstall either fields_ui module or configuration translation module the error is gone.

I'm using the latest drupal 8.6.3, I have tested it on 8.5.5 and it's working normally.

Problem/Motivation

#3041924: [META] Convert hook_help() module overview text to topics for the forum 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. Existing topics could be in one of the following directories:
   

   core/modules/help_topics/help_topics
   core/modules/MODULENAME/help_topics
   core/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 one of the modules' help_topics directory (you will probably need to create that directory). Alternatively, if the information spans several modules or if the information should be visible before the module is installed, you can put it in core/help_topics. 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 Core), 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).
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 .
7. Make a patch file that adds/updates the Twig templates in Core. 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/action/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

Sections are currently given numbers by their order. Section 1, Section 2, etc.
As a more complex layout can be built by combining many simple layouts, it would be nice to be able to give meaningful names to these sections.

These would only be shown when editing the layout, never on the front end.

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Issue Summary

I ran into this error using the following code in an attempt to clear any existing messages before adding another via the new JS Messages API.

var messages = new Drupal.Message();
messages.clear(); // Throws exception - Uncaught TypeError: Cannot read property 'querySelectorAll' of null

This is a result of the fact that in the constructor: the messageWrapper can be initialized as null.

Drupal.Message = class {
    constructor(messageWrapper = null) {
      this.messageWrapper = messageWrapper;
    }

But in the clear function there is no check on a null value as exists in other functions such as add().

clear() {
  Array.prototype.forEach.call(
    this.messageWrapper.querySelectorAll('[data-drupal-message-id]'),
    message => {
      this.messageWrapper.removeChild(message);
    },
  );
}

Proposed Resolution

Minimally, the clear function should be updated with a defaultWrapper() call similar to add().

clear() {
  if (!this.messageWrapper) {
    this.messageWrapper = Drupal.Message.defaultWrapper();
  }
  Array.prototype.forEach.call(
    this.messageWrapper.querySelectorAll('[data-drupal-message-id]'),
    message => {
      this.messageWrapper.removeChild(message);
    },
  );
}

However, it might make even more sense to always initialize the messageWrapper in the constructor so that other calls such as select() don't throw this same exception.

Drupal.Message = class {
  constructor(messageWrapper = null) {
    if (!messageWrapper) {
      this.messageWrapper = Drupal.Message.defaultWrapper();
    } else {
      this.messageWrapper = messageWrapper;
    }
  }