Fix references to the deprecated Entity class. It was renamed to EntityBase.
During the search for references I've found some more inconsistencies, which I hope could be fixed together.
Use this to search for instances grep -r "[/*].*[ \]Entity::" core | grep -v processStubRow | grep -v validateArgument | grep -v config_test
Review
We're using Linkit to link to nodes. In the autocompletion we would like to display the content moderation state of an item. We can do this using tokens but there's no token for the content moderation state.
Add tokens for content moderation state entities.
Gin has a new feature to display all form items in a sticky bar which resides outside of the actual <form>. This is natively support by HTML but will fail regular functional tests using submitForm() as this assumes the form actions being part of the <form>.
We temporarily override the submitForm() so the PHPUnit tests within the Gin theme do not fail. However if you run any functional testing on the backend it will now potentially fail.
I can think of a couple of ways how we can easily solve this.
Approach A:
Install Gin theme
Enable sticky form actions
Run PHPUnit tests on an admin form
Approach B:
Create form where button render outside the form actions
like:
<form action="/action_page.php" method="get" id="form1">
What is your favorite color? <input type="text" name="fav_color"><br>
<input type="submit">
</form>
<fieldset form="form1">
Name: <input type="text" name="username"><br>
Email: <input type="text" name="usermail"><br>
</fieldset>Reference link: https://www.w3schools.com/tags/att_form.asp
Now if you try to add Phpunit test case for this form , then test fails.
Alter submitForm() to support form actions being set outside of a <form>.
Update submitForm()
Olivero's pager component should be using SDC. Let's migrate it. The current code lives in core/themes/olivero/templates/navigation/pager.html.twig
This is a child issue of #3376057: [META] Add declare(strict_types=1) to all tests. After adding enabling strict types to all tests there were around 3000 errors. Fixing them all in one issue will lead to an enormous merge request that's difficult to review, as per the issue scope guidelines.
See #3400334: [PP-1] Add declare(strict_types=1) to all test modules
Review MR !5843
Follow up from #3443959: DialogRenderer::getTitleAsStringable() does not support all return types of TitleResolverInterface::getTitle() from @catch
I think we should have test coverage for the bug, but also I think we might want to open a dedicated issue for that and fix the regression before 10.3.0 beta so that various contrib aren't stuck with an unresolvable blocker. Bumping to critical and tagging as beta target.
Create module in which in modulename.routing.yml file , add _title_callback
Add ajax link on any page that 'll be open in modal:<a class="use-ajax" data-dialog-type="modal" href="/admin/content">Modal Page</a></p>
Here in the href of anchor tag goes the path of that page that defined in .routing file along with _titile_callback(key)
Add additional test coverage that covers that ticket
Implement
Review
N/A
N/A
N/A
N/A
Blocks are some of the most widely used config entities. They should be validatable. This would be very valuable for the Recipes Initiative, especially now that Recipes uses config validation (see #3405328: [meta] Make recipes safer to use in the real world by supporting config validation and rolling back a broken recipe for details).
This can easily become a huge scope, so limit the scope to be reviewable:
block.block.* validatable.type: block.settings.block_content:* to fix the accidental leftovers from when content blocks ("custom blocks" in Drupal 7) were split out — see #5type: block.settings.search_form_block).
search_form_block blocks'page_id setting
Block config entity in BlockValidationTest.Follow-ups:
None.
None.
None.
TBD
Follow-up for #3376376-26: HelpSectionManager::clearCachedDefinitions breaks the update system
We should be able to remove both places in 11.x - once the update is removed, we can also guarantee that the module has been updated to at least this schema version. Let's open a follow-up for that explicitly since there's no @deprecated tag or anything and probably a @todo linking to the issue as well.
$ git grep 10200 -- core/modules/help
core/modules/help/help.install:56:function help_update_10200(&$sandbox = NULL) {
core/modules/help/help.module:151: if (\Drupal::service('update.update_hook_registry')->getInstalledVersion('help') >= 10200) {
core/modules/help/src/HelpSectionManager.php:61: if ($this->searchManager && $version >= 10200) {
core/modules/help/tests/src/Functional/Update/HelpTopicsMerge.php:33: * @see \help_update_10200()
core/modules/help/tests/src/Functional/Update/HelpTopicsUninstall.php:32: * @see \help_update_10200()
Remove check and update hook help_update_10200() when updates for 11.0 will be prepared
patch, review, commit
no
no
no
Let's convert Olivero's teaser component to use single directory components. This currently lives in node--teaser.html.twig, and has an associated library.
SDC ecosystem is currently lacking a fully working way of using components while building displays (with block, layouts, field formatters...) from admin pages. They are some work currently in progress:
But we are not there yet and it may be hard for the SDC enthusiasts and early adopters to project themselves into a future where we use SDC components mainly from render arrays instead of from Twig templates.
So, today, most of the use of SDC components (in custom, contrib and core projects) seems to rely on "template to template" calls:
{{ include('sdc_examples:my-button', { text: 'Click Me', iconType: 'external' }, with_context = false) }}
{% embed 'sdc_examples:my-card' with { header: label } %}
{% block card_body %}
…
{% endblock %}
{% endembed %}
Those calls may cause incompatibly with those site building tools and may be considered as future technical debt.
For example, #3365367: Convert Olivero's teaser into a single directory component has recently replaced the markup of node--teaser.html.twig by a call to a component:
{% embed "olivero:teaser" with {
attributes: attributes.addClass(classes),
author_attributes,
author_name,
content,
...
} only %}
content variable is where the display build from admin pages (by Manage Display, Layout Builder, Display Suite...) is injected.
So, because the call to this component is now hardcoded, an unwanted olivero:teaser component will wrap the expected display, and the builder will have two solutions:
node--teaser.html.twig template in a theme to remove the call to this component and directly print content#theme => node wrapper, at the risk of missing or breaking some features built around this wrapperBecause of this #3365625: Migrate Olivero's comments to use single directory components, and other similar issues...It would be a pity if Olivero, the default Drupal theme, is becoming incompatible with the strategy of targeting the ambitious site builders by improving the display building experience.
In the upcoming SDC + experience builder era, we need to:
node.html.twig, user.html.twig, field.html.twig, block.html.twig, views.html.twig...) as:
#theme => node , #theme => field , #theme => block ...)Cache bin service naming is hardwired in Drupal and ListCacheBinsPass classes. This is weird and highly unusual, might be called an antipattern.
Also, RenderCache presumes every cache bin service is defined with factory: ['@cache_factory', 'get'].
cache.bin tag. This makes it possible to drop any presumptions on the service naming.
cache_factory_delegated service which allows getting any cache service. Drupal::cache becomes return static::getContainer()->get('cache_factory_delegated')->get($bin);. RenderCache similarly.
The necessary code is minimal because ListCacheBinsPass already exists. Not counting the BC layer, it requires three new lines of code there. The new DelegatedCacheFactory contains a single line of code of logic the rest is comments etc.
Review.
None.
Cache bins must now include a bin specified in the service tag.
None.
CR drafted.
When enabling the "Media" module and adding "Media types", these end up as first level links in the new navigation menu.
Before:
After:
--
Also, the top "User" link goes to "Add user" (which is under People > Add user). I don't know if this is the same as the other but as it is a first level link that seems "wrong" I am reporting it here.
Enable media, create media types
Enable navigation menu
Investigate.
The people at the county fair,
Were shocked asethey heard a loud blare:A bear, a bear!
it's right over there, it's right over there!
I swear, I swear!
It shouldn't be there, It _shouldn't_ be there!And one said with some flair:
And why exactly, should we care?
Because it causes a random ExpectationFailedException, you fake Dr. Suess!
1) Drupal\Tests\media_library\FunctionalJavascript\EntityReferenceWidgetTest::testWidget
"Bear" was found but shouldn't be there.
Failed asserting that a boolean is not empty.
/var/www/html/vendor/phpunit/phpunit/src/Framework/Constraint/Constraint.php:122
/var/www/html/vendor/phpunit/phpunit/src/Framework/Constraint/Constraint.php:55
/var/www/html/core/modules/media_library/tests/src/FunctionalJavascript/MediaLibraryTestBase.php:86
/var/www/html/core/modules/media_library/tests/src/FunctionalJavascript/EntityReferenceWidgetTest.php:212
/var/www/html/vendor/phpunit/phpunit/src/Framework/TestResult.php:728
And add to that,
the appearance of a cat!
Which is bad,
because the place it's at,
has no need for a cat.
O no, we don't want that!
Oh, shut up!
It seems that a similar random failure occurs (less frequently than the above one) later on in the test:
1) Drupal\Tests\media_library\FunctionalJavascript\EntityReferenceWidgetTest::testWidget
Behat\Mink\Exception\ResponseTextException: The text "Cat" appears in the text of this page, but it should not.
/var/www/html/vendor/behat/mink/src/WebAssert.php:811
/var/www/html/vendor/behat/mink/src/WebAssert.php:279
/var/www/html/core/modules/media_library/tests/src/FunctionalJavascript/EntityReferenceWidgetTest.php:417
/var/www/html/vendor/phpunit/phpunit/src/Framework/TestResult.php:728
In #3420990: Convert Constraint plugin discovery to attributes, \Drupal\Core\Validation\Annotation\Constraint plugins were converted to Attributes. MediaMappingsConstraint landed after that in #3271688: Remove source from media mappings and did not used Attributes.
Use attribute for MediaMappingsConstraint
It was discovered in #3379725: Make Block config entities fully validatable that the Block weight exported property is often null.
This seems to have been unintentional/an oversight, because
BlockInterface::getWeight() has a int return typeBlock::getWeight()does not cast from null to intTherefore null never makes sense, and it's only thanks to PHP's automatic typecasting that this has never been a problem 😅
N/A
nullable: true that #3379725: Make Block config entities fully validatable added.weight of null to 0 for all blocks.None.
None.
None.
None.
For entities with a large number of fields, it is cumbersome to drag all fields into the disabled section. This issue commonly arises when configuring teaser view modes where only a few fields need to be visible. If the functionality to disable all fields at once was available, it would be much quicker to then drag only the necessary fields back into view.
Add both "Disable All" and "Enable All" buttons or links to move all fields into the respective section.
Providing a Single Link Navigation Block type could be useful for situations where a single item needs to be added to navigation and creating a new menu just for this purpose would be overkill and complex for editors.
A good example of this is the Help link in the current navigation. This is a single link and it was hardcoded in the NavigationUserBlock to avoid creating an extra menu.
If we add this new item, we could migrate Help link to be an usage of this block type and significantly simplify logic in NavigationUserBlock.
Related issues where complexity could be reduced:
#3441576: Investigate using the core "User account menu" in favor of custom Navigation Block for same
#3441118: [PP1] Add the user image to the user menu when available
Current process to add a single link to page Foo in navigation:
Create a new Block plugin for use in the navigation, which allows for configuring a navigation block with a single link, rather than having to place a single link with the overhead of creating a menu, setting a link within it, then setting up a navigation block. This would alleviate the present hardcoding of the Help link as noted above, simplifying NavigationUserBlock, and potentially other user cases, also noted above.
Due to UX concerns with this approach, e.g. the potential proliferation of many single link blocks, this new block type will not be available to be added via UI. But created to make the work on the related issues smoother.
Update proposed resolutionUpdate change record
None. While we added a new Link block here, it is presently hidden from the general Block layout page as well as the Navigation layout page.
A new block with machine name navigation_link was added.
None.
In #2482295: Rebuilding field map with many bundles/fields is very slow, the bundle field map was moved from being generated on demand and cached to being saved in the KV store. I've encountered a number of projects where this has gone out of sync.
When this happens it can be really hard to track down, since there aren't any immediate adverse effects you can notice the issue long after it was caused. However it can still cause errors and create noisy log entries that emanate from views.
The map used to be generated on demand, so at least provide some method of programatically rebuilding the map, so when troubleshooting issues that are caused by an out of sync map, there is an easier way to diagnose and fix the problem.
Address #34
The simple component with null type (without wrapping it in a string) produces an unhelpful PHP error.
TypeError: Drupal\Core\Theme\Component\ComponentValidator::Drupal\Core\Theme\Component\{closure}(): Argument #1 ($type) must be of type string, null given in Drupal\Core\Theme\Component\ComponentValidator::Drupal\Core\Theme\Component\{closure}() (line 278 of core/lib/Drupal/Core/Theme/Component/ComponentValidator.php).
Create a component propert with type null:
$schema: https://git.drupalcode.org/project/drupal/-/raw/HEAD/core/assets/schemas/v1/metadata.schema.json
name: Example
status: experimental
props:
type: object
properties:
foo:
type: [null, boolean]
It should be 'null', but if you miss that part and get back to component usage later, it is hard to understand which component is the problematic one, because the error doesn't have any hints to it.
private function getClassProps(array $props_schema): array {
$classes_per_prop = [];
foreach ($props_schema['properties'] ?? [] as $prop_name => $prop_def) {
$type = $prop_def['type'] ?? 'null';
$types = is_string($type) ? [$type] : $type;
// For each possible type, check if it is a class.
$class_types = array_filter($types, static fn(string $type) => !in_array(
$type,
['array', 'boolean', 'integer', 'null', 'number', 'object', 'string']
));
$classes_per_prop[$prop_name] = $class_types;
}
return array_filter($classes_per_prop);
}
This is the current code from \Drupal\Core\Theme\Component\ComponentValidator::getClassProps. As you can see, the anonymous function expects $type to be a strictly string. But if it is NULL, this leads to a PHP error with an useless message.
$type = $prop_def['type'] ?? 'null';— this part also fails, because it is an array with a NULL value. https://3v4l.org/lfJ6e
NULL into 'null'.\Drupal\Core\Theme\Component\ComponentValidator::getClassProps and throw a meaningful exception with mention of component ID and problem.Decide how to handle this. The loop below also expects that all props will be strings, so maybe there should be a validation before that, to ensure that all property types are actual strings?
This is an edge case, but still causing same error:
$schema: https://git.drupalcode.org/project/drupal/-/raw/HEAD/core/assets/schemas/v1/metadata.schema.json
name: Example
status: experimental
props:
type: object
properties:
foo:
type: [!!float 12.3, boolean]