Quantcast
Channel: Issues for Drupal core
Viewing all 295251 articles
Browse latest View live

Replace usages of AssertLegacyTrait::assert(No)FieldByName, that is deprecated

$
0
0

Problem/Motivation

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

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet


Deprecate overloading arguments to WebAssert methods to prevent conversions of legacy Simpletest test to carry over cruft

$
0
0

Problem/Motivation

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.

Proposed resolution

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.

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

The user.page route only redirects, so remove it

$
0
0

Problem/Motivation

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.

Proposed resolution

Option 1

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.

Option 2

Make the "My account" link support dynamic route parameters: #2306991: MyAccountMenuLink should dynamically adjust route parameters, not hidden property.

Remaining tasks

Pick an option and do it.

User interface changes

API changes

Text trimmed half-way through tag/format problem

[Backport] The media library should perform access checks against the revision of the entity being edited

$
0
0

Problem/Motivation

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:

  • You aren't guaranteed to be modifying the latest or default revision of an inline block.
  • The revision ID of an inline block is very important to it's access control.

Steps to reproduce:

  • Enable media_library, layout_builder.
  • Add a media field + media library to a custom block type.
  • Enable layout builder + per entity overrides on a content type.
  • Embed a block with the media library field into a per entity override.
  • Create two revisions, modify the inline block in both.
  • Go to the "Revisions" tab and revert to the first revision.
  • Go back to the layout tab and try to edit and save a new image in the media library.
  • AJAX request will come back a 403.

What is happening under the hood:

  • The media library has an block content entity ID.
  • It loads that entity and checks access against it.
  • The inline block's access is based on it's host entity, so it loads the host and confirms the revision ID of the block is used on the layout (\Drupal\layout_builder\EventSubscriber\SetInlineBlockDependency::isBlockRevisionUsedInEntity).
  • The media libraries ::load call doesn't match the actual revision ID in the layout and the access chain is broken, resulting in an access denied.

Proposed resolution

Pass the host entity's revision ID around, instead of it's ID and load that instead for the purposes of access control.

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Drupal alter's svg fill path's with base url -> broken svg

$
0
0

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 to
url(http://domain.com/path/path/#SVGID_1_1)

Resulting in a broke svg.

(added an svg that has this problem)

Document how to have two sets of exposed filters for same view (e.g. header and main page)

$
0
0

Problem/Motivation

A Site builder wants 2x search filters on the site.

  • 1x on site header (just text search for example)
  • 1x on search results page (has text search and extra optional filters for example)

Site builder has as no documented way to do this:

Steps to reproduce

Steps tried that seem working.

  • Create a view.
  • Create a "page" display with path /search (display ID "page_1")
  • Edit and add text filter and leave default "no" to exposed filter in a block
  • Create a "page" display with same path /search (display ID "page_exposed")
  • Use the defaults filters from the first display. BUT set "yes" to exposed filter in a block
  • Add exposed filter block to the a header region.
  • Search from exposed filter and you will be redirected :page_1" dispaly of results.

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.

Proposed resolution

Documentation page is updated: https://www.drupal.org/docs/8/core/modules/views/expose-a-filter-to-site...

Remaining tasks

N/A

User interface changes

N/A

API changes

Not sure.

Data model changes

Not sure.

Release notes snippet

Not sure.

file_create_url() causes LogicException when used with certain stream wrappers

$
0
0

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 calls
url() 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.


SystemMainBlock only functions when used by block.module

Also use text editor (CKEditor) for "summary" of a text field

$
0
0

Problem/Motivation

The Summary part of the textfield should have a WYSIWYG Editor because the format applies to body and summary.

Proposed resolution

@todo
- Lock down the format for summary in the widget. (?)

Remaining tasks

  1. Update this summary to accurately reflect the proposed change.
  2. Fix the existing test failures.
  3. Add new tests to cover the new functionality.
  4. Move this back to 'Needs review'
  5. Reviews/refinements.
  6. RTBC.
  7. Commit.

User interface changes

WYSIWYG editor available on the separate 'Summary' field on text areas that support them.

Before

@todo

After

API changes

TBD.

Data model changes

TBD, hopefully none.

t() calls should be avoided , use $this->t() instead in color module

$
0
0

Problem/Motivation

Steps to reproduce

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

t() calls should be avoided , use $this->t() instead in link module

$
0
0

Problem/Motivation

Steps to reproduce

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

t() calls should be avoided , use $this->t() instead in responsive_image module

t() calls should be avoided , use $this->t() instead in text module

$
0
0

Problem/Motivation

Steps to reproduce

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

t() calls should be avoided , use $this->t() instead in search module

$
0
0

Problem/Motivation

Steps to reproduce

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes


fast_404 paths should include "map" files

$
0
0

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.

Count all content entities views in the Statistics module

$
0
0

Problem/Motivation

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.

Proposed resolution

- 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

Remaining tasks

All of them

User interface changes

none

API changes

none

Data model changes

- Table name changes
- Column name changes

Text format wrapper does not take description_display into account

Node revision UI will sometimes show no revisions on a page

$
0
0

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.

[ignore] patch testing

Viewing all 295251 articles
Browse latest View live


<script src="https://jsc.adskeeper.com/r/s/rssing.com.1596347.js" async> </script>