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

[PHP 8.1] Add a shim to Guzzle 6 for PHP 8.1 compatibility

$
0
0

Problem/Motivation

Guzzle 6 passes NULL as the $numeric_prefix parameter to http_build_query(). PHP 8.1 has tightened up parameter types and only allows strings here.

The Guzzle team will not fix this as Guzzle 6 is considered end of life, and the issue does not exist in Guzzle 7: https://github.com/guzzle/guzzle/pull/2918

Steps to reproduce

Proposed resolution

Guzzle does not use use function or prefix any function calls with \ so we can inject a shim into the GuzzleHttp namespace that intercepts the call and passes on the correct argument.

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet


Add a 'void' return typehint to custom assert* methods

$
0
0

Problem/Motivation

In #3131900: Refactor assertions that assign return values to variables we realized we have in test code assertion helpers in the form of assert*() methods that return a value to the caller. This is legacy of Simpletest. In PHPUnit, all assertions methods return types are typehinted to void, and PHPUnit any way stops test execution if an assertion fails, so no purpose to return a value anyway.

Proposed resolution

Typehint to void the custom assertion methods; methods that generate a return value should be converted to helpers called by the asserts if needed.

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Add an inline comment for the "two double colons" check in Renderer::doCallbac()

$
0
0

Problem/Motivation

#2247779: Allow #pre_render, #post_render and #post_render_cache callbacks to be service methods made it possible to use service methods as #pre_render, #post_render and #post_render_cache callbacks.

Sadly, it includes this very confusing hack. dawehner said that this was necessary (#2247779-12: Allow #pre_render, #post_render and #post_render_cache callbacks to be service methods):

      if (strpos($callback, '::') == FALSE) {

This sadly is needed at the moment because there are callbables like 'Drupal\comment\CommentViewBuilder::attachNewCommentsLinkMetadata' which sadly don't implement ContainerFactoryInterface
but EntityControllerInterface

At the time we deferred clarifying this to a follow-up (because it blocked other issues), but we forgot to do so. This confusing check again surfaced in a code review of an unrelated patch at #2273277-19: Figure out a solution for the problematic interaction between the render system and the theme system when using #pre_render, point 2, so it's about time we fix this.

Proposed resolution

Remove this check if possible, otherwise at least clearly document it.

Remaining tasks

TBD

User interface changes

None.

API changes

None.

Views hardcodes exposed filter block form ID's which breaks AJAX when the same form is shown multiple times on one page

$
0
0

Problem/Motivation

When an exposed filter is placed twice on the same page it gets the same html identifier. Every instance of this form needs a unique id.

Proposed resolution

Use Html::getUniqueId() to generate the ID.

Remaining tasks

Review

User interface changes

None

Release notes snippet

[pp-3] Bubbling of elements' max-age to the page's headers and the page cache

$
0
0

Problem/Motivation

When I set a certain block to be cached for up to e.g. 15 minutes, then I expect that the containing page also emits a corresponding header. And I also expect Drupal's page cache to honor this.

Examples:

  1. A block with a weather forecast summary. The data constantly changes so e.g. cache for maximum 15 minutes.
  2. A View with a date filter relative to current time, such as "Upcoming Events", showing say 3 soonest future events. The block can be cached for maximum until the time/day of first event, then it must be refreshed to exclude the event now in the past.

Proposed resolution

TBD

Workaround

Install contrib module Cache Control Override. However this is not perfect, and if you use it you might hit the exact same problems that are making this issue be postponed (see #113).

  1. Other system blocks such as forms, language switcher that are in fact cachable currently may emit max-age = 0 so will prevent caching after CCO is installed.
  2. CCO disables dynamic cache as well as static cache.
  3. CCO only detects max-age = 0 so it won't work if your block has a small positive max-age.

Also note that in the case of the second example above, Views will not automatically emit the correct max-age based on the presence of a date filter - you need to write a hook to do that.

Remaining tasks

We need to fix these issues first:

User interface changes

None.

API changes

None.

Upgrade tests to HTML5

$
0
0

This issue is part of #1333730: [Meta] PHP DOM (libxml2) misinterprets HTML5.

The Drupal\system\Tests\Theme\FunctionsTest needs to be upgraded to HTML5.

Blocked on #2667340: Usage of field_prefix and container-inline creates invalid markup. which was fixed in #3072752: Invalid markup in ImageItem (causes test failures with symfony/dom-crawler:4.3+).

Beta phase evaluation

Reference: https://www.drupal.org/core/beta-changes
Issue priorityMajor because the testing system needs HTML5 support to test HTML5 code.
Prioritized changesThe main goal of this issue is a bugfix to for HTML5 support, which is part of the Drupal 8 product.

Commit credits
Please give commit credits to all who have worked on the parent issue (#1333730: [Meta] PHP DOM (libxml2) misinterprets HTML5).

Entity invalidations in cachetags table are saved if Entity have cache disabled (persistent_cache = FALSE)

$
0
0

Problem/Motivation

My project have more than 10 million of entities, that have persistent_cache = FALSE property. They are not added to cache_entity table and this is right.

But the problem is that Drupal still save invalidations statistics into cachetags table, as result my cachetags table filled up by millions of unnecessary records, that dramatically slow-down the whole Drupal cache performance.

Steps to reproduce

1. Create the `test1` custom entity with persistent_cache = FALSE property.
2. Create about 1000 entities.
3. Lookup into cache_entity SQL table - you will not see those entities in it.
3. Lookup into cachetags SQL table - you will see 1000 records with tag like test1:123

Proposed resolution

Drupal should check the persistent_cache = FALSE and skip saving statistics to cachetags SQL table.

[meta] Priorities for 2021-12-01 release of Drupal 7

$
0
0

Assorted todo lists carried over from #3207851: [meta] Priorities for 2021-06-02 release of Drupal 7.

These are not necessarily in priority order.
Almost all of these fixes are viewed by some people to be important and may be included in their drush make or composer.json files.

Done

Not done

Issues which have had recent activity, and are RTBC.

Simple Fixes: These may only take a few minutes each to review and commit.

Important Fixes:

Unsorted Fixes:


FileStorage Bug

$
0
0

Problem/Motivation

Bug in Phpstorage/Filestorage

Steps to reproduce

In a Drupal 9.2.2 (and probably prior versions) change settings.php to add:
$settings['php_storage']['default']['class'] = '\Drupal\Component\PhpStorage\FileStorage';
Then go into configuration/clear cache and you will get:

results in:
"Warning: file_put_contents(sites/default/files/php/twig/60f9c22fee0ac_admin-block-content.html._dNvqx-a2l_IKrU2qS5LcIDcMB): failed to open stream: Is a directory in Drupal\Component\PhpStorage\FileStorage->save() (line 55 of /home/fkelly5/public_html/drupal8/core/lib/Drupal/Component/PhpStorage/FileStorage.php). =>

Proposed resolution

Fix line 55

Olivero: Save button and discard changes button are not aligned to each other in Discard Changes? the dialog box for quick-edit.

$
0
0

Steps to reproduce

1. Go to any page.
2. Quick edit the content on the page.
3. Make some changes and click on the close icon.
4. The Discard Changes? a dialog box will appear.

Only local images are allowed.

[PHP bug] Illegal length modifier specified 'f' in s[np]printf call on rename() in MTimeProtectedFastFileStorage

$
0
0

Hi,

I am getting a error when I am clearing a cache or opening module page it's happening on live server not in localhost

Error -

Fatal error: Illegal length modifier specified 'f' in s[np]printf call in /core/lib/Drupal/Component/PhpStorage/MTimeProtectedFastFileStorage.php on line 88

RuntimeException: Base route not available for route entity.field_config.image_slider_field_edit_form in Drupal\config_translation\ConfigNamesMapper->getOverviewRoute()

$
0
0

I get this message when trying to run Drush cr and/or clearing cache in drupal. Any help would be very much appreciated! I did not find anything on this issue I have already installed Path Auto Module and still getting the same error message.

The website encountered an unexpected error. Please try again later.

RuntimeException: Base route not available for route entity.field_config.image_slider_field_edit_form in Drupal\config_translation\ConfigNamesMapper->getOverviewRoute() (line 248 of core\modules\config_translation\src\ConfigNamesMapper.php).

Webform radios -> display issues

$
0
0

Problem/Motivation

Radios

Note: top is on Mac OS X/Chrome and bottom is on Mac OS X/Firefox (on larger screens). If I squish the Firefox window to smaller width -> the QEON radio button becomes visible.

Steps to reproduce

Install Webform module -> then add Element of type radios:

  area:
    '#type': radios
    '#title': Area
    '#options':
      1: AB/NWT
      2: AC
      3: BC/Y
      4: CSO
      5: QEON
      6: MB/SK/WO
    '#options_display': three_columns
    '#required': true

Documenting this here. Happy to provide more info and/or test possible patches. I'm seeing this on 9.1.x - I'll bump another site to 9.2.x to see if the issue is present there.

Make the JsWebAssert::waitFor*() methods behave like real assertions

Installing the syslog module uses its configuration before it is written

$
0
0

Problem/Motivation

While testing Drupal 8 on PHP 8.1 #3220021: [meta] Ensure compatibility of Drupal 9 with PHP 8.1 (as it evolves) it was discovered that \Drupal\syslog\Logger\SysLog is instantiated before it is written. This because we call \Drupal::getContainer()->get('plugin.cache_clearer')->clearCachedDefinitions(); before writing the config from syslog/config/install.

Steps to reproduce

Proposed resolution

Options:

  1. Bail early in \Drupal\syslog\Logger\SysLog::log() if $this->config->get('format') returns NULL.
  2. Provide hardcoded defaults in \Drupal\syslog\Logger\SysLog::log()
  3. add a config listener and update the config when it is written
  4. Decouple completely from config and fix #3103620: Dependency on config storage causes circular reference in service container too

In #3220021: [meta] Ensure compatibility of Drupal 9 with PHP 8.1 (as it evolves) I initially implemented option 3. This had the advantage of making it possible for syslog to log its own installation - i.e. the log message at the end of \Drupal\Core\Extension\ModuleInstaller::install(). One problem with this approach is that kernel tests with syslog still fail because config is often not installed with them.

Option 2 means that we'd have to keep the defaults across \Drupal\syslog\Logger\SysLog and config/install/syslog.settings.yml aligned. Also if you are doing a config import to install the syslog module and you've changed the config it'll use the wrong settings until the config kicked in.

Option 4 will involve way more way work and change the constructor and still has to grapple with when and which config to use to provide defaults.

Given the above option 1 is the simplest solution.

Remaining tasks

User interface changes

N/a

API changes

N/a

Data model changes

N/a

Release notes snippet


Remove taxonomy term description field; provide description field for forum taxonomy

$
0
0

Updated: Comment #171, #242

Problem/Motivation

  • Following #413192 make taxonomy terms fieldable, the taxonomy term description base field is unnecessary.
  • For some vocabularies, e.g. the forum vocabulary, a taxonomy term description is a reasonable part of the taxonomy data model.
  • The tags vocabulary supplied for article nodes is intended for freetagging, so a description field doesn't really fit the usecase for that vocabulary.

Proposed resolution

  • Remove the description base field from taxonomy.
  • Do not add a description field to term bundles by default.
  • Do not add it for tags.
  • Do add a fixed, locked description for forum terms, in forum.module, so that the templates and code there can rely on it.
  • Most likely what we need to do is convert it to a configurable field with the same name and add it to all bundles on existing installations, but we have \Drupal\taxonomy\TermInterface::getDescription(), so terms having a description is part of the API. so likely we need to install this configurable field even for new D9 installations, deprecate it for D10 and then remove the default config. But to not break the API, we'd literally need to *disallow* deleting and always force-enable that field on all vocabularies.

    #242

Remaining tasks

  • Update the patch for this issue to implement the proposed resolution, without any upgrade path.
  • TBD, potentially a followup discussion: For D7 -> D8 migrations, any term bundle having a populated description field for any terms in the vocabulary should be migrated into a new configurable description field on that term bundle on the destination site. How do we make this easy for people?

User interface changes

There is no longer a description field available on taxonomy terms by default.

API changes

Removed TermInterface methods as follows:
- public function getDescription();
- public function setDescription($description);
- public function getFormat();
- public function setFormat($format);

Beta phase evaluation

Reference: https://www.drupal.org/core/beta-changes
Issue categoryTask because not broken as is
Issue priorityNot critical because works as is
Prioritized changesThis is not a prioritized change for the beta phase (it does not fix a bug, improve usability or security or performance, etc.).
DisruptionDisruptive for core/contributed and custom modules/themes that use the removed methods, and for existing sites that have data in the field.

Pass the media library state object to createAccess()

$
0
0

Problem/Motivation

This got spun off from #2993187-34: Add a media library widget setting to only choose existing media and subsequent discussion. The media library already delegates access control for the "add new media" form to the entity system, but it does not provide any additional context (e.g., the MediaLibraryState object). If it did, then contrib modules and custom code could support more complex access control, including the functionality requested in #2993187: Add a media library widget setting to only choose existing media.

Steps to reproduce

N/A

Proposed resolution

In \Drupal\media_library\MediaLibraryUiBuilder::buildMediaTypeAddForm(), pass the MediaLibraryState object to the access control handler, in its $context parameter.

Remaining tasks

Create a merge request with test coverage.

User interface changes

None.

API changes

None.

Data model changes

None.

Release notes snippet

TBD.

Update standard profile so Olivero is the default theme

Webform button accessibility while Claro theme is enabled

$
0
0

Problem/Motivation

When Claro is enabled by default, some of the buttons in the Webform UI have very insufficient color contrast.
The contrast ratio is 1.47 out of a required 4.5
Text color #333333 against background of #003cc5

screenshot of bug

Steps to reproduce

  • Fresh Drupal 9 site.
  • Enable Claro, use as admin theme.
  • Enable Webform and Webform UI modules.
  • Create a new Webform.
  • Click to “+ Add element”
  • Black text on blue buttons on the “Select an element” modal.

Proposed resolution

I suggest having white text against the blue background like many of the other buttons in the UI

I tagged this issue with Needs issue summary update so others can weigh in on solution and decide on priorities.

Allow layouts to provide dynamic regions

$
0
0

Problem/Motivation

Currently layout_builder is very limited when it comes to more complex layouts. The issue is lack of nesting or wrapping ability. See:

I believe that all use cases bringing people towards these issues could be solved if we would simply allow people to create layouts with configurable regions. These could be a "second class citizens", yet would allow devs or contrib modules to develop custom complex rules of layout building, and store them in layouts configurations.

Proposed resolution

Introducing a new DynamicRegionsProviderInterface that could be implemented by Layout classes. That would allow layout to provide additional regions if needed. Thanks to that, we could work around any limits currently set by the layout_builder, by delegating dynamic construction of more complex layout structures to the Layout class itself.

Remaining tasks

  • Patch review
  • Discuss and agree on the solution

API changes

Addition of a new optional interface for layout classes. This change is completely backward compatible.

Viewing all 293396 articles
Browse latest View live


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