Provide a hook function to alter the skip fields in the hasTranslationChanges function in ColntentEntityBase.php

July 6, 2020, 1:11 am

≫ Next: Remove uses of t() in setLabel() and setDescription() calls

≪ Previous: "composer install --no-dev" presents errors if drupal/core-dev package is a dev dependency

$

0

0

Problem/Motivation

When using the multi-language website with the encrypted data field, we always get TRUE in hasTranslationChanges() even if we didn't modify the translation. The reason is the data stored in DB is [ENCRYPTED] instead of the real value. Which means we will always get the RevisionTranslatedAffected on all the languages when we update any one of the translation.

Proposed resolution

Provide the hook method to alter the skip fields that we can add our own skip fields when we run hasTranslationChanges()

---

Remove uses of t() in setLabel() and setDescription() calls

June 19, 2020, 1:47 am

≫ Next: Un-inline SVGs in pcss.css files, add build tool to inline them when compiled

≪ Previous: Provide a hook function to alter the skip fields in the hasTranslationChanges function in ColntentEntityBase.php

$

0

0

Problem/Motivation

There is no need to use t() in tests, unless we're testing translations, however in core we do not follow this consistently, which does not set a good example for new contributions.

In #3133726: [meta] Remove usage of t() in tests not testing translation we identified there are severals of calls to t() in calls to setLabel() and setDescription() and that removing all these in one go seems to be a suitable way of attacking this problem.

Proposed resolution

Identify and remove all calls to t() wrapped in calls to setLabel() and setDescription(), except those used by translation-related code (if any).

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Un-inline SVGs in pcss.css files, add build tool to inline them when compiled

October 2, 2019, 8:00 am

≫ Next: \Drupal\Core\Access\CsrfTokenGenerator::validate() - ensure $token is a string before calling hash_equals()

≪ Previous: Remove uses of t() in setLabel() and setDescription() calls

$

0

0

Problem/Motivation

Originally from
From #3079738-49: Add Claro administration theme to core:

16. +++ b/core/themes/claro/css/dist/components/action-link.css
    @@ -0,0 +1,276 @@
    +  background-image: url("data:image/svg+xml,%3Csvg xmlns='http://www.w3.org/2000/svg' width='14px' height='16px' viewBox='0 0 14 16'%3E%3Cpath fill='%23545560' d='M13.9,2.9c-0.1-0.4-0.2-0.6-0.2-0.6c-0.1-0.4-0.4-0.4-0.8-0.5l-2.3-0.3c-0.3,0-0.3,0-0.4-0.3 C9.8,0.5,9.7,0,9.3,0H4.7C4.3,0,4.2,0.5,3.8,1.3C3.7,1.5,3.7,1.5,3.4,1.6L1.1,1.9C0.7,1.9,0.4,2,0.3,2.3c0,0-0.1,0.2-0.2,0.5 C0,3.4-0.1,3.3,0.4,3.3h13.2C14.1,3.3,14,3.4,13.9,2.9z M12.4,4.7H1.6c-0.7,0-0.8,0.1-0.7,0.6l0.8,10.1C1.8,15.9,1.8,16,2.5,16h9.1 c0.6,0,0.7-0.1,0.8-0.6l0.8-10.1C13.2,4.8,13.1,4.7,12.4,4.7z'/%3E%3C/svg%3E");
    

    🤓 Have these SVGs been optimized?

    🤔🤔🤔 More importantly: why are these inlined already? (These were done in #3036732: Action link component.) I'm sure that the build tools (#3060153: Use PostCSS in core, initially only for Claro) allow this to happen at build time? That'd make it much easier to inspect the SVGs, to apply SVG optimization tools, to encourage reuse, etc. It also allows us to decide whether we truly want to inline these as data: URIs, or whether it makes more sense to let them be loaded by HTTP requests. This particular CSS file is 24 KB ungzipped and unminified. That's … a lot. Most of that is due to these inlined SVG files (this CSS file is the single largest CSS file in Claro).

    In other words: for developer ergonomics and for web performance optimization reasons I think we should consider changing this.

    In #3083657: Devise strategy to address several SVG loading+usage issues, it was agreed this was a sound approach.

Proposed resolution

Evaluate a build tools that will inline the SVGs from the .pcss.css files when compiled to their .css counterparts.

For each inlined svg either:

1. Un-inline
2. Or document why it's inlined

For all of them, regardless of the above choice: optimize them. Using for example https://imageoptim.com.

Remaining tasks

User interface changes

None.

API changes

None.

Data model changes

None.

Release notes snippet

N/A

\Drupal\Core\Access\CsrfTokenGenerator::validate() - ensure $token is a string before calling hash_equals()

July 4, 2020, 8:37 am

≫ Next: Views table settings exposes "Details" field even when empty

≪ Previous: Un-inline SVGs in pcss.css files, add build tool to inline them when compiled

$

0

0

Problem/Motivation

In \Drupal\Core\Access\CsrfTokenGenerator::validate() it's possible that $token is something other than a string. In PHP 8 this causes a warning.

The only times $token is something other than a string is in our test coverage - \Drupal\Tests\Core\Access\CsrfTokenGeneratorTest. On PHP < 8 this method will return FALSE in these case because that's the behaviour of hash_equals(). In PHP 8 hash_equals only accepts strings therefore we need to check the type of $token and return early. See https://3v4l.org/KFNqm

Not that once we change \Drupal\Core\Access\CsrfTokenGenerator::validate() to use scalar typehints this "problem" goes away.

Proposed resolution

Ensure that $token is a string.

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Views table settings exposes "Details" field even when empty

June 8, 2020, 7:17 am

≫ Next: Drupal should not use full CSS required marker in forms according to WCAG 2.0

≪ Previous: \Drupal\Core\Access\CsrfTokenGenerator::validate() - ensure $token is a string before calling hash_equals()

$

0

0

After recent update from 8.8 to 8.9 a field now shows up when ever a a grouping is used. it matters not what field is exposed. It is a collapsed field directly above the table and says "details" It is in a collapsed field/element.

I narrowed it down to the field in TABLE:SETTINGS at the bottom called "Table Details", there is nothing in it but there is also no way to disable it.

Step to reproduce:

• Take a view with table display (say the content view)
• Go to the table settings
• set Grouping field Nr.1 to 'content type'
• save settings
• check the preview and see that this now shows the 'detail' as shown in the screenshot

Drupal should not use full CSS required marker in forms according to WCAG 2.0

November 7, 2017, 9:22 am

≫ Next: Regression: not possible to delete source strings in Drupal 8 interface translation

≪ Previous: Views table settings exposes "Details" field even when empty

$

0

0

Follow-up to #2152217: Remove theme_form_required_marker() from the theme system - use CSS instead

Problem/Motivation

3 years ago, in #2152217: Remove theme_form_required_marker() from the theme system - use CSS instead, the community decided to remove the star (*) used to indicate that a form field is required from the source code to add it from the CSS. Initially, the issue was just about converting the theme function to a Twig template but changed quickly. The purpose of this change was to simplify theming and improve accessibility. The thing is that, according to WCAG, this is not as accessible as we thought.

References:

• WCAG 2.0 - 1.1.1 Non-text Content
• F3: Failure of Success Criterion 1.1.1 due to using CSS to include images that convey important information
• WCAG 2.0 - 1.3.1 Info and Relationships
• F87: Failure of Success Criterion 1.3.1 due to inserting non-decorative content by using :before and :after pseudo-elements and the 'content' property in CSS
• Accessiweb 2.2 - Criterion 10.2 - [Bronze] On each Web page, is visible content still available when style sheets or images are disabled? (Accessiweb is the French accessibility standard)

Screenshots

	With CSS	Without CSS
Before patch
After patch

Proposed resolution

Bring back markup but use the hidden CSS class to avoid changing the current look of the existing sites and aria-hidden to avoid screen readers to vocalize the content of the span as it's already covered by the aria-required and HTML5 required attributes.

Remaining tasks

Contributor tasks needed

Task	Novice task?	Contributor instructions	Complete?
Create a patch		Instructions	Done #19
Update the issue summary		Instructions	Done
Add automated tests		Instructions
Draft a change record for the API changes		Instructions
Update the patch to incorporate feedback from reviews (include an interdiff)		Instructions	Done #19
Manually test the patch	Novice	Instructions	Done #19
Add steps to reproduce the issue	Novice	Instructions
Embed before and after screenshots in the issue summary	Novice	Instructions	Done
Review patch to ensure that it fixes the issue, stays within scope, is properly documented, and follows coding standards		Instructions

User interface changes

Visually nothing as long as you have your CSS enabled.
A new "(required)" mention should be show on form labels for people that does not have their CSS enabled.

API changes

None.

Data model changes

None.

Regression: not possible to delete source strings in Drupal 8 interface translation

June 10, 2015, 8:33 am

≫ Next: Make Drupal 9 installable on PHP8

≪ Previous: Drupal should not use full CSS required marker in forms according to WCAG 2.0

$

0

0

Hello, In D7 we had the option to edit and delete text strings in theme_locale_languages_overview_form

Now, in D8 we have the option to edit in-line, but where is the option to delete? (in TranslateEditForm)

Screenshot after patch in #25 (screenshot from #28)

Any alternative to delete strings?

Thanks

Make Drupal 9 installable on PHP8

July 2, 2020, 6:35 pm

≫ Next: Views exposed filters take too much space

≪ Previous: Regression: not possible to delete source strings in Drupal 8 interface translation

$

0

0

Problem/Motivation

This task will try to get Drupal 9 installable on PHP8.0 alpha so we can work out issues to address.

Proposed resolution

Make Drupal 9 testable on PHP 8 and PHP 7 at the same time.

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

---

Views exposed filters take too much space

March 26, 2020, 5:34 am

≫ Next: Improve documentation on the working of Url::fromUserInput

≪ Previous: Make Drupal 9 installable on PHP8

$

0

0

Hi, the exposed filters on views take a lot (too much) space. Let's see an example of a Commerce orders page with some extra exposed filters: the page is filled with toolbar, title, tabs, buttons, filters... and the orders are above the fold:

Now I'm creating a Claro child theme to add some custom CSS/JS in order to minimize the waste of space and collapse the filter, but a out of the box solution should be provided.

Thanks for the attention.

Improve documentation on the working of Url::fromUserInput

June 11, 2019, 2:42 am

≫ Next: Harden SubProcess process plugin

≪ Previous: Views exposed filters take too much space

$

0

0

Problem/Motivation

Currently it's not clear whether Url::fromUserInput expect a URL relative to the Drupal root, or relative to the host.

In 99% of the cases this is the same, but when installing Drupal in a subdirectory this is not the same.

If Drupal is installed in example.com/subdirectory one might understand that it's possible to pass the url relative to the host to Url::fromUserInput (/subdirectory/whatever-route). This however should never happen, as it results in incorrectly parsed Url strings. (subdirectory/subdirectory/whatever-route)

The fact that this is not documented, and the fact that the testbot in some cases doesn't actually fail, leads to problems: see the related issues.

Proposed resolution

As said, there is no way of stripping out the subdirectory within current API. This is because the 'fromUserInput' can come from various sources which might or might not include the subdirectory. When that subdirectory is, say, 'admin', and the drupal relative url is also 'admin', there is no way to know what to strip away.

Proposed solution is to at least make sure that this is properly documented and that there is a clear pattern/helper of how to strip away the subdirectory if necessary.

Remaining tasks

1. Update the documentation comment in Url::fromUserInput.
2. Find where this might be documented on Drupal.org
3. Update/comment all issues that might be related to this project.
4. Create/find issue to create a helper method to strip away subdirectories when needed
5. Create/link issue about the not-failing tests when there is a subdirectory

Harden SubProcess process plugin

April 8, 2020, 8:54 am

≫ Next: Claro + layout builder messages display additional icon in top left corner

≪ Previous: Improve documentation on the working of Url::fromUserInput

$

0

0

Problem/Motivation

#3061571: If no Drupal 8 equivalent filter is found during migration, drop transformation-only filters, so that body fields show up significantly improved migrations of text formats, which can be a big stumbling block when getting a migration off the ground.

I've been using the 8.8.x patch for months, been working fine.

Just updated to 9.0.x, and suddenly this is failing. Why?!

@heddn pointed out over at #3061571-19: If no Drupal 8 equivalent filter is found during migration, drop transformation-only filters, so that body fields show up:

+++ b/core/modules/migrate/src/Plugin/migrate/process/SubProcess.php
@@ -207,6 +207,9 @@ public function transform($value, MigrateExecutableInterface $migrate_executable
+        if ($key === NULL) {
+          continue;
+        }

This could use some docs on why this is needed. or split it out into another issue. I don't see any reason for its existence previously mentioned in this issue.

To which I responded over at #3061571-21: If no Drupal 8 equivalent filter is found during migration, drop transformation-only filters, so that body fields show up:

RE: SubProcess: I'd swear I needed to do this for stuff to work … but now it's been a month since I wrote that code and I stupidly didn't write down the "why" back then 🙈

So … let's remove it and let's see if it passes!

Well, turns out that is the root cause. Because this is what happens:

That error reads:

The "" plugin does not exist. Valid plugin IDs for Drupal\filter\FilterPluginManager are: editor_file_reference, filter_html_image_secure, filter_url, filter_null, filter_html, filter_autop, filter_align, filter_caption, filter_htmlcorrector, filter_html_escape, markdown, media_embed, TypogrifyFilter (/Users/wim.leers/Work/d8/core/lib/Drupal/Component/Plugin/Discovery/DiscoveryTrait.php:53)

… and it causes a text format to not get migrated at all! Which makes all content using that text format impossible to migrate too!

(My personal site uses the image_resize_filter module on Drupal 7, and this is what happens when I try to migrate it.)

Proposed resolution

Harden SubProcess.

Remaining tasks

• Patch
• Tests
• Review

User interface changes

None.

API changes

TBD

Data model changes

None.

Claro + layout builder messages display additional icon in top left corner

May 27, 2020, 6:11 am

≫ Next: Entity reference fields can easily become stale (b/c of DataReferenceBase)

≪ Previous: Harden SubProcess process plugin

$

0

0

Steps to reproduce

1. Install Drupal 8.9
2. Create a block type or two
3. Enable layout builder module
4. Enable Claro theme
5. On a CT display, enable "Use Layout Builder" and click "Edit layout"
6. Add a block in a region

Current result

• Messages display an additional icon in the top left corner

Expected result

• Messages should not display any additional icon in the top left corner

 

Entity reference fields can easily become stale (b/c of DataReferenceBase)

June 24, 2020, 1:55 am

≫ Next: Remove blocks that are not useful within Layout Builder

≪ Previous: Claro + layout builder messages display additional icon in top left corner

$

0

0

Entity reference fields internally use \Drupal\Core\Entity\Plugin\DataType\EntityReference, which extends \Drupal\Core\TypedData\DataReferenceBase. However, neither DataReferenceBase nor EntityReference have a way to clear its $target property. This leads to entity reference fields becoming stale as soon as the target entity changes.

See the following scenario:

$node_storage = $entity_type_manager->getStorage('node');
$node_type_storage = $entity_type_manager->getStorage('node_type');

$node = $node_storage->load(1);
echo $node->type->entity->label(); // Hello world!

$node_type = $node_type_storage->load('hello_world');
$node_type->name = 'Hello moon!";
$node_type_storage->save($node_type);

// Reference's "target" property is stale.
echo $node->type->entity->label(); // Hello world!

// Storage thinks node is unchanged so returns node with stale reference.
$node = $node_storage->load(1);
echo $node->type->entity->label(); // Hello world!

// Storage returns new copy of the node, so the reference target is unset and needs to be loaded.
$node = $node_storage->loadUnchanged(1);
echo $node->type->entity->label(); // Hello moon!

I was wondering if we should replace the property with a static cache that uses the target entity's cache tags.

Remove blocks that are not useful within Layout Builder

March 14, 2019, 10:47 am

≫ Next: Properties of Form FormElement are missing

≪ Previous: Entity reference fields can easily become stale (b/c of DataReferenceBase)

$

0

0

Problem/Motivation

Similar to #2977587: Improve block listing in Layout Builder by hiding uncommon block plugins this issue is intended to simplify the block listing

Proposed resolution

Remove some of the core blocks that do not serve any purpose within Layout Builder

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Properties of Form FormElement are missing

July 6, 2020, 3:07 am

≫ Next: Unused local variables from EntityLinkTest file.

≪ Previous: Remove blocks that are not useful within Layout Builder

$

0

0

API page: https://api.drupal.org/api/drupal/core%21lib%21Drupal%21Core%21Render%21...

I think Properties of Form FormElement are missing. For example: #validate, #submit, #tree, #method etc.

---

Unused local variables from EntityLinkTest file.

July 6, 2020, 3:21 am

≫ Next: Bring back overriding breadcrumb with contextual filter

≪ Previous: Properties of Form FormElement are missing

$

0

0

In core/tests/Drupal/Tests/Core/Entity/EntityLinkTest.php file test method testToLink() found unused variable.

Removing the following variable.

$expected = '<a href="/test_entity_type/test_entity_id">' . $expected_text . '</a>';

Bring back overriding breadcrumb with contextual filter

July 3, 2020, 5:52 am

≫ Next: Database primary keys can exceed maximum integer storeable (has actually occurred, in watchdog)

≪ Previous: Unused local variables from EntityLinkTest file.

$

0

0

In Drupal 7, it was possible to override breadcrumb by a contextual filter. That feature is missing in Drupal 8. Maybe in Drupal 9 too, but I am yet to try Drupal 9.

Not sure any resolution happened already on it. I did not get any result so far.

It would be good if we get that feature back.

Database primary keys can exceed maximum integer storeable (has actually occurred, in watchdog)

September 13, 2019, 6:12 am

≫ Next: Add a 'void' return typehint to custom assert* methods

≪ Previous: Bring back overriding breadcrumb with contextual filter

$

0

0

Original report

Watchdog wid reaches maximum integer storeable

To reproduce: have a site which generates a large number of Notices and Warnings (eg. uninitialised variables, unset array keys) per page load, and which receives a very large amount of traffic.

Expected behaviour: dblog automatically limits the number of log messages to the specified value, site continues to function without issue.

Actual behaviour: because dblog never resets the wid auto_increment value, the wid eventually reaches 2147483648. At this point the site suffers a White Screen of Death; all requests fail with a 500 code but no errors are logged in the server logs (as is usual with such errors) and altering error logging does not produce any on-screen errors. (Probably because the attempt to log the DB exception raised fails in its own right.)

Detection of issue: the only ways to find out what is happening are a) to know this is a possible issue and check the current value of the auto_increment, or b) to use a debugger to step through the code line-by-line until a notice is generated.

Possible fixes or remediation:

1. Have dblog output the database error to the server logs, to screen, or somewhere accessible to developers.

2. Have dblog be aware of the maximum value an integer can take in the database used, and refrain from attempting to add any more entries once the wid gets close to that maximum.

3. Have dblog periodically reset all extant wids to start at 1, and reset the auto_increment.

Issue was observed in Drupal v7.67, but definitely affects all v7 variants, and may well affect v8 as well.

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

May 20, 2020, 12:11 am

≫ Next: Using @requires extension_name in PHPUnit unit tests fails if extension is not present

≪ Previous: Database primary keys can exceed maximum integer storeable (has actually occurred, in watchdog)

$

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

Using @requires extension_name in PHPUnit unit tests fails if extension is not present

July 5, 2020, 5:52 am

≫ Next: Manual select contextual filter when adding block to layout

≪ Previous: Add a 'void' return typehint to custom assert* methods

$

0

0

Problem/Motivation

If you change * @requires extension yaml to * @requires extension nope in \Drupal\Tests\Component\Serialization\YamlPeclTest and run the test you'll see:

OK, but incomplete, skipped, or risky tests!
Tests: 40, Assertions: 0, Skipped: 7.

THE ERROR HANDLER HAS CHANGED!

Other deprecation notices (2)

  1x: The "Drupal\Tests\Listeners\DrupalListener" class implements "PHPUnit\Framework\TestListener" that is deprecated Use the `TestHook` interfaces instead.

  1x: The "Drupal\Tests\Listeners\DrupalListener" class uses "PHPUnit\Framework\TestListenerDefaultImplementation" that is deprecated The `TestListener` interface is deprecated.

Process finished with exit code 1

The problem is the test is marked as failed because THE ERROR HANDLER HAS CHANGED! is outputted from \Symfony\Bridge\PhpUnit\DeprecationErrorHandler::shutdown(). This happens when the error handler that's registered in \Drupal\Tests\Listeners\DeprecationListenerTrait::registerErrorHandler() is not removed.

Proposed resolution

Remaining tasks

User interface changes

None

API changes

None (hopefully)

Data model changes

None

Release notes snippet