Password strength and password match texts on user edit always use the default language.
This means that the strings have the wrong translation when editing a user in a language other than the default language.

The default language in the attached screenshot is English.
If the default language was Dutch, the Dutch translation would be used when editing a user in English.

The strings which are passed to the javascript layer are built in the user_form_process_password_confirm() in user.module.
Replacing for example 'confirmTitle' => t('Passwords match:') with 'confirmTitle' => t('Passwords match:')->render() solves the problem but it seems to me that this is not the proper solution.

Following from #2908391: Add a rule for expected format of @deprecated and @trigger_error() text we need to fix core to adhere to the two new coding standards.

This issue will fix the @trigger_error() function calls to adhere to standards.
Ideally wait for #3041983: Fix unused imports and update Coder to 8.3.4 so that testing the new sniff will be simpler, but we can use the new coder code by patching it via drupalci - see comment #28. The patch in #28 can be used now to start fixing the standards.

Step 1: Preparation

Open the file core/phpcs.xml.dist and add a line for the sniff of this ticket. The sniff name is in the issue title. Make sure your patch will include the addition of this line.

Step 2: Install & configure PHPCS

Install PHP CodeSniffer and the ruleset from the Coder module:

$ composer install
$ ./vendor/bin/phpcs --config-set installed_paths ../../drupal/coder/coder_sniffer

Once you have installed the phpcs package, you can list all the sniffs available to you like this:

$ ./vendor/bin/phpcs --standard=Drupal -e

This will give you a big list of sniffs, and the Drupal-based ones should be present.

Step 3: Prepare the phpcs.xml file

To speed up the testing you should make a copy of the file phpcs.xml.dist (in the core/ folder) and save it as phpcs.xml. This is the configuration file for PHP CodeSniffer. We only want this phpcs.xml file to specify the sniff we're interested in. So we need to remove all the rule items, and add only our own sniff's rule. Rule items look like this:

<rule ref="Drupal.Semantics.FunctionTriggerError"/>

Remove all of them, and add only the sniff from this issue title. This will make sure that our tests run quickly, and are not going to contain any output from unrelated sniffs.

Step 4: Run the test

Now you are ready to run the test! From within the core/ folder, run the following command to launch the test:

$ cd core/
$ ../vendor/bin/phpcs -p

This takes a couple of minutes. The -p flag shows the progress, so you have a bunch of nice dots to look at while it is running.

Step 5: Fix the failures

When the test is complete it will present you a list of all the files that contain violations of your sniff, and the line numbers where the violations occur.

I have users and deliveries, in a view I need to display a list of users, last delivery date and number of deliveries per user.
Adding aggregation to view works fine but max(field_delivery_date) displays only year.

User ID	Last/Next Delivery	Number of deliveries
26	2020	4
2224	2020	3
1195	2020	3

* field_delivery_date is of datetime_default type
* if I use max(created) view displays proper date (as it's timestamp and not actually a date)
* Database returns proper date (if I run a debug in [my_module]_views_pre_render $result->field_users_delivery_users_field_data__node__field_delivery_date_fi it returns a proper date)

Reason for this issue is in display handler is changed to Numeric for any grouped field (max, min, count, etc):
https://git.drupalcode.org/project/drupal/-/blob/8.9.x/core/modules/view...

Min/Max aggregations should be mindful of the field type they apply (as datetime actually can have min/max date).

Same issue applies to Drupal 7/9.

Problem/Motivation

HTML classes should be usually added in templates instead of preprocess functions.

Proposed resolution

Move the HTML classes from the preprocess function to the template. The classes should be added in a template textarea.html.twig file.

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

I have finally successful migrated my site from 8.9 to 9.0 after sacrificing legacy show stopper modules as follows:

1. Backup_migrate (this is a famous module - it should be fixed soon)
2. Business_Rules (this is a famous module - it should be fixed soon)
3. field_report (legacy module)
4. library manager (legacy module)
5. ng_lighbox (legacy module)
6. permission report (legacy module)
7. search_api_exclude (legacy module)
8. view_mode_selector (legacy module)

Now my homepage of my drupal 9.0 project site opens without further white screen errors. (mostly complaints about entity.manager)

But now i am getting a new bread of left-over errors as follows::
User error: Drupal\Core\Security\UntrustedCallbackException: Render #lazy_builder callbacks must be methods of a class that implements \Drupal\Core\Security\TrustedCallbackInterface or be an anonymous function. The callback was Drupal\devel\ToolbarHandler::lazyBuilder. See https://www.drupal.org/node/2966725 in D:\wamp64\www\workbench\workbench_d9_test1\core\lib\Drupal\Core\Security\DoTrustedCallbackTrait.php:96 Stack trace: #0 D:\wamp64\www\workbench\workbench_d9_test1\core\lib\Drupal\Core\Render\Renderer.php(781): Drupal\Core\Render\Renderer->doTrustedCallback(Array, Array, 'Render #lazy_bu...', 'exception', 'Drupal\\Core\\Ren...') #1 D:\wamp64\www\workbench\workbench_d9_test1\core\lib\Drupal\Core\Render\Renderer.php(355): Drupal\Core\Render\Renderer->doCallback('#lazy_builder', Array, Array) #2 D:\wamp64\www\workbench\workbench_d9_test1\core\lib\Drupal\Core\Render\Renderer.php(200): Drupal\Core\Render\Renderer->doRender(Array, true) #3 D:\wamp64\www\workbench\workbench_d9_test1\core\lib\Drupal\Core\Render\Renderer.php(156): Drupal\Core\Render\Renderer->render(Array, true) #4 D:\wamp64\www\workbench\workbench_d9_test1\core\lib\Drupal\Core\Render\Renderer.php(573): Drupal\Core\Render\Renderer->Drupal\Core\Render\{closure}() #5 D:\wamp64\www\workbench\workbench_d9_test1\core\lib\Drupal\Core\Render\Renderer.php(157): Drupal\Core\Render\Renderer->executeInRenderContext(Object(Drupal\Core\Render\RenderContext), Object(Closure)) #6 D:\wamp64\www\workbench\workbench_d9_test1\core\lib\Drupal\Core\Render\Renderer.php(171): Drupal\Core\Render\Renderer->renderPlain(Array) #7 D:\wamp64\www\workbench\workbench_d9_test1\core\modules\big_pipe\src\Render\BigPipe.php(693): Drupal\Core\Render\Renderer->renderPlaceholder('callback=Drupal...', Array) #8 D:\wamp64\www\workbench\workbench_d9_test1\core\modules\big_pipe\src\Render\BigPipe.php(547): Drupal\big_pipe\Render\BigPipe->renderPlaceholder('callback=Drupal...', Array) #9 D:\wamp64\www\workbench\workbench_d9_test1\core\modules\big_pipe\src\Render\BigPipe.php(305): Drupal\big_pipe\Render\BigPipe->sendPlaceholders(Array, Array, Object(Drupal\Core\Asset\AttachedAssets)) #10 D:\wamp64\www\workbench\workbench_d9_test1\core\modules\big_pipe\src\Render\BigPipeResponse.php(112): Drupal\big_pipe\Render\BigPipe->sendContent(Object(Drupal\big_pipe\Render\BigPipeResponse)) #11 D:\wamp64\www\workbench\workbench_d9_test1\vendor\symfony\http-foundation\Response.php(381): Drupal\big_pipe\Render\BigPipeResponse->sendContent() #12 D:\wamp64\www\workbench\workbench_d9_test1\index.php(20): Symfony\Component\HttpFoundation\Response->send() #13 {main} in Drupal\big_pipe\Render\BigPipe->sendPlaceholders() (line 554 of core\modules\big_pipe\src\Render\BigPipe.php).

And when i try to access a node, in node view, i get the following WSOD::

The website encountered an unexpected error. Please try again later.
Error: Call to undefined method Drupal\taxonomy\Entity\Term::urlInfo() in Drupal\shs\Plugin\Field\FieldFormatter\EntityReferenceShsFormatter->viewElements() (line 60 of modules\contrib\shs\src\Plugin\Field\FieldFormatter\EntityReferenceShsFormatter.php).

Hm. Perhaps I'm doing sth. wrong, but after upgrading a few sites to Drupal 8.8 I found that I cannot save newly translated nodes anymore. The error message is "Either the path '/node/[nid]' is invalid or you do not have access to it." where [nid] is of course the corresponding NID.

Steps to reproduce:

* Use sth. other than the administrator account. You should have the usual editor permissions to create nodes and create/update translations and translate any entity, of course. You should not have any url alias permissions.
* Create a new node in the original language (in my case: German)
* Save the node
* Edit the node again
* Click on translation, add translation (English)
* Try to save
=> Error.

I found that this error comes from "ValidPathConstraintValidator::validate". If I insert a return statement in the first line of that method, everything works as expected.

I don't have pathauto installed or sth. I *would* like to set/assign an automatic alias in a custom hook_node_presave, but the validation error seems to be trigged before this hook is even called. I checked pathauto and they are also using that hook to do their auto-path magic.

I don't understand the error message to be honest. Yes "/node/123" is of course not a valid alias, because it's reserved for the nodes. But I didn't assign anything. I don't even have permissions to assign any manual alias.

It used to work with 8.7 but not with 8.8.

Problem/Motivation

When an image is inserted to CKEditor field, it can't be edited under certain (unexpected) circumstances.

Basic steps to reproduce (common to all cases bellow)

• Completely clear, minimal installation of Drupal 8.8.5 (from zip file).
• Install CKEditor module.
• Go to admin/config/content/formats and create new format.
  • Name: rich text.
  • Editor: CKEditor.
  • Don't enable any filter (yet).
• Go to admin/structure/types and create simple node type "page" with default body field.
• Everything bellow is done under administrator account.

Scenario #1; link-image cannot be resized after saving.

• Go to node/add/page.
• Edit text, add an image.
• Select the image, click on link icon and set the link to same address as the image.
• Observe black square in right bottom corner which can modify the image size.
• Click on preview button and then click on back link.
• Observe black square in right bottom corner is missing (in both selected and unselected state) and cannot change the image size.
• Expected: image can be resized.
• Save the node and edit it.
• Observe black square in right bottom corner is missing (in both selected and unselected state) and cannot change the image size.
• Expected: image can be resized.

Scenario #2; image cannot be modifed after saving with Align images filter.

• Change rich text format: enable Align images filter.
• Go to node/add/page.
• Edit text, add an image.
• Observe black square in right bottom corner which can modify the image size.
• Click on the image with rmb and observe "Image properties" option is available in context menu and allows to change image properties (like URL).
• Double-click on the image and observe popup which allows to change image properties.
• Select the image, click on image icon and observe popup which allows to change image properties.
• Click on preview button and then click on back link.
• Observe black square is missing. When image is selected, 8 white squares appear instead, which still allows to resize the image.
• Click on the image with rmb and observe "Image properties" option is missing in context menu.
• Expected: "Image properties" option is still available.
• Double-click the image and observe that nothing happens.
• Expected: popup which allows to change image properties.
• Select the image, click on image icon and observe popup with empty image properties.
• Expected: popup with selected image properties.

Notes; my environment:

• PHP 7.2, Apache.
• Mariadb 10.0.
• Docker on Ubuntu 18.04 64 bit
• Firefox 75.0 64 bit

Proposed resolution

• Image should be resizable (at least when selected) regardless on Align images filter and whether node was saved or previewed.
• Image resize widget should be visually consistent and not change after saving/preview.
• Image should be editable (through context menu, double-click and image icon) regardless on Align images filter and whether node was saved or previewed.

Workaround: edit HTML directly (not possible with my target audience).

Rationale

My target audience are people without much computer knowledge and I believe this group of people is big enough not to be overlooked. These kind of people need reliable, consistent, stable gui and system behaviour, otherwise they'll get scared and stop using the web.

Remaining tasks

I apologize, but I don't have proposed implementation, because my technical knowledge of this part of Drupal are poor and close to zero. That means the cause of the problem must yet to be discovered, then a solution can be proposed.

User interface changes

IMHO none needed.

API changes

Probably none needed.

Data model changes

Probably none needed.

Release notes snippet

None.

Original report by Inaetaru

See above.

The MigrateExecutable class catches exceptions and turns then into messages for the migration.

But in doing so, it loses information, as it only takes the exception message and not the place where it happened.

Sometimes that's enough, if the exception message is quite specific. But often it's not, as you've no idea where something like an 'Undefined offset' error can have happened.

For example, when running migration tests, I got this output from PHPUnit, which is pretty unhelpful:

1) Drupal\Tests\commerce_migrate_ubercart\Kernel\Migrate\d6\ProfileBillingTest::testProfileBilling
Migration failed with source plugin exception: Undefined offset: 0
Failed asserting that false is true.

/Users/joachim/Sites/drupal-8-commerce/core/tests/Drupal/KernelTests/AssertLegacyTrait.php:23
/Users/joachim/Sites/drupal-8-commerce/core/modules/migrate/tests/src/Kernel/MigrateTestBase.php:195
/Users/joachim/Sites/drupal-8-commerce/core/modules/migrate/src/MigrateExecutable.php:275
/Users/joachim/Sites/drupal-8-commerce/core/modules/migrate/tests/src/Kernel/MigrateTestBase.php:169
/Users/joachim/Sites/drupal-8-commerce/core/modules/migrate/tests/src/Kernel/MigrateTestBase.php:183
/Users/joachim/Sites/drupal-8-commerce/core/modules/migrate/tests/src/Kernel/MigrateTestBase.php:184

I have emails in a field and i want to display them with Views, those emails will be used for skype Entreprise contact :

So i use the REWRITE RESULTS to add the tag :

And i get this :

Skype
The problem is that the link genrated is :

http://www.website.com/username@website.com

And i want the link to be :

sip:username@website.com

How can i do that ?

Problem/Motivation

It is not currently possible to use the views 'Combined fields filter' to search the 'Summary' value of a given long text field. When you add the long text field, the filter runs on the full field value but not on the summary value.

Steps to reproduce:

1. Install Drupal
2. Create a basic page node with a summary value 'xyz' that does not appear in the body field value
3. Create a view of basic pages with the title and body fields
4. Add a combined fields filter that includes the field with a summary
5. Search for 'xyz'
6. The node does not appear because the filter does not include the summary value

Proposed resolution

Add support for searching the summary value of a long text field.

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Original post
----

This issue was reported for drupal 7 long time ago:
https://www.drupal.org/project/views/issues/2934230
I am trying to use the Combined Fields Filter to filter based on text contained within a body field SUMMARY (combined with other fields, of course), but no matter what I do, the filter only returns results if I enter text contained within the body field VALUE. I've tried many things, such as rewriting the output of the body field as summary text or choosing field formatters that display the summary when present, but nothing works. I can get the view to display the body field summary just fine in the results, but I cannot filter the view on it. I can add a second exposed filter, to filter on body:summary, and that works just fine, but I cannot use Combined Fields Filter to do so, as it ignores any settings I have configured on my body field to display the summary.

Problem/Motivation

At present we don't have a generic entity API for determining revision support for operations such as:

• view
• delete
• revert
• edit

Node module defines the following permissions:

• delete all revisions
• revert all revisions
• view all revisions

But these are silver-bullet permissions, they don't allow granular access (per node-type, per entity etc).

The test entities in core don't do anything with revision (their routing has access: TRUE)

These entities don't have any UI for viewing/reverting/deleting revisions:

• media
• block content
• taxonomy
• menu link content

This is now starting to be a hard blocker for further generic improvements in core including:

• #2350939: [PP-2] Implement a generic revision UI
• #2795279: [PP-4] [META] Revisions support
• #2925532: Provide bulk action to delete all old revisions of an entity

Proposed resolution

Add new operations to the existing ::access signature such as

• delete revision
• update revision
• view revision

Remaining tasks

• Change deprecation to target removal 10.x instead of 9.x.

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

When adding a text field with multiple values, the text field will overflow over its designated area on narrow screens (the minimum width this happens is 780px).

Proposed resolution

Port the solution from Claro, and change .form-element to .form-text

/**
 * Target every .form-element input that parent is a form-item of a table cell.
 * This ignores the filter format select of the textarea editor.
 */

td > .form-item > .form-element,
td > .ajax-new-content > .form-item > .form-element {
  width: 100%;
}

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Admin area where users are able to make menu edit changes to menu links e.g. /admin/structure/menu/manage/main seem to break core functionality when appending the forward slash to node references. The following steps will recreate the issue.

Steps to recreate:
1. Visit admin/config/search/path
2. Click on the ‘edit’ operation, assuming there are existing menu links created.
3. Append the 'System path' field value with the forward slash character ’/‘. e.g. /node/1 will become /node/1/
4. Save the changes.
5. Visit any page that contains the main menu and you’ll notice the url alias no longer working. The link will now reference the node path with the ‘/‘ prepended.

Note: Please be sure to disable all all caches, and will need to re-save #3(no edits) in order for the '/' to be stripped, as the '/' is stored in the database.

Problem/Motivation

drupal_get_path() allows you to find the location of a module via the module name - this accounts for the different possible locations where a module could be installed ( contrib/, sites/SITENAME/modules/contrib etc.)

However, there are multiple uses on core where it's not necessary, because the call is inside the module being referred to.

In these cases, just __DIR__ returns the same thing (or sometimes __DIR__ . '../' if the call is in a subdirectory of the module) without having to go through all the Drupal logic.

When we eventually deprecate drupal_get_path(), this will reduce the number of replacements that need to happen. It should also make it clearer what use-cases the replacement actually needs to solve.

An obvious example is this one in statistics.module:

$settings = ['data' => ['nid' => $node->id()], 'url' => \Drupal::request()->getBasePath() . '/' . drupal_get_path('module', 'statistics') . '/statistics.php'];

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Doing a testing of migrating a D7 site to D8 using migrate_drupal_ui, the migration worked well with one unusual exception - the image fields were not migrated.

The table currently only shows books that are published in the list.
Ideally, I (and I'm sure a few others) would like this to show both published and unpublished books.

HI,

I just noticed something while building a view and either I misinterpret what's happening or it's some kind of a bug. I searched for any relevant issues but couldn't really find anything.

When you have both an exposed filter and a contextual filter in a view, they'll combine by default. Example: an /events overview where you can filter on categories: /events/webinar. Within a category it's possible to filter on a country: /events/webinar?country=US.

However, when you turn on "Exposed form in block", this functionality stops working and you can only either filter on a contextual argument or on an exposed filter.

Problem/Motivation

While working on #2976147: Create a sales report supporting daily, weekly, monthly, and yearly breakdowns., my tests failed due to configuration schema validation.

Schema errors for views.view.sales_report with the following errors: views.view.sales_report:display.default.display_options.fields.report_id.set_precision missing schema

The report_id is the entity identifier base field. The View has aggregation enabled, and the report_id is set to COUNT.

In Views, the handler is swapped to numeric as an override when the display is built. This is causing a SchemaIncompleteException exception to be thrown.

This following code is what changes the handler and causes the schema error

\Drupal\views\Plugin\views\display\DisplayPluginBase::getHandlers

        // If aggregation is on, the group type might override the actual
        // handler that is in use. This piece of code checks that and,
        // if necessary, sets the override handler.
        $override = NULL;
        if ($this->useGroupBy() && !empty($info['group_type'])) {
          if (empty($this->view->query)) {
            $this->view->initQuery();
          }
          $aggregate = $this->view->query->getAggregationInfo();
          if (!empty($aggregate[$info['group_type']]['handler'][$type])) {
            $override = $aggregate[$info['group_type']]['handler'][$type];
          }
        }

Proposed resolution

No idea.

Remaining tasks

• Write test which aggregates an entity ID
• ???

User interface changes

API changes

Data model changes

Problem/Motivation

This is a follow up to #2925899: MigrateUpgradeImportBatch does not use source_private_file_path & source_base_path correctly, making it impossible to have public & private files in separate locations.
In that issue benjifisher stated,

The current form suggests (at least to me) that the files will be directly under bar/, when they are actually under bar/sites/default/files/.

Let's review the help text and make sure it is clear to everyone where the files need to be. Use the description in the makeFiles method from the patch in 2925899-Comment#39 for inspiration.

For reference here are the current descriptions:
Public files
To import public files from your current Drupal site, enter a local file directory containing your site (e.g. /var/www/docroot), or your site address (for example http://example.com).
Private files
To import private files from your current Drupal site, enter a local file directory containing your site (e.g. /var/www/docroot).

Proposed resolution

TBD

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Punctuation is cool, we should use it and improve legibility of interfaces.

Before

After

Affected

• Taxonomy select
• Menu parent select
• Book outline select