Not sure what this is postponed on but I guess it was #2978270: Javascript tests are failing if you override MINK_DRIVER_CLASS → . That is now closed so changing status.
I rebased and wrapped the new comments to 80 columns. Leaving at RTBC.
quietone → made their first commit to this issue’s fork.
In both the before and after screenshots the 'advanced' section is expanded. This does not show the change.
I made new screenshots as follows. On a fresh standard install of Drupal 11.x I navigated to "/admin/structure/views/view/who_s_online" and took the 'before' screenshot. I then applied the diff, re-installed, and navigated to "/admin/structure/views/view/who_s_online" and took the 'after' screenshot.
While here I updated credit.
@tim.plunkett, thanks for rewriting the change record. I have reviewed it and it is very clear what this change is.
I read the MR and changed 2 comments which didn't read correctly. Leaving at RTBC
Triaging the RTBC queue.
All questions are answered here and credit is updated.
I did think that the wording is the comments in the test could be improved and simplified a bit. Plus one was not wrapped correctly. Also, there were 2 @see lines in the method. I thought one was not necessary and the other should be in the method doc block. Given those changes are only to comments and did not change the intent I am leaving at RTBC.
quietone → made their first commit to this issue’s fork.
Added comments for a new file. Since linting has passed, setting to NR.
All the changes are in views_ui module, so changing component.
I read the comments and the MR (not a code review) and didn't see anything amiss. I have updated credit.
I updated credit and didn't find any unanswered questions.
I see that @smustgrave asked for tests but I am not convinced that the test in this MR is needed. It is only testing that the '#options' of a 'select' item are displayed. Surely that is tested elsewhere.
Hi, 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.
"Review (and in most cases remove) use of target=""_blank"" attribute outside the installer or update.php (2652272)"
Hi, 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.
Hi, 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.
Hi, 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.
The MR needs to be rebased to 11.x
Hi, 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.
Should be needs work for the usability review and a change record, and maybe even doc updates. I did bring this up with the other committers.
Using Umami, I created a new content type and created an English node. When a Spanish translation was added the English revision tab showed a new revision. Seeing this in action and from an editor perspective that was unexpected because the English version of the node was not changed. I added another language, bringing the total to 3. And confirmed that every save to the node in another language caused a revision to appear on the English language revision page. In my limited testing the English version revision page shows 7 revisions with this change and 1 revision without this change. That does reflect the database but will it make sense to the editor?
Like @smustgrave, I wasn't able to reproduce the test from the UI. So, I can't confirm what the test is doing. The test alone went from 2 revisions to 5 revisions displayed.
I would like to know more about how this will effect editors. There will definitely by an increase in the number of revisions shown on the revision tab for the default site language. And for a site with many languages and revisions on a node that is surely going to be a surprise. This would need a CR to explain that, I think.
So, if I am following this correctly then there should be a UX review of this.
Is there a follow up for the point raised by catch in #24?
@smustgrave, thanks for asking for an issue summary update, that is really helpful.
I have updated credit.
Thanks for the fix. I noticed that the paragraph being changed was also not wrapped correctly to 80 chars. I have done that on commit using a plugin available with PhpStorm. I have never had problems with that plugin in the past so it seems safe to do so.
Committed 0d158e2 and pushed to 11.x. Thanks!
Is 📌 Move source_module and destination_module from Migrate to Migrate Drupal Needs work really the issue that caused the problem? The code changed in the MR is from 📌 Move multiple provider plugin work from migrate into core's plugin system Active .
Hmm, this lost my comment that I was asking the other committers about the lack of name. Which I did and there hasn't been a response yet.
@smustgrave, can you elaborate more? who did you send a slack message to etc?
Hi, 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.
Hi, 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.
Hi, 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.
Hi, 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.
This is passing the core gates and I updated credit. I read the MR and didn't see anything amiss.
I am going to ask the other committers about the change record on this.
I have updated credit.
This appears to pass the core gates and the credit looks credit as well.
There are no unanswered questions here and I updated credit.
There is no indication what this is postponed on, so setting to active.
This adds a deprecated module and it should be added to https://www.drupal.org/docs/core-modules-and-themes/deprecated-and-obsolete. There is a similar module listed on that page and the documentation style may be of some use, https://www.drupal.org/node/3223395#s-layout-builder-expose-all-field-bl... → .
I don't see a review of the change record. Can someone check that?
I read the changes and they read well, the changes asked for by xjm have been made. They are no unanswered questions.
This is definitely an improvement. Thanks.
Committed 3c8dd1c and pushed to 11.x. Thanks!
Changed it to 'guidelines'. I didn't want to remove because the previous items are more about the reasoning while the 'guidelines' are more about how to select.
I applied the diff and searched for more instances with $ git grep -B5 'typedData;'. There were 6 instances, none of which were for the typed data manager. None of the tests as base classes and I search any way for usages in contrib and didn't find anything.
Committed 56ee638 and pushed to 11.x. Thanks!
Oh, I did update the policy doc with the suggestion from #23. So we have covered to case pointed out in #21.
Add that the PHP version must be supported by a previous minor
#23 looks fine.
I did have a go at reducing the long sentences and came up with this:
- The minimum PHP required should be set to the highest stable PHP version available at the time beta1 of the next major version is released. This is the target PHP version.
- An earlier PHP version may be selected when any of the following apply.
- If the target PHP version is not supported by a Drupal minor release by the time of the beta1.
- If the target PHP version is not sufficiently supported by a dependency by the time of the beta1.
I was about to commit this but the new entry should include the real name as well.
@yoroy, it was a pleasure to meet you and work with you in Kingston.
Committed to 11.x, 11.2.x, 10.6.x, and 10.5.x. I will also update the core node, the Google group, and the maintainer channel as needed.
Updating version because 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 → .
Drupal 10 is in maintenance mode and this doesn't fit in to the allow changes → .
Updating the version because 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 → .
So now does this happen on 11.2.x or 11.x?
Hi, 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.
Hi, the Drupal Core issue queue is not the ideal place for support requests. The 'support request' option is there for filing support issues for contributed modules and themes. 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.
Hi, 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.
Also for Drupal core, it is preferred that contributors add a comment that they are working on an issue instead of assigning it to themselves. See Assigning ownership of a Drupal core issue → .
@joachim, in case you are not aware there is a policy issue for discussing how we can safely close stale issues, that is 🌱 [Policy, no patch] closing older issues Active and there is also a Drupal slack channel #stale-issue-cleanup. Contributing your feedback and ideas on how to improve the process are welcome.
@joachim, I don't there is a need to shout at anyone here.
To say none of this is done seems incorrect as the 4 child issue are complete. And even the remaining task section here does implies that this is waiting on the child issues to be completed.
In #45 you said that the new issue made there would cover this issue. Does that mean to continue the work over there or something else?
Triaging the RTBC queue.
I have not read all the comments but nothing stood out as incomplete in a skim. I read the MR and made some suggested changes so setting to needs work for that. Also, the issue summary is out of date. If refers to 'aria-required' which is not in the MR and to Seven and Bartik which are no longer i core. Tagging for an IS update.
Triaging the RTBC queue.
This is straightforwards as was said in #4. I applied the diff and searched for 'test_entity_reference' and confirmed that the correct instances are changed. I didn't find any that should be changed that are not. Well done.
I checked credit. Everything is in order here.
And thanks to @nicxvan for helping with how we work in the Drupal core issue queue.
Rebased and linting passes. There are new changes that need to be reviewed. These are for the use of "#[TestWith(" and there is no standard yet for that. For readability, it made sense to me to simply add an ignore line to ignore this sniff.
And this was fixed.
This was committed to 8.0 and not fixed in 7 so I am updating the version. Also, updated credit, which is always challenging on an older issue with lots of comments.
@borisson_ suggested that a replacement URL isn't necessary, that we just use the Node ID. And catch said the same in #8.
So let's do that.
HI, 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 → . Thanks.
Hi, 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 → . Thanks.
In Drupal core the standard issue template should be used and each heading filled out as much as possible. I am restoring the template. This also needs steps to reproduce so adding tag.
Hi, 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 → . Thanks.
Hi, 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 → . Thanks.
Hi, 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 → . Thanks.
Hi, 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 → . Thanks.
Hi, 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 → . Thanks.
If I am reading this correctly then the consensus is to go with "Redirects without deleting make the old pages mostly inaccessible, so they might as well be deleted."
Being 'mostly' inaccessible is helpful for the Coding Standards Committee. It allows the history to be available to the Committee and those interested in coding standards. If they happen to get edited, the committee will have to follow up on that.
I updated the proposed resolution with all the URLs in the Coding standard guide as asked for in #6. I have also split them to two groups because not all the pages have history that needs to be kept.
I am not sure what the replacement URL should be for the pages that are to kept for their history.
This came up in the last meeting and there were no objections, 📌 Coding Standards Meeting Wednesday 2025-08-27 0900 UTC Active .
I think is outdated as of 📌 Deprecate and remove usages of datetime_date_default_time(). Fixed . That issue also added tests and documentation.
If I am wrong, re-open the issue.
formatting
@luismagr, Can you make an MR so the tests run?
I personally do not care if we use 'by' or 'co-authored-by' but I do care if improvements to the commit message format and gitlab issues get delayed by bike shedding over entirely hypothetical situations.
+1. This is all GPL and in a community that wants to recognize all the people who contributed to get an issue finished.
I also want to remind us all that that this issue is to tweak the agreement of the original issue because of technical reasons. Let's keep it to that.
I hadn't read the other issue, 📌 Properly handle that PHP bcrypt passwords are truncated to 72 bytes Active , until now. I like the suggestion in #43.
The link in the message is to a change record. Should that be to a documentation page instead?
@xjm, I am a bit under the weather. Do you have new wording to recommend?
@gábor hojtsy, thanks for reviewing that. Glad we agree.
This reads well to me, I agree with this change.
nit: I made a suggestion in the MR to use serial commas, which I believe Drupal uses and is recommended in the Content style guide → .
Is this a duplicate of 💬 Responsive grid view not responsive Active ?
I added @phpstan-ignore classConstant.deprecatedClass to two test files to fix reported errors from the use of #[CoversClass( )] with a deprecated class.
Although this is older I am closing this as a duplicate of a recent issue with an MR
It has been 13 years since this was discussed. That suggests people have managed with the existing statuses, whether we all like them or not.
Related to this is an issue collecting all the issues about issue management, 🌱 [meta] Improve issue management Active . There is also the Bug Smash Initiative that has done much to triage and close duplicates and outdated issues. And the Needs Review Initiative is also keeping the number of issues at needs review in a more manageable state. And the total number of issues is being reduce by the identifying stale and very old issues and requesting confirmation that they are still a problem.
There is also work being done to add active subsystem and topic maintainers and remove inactive ones.
All these steps help to improve the issue throughput with, to me, is the goal.
Therefore, closing this as outdated.