in #3316224: Drupal\FunctionalJavascriptTests\Tests\JSWebAssertTest randomly fails we added a worked around because some chrome driver requests were taking around 5 seconds. Which completely breaks a part of the test that relies on the request taking less than half a second.
SDCs should be able to limit what components are allowed within its respective slots.
An example use case of this is that an accordion_group component should only allow an accordion_item component in it's main slot.
Similar use cases are tab groups and tab items, or a card carousel and a card.
We also need to ensure this works if the replaces key is being used where a theme replaces a module's component with its own.
Note that this is a vital use case for Experience Builder which is due Q3 this year.
The feature added in #2205271: Project namespace for dependencies was missing some documentation of the new 'project' key. Let's add it here.
In \Drupal\Core\Extension\InfoParserInterface::parse change * - (versions): Version information, consisting of one or more
to * - (versions): (optional) Version information, consisting of one or more
MR with the recommended change
Review
Commit
Drupal\FunctionalJavascriptTests\Tests\JSWebAssertTest::testJsWebAssert sometimes fails randomly as per the output below.
JSWeb Assert (Drupal\FunctionalJavascriptTests\Tests\JSWebAssert)
✘ Js web assert
┐
├ WebDriver\Exception\StaleElementReference: stale element reference: stale element not found in the current frame
├ (Session info: chrome-headless-shell=127.0.6533.119)
│
│ /builds/issue/drupal-1822440/vendor/lullabot/php-webdriver/lib/WebDriver/Exception.php:198
│ /builds/issue/drupal-1822440/vendor/lullabot/php-webdriver/lib/WebDriver/AbstractWebDriver.php:227
│ /builds/issue/drupal-1822440/vendor/lullabot/php-webdriver/lib/WebDriver/Execute.php:56
│ /builds/issue/drupal-1822440/vendor/lullabot/php-webdriver/lib/WebDriver/Session.php:530
│ /builds/issue/drupal-1822440/vendor/lullabot/mink-selenium2-driver/src/Selenium2Driver.php:353
│ /builds/issue/drupal-1822440/vendor/lullabot/mink-selenium2-driver/src/Selenium2Driver.php:315
│ /builds/issue/drupal-1822440/vendor/lullabot/mink-selenium2-driver/src/Selenium2Driver.php:621
│ /builds/issue/drupal-1822440/vendor/behat/mink/src/Element/NodeElement.php:142
│ /builds/issue/drupal-1822440/core/tests/Drupal/FunctionalJavascriptTests/Tests/JSWebAssertTest.php:124
┴
Here's the relevant part of the test, the last line being the one that fails ($result->getAttribute('id')):
// Ensure that the javascript has replaced the element 1100 times.
$assert_session->waitForText('New Text!! 1100');
$result = $page->find('named', ['id', 'test_text']);
$this->assertSame('test_text', $result->getAttribute('id'));
The waitForText call returns TRUE or FALSE, but we don't check which we get. If the element doesn't exist we continue anyway.
Furthermore, it's possible the controller logic is flawed:
// Clear the interval after 1.1 seconds as this is shorter than the 10 seconds
// JSWebAssert::waitForElementVisible() waits for.
The comments suggest the the loop should take 1.1 seconds to complete, but in my browser it feels more like 5 seconds. I added some profiling and it varies from 4300 ms to 4600 ms for me. It's not unthinkable that this could take more than 10 seconds in some CI environments.
So in the case of a slow runner, waitForText is possibly exceeding the threshold. Then $page->find finds an element from loop number 1050 (for example). Then by the time we try to fetch the id attribute, the element has been replaced a further 50 times.
https://git.drupalcode.org/issue/drupal-1822440/-/jobs/4730776
This issue is intended as a tracking issue only to list all of the known intermittent test failures affecting Drupal core. Some issues are due to bugs in Drupal core; others may be due to issues with DrupalCI infrastructure.
Only open issues should be listed in the summary.
The core leader roles are being relabelled in #3474813: Use Drupal Core Leadership Team terminology in governance for clarity and to avoid confusion. We need to update MAINTAINERS.txt accordingly.
The problem is inherent in the way the queries are written, nothing is broken as we have passing tests.
Split #3513326: Add return type to functions in global namespace in to manageable chunks
See parent
Run ReturnTypeFromStrictNewArrayRector on module, inc, engine, theme, profile, sh, post_update.php files. Anything not detected by this rector rule is out of scope.
Manually fix @return annotations that are added but out of scope
In code comments, there are three references to the interface \Drupal\Core\TypedData\ListDefinitionInterface, which does not seem to exist. If you encounter references to \Drupal\Core\TypedData\ListDefinitionInterface in code comments or documentation, they might be erroneous, as this interface does not exist in Drupal 11.
$ grep -R 'ListDefinitionInterface' .
./core/lib/Drupal/Core/TypedData/ListInterface.php: * @see \Drupal\Core\TypedData\ListDefinitionInterface
./core/lib/Drupal/Core/TypedData/DataDefinitionInterface.php: * @see \Drupal\Core\TypedData\ListDefinitionInterface
./core/lib/Drupal/Core/TypedData/DataDefinitionInterface.php: * \Drupal\Core\TypedData\ListDefinitionInterface interface
$ ls -lah core/lib/Drupal/Core/TypedData/ListDefinitionInterface.php
ls: core/lib/Drupal/Core/TypedData/ListDefinitionInterface.php: No such file or directory
In Drupal 11, there is no interface named \Drupal\Core\TypedData\ListDefinitionInterface. If you're looking for the interface that defines data definitions for lists, you should use \Drupal\Core\TypedData\ListDataDefinitionInterface instead.
Check the commit history to verify that the name change is correct.
when a custom URL under "Link display" is used for a given display, there is not anything in views to check user access to these links.
@dawehner suggested using the access system provided by the routing system.
this was discovered in #2020393-11: Convert "Recent content" block to a View, when a "More" link was being added.
Instructions to reproduce the issue:
Check if user has access to the read more link.
Code review
NA
NA
NA
NA
Follow-up from #3471104: Nightwatch and Functional JavaScript fails since selenium/standalone-chrome:128.
standalone-chrome:latest in updated deps jobOn the Node Revisions overview table, there is no link for the "View" operation in the "operations" dropdown button.
See screenshot:
The "View" link for the revision is generated in the "Revision" column as MMDDYY - H:i which is not always obvious.
1) As we already have an Operations column with a list of links operations that can be done on a revision, and
2) as "viewing" a revision is fact an operation,
I think we might add the "View" link as the first one on the Operations dropdown menu.
I'm attaching here a really small patch to cover this request.
Screenshot after I've applied the supplied patch:
This was uncovered by #2916898: Do not use basic_html text format for 'No log messages available.' message.
If you add a custom text with a text format to a views area (for example the empty text of many views), the view will not have a dependency on that text format, so that it will break when that text format is missing.
Add a dependency on the text format.
Fuzzing reveals that Html::cleanCssIdentifier() triggers a deprecation when called with a malformed string:
DEPRECATED preg_replace(): Passing null to parameter #3 ($subject) of type array|string is deprecated in core/lib/Drupal/Component/Utility/Html.php on line 129.
This can be reproduced with the attached file:
\Drupal\Component\Utility\Html::cleanCssIdentifier(file_get_contents('/var/www/crash-990e7227d1b261b58910c41def8090bb.txt'))
The code should probably check if $identifier is NULL before calling preg_replace.
Unless you're using the Standard profile, the default value of the Use the administration theme when editing or creating content option on the Appearance page is false, which means that node forms are rendered using the frontend theme. I feel like since the progress in the Admin UI and JavaScript Modernisation Initiative, the Claro theme set as default admin theme and the rise in popularity of Gin theme this is no longer a sensible default. Maybe I'm biased since I have never had to integrate admin forms with custom frontend themes, but is this still a thing nowadays?
Set up a fresh Drupal installation with the Minimal install profile and visit the Appearance admin page. The option is turned off.
Turn on the Use the administration theme when editing or creating content by default for new installations.
Do it.
Node forms will be rendered in the admin theme by default.
NodeViewBuilder hardcodes the display of the langcode field ignoring any formatter configuration. This is a barrier if you want to create new formatter such as:
Remove the hardcode langcode element in NodeViewBuilder and keep the wrapper for BC.
Review
The display of the language field will change a little, because the 'field-language-display' wrapper will be gone.
The 'field-language-display' wrapper will be gone. However, this fixes a potential issue with having multiple same ID's on the same page, e.g. on a node list.
None
Through the removal of the hardcoded display of the langcode field, are <a href="https://www.drupal.org/node/3325438">developers be able to provide new formatters</a>, so that sitebuilder can configure a different output.
-- Original report --
Any options that are selected for language field formatter are ignored and the language field is always displayed as plain text language name.
I have noticed this when I was writing custom field formatter for the language field. It's easy to see the problem once you try to change the output for the core's language field. For example try this formatter:
namespace Drupal\custom_formatter\Plugin\Field\FieldFormatter;
use Drupal\Core\Field\FieldItemInterface;
use Drupal\Core\Field\Plugin\Field\FieldFormatter\LanguageFormatter as BaseFormatter;
/**
* Plugin implementation of the 'custom_formatter' formatter.
*
* @FieldFormatter(
* id = "language_custom_fomatter",
* label = @Translation("Language with flag"),
* field_types = {
* "language"
* }
* )
*/
class LanguageCustomFormatter extends BaseFormatter {
/**
* {@inheritdoc}
*/
protected function viewValue(FieldItemInterface $item) {
$view = parent::viewValue($item);
$view['#plain_text'] .= ' Test';
return $view;
}
}
The formatter itself is registered correctly, you can enable it for the language field. The settings form works fine, but the actual output of the formatter is totally ignored. For example instead of seeing "English Test" I always get "English".
An invalid query is produced on a node revisions view when adding a relationship to the actual content and adding an exposed filter on Search keywords
Install the standard profile on Drupal 10.1.x
Import the attached views config (making sure to rename it to remove the underscore from views.view_
Visit admin/structure/views/view/test_revisions
Submit the filter in the view preview.
A view that is based on node revisions will create an incorrect query if a keyword search filter is included. I've attached the simplest of views from a new drupal 8.7 install to reproduce this. In trying to debug this on a client site I stepped through the search views plugin but it seems like the error in creating table aliases happens earlier which is why I assume the node module.
Here is a base query that works:
SELECT "node_field_revision"."vid" AS "vid", "node_field_data_node_field_revision"."nid" AS "node_field_data_node_field_revision_nid"
FROM
{node_field_revision} "node_field_revision"
LEFT JOIN {node_field_data} "node_field_data_node_field_revision" ON node_field_revision.nid = node_field_data_node_field_revision.nid AND node_field_data_node_field_revision.langcode = node_field_revision.langcode
WHERE "node_field_revision"."status" = '1'Here's the query that throws an exception when adding a search word of "test":
SELECT SUM(node_field_data_node_field_revision_node_search_index.score * search_total.count) AS "score", MIN(node_field_revision.vid) AS "vid", MIN(node_field_data_node_field_revision.nid) AS "node_field_data_node_field_revision_nid"
FROM
{node_field_revision} "node_field_revision"
LEFT JOIN {node_field_data} "node_field_data_node_field_revision" ON node_field_revision.nid = node_field_data_node_field_revision.nid AND node_field_data_node_field_revision.langcode = node_field_revision.langcode
LEFT JOIN {search_index} "node_field_data_node_field_revision_node_search_index" ON node_field_data_node_field_revision.nid = node_field_data_node_field_revision_node_search_index.sid AND (node_search_index.type = 'node_search' AND node_search_index.langcode = node_field_data.langcode)
LEFT JOIN {search_total} "search_total" ON node_field_data_node_field_revision_node_search_index.word = search_total.word
WHERE ("node_field_revision"."status" = '1') AND (("node_field_data_node_field_revision_node_search_index"."type" = 'node_search') AND (""."data" LIKE '% test %' ESCAPE '\\') AND ("node_field_data_node_field_revision_node_search_index"."word" = 'test'))
GROUP BY "node_field_data_node_field_revision_node_search_index"."sid"
HAVING (COUNT(*) >= '1')
The '.data' in the third WHERE condition should get replaced by something like 'node_field_data_node_field_revision_node_search_dataset.data' but the search plugin never gets passed any table aliases to use for replacements. line 175 of core/modules/search/src/Plugin/views/filter/Search.php$search_dataset = $this->query->addTable('node_search_dataset'); returns FALSE:
I was able to alter the query just for my view and that's basically what I had to do. I'm also hoping to figure out where this needs to be patched but I haven't figured that out myself yet.
#type fieldgroup exists only to add a class and after #3512236: Move fieldgroup CSS to its own library a library.
The only place it's used in core is the installer site configure form. Field UI uses the fieldgroup class without using the #type (don't ask me why).
I think we can deprecate and remove this entirely.
Error message
TypeError: array_filter(): Argument #1 ($array) must be of type array, null given in array_filter() (line 723 of /app/web/core/modules/views/src/Plugin/views/field/EntityField.php).
Also, confirmed in Drupal 10.4 and Drupal 11.0.
TBA
NA
NA
NA
NA
NA
TBA
Block layout overflow issue and Incorrect style for all draggable table on mobile.
1. login as admin
2. use claro or olivero (issue in both)
3. goto => structure => block layout
4. switch to mobile device you will see contents are overflowing outside page from right.
the fix is to add overflow scroll to table wrapper
Need review and test
scroll added for table and align for text and buttons are also fixed
Drupal version 11
