quietone → created an issue.
Changes this to just the jsonapi tests, which are the easy ones. Moving work on the others to another issue.
Changes are made on 11.x, the main development branch first. Thanks.
Checked on 11.x HEAD today, standard install, and this still happens. I applied the latest diff, cleared cache and the problem removes.
Tagging for an issue summary update.
The question in #12 hasn't been answered in 8 months. So, I testing this on 11.x with and without the link_attribute module. I was not able to reproduce the problem using the steps in the issue summary.
Therefore, closing as cannot reproduce. 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!
Since no reason for making this change has been given in 7 months, I am closing this issue.
If you agree with change then add a comment explaining why this is needed and reopen the issue, by setting the status to 'Active'.
Thanks!
Time to close this one, per #27.
More information about this issue was asked for 7 months ago about the site configuration. No additional information has been supplied.
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!
It has been 10 months and more information about how to reproduce this has not been supplied.
Therefore, closing as cannot reproduce per #2.
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!
Bug are fixed on the main development branch, 11.x, first. Thanks
smustgrave → credited quietone → .
Change required in ElementInfoManager.php.
Sharing the goals and progress via a blog post would spread the word wider about this vital work. And it is more that statistics, it is an opportunity to discuss each part of the review process, when to ping someone, when not to ping someone, what tags to use, why keeping the issue summary up to date help, how to postpone an issue etc. And maybe there is a sense that reviews or reviewers are improving there skills.
If the blog posts included more that statistics, then the frequency the post would likely be less. At that can be a good thing.
Drupal 9 is EOL. Does this happen on a supported version of Drupal?
Forgot to change the version.
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, support for Drupal 10.1 ended when Drupal 10.3.0 was released. Thanks
@joepublic, have your searched for a duplicate of this problem?
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
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
@catch, since this about Drupal on production sites it is necessary to bring up local development on OSX, or any other platform?
What issue is this a duplicate of?
@drumm, sorry about that.
There is an issue to remove the tips 📌 Remove 'filter tips' and deprecate the API Active , which has product manager approval. Therefor I am closing this as a won't fix.
The issue summary states this is about text on "issue edit pages" so this should be in the customization project. Although now that issues are moving to GitLab this probably will not be fixed.
Made a suggested text.
@immaculatexavier, the MR looks fine. The only thing is to remember to check that tests are passing before setting an issue to Needs Review. There was a failing test, which I presume, is why this was set back to Needs work. In this case the solution was simply to rerun the failing linting test. Then, since that passed the next step was to start the tests. All that is from the GitLab UI.
I reran test failing tests and tests are passing now.
quietone → created an issue.
Should have been no known problems since the gate was moved here.
Should have been no known problems since the gate was moved here.
Comment, #8, suggested that this needs input from core committers and not work on the issue. Actually what this needs is input from the Usability team.
There is a core gate, for Usability → . I am tagging for usability based on that. Also, adding tag for a usability review to get resolution on the wording changes. The "Needs usability review" is a special tag → . The description for that explains what needs to be done to prepare the issue for review.
I suggest asking in the Drupal Slack #ux channel for help on this one. Work on the MR should wait until the Usability team responds.
I should add that the 'release prep' issues for minor releases already has an item for using the equivalent update, so that should be happening for each minor release. For example, 🌱 [meta] Release preparation steps for 11.3.0 and 10.6.0 Postponed .
With all that I think we have this 'in place' for the future as well.
I added a draft sentence to the 10.6.0 release notes google doc. Once that is agreed to it can be used in future release notes.
As for making the 12.1.x issue, in order to remember that for each major release I added a new item to 🌱 [12.x] [meta] Release Drupal 12 in 2026 Active .
Added an item to ensure an issue is made to use the equivalent update API in Drupal 12. This issue will be used as the template for the Drupal 13 issue, so the item will be remembered in the future. catch brought up this in #3463225-13: [meta] Prevent 'downgrades' from maintenance minors to older minor releases for the next major version → and with the the release managers.
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.
Sorry, should be 11.x, the main development branch.
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
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
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
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 → . Thanks
Closing this as a duplicate of 📌 Defer disruptive 11.3 deprecations for removal until 13.0 Active
Crediting those not already credited on the other issue. japerry
quietone → created an issue.
@mgifford, thank you for responding here and in slack, confirming that this core gate is correct.
I updated the IS to say the implementation is to be done in 📌 Target="_blank" attribute add to external links. Postponed .
Also restoring the outdated status.
@longwave, thanks for improving the consistency.
There were no conflicts in the rebase so back to RTBC
Another rebase. Some conflicts from all the hook changes but all were simple.
quietone → created an 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 → . Also mentioned on the version → section of the list of issue fields documentation. Thanks.
Changes are made on 11.x first.
OK. The followup is 📌 [policy, no patch] Update allowed changes to current practice for backport of Test API changes Active
quietone → created an 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 → .
@benjifisher, thanks for the details of why the entity schema is needed. I admit my earlier reply lacked detail and could be seen as, well not kind. It is a reminder to take more care after a disturbed night of sleep.
I've copied the comment. And that too I should have looked for in the issue.
Linting has passed so setting this to NR.
@mstrelan, still interested in Ban in contrib? If so, is the contrib project created? I ask because the issue to deprecate Ban is needs review.
xjm brought this up in the rm channel suggesting changes to bring the policy up to current practice. That being that testing API additions may be backported to help contrib.
The idea is to modify the text so that "Testing API additions should be backported to the production and maintenance minor branches" are allowed.
@xjm reminded me that this should be check by the Accessibility maintainers. I will ping in slack.
That test installs path_alias in a kernel test but does not install the entity schema which Migrate Drupal UI seems to need but doesn't have a dependency on.
Is there any else to do here?
The CSS in stable9 can be removed in when this module is removed from core. The same happened for tour 📌 Remove Tour module Fixed
The dev dependencies are included in the two dev tarball
https://ftp.drupal.org/files/projects/drupal-11.x-dev.tar.gz
https://ftp.drupal.org/files/projects/drupal-10.6.x-dev.tar.gz
$ curl -O https://ftp.drupal.org/files/projects/drupal-11.x-dev.tar.gz
$ tar -xf drupal-11.x-dev.tar.gz
$ ls drupal-11.x-dev/vendor
asm89 colinodell egulias marc-mabe mikey179 pear phpstan ramsey sirbrillig tbachert
autoload.php composer google masterminds myclabs phar-io php-tuf react slevomat theseer
behat dealerdirect guzzlehttp mck89 nikic phpdocumentor phpunit revolt squizlabs twig
bin doctrine justinrainbow mglaman nyholm php-http psr sebastian staabm webflo
brick drupal lullabot micheh open-telemetry phpspec ralouphie seld symfony webmozart
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.
An h4 is used on 11.x as well.
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.
Fix link in the issue summary
As I read it is trying to say that since hook_update_N has run the db is in a state where it is safe to run other updates. In that sense, 'repaired' makes sense. Although I would prefer "updated" to allow for fixes and features.
For history, 'repaired' was added in #2538108: Add hook_post_update_NAME() for data value updates to reliably run after data format updates → , at this comment → . I did not find the word 'repair' in the issue.
quietone → created an issue.
@cadence96, thanks for letting us know.
This is an issue for the API project.
Starting over. Will deprecating FieldPluginBase be sufficient, similar to DrupalSqlBase for the source plugins?
What needs to happen to the css in stable 9, item 1 of the remaining tasks.