🇳🇿New Zealand @quietone

In Drupal core 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 → . Thanks

If this problem was discovered on a version of Drupal that is not 11.x, add that information in the issue summary and leave the version at 11.x. In Drupal core 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 mentioned on the version → section of the list of issue fields documentation. Thanks.

In Drupal core 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 → . Thanks.

In Drupal core 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, Drupal 10 is in maintenance mode with a limited set of allow changes → . Thanks.

In Drupal core 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 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 → . Thanks

In Drupal core 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 → . Thanks.

@mykola dolynskyi, thanks for adding the related issues. Can you add them to the ' Related issues → ' section of the issue summary. That way they will appear on the right hand side of this issue as well as on the related issues. Thanks.

Tested this on 11.x today with the standard profile and was not able to reproduce the problem.

Are the contrib module or custom code installed?

Just updating the version.

@uroki, thanks for pointing out the Drush issue.

Since this has a Drush issue I am closing this issue.

In Drupal core 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 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 mentioned on the version → section of the list of issue fields documentation. Thanks.

In Drupal core 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 mentioned on the version → section of the list of issue fields documentation. Thanks.

In Drupal core 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 → . Thanks.

If this problem was discovered on a version of Drupal that is not 11.x, add that information in the issue summary and leave the version at 11.x. In Drupal core 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 mentioned on the version → section of the list of issue fields documentation. Thanks.

@fjgarlin, thanks for pulling this together.

I am all for a simple solution, which the proposed resolution is. And I prefer 'By" instead of "Authored-by".

Also, we seem to be “linking” (again?) the commit message with the credits, when these two things are (and should be) independent.

Where is this happening, on an issue?

Let's make this a meta and create child issues. Starting with one to deprecate route comment.new_comments_node_links.

quietone → created an issue.

I tested this on 11.x today with Umami and wasn't able to reproduce the problem. Perhaps this has been resolved sometime in the past 8 years.

Is this still a problem on a currently supported version of Drupal?

Since we need more information to move forward with this issue, I am keeping the status at Postponed (maintainer needs more info. If we don't receive additional information to help with the issue, it may be closed after three months.

Thanks!

There has been no discussion here for 8 years, perhaps suggesting this is no longer relevant? Is this something that requires documentation?

Since we need more information to move forward with this issue, I am keeping the status at Postponed (maintainer needs more info. If we don't receive additional information to help with the issue, it may be closed after three months.

Thanks!

quietone → created an issue.

quietone → created an issue.

REmoved some '@group legacy' because of the deprecation is in .deprecation-ignore.txt. That keeps this consistent with the way the source plugins are deprecated.

This looks fine to me.

Add the process plugins in migrate_drupal.

mondrake reported in Slack that testing is failing on HEAD for PostgreSQL and SQLite.

I git bisected with PostgreSQL and found that this issue caused the problem.

smustgrave → credited quietone → .

I removed the topic as suggested.

griffynh → credited quietone → .

Committed to 11.2.x and 11.x

Thanks!

Thanks!

Committed to 11.x and 11.2.x

@dww, thanks, I did miss that last night.

I changed it to @return string[].

s/array[]/straing[]

Another rebase. Conflict due to removed code in \Drupal\Core\Render\ElementInfoManager, the file doesn't have changes anymore. Therefor restoring RTBC.

I am not sure we should delete them and lose all the history. Can we archive them somewhere?

quietone → created an issue.

@aklump, thanks for helping to improve the standards. However, all changes to this page must be approved by the coding standards committee, as stated at the top of the page. Therefore, I am reverting the changes.

I have time so I will make an issue in the project for these suggested changes.

The proposal in #8 looks better. I have updated the 'how to' doc with that example as well as the issue summary. I think everything is done here.

Setting to RTBC for a check that the doc updates are correct.

Improve adding additional parameters to interface methods, https://www.drupal.org/project/drupal/issues/3531685 📌 Ignore specifc sniffs when adding additional parameters to interface methods Active

Fix link in issue summary

@borisson_, thank you.

@borisson_, thanks

This meeting did not happen.

quietone → created an issue.

Yes, Drupal 9 is no longer supported here. In Drupal core 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 → .
If you are no longer having this issue, please close this issue and if possible, leave a comment describing how you fixed it, as it may help others with the same issue.

Since we need to know if this is happening on a supported version of Drupal, I am setting the status to Postponed (maintainer needs more info. If we don't receive additional information to help with the issue, it may be closed after three months.

It has been 4 months since @cilefen asked for more information on this Drupal 8 Critical issue and there has been no response. Hopefully the problem has been resolved. Since Drupal 8 is no supported in the issue queue I am restoring the latest closed status of won't fix.

If you are experiencing this problem on a supported version of Drupal open a new issue.

If you are experiencing this problem on a unsupported version of Drupal try the various support options. There are several support options listed on our Support page → , including the Drupal Forums → and Drupal Answers. There is also Drupal Slack → . You may get better replies in one of those places.

In Drupal core 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 mentioned on the version → section of the list of issue fields documentation. Thanks.

Should be fixed on 11.x first, thanks.

Drupal 10 is in maintenance mode with a limited set of allow changes → . This would have to be confirmed on 11.x and fixed there first.

If this problem was discovered on a version of Drupal that is not 11.x, add that information in the issue summary and leave the version at 11.x. In Drupal core 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 mentioned on the version → section of the list of issue fields documentation. Thanks.

If this problem was discovered on a version of Drupal that is not 11.x, add that information in the issue summary and leave the version at 11.x. In Drupal core 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 mentioned on the version → section of the list of issue fields documentation. Thanks.

If this problem was discovered on a version of Drupal that is not 11.x, add that information in the issue summary and leave the version at 11.x. In Drupal core 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 mentioned on the version → section of the list of issue fields documentation. Thanks.

Drupal 10 is in maintenance mode with a limited set of allow changes → . This should be fixed on 11.x first.

If this problem was discovered on a version of Drupal that is not 11.x, add that information in the issue summary and leave the version at 11.x. In Drupal core 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 mentioned on the version → section of the list of issue fields documentation. Thanks.

Just updating the version.

Drupal 10 is in maintenance mode with a limited set of allow changes → . This would have to be confirmed on 11.x and fixed there first and then considered for backport.

In Drupal core 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 mentioned on the version → section of the list of issue fields documentation. Changing this to 11.x.

In Drupal core 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 mentioned on the version → section of the list of issue fields documentation. Thanks.

I tested this on 11.3.x-dev today and was not able to reproduce the problem using the steps to reproduce in the issue summary.

@abhijeetsatpute, can you confirm this happens on 11.x ?

In Drupal core 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 mentioned on the version → section of the list of issue fields documentation. Thanks.

The IS states "it was asked to split this issue further just based on the number of lines/size of the MR". That was my comment and I was too brief. The size is just one of the indicators used when determining issue scope. It is the easiest to spot, a red flag if you will, that will then spark a review of the issue scope. The comment was never intended to mean that lines/size is the only indicator.

Unfortunately, the discussion with the other committers is not available (because, well Slack) but I am confident that all aspect of the scope guidelines → were considered.

There is still no proposed resolution here, but the comments suggest using 400 lines as a guide. That contradicts the conclusion of the research, which states

Given these factors, the single best piece of advice we can
give is to review between 100 and 300 lines of code at a time and
spend 30-60 minutes to review it.

I would much rather stay within the limits of the research.

@gábor hojtsy, thanks for pointing out the launcher page. Clarifying the two environments for Windows makes sense.

I've updated the system requirements page with the extra information from #20.

Update per https://www.drupal.org/project/drupal/issues/3436617#comment-16225141 🌱 [policy, no patch] Drop support for Windows in production in Drupal 11 Active

Update per It is recommended to use Linux or a similar operating system for hosting Drupal websites.

Added policy doc, https://www.drupal.org/about/core/policies/core-change-policies/set-plat... → . And this can be used for whatever is decided in the similar database issue, 🌱 [Policy] How to select the minimum required database versions Active .

I too am not sure what the 'meta issue template is'. I understand that the similar issue from the previous major version is used as a starting point and improved as we go. So, that changes that were made to the Drupal 12 set of release management issues will be used for Drupal 13 and the 'bump' issue will be created.

Only found references in Claro as shown below and made a sibling issue for that.

$ grep -ri IE11 --exclude-dir="node_modules" --exclude-dir="assets" core
core/themes/claro/js/tableselect.js:        // is preferable, but not supported by IE11.
core/themes/claro/js/tableselect.js:          // Determine add/remove with ternary since IE11 does not support the

Therefore closing this meta.

Thanks to everyone who kept this meta up to date.

$ grep -ri IE11 --exclude-dir="node_modules" --exclude-dir="assets" core
core/themes/claro/js/tableselect.js:        // is preferable, but not supported by IE11.
core/themes/claro/js/tableselect.js:          // Determine add/remove with ternary since IE11 does not support the

Made an issue for this, 📌 Remove IE11 Support from Olivero Active

quietone → created an issue.

quietone → created an issue.

@nicxvan, the diff in #13 has the same comment for two of the functions and @xjm wants a specific message for each function. One that explains what it is testing. I can appreciate that, there is nothing in the file to explain why two very similar functions are needed.

I commented an hour ago but forgot to save. Here is that comment.

@nicxvan, thanks for prompt response to our Slack conversation about this. I updated your suggestions in the MR. In particular, wanting to add more detail so that the last two functions do not have identical comments. This was pointed out by xjm and is why I have moved adding comments to the HookOrder related test modules to a new issue.

Linting passed, back to Needs review.

Rebased, there was a conflict in \Drupal\KernelTests\Core\Entity\EntityQueryTest::testEntityQuery

Leave this to me for a week or two, thanks.

quietone → created an issue.

Removed the hook related ignores, except one for what is an unused function, \template_preprocess_test.

Committed to 11.x and 11.2.x

Thanks!

I used 'git log -Sblock_themes_installed' to find where the function was changed and to confirm the new method name in the MR is correct. That agrees with what jesseh reported in #5. Also checked that there are no other instances of "block_themes_installed".

The comment is an improvement and it is wrapped correctly.

@sajosh, I would say no, that the other pages in this guide can not be removed. 'Install Drupal using DDEV ...' was created recently as a result of https://www.drupal.org/project/documentation/issues/3398293 🌱 Consolidate local development environment documentation to recommend DDEV Active .

The added page seems more about guiding the reader to find information. This seems more suitable to a guide page and not an individual page in a guide, so for now, I have removed it from the menu. I think we need to find a way to ensure your points are resolved by improving the documentation structure, the text in the Guide (Installing Drupal) and the summary text in each page of this guide.

This is a nice improvement but I wonder why it is referring to annotations since attributes are now used.

This needs one small change, see the comment in the MR.

I didn't know about https://www.drupal.org/docs/develop/managing-a-drupalorg-theme-module-or... → . And I think this content fits better in that guide.

I am assigning this to myself to move the doc next week.

@scambler, thanks for providing a fix and a test. In Drupal, the change needs to be reviewed by peers and set to RTBC by a community member.

There are lot of views issues and this seems a basic problem so I am tagging for a subsystem maintainer reviews. Also, are there duplicates of this issue?

I tested this with Umami on 11.x and confirmed the problem exists. However, applying the MR did not fix the problem. Maybe I misunderstood the steps to reproduce.

I'm triaging RTBC issues → . I read the IS, the comments and the MR (not a code review). I have restored the standard template and updated the remaining tasks.

Remove related content to an obsolete module

I tested this on 11.x today and confirmed this is still a bug.

@tedbow, thanks for your work on the Settings Tray!

Committed to 11.x, 11.2.x, 10.6.x, and 10.5.x. I'll also do the admin tasks, such as updating the core node, the Google group, the maintainer channel and the past maintainer page.

@shaal, Sorry about thanking smustgrave instead of you!

@smustgrave, thank you.

Remove references to book pages and migrating such pages.

Adding that this issue was reverted from 11.x and 11.2.x.

I don't know why the comments do not show the 'revert' commits.