🇳🇿New Zealand @quietone

When the dictionary was rebuilt just before the commit to 11.x, the word 'varchar' was removed from the dictionary. Curiously, yarn cspell trace varchar does not show the word is in any of the dictionaries Drupal uses.

I corrected spelling in the CR and other minor tweaks. Updating credit.

Thanks for working on this.

Just one more thing, the changes here need to be wrapped at 80 characters to meet the Drupal coding standards, https://www.drupal.org/docs/develop/standards/php/php-coding-standards#line-length.

Thanks for working on this. I left some comments in the MR.

For those that want this to change, can you add suggested wording to the issue summary so it can be evaluated? Showing before and after text would help.

@tolstoydotcom, I think this is a duplicate of #1765576: Redesign Permissions Page → . Can you confirm?

Changes are made on on 11.x (our main development branch) first, and are then back ported as needed according to the Core change policies → .

@kul.pratap, Thanks for asking! The suggested changes to phpcs.xml.dist should exclude the files that have just started to cause violations from being checked by phpcs. Without those being checked that will bet this back on track to where only the feedback from larowlan and myself need to be resolved.

The files that have just started to cause the violations are going to be fixed in the parent issue, along with enabling the sniff on all of core. I've already set that up and postponed that on this issue.

I hope that all make sense.

Created MR with what should be the remaining fixes.

And postponing on the last child.

Due to recent commits of coding standard fixes, there are too many changes to fix and enable this sniff in 📌 Fix remaining missing @var annotation that do not have a default value RTBC . So, opening this up again to do the final enable and fixes.

@kul.pratap, thanks. I just added another change to exclude files in 'Plugin' directories. That should help here.

Updating title for the new scope.

I'll work on an issue for the changes in the 'Plugin' directories.

@kul.pratap, Welcome to Drupal! Thanks for working on this. I made a few comments in the MR. Also, This is failing the pre commit checks. It is good practice to Run core development checks → locally before submitting a change.

There have been recent commits that are causing more errors. I don't think the sniff can be enabled here. This will have to go back to doing a subset of files. I'll look into that now.

linting checks have passed to setting this to review.

Committed 10154d1 and pushed to 11.x.

Thanks!

@seumas.gagne, The Drupal Core issue queue is not the ideal place for support requests. For migration, you will get better responses from the migration community in the #migration channel of Drupal Slack → . There are other support options listed on our support page → (Community > Support at the top of Drupal.org). You may get better replies in one of those places.

Committed and push to 11.x

Thanks!

Aside from reading the MR I confirmed all the alters were fixed by checking how many there are on HEAD

$ git grep -A2 'Implements hook' | grep function.*alter | wc -l
52

With the number with 'void'

$ git grep -A2 'Implements hook' | grep function.*alter | grep void | wc -l
52

Thanks for improving the docs!

Committed to 11.x and cherry-picked to 11.1.x

I changed the policy the make it clear that CSS changes are to be considered. I did not attempt to define what a significant CSS change would be or to provide examples. I think it is OK to be flexible and allow those working on a issue to decide.

I am going to close this. The change is only a few words and simple.

Thanks

Make is clear that CSS changes are included.

Back to NW for the above comment.

No conflicts with the rebase, restoring RTBC

Changes are made on on 11.x (our main development branch) first, and are then back ported as needed according to the Core change policies → .

Changes are made on on 11.x (our main development branch) first, and are then back ported as needed according to the Core change policies → .

Changes are made on on 11.x (our main development branch) first, and are then back ported as needed according to the Core change policies → .

The is a duplicate of an issue that got moved to the Project project.

There is a test, so removing tag. The MR also has out of scope changes, but that is minor to deciding what the solution should be here.

@mikelutz, thanks. I was mistaken.

Committed to 11.x and cherry-picked to 11.1.x.

Thanks!

In display view mode the dropdown buttons overlap

Changes are made on on 11.x (our main development branch) first, and are then back ported as needed according to the Core change policies → . Also restoring template to help keep track of decisions made here.

Applied two suggestions from alexpott, so let's have another review.

I forgot to update the IS. Also adding credit.

📌 Fix 'Drupal.Semantics.FunctionT.NotLiteralString' coding standard Active committed, and removed from the issue summary.

linting check passed so I am setting this to needs review.

One child completed.

One child completed.

Thank you to everyone who helped to complete this issue. The last child was recently committed. So, I am closing this as fixed.

Another one committed.

Linting passed, so this can be reviewed.

linting passed, try again.

I've made changes to fix the new fails.

Rebased, and linting checks have passed, restoring RTBC

Rebased, linting has passed, although other tests are still running.

Updated the IS.

What text do you want to add?

It has been 18 months since steps to reproduce this were asked for, but haven't been supplied. This was also reported on Drupal 10.1.0, which is no longer supported and there were many fixes added to Drupal 10.1.1, see #8.

Therefore, I closing this issue. If you are experiencing this problem on a supported version of Drupal reopen the issue, by setting the status to 'Active', and provide complete steps to reproduce the issue → starting from "Install Drupal core".

Thanks!

Thanks, I think that is an improvement. Others may have further ideas but I am OK with closing this issue.

I verified that this by searching for where the hook was removed. Skimming that changed showed that it really was removed.

$ git log -Shook_process_HOOK
commit 29c09effc38271277b7cad1114be5f32eed5f9f5
Author: Nathaniel Catchpole <catch@35733.no-reply.drupal.org>
Date:   Sat Jul 27 15:26:33 2013 +0100

    Issue #1843650 by Mark Carver, jenlampton, Cottser: Remove the process layer (hook_process() and hook_process_HOOK).

Committed to 11.x and cherry-picked to 11.1.x

Thanks!

Committed to 11.x and cherry-picked to 11.1.x

Thanks!

Committed and pushed to 11.x and cherry-picked to 11.1.x only, here were conflicts in the phpstan baseline for other branches.

Thanks for improving the documentation in core!

Committed to 11.x and cherry-picked to 11.1.x 10.5.x 10.4.x 11.0.x 10.3.x

Thanks!

There should be return types on the new methods.

I think there should be return types on the new methods in the stub file.

@mondrake, thanks for keeping this up to date.

Committed to 11.x and cherry-picked to 11.1.x

Thanks!

That equivalent_update_test_update_100201 returns TranslatableMarkup is unusual but it is part of the testing.

Committed to 11.x and cherry-picked to 11.1.x

Thanks

@pameeela, Yes, 'Get started' is much better for this step. Thanks for considering this minor issue.

I followed the steps in the issue summary to confirm the changes. At first I thought the return type was wrong for findRowById but then I took into account the assertEmtpy().

Committed to 11.x, cherry-pick to 11.1.x

Thanks

Changes are made on on 11.x (our main development branch) first, and are then back ported as needed according to the Core change policies → .

Changes are made on on 11.x (our main development branch) first, and are then back ported as needed according to the Core change policies → .

Add administer releases

Changing to fixed here because this was useful for coordinating the work on this topics and in the child issues.

Some of the documentation referred to her has been migrated from the book system. The link for the book given in #2 is now a 404.

I think this is now outdated.

Yes, and the documentation page has been updated. So I think this can be closed. Or, did I miss something?

Thanks for the suggestion. I updated the page with your suggestion.

@ressa, thanks for making that clear.

I have updated https://www.drupal.org/docs/updating-drupal/updating-modules-and-themes-... → to use just 'drush' in the commands.

s#vendor/bin/drush#vendor per decision made in https://www.drupal.org/project/documentation/issues/3405506 📌 Use drush in documentation pages Active

Thanks, I'm glad you found it easier to read. As for that spam, I only added formatting, that part about spam is already on the page. If that needs to be changed, I trust you know better than me what it should be.

That works for me. I think it is an improvement, and of course, it can easily be changed.

@avpaderno, thank you.

I have updated the IS.

And "Core Theme Candidate Requirements" could be preserved as a documentation for what is required for the next core theme. I read the 15 (+) year old issue ...

Where to 'preserve it'?

And what about the two 'resolution' warning?

warning Resolution field "ejs@3.1.10" is incompatible with requested version "nightwatch#ejs@3.1.8"
warning Resolution field "nightwatch#semver@7.5.4" is incompatible with requested version "nightwatch#semver@7.3.5"

The Systems requirements Guide → has a page for Browser requirements. →

@ nick hope → , I made some small changes to add the link you gave in your comment, so it is there while this is discussed more. Not ideal, but a start.

What do you suggest? How to provide more guidance but not repeat information already given in the DDEV docs?

Adding a bit more for finding the correct DDEV docs pages for windows.

I have fixed the link in comment #62.

@ressa, nice improvements on the Evaluator guide.

@volger, discussing those points is for the core issue queue. One existing issue I found is https://www.drupal.org/project/drupal/issues/3481555 📌 [Plan] Determine how to deprecate procedural hooks. Active .

There was not a bug here so there isn't anything to 'not fix'. I think 'works as designed' makes more sense.

xjm → credited quietone → .

There is an open issue about dedupe, https://github.com/yarnpkg/yarn/issues/7568. Someone solved that by deleting the lock file and then 'yarn install'.

Locally, that worked for the dedupe errors. Still to do is the resolution one.

I also meant to change this to 11.x. Even though this is a test issue, it helps with issue queue management if the version is 11.x.

Changes are made on on 11.x (our main development branch) first, and are then back ported as needed according to the Core change policies → .

Changes are made on on 11.x (our main development branch) first, and are then back ported as needed according to the Core change policies → .

Changes are made on on 11.x (our main development branch) first, and are then back ported as needed according to the Core change policies → .

In Drupal core we prefer that people add a comment stating they are working on an issue. See Assigning ownership of a Drupal core issue → for the details. Therefore, changing to 'unassigned'

Changes are made on on 11.x (our main development branch) first, and are then back ported as needed according to the Core change policies → .

Changes are made on on 11.x (our main development branch) first, and are then back ported as needed according to the Core change policies → .

Changes are made on on 11.x (our main development branch) first, and are then back ported as needed according to the Core change policies → .

Changes are made on on 11.x (our main development branch) first, and are then back ported as needed according to the Core change policies → .

This sounds familiar.

Yes, I found it, I think this was fixed in 🐛 Avoid loading all terms on the taxonomy overview form Needs work . That was committed to 10.2.x. And this is for Drupal 10.0, which is no longer receiving support. Can you upgrade to a supported version?

Changing to a support request.

Changes are made on on 11.x (our main development branch) first, and are then back ported as needed according to the Core change policies → .

Changes are made on on 11.x (our main development branch) first, and are then back ported as needed according to the Core change policies → .

Changes are made on on 11.x (our main development branch) first, and are then back ported as needed according to the Core change policies → .

Changes are made on on 11.x (our main development branch) first, and are then back ported as needed according to the Core change policies → .