AssertLegacyTrait::assertFieldByName() is deprecated in drupal:8.2.0 and is removed from drupal:10.0.0. Use $this->assertSession()->fieldExists() or $this->assertSession()->buttonExists() or $this->assertSession()->fieldValueEquals() instead. See https://www.drupal.org/node/3129738
Ditto.
Some WebAsserts methods are used to convert to PHPUnit earlier Simpletest tests. The original methods carried $message and $group arguments that were used to print information on the Simpletest Test Results UI - but no longer are relevant in PHPUnit.
In order to prevent cruft, deprecate passing more arguments than the signature allows, so that in D10 these deprecation can be converted to exception throwing.
The route user.page (path = /user) exists as a distinct route from entity.user.canonical (path = /user/{user}). However, once #2294571: Redirect anonymous users to login page from an exception listener instead of in MaintenanceModeSubscriber and restrict access to the my-account link to authenticated users lands, all the former route does is redirect to the latter one. That allows the "My account" link (a static link defined in user.links.menu.yml, so no current support to vary a route parameter by user) to work, but the redirect requires an extra server to browser back to server round trip.
Make the entity.user.canonical route define the {user} parameter as optional and add something (a route enhancer?) that defaults it to the currently logged in user.
Make the "My account" link support dynamic route parameters: #2306991: MyAccountMenuLink should dynamically adjust route parameters, not hidden property.
Pick an option and do it.
https://i.imgur.com/oQK6e47.png
Is there something I can do to resolve that? Or is it a bug?
Currently when the media library does access checking on the entity that opened the media library, it does so by loading the entity using a simple \Drupal\Core\Entity\EntityStorageInterface::load. When editing inline blocks and layout builder both of these things are true:
Steps to reproduce:
What is happening under the hood:
\Drupal\layout_builder\EventSubscriber\SetInlineBlockDependency::isBlockRevisionUsedInEntity).::load call doesn't match the actual revision ID in the layout and the access chain is broken, resulting in an access denied.Pass the host entity's revision ID around, instead of it's ID and load that instead for the purposes of access control.
Example inside an svg that is imported in css as data-url:<path fill="url(#SVGID_1_)" d="M1256.4,386h1500v21h-1500V386z"/>
Notice the "url(#SVGID_1_)". This will be converted tourl(http://domain.com/path/path/#SVGID_1_1)
Resulting in a broke svg.
(added an svg that has this problem)
A Site builder wants 2x search filters on the site.
Site builder has as no documented way to do this:
Steps tried that seem working.
Problems / bugs:
If display IDs are different, we can have different results.
Working:
Page: "page_1" (used on search result page)
Exposed "page_exposed"
NOT working:
Page: "page_1"
Exposed "exposed_page" (used on search result page)
NOT working:
Page: "page_search"
Exposed "exposed_page" (used on search result page)
NOT working:
Page: "page_search"
Exposed "page_exposed" (used on search result page
It seems if "exposed" is first in display ID, it will be used for the result page.
It seems if "page" is first in display ID AND it is page_1, it will be used for the result page but only if the earlier is FALSE.
Order of displays does not seem to have an effect.
Documentation page is updated: https://www.drupal.org/docs/8/core/modules/views/expose-a-filter-to-site...
N/A
N/A
Not sure.
Not sure.
Not sure.
While working on a Rest-resource we have an issue with rendering Url's to private files.
We used $file->url() and that resulted in this error:
The controller result claims to be providing relevant cache metadata, but leaked metadata was detected. Please ensure you are not rendering content too early.
Diving into it looks like PrivateStream::getExternalUrl() and UrlGeneratorTrait::url() are here to blame, because these functions do not pass the collect_bubbleable_metadata attribute when rendering the url.
We used:
$file->url()
This will call file_create_url() located in /core/includes/file.inc
At some point in file_create_url() the appropriate wrapper is loaded and the method getExternalUrl() will be called.
// Attempt to return an external URL using the appropriate wrapper.
if ($wrapper = \Drupal::service('stream_wrapper_manager')->getViaUri($uri)) {
return $wrapper->getExternalUrl();
}
else {
return FALSE;
}
The function getExternalUrl on the PrivateStreamWrapper callsurl() in Drupal/Core/Routing/UrlGeneratorTrait.php
This doc-comment says that \Drupal\Core\Routing\UrlGeneratorTrait::url() follows \Drupal\Core\Routing\UrlGeneratorInterface::generateFromRoute(), but it does not.
The collect_bubbleable_metadata attribute is missing.
If the SystemMainBlock is used by a module like Page Manager, it will cause a fatal error.
See #2819219: Fatal error when "setMainContent()" method is not called (block module not installed)
Restrict the block to block.module.
Is this an abuse of the context system?
The Summary part of the textfield should have a WYSIWYG Editor because the format applies to body and summary.
@todo
- Lock down the format for summary in the widget. (?)
WYSIWYG editor available on the separate 'Summary' field on text areas that support them.
@todo
TBD.
TBD, hopefully none.
The fast_404 systems allows a shortcut path, which is by default configured to asset extensions like txt, png...
One case which is not covered currently is the case of source maps for CSS and JS, which are requested when devs have browsers with dev tools open, and which cause extra 404s all going to the Drupal backend (hopefully cached if cache_ttl_4xx is active).
Since these are assets, present or not, these requests should not have to go to the router is fast_404 has been set up, just like the other asset types.
As a relic of Drupal <6 the Statistics module only counts node views. Now we have many different entities we should be counting those too.
- Replace the node_counter table with statistics_counter
- Add column for entity type
- Replace node id column with entity id
- Replace statistics_node_view with statistics_entity_view
- Replace statistics_node_predelete with statistics_entity_predelete
All of them
none
none
- Table name changes
- Column name changes
If I 'wrap' my element into text_format element, the original description_display has no effect anymore. I think this is because text-format-wrapper.html.twig (and maybe the preprocess function) does not take it into account.
See #314385: Make position of #description configurable via the API
Under the current node revisions overview logic, it is possible for a page of the revisions listing to show no revisions. This is confusing.
The NodeController->revisionsOverview() method reads in all revisions of the current node, and then filters them down according to whether the revision in question has a translation for the currently active language, and whether that revision translation is 'affected'. This was done in #2465907: Node revision UI reverts multiple languages when only one language should be reverted to address the issue of the revision UI reverting multiple translations when it shouldn't be.
Because the paging of the revisions query doesn't account for language and 'affected' state, it is possible for the revisions query to return a set of revisions for a node of which none of the revisions belong to the language being tested, nor are any of them marked as 'affected'. This filters the list down to zero, which results in an empty table of revisions for that page, which is confusing.
It's possible for this situation to arise on a site with many active languages. Given a site with 55 languages, if a node goes through translation, and there is a new revision for each language that is translated, it would be very possible for a given page of revisions to contain no revisions eligible for display.
The logic which filters down the returned page of revisions to the current language and 'affected' should be able to be pushed into the revision query itself (NodeController->getRevisionIds()). Since this is a protected method not called anywhere else, it should be safe to add these conditions to the query, to allow the pager to function properly.