ArgumentValidatorTermTest makes no HTTP requests but is a functional test
Convert ArgumentValidatorTermTest into a Kernel test
None.
None.
None.
None.
N/A
RelationshipRepresentativeNodeTest (from user module) makes no HTTP requests but is a functional test
Convert RelationshipRepresentativeNodeTest into a Kernel test
None.
None.
None.
None.
N/A
There are still functional tests that can be converted, entirely or partially into Kernel tests.
Identify them and convert them:
Discovered so far:
Done:
None.
None.
None.
None.
N/A
\Drupal\Core\Plugin\Context\ContextHandlerInterface::applyContextMapping() applies a set of contexts to a given plugin.
If any of the contexts required by the plugin are not present in those passed to the method, an exception is thrown.
However, if the plugin already had that context set, there is no reason to throw the exception
If a context is "missing" from those being applied, only throw an exception if the plugin doesn't already have that context
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.
A timezone handling configuration drop down on field storage configuration, and if configured for per-date storage, a timezone selector on the date widget.
datetime form element will have an optional #expose_timezone boolean, that if TRUE, will add a timezone selector to the element.
Datetime storage will store a timezone per date.
When accessing admin/structure/display-modes/view at the end of each entity type there's a link for adding a new view mode. Here are some examples:
Add new Custom block view mode
Add new Comment view mode
Add new Taxonomy term view mode
The problem is that the string used to create this output and also used for translation is: Add new %label @entity-type which looking above @entity-type should be 'Custom block', 'Comment' and 'Taxonomy term' not 'view mode' and %label should be 'view mode' not the actual entity types.
This is confusing when translating the UI and should be an easy fix.
Drupal 8 is running on CKEditor 4.x. CKEditor 5.x has gone stable and looks like it has enhancements to help improve the authoring experience.
CKEditor 5 also no longer relies on inline JavaScript, which requires a more permissive Content Security Policy due to its use in CKEditor 4 (#2789139: [upstream] CSP requires 'unsafe-inline' because of CKEditor 4).
Upgrade CKEditor in Drupal to 5.x.
TBD
TBD
A migration guide has been provided from migrating from 4.x to 5.x, covering plugins, skins, and APIs:
TBD
I applied the patch in #2952967: When allowing content items to have customized layouts, clicking 'Layout' on full view of a node takes you to the configuration for the 'default' view mode to my 8.5.0 project. Even with the patch applied, I was not able to view customized layouts on a per node basis.
Steps to reproduce:
- Enable the "full content" view mode for basic page
- Check "Allow each content item to have its layout customized."
- Create a new basic page
- Click "Layout" and add a block to the layout (I used the powered by Drupal block)
- Save the layout and view the node
I expected to see the customized layout with the new block added, but only the default layout appeared.
It appears that the allow_custom setting applies on a per-view mode basis. The third party settings config object for the view mode's layout_builder does not include that flag for any view mode configuration other than the default. LayoutBuilderEntityViewDisplay checks this value before it decides whether to return the section configuration from the view mode config or the customized layout stored with the node.
I updated the form method in LayoutBuilderEntityViewDisplayForm to include the layout options form elements for both "default" and "full" view modes and updated my view mode configuration. The customized layout was then used when viewing the node.
I am not sure this is the best solution as it appears that the layout stored with the node is not associated with a particular view mode so the updates would show for any view mode which can be customized. I think this can cause unexpected behavior as it is.
AccessPermissionTest makes no HTTP requests but is a functional test
Convert AccessPermissionTest into a Kernel test
None.
None.
None.
None.
N/A
HandlerAllTest makes no HTTP requests but is a functional test.
Convert HandlerAllTest into a kernel test.
None.
None.
None.
None.
N/A
TaxonomyIndexTidFilterTest makes no HTTP requests but is a functional test
Convert TaxonomyIndexTidFilterTest into a Kernel test
None.
None.
None.
None.
N/A
ConfigEntityImportTest makes no HTTP requests but is a functional test.
Convert it to a kernel test.
None.
None.
None.
None.
N/A
https://www.drupal.org/node/2880911 was fixed a long time ago but the codebase still has a code related to that issue (but not used anymore)
As that code is not used anywhere (lines 344-353 of KernelTestBase) it can be safely removed.
KernelTestBase used to say this;
+ // Prepare a precompiled container for all tests of this class.
+ // Substantially improves performance, since ContainerBuilder::compile()
+ // is very expensive. Encourages testing best practices (small tests).
+ // Normally a setUpBeforeClass() operation, but object scope is required to
+ // inject $this test class instance as a service provider (see above).
+ $rc = new \ReflectionClass(get_class($this));
+ $test_method_count = count(array_filter($rc->getMethods(), function ($method) {
+ // PHPUnit's @test annotations are intentionally ignored/not supported.
+ return strpos($method->getName(), 'test') === 0;
+ }));
+ if ($test_method_count > 1 && !$this->isTestInIsolation()) {
+ // Clone a precompiled, empty ContainerBuilder instance for each test.
+ $container = $this->getCompiledContainerBuilder($modules);
+ }
But that last if statement is now gone, leaving only the declarations of $rc and $test_method_count.
We are still migrating a Website from Drupal 6 to Drupal 8. After migrating a content-type with a link field I encountered this error when viewing the migrated node:
Error: Unsupported operand types in Drupal\Core\Utility\LinkGenerator->generate() (line 153 of core/lib/Drupal/Core/Utility/LinkGenerator.php).
After setting a breakpoint in transform() in Drupal\link\Plugin\migrate\process\FieldLink I noticed, that the link attributes got triple-serialized in our D6 page:$value['attributes'] = 's:13:"s:6:"a:0:{}";";'
This seems to have happened to others too, but the other issue fixes the symptoms: https://www.drupal.org/project/drupal/issues/2596937
As I don’t think a triple-serialized value ever worked, my suggestion is to reset the attributes to an empty array in case it is not working after the first two unserialize-attempts.
None
None
None
None
Prevent link field migration from creating invalid link attributes.
API page: https://api.drupal.org/api/drupal/core%21core.api.php/group/testing/8.6.x
At the bottom of the page, in Class list, below the "KernelTestBase Deprecated core/modules/simpletest/src/KernelTestBase.php Base class for functional integration tests. " should be added "KernelTestBase core/tests/Drupal/KernelTests/KernelTestBase.php Base class for functional integration tests."
So, the Class list should look like:
.....
Classes
.....
BrowserTestBase Deprecated core/modules/simpletest/src/BrowserTestBase.php Provides a test case for functional Drupal tests.
BrowserTestBase core/tests/Drupal/Tests/BrowserTestBase.php Provides a test case for functional Drupal tests.
KernelTestBase Deprecated core/modules/simpletest/src/KernelTestBase.php Base class for functional integration tests.
KernelTestBase core/tests/Drupal/KernelTests/KernelTestBase.php Base class for functional integration tests.
UnitTestCase core/tests/Drupal/Tests/UnitTestCase.php Provides a base class and helpers for Drupal unit tests.
WebTestBase core/modules/simpletest/src/WebTestBase.php Test case for typical Drupal tests.
.....
The block listing in Layout Builder is a little overwhelming for users. When adding a block to a Standard profile Article, there are 59 block plugins in the list. You can imagine that with contrib enabled this list would become even longer and more irrelevant for the majority of users. It looks like this, currently:
By default close all categories except for the entity type categories which contain the field blocks.
Inside the entity type categories move all of the non view configurable fields, anything that doesn't show up on the "Manage Display" page of the Field UI module, into a subsection labeled "More",
Here is the listing when it is first opened
Clicking "More" will show the other fields for the entity type.
The following issues are not blockers, but they are related because they will do even more to make the UI simple and pleasing for users:
Yes. See above.
None
None
The current regex used in _locale_parse_js_file (file core/modules/locale/locale.module) doesn't allow to format plural string that doesn't contains @count in it.
The current regex looks like this:
'~
[^\w]Drupal\s*\.\s*formatPlural\s* # match "Drupal.formatPlural" with whitespace
\( # match "(" argument list start
\s*.+?\s*,\s* # match count argument
(' . LOCALE_JS_STRING . ')\s*,\s* # match singular string argument
( # capture plural string argument
(?: # non-capturing group to repeat string pieces
(?:
\' # match start of single-quoted string
(?:\\\\\'|[^\'])* # match any character except unescaped single-quote
@count # match "@count"
(?:\\\\\'|[^\'])* # match any character except unescaped single-quote
\' # match end of single-quoted string
|
" # match start of double-quoted string
(?:\\\\"|[^"])* # match any character except unescaped double-quote
@count # match "@count"
(?:\\\\"|[^"])* # match any character except unescaped double-quote
" # match end of double-quoted string
)
(?:\s*\+\s*)? # match "+" with possible whitespace, for str concat
)+ # match multiple because we supports concatenating strs
)\s* # end capturing of plural string argument
(?:,\s*' . LOCALE_JS_OBJECT . '\s* # optionally capture string args
(?:,\s*' . LOCALE_JS_OBJECT_CONTEXT . '\s*)? # optionally capture context
)?
[,\)]
~sx';
With this regex, this JavaScript code will be correctly matched and translations will be available:
Drupal.formatPlural(quantity, "element", "@count elements");
But this JavaScript code will not be matched and translations will not be available:
Drupal.formatPlural(quantity, "element", "elements");
Proposed resolution: avoid having to have @count in the plural argument by modifying the regex like this:
'~
[^\w]Drupal\s*\.\s*formatPlural\s* # match "Drupal.formatPlural" with whitespace
\( # match "(" argument list start
\s*.+?\s*,\s* # match count argument
(' . LOCALE_JS_STRING . ')\s*,\s* # match singular string argument
( # capture plural string argument
(?: # non-capturing group to repeat string pieces
(?:
\'(?:\\\\\'|[^\'])*\' # match single-quoted string
|
"(?:\\\\"|[^"])*" # match double-quoted string
)
(?:\s*\+\s*)? # match "+" with possible whitespace, for str concat
)+ # match multiple because we supports concatenating strs
)\s* # end capturing of plural string argument
(?:,\s*' . LOCALE_JS_OBJECT . '\s* # optionally capture string args
(?:,\s*' . LOCALE_JS_OBJECT_CONTEXT . '\s*)? # optionally capture context
)?
[,\)]
~sx';
NOTE: A review of the issue queue and multiple efforts to search via Google did not turn up any relevant results to my issue. All issues that came up regarding this were from years ago and not relevant to unsupported operand types.
Running PHP 5.5.14 with Drupal 8 locally. Requirements state PHP 5.5.9 and above so I should be covered. I was receiving the below fatal error after migrating a site from D6 to D8. Sorry I don't have exact steps to reproduce, but I think the issue is a pretty clear one just reviewing the code.
Fatal error: Unsupported operand types in /Users/jessenicola/projects/jessenicola.com/docroot/core/lib/Drupal/Core/Utility/LinkGenerator.php on line 153
The code on line 153:$attributes = array('href' => '') + $variables['options']['attributes'];
As you can see, it's trying to bring two arrays together just using +, when array merge seems to really be the correct way of accomplishing this.
This code resolves the issue for me:$attributes = array_merge(array('href' => ''), $variables['options']['attributes']);
Steps to reproduce are rather prohibitive for the casual issue queue goer, but are as follows:
\Drupal\Core\Database\Connection::query() and ::defaultOptions() refer to a 'target' option where the database connection can be changed. This doesn't actually work, as with the current API you first define the target when setting up the connection object, then execute operations on it - you can't change it later. This is was presumably copied as-is from the db_*() functions which did support the 'target' option but now should be removed from the documentation.
Connection class, code and documentation.db_* wrappers manage the connection before invoking the OO API, and that the 'target' key is not passing throughConnection::query for any reasonReview patch
None
None
None