🇳🇿New Zealand @quietone

The field mentioned in the issue summary, comment_forum, was removed when Forum was removed from core.

Are there any other hard coded field names in core?

Since we need more information to move forward with this issue, I am setting 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!

All the pages in the 'to be completed section have been updated quite a few times since the last comment here 8 years ago. I am closing this as outdated. A new issue can be opened, if needed, to coordinate any remaining work in this area.

AFAIKT the change made when set to needs review is correct

Is this fixed by #3211164: Random errors in Javascript Testing → ?

There are 2 open related issues here and one if for the Drupal 7 Views contrib module. By convention, a meta can be closed when there is one remaining issue. Also, there has been quite a bit of work on the database API and moving each database driver to their own module.

So, I am closing that at outdated.

Add all children to the lists in the issue summary

Remove closed issues from the IS

No worries. Glad this is resolved.

As stated in #4, I don't think any change to any existing policy is needed. I will try to make it clearer.

The backport policy → states

Most patches that are allowed in patch releases can be cherry-picked between minor versions. Committer apply these patches to both branches at the same time.

The allowed changes policy → lists what can be applied in patch fixed and that includes

non-disruptive bug fixes

. Since, the changes to Starterkit theme CSS, markup, and templates are non-disruptive, they are already covered. Therefore, there is no need to update policy.

Restoring RTBC since I've only added more explanation and updated the IS.

Everything looks in order here. I updated credit.

Everything looks in order here. I updated credit.

Setting to needs work for an item in the MR. Also, this needs a title update.

I see that xjm asked for a Meta to make these changes in other permission callback but I wonder if these can all be done at once. Not sure.

I didn't find any problems with this and all questions are answered.

Change use of Drupal 8

Change reference to Drupal 8

No indication was given to say what needs to be done.

Change references to Drupal 8 and other minor cleanup.

Change reference to Drupal 8

Change references to Drupal 8

Change references to Drupal 8

Remove section that just links to another page in this guide.

Change references to Drupal 8

Remove references to Drupal 8

Change references to Drupal 8

Something went wrong here. The rebase has lost all the changes in the previous 2 commits and has reverted changes in a recent commit, for 📌 The documentation for the function FormattableMarkup::placeholderFormat contains typos Active .

This also seems like a good time to check in to see if there is support for this feature request.

I am setting the status at Postponed (maintainer needs more info) to get comments about the interest in this issue.

The Ideas project is being deprecated. This issue is moved to the Drupal project. Check that the selected component is correct. Also, add the relevant tags, especially any 'needs manager review' tags.

I think there is another issue about these paths, so this may be a duplicate

Thanks for this improvement!

Needs a rebase

Nice to get this finally fixed!

@brandonlira, yes, thanks for the explanation. Have you seen rebase a merge request → ?

Thanks everyone for improving the documentation.!

This still needs a title that will have meaning when scanning the git log years from now. It is changing the API and adding a new method, after all. Something along the lines of 'Add BreakpointInterface::hasMediaQuery() for ...'?

@poker10, thanks for searching for where this was introduced. That is always helpful.

Updated credit. I will commit this presently.

@lostcarpark, Thank you for helping others!

I changed the titled. I applied the MR and search for node/src/NodeForm, node/src/Form/NodeForm and the old namespace and found no occurrences. And some tweaks to the change record.

Instead of creating a new functional test for this one assertion, can the test be moved into the existing \Drupal\Tests\node\Functional\NodeEditFormTest::testNodeEdit method? I see @larowlan suggested reusing NodeEditFormTest which I think means a new method but testNodeEdit is for testing the functionality of that form. Leaving at RTBC.

It is not clear to me if the latest version of the MR has been manually tested, so tagging for that.

I tried to test this myself but on 11.x HEAD I am not able to reproduce the problem. Are there missing steps? The screenshots don't appear to be on Claro. Testing and screeshots should be on a core theme.

I rebased and reworded a comment. It did not change the meaning, so I am leaving this Major issue at RTBC.

Also need release manager sign-off, which I don't see here.

formatting change in the issue summary.

move Evaluating dependency changes with composer-lock-diff to  https://www.drupal.org/node/3089540 →

move Evaluating dependency changes with composer-lock-diff from https://www.drupal.org/node/3051219 →

quietone → made their first commit to this issue’s fork.

Update 'upcoming deprecations'

Updated from discussion on the Migrate video call today, benjifisher, heddn, mikelutz and myself were present. 📌 [meeting] Migrate Meeting 2025-04-24 2100Z Active

This was discussed on the Migrate video call today, benjifisher, heddn, mikelutz and myself were present. 📌 [meeting] Migrate Meeting 2025-04-24 2100Z Active

The properties source_module and destination_module was added to support the Migrate Drupal UI. The source_module was specific to legacy Drupal module so it has been moved from Migrate to Migrate Drupal. However, destination_module refers to the modern Drupal module so there is no urgent need to remove it. Having in core does no harm, even if it becomes unused. So, this is a won't fix. Like always, that decision can be reviewed later.

Right now, we want to put effort into removing Migrate Drupal and Migrate Drupal UI from core and improving the migrate ecosystem.

Because deprecating an extension has many steps and this is the last step in the process outlined in the parent issue. It is best to do the other ones first.

Rebased and updated the issue summary.

I think that this is suitable as a novice level issue.

quietone → created an issue.

I didn't expect the significant changes here to the Product manager role. Not yet sure if I agree or disagree with all those changes.

Is a 'Needs UX manager review' tag needed?

benjifisher → credited quietone → .

Change references to Drupal 8

Change references to Drupal 8

OK, so no tests.

However, with that 'typo' fixed the script fails to run.Doing so results in the error reported by @jaydev bhatt, in #9. The solution in the MR is too bootstrap Drupal so that t() is found. That seems unnecessary since this isn't doing any translations. So, I did some digging.

$ git log -- core/scripts/update-countries.sh reported 🐛 Remove redefintion of t() from update-countries.sh Fixed was committed in Sep 2023. Reading that issue brought back memories of being here before. Now that there is an argument in the t() functions in CountryManager I think the fake t() removed in #3384436 can be restored.

I was thinking along the same line as @drumm when I moved this but didn't comment. This is looking like a won't fix.

Does anyone else support this idea?

If the same column was added for the 'published' view then it would make it harder to know which view one was looking at. That is likely to cause confusion to others so probably not a good idea. Unless, the extra column was only visible to core committers?

Nice, thanks!

Created text for the policy doc which is ready for review.

Do we want both and issue tag and a api doc tag?

The allowed changes for minor releases → does list CSS, markup, or template changes (except for stable base themes) for minor releases. However, the allowed changes for patch releases → states that "non-disruptive bug fixes" are allowed. So, the fixes described in the issue summary would fit within the existing criteria.

An extra sentence could be added to explain that changes to Starterkit are not disruptive. However, Disruptive → is defined later in the document and can be evaluated in any issue or amongst the core committers. Also, there is always tension in such documents to provide both detail and flexibility in interpretation. I would rather leave the policy as is.

Internal path

Add a route for the deprecated path. Name the route the same at the original adding ".bc" to the end. Set the path to the deprecated path. Add a controller, naming it to identify it as a redirect. Create the controller. The controller includes the @trigger_error('...', E_USER_DEPRECATED) and the necessary logic to perform the redirect.

For example:

# @todo Deprecate this route once
#   https://www.drupal.org/project/drupal/issues/3159210 is fixed, or remove
#   it in Drupal 11.
# @see https://www.drupal.org/node/3320855
entity.block_content_type.collection.bc:
  path: '/admin/structure/block/block-content/types'
  defaults:
    _controller: '\Drupal\block_content\Controller\BlockContentController::blockContentTypeRedirect'
  options:
    _admin_route: TRUE
  requirements:
    _permission: 'administer blocks'

  /**
   * Provides a redirect to the list of custom block types.
   *
   * @return \Symfony\Component\HttpFoundation\RedirectResponse
   *
   * @deprecated in drupal:10.1.0 and is removed from drupal:11.0.0. Use
   *   /admin/structure/block-content directly instead of
   *   /admin/structure/block/block-content/types.
   *
   * @see https://www.drupal.org/node/3320855
   */
  public function blockContentTypeRedirect(): RedirectResponse {
    @trigger_error('The path /admin/structure/block/block-content/types is deprecated in drupal:10.1.0 and is removed from drupal:11.0.0. Use /admin/structure/block-content. See https://www.drupal.org/node/3320855.', E_USER_DEPRECATED);
    $route = 'entity.block_content_type.collection';
    $params = [
      '%old_path' => Url::fromRoute("$route.bc")->toString(),
      '%new_path' => Url::fromRoute($route)->toString(),
      '%change_record' => 'https://www.drupal.org/node/3320855',
    ];
    $warning_message = $this->t('You have been redirected from %old_path. Update links, shortcuts, and bookmarks to use %new_path.', $params);
    $this->messenger()->addWarning($warning_message);
    $this->getLogger('block_content')->warning('A user was redirected from %old_path to %new_path. This redirect will be removed in a future version of Drupal. Update links, shortcuts, and bookmarks to use %new_path. See %change_record for more information.', $params);

    return $this->redirect($route, [], [], 301);
  }

The remaining tasks has, "Ticket out". That does that mean?

Thanks for pointing out the other issues. That shows there are concrete efforts to improve testing.

Looking at the topics in the issue summary, I wonder if this issue is the place to make progress, especially since there has only been two voices here.

• Make writing tests easier - How to do this? Is this through mentoring or tutorials in documentation or something else?
• Better document the existing tests - While true, is it in the best interest of the project to spend time on improving the docs on existing tests?
• Incentivize test writing - There are 2006, about 13%, of open issues in core that are tagged 'needs tests'. Is that a high enough percentage that incentives are needed?
• Prioritize (like core initiative style) efforts to rationalize, standardize and clean-up our existing tests. - Anyone can start and initiate, so this issue isn't needed to approve that.
• Make it easier and faster to iterate on tests in the issue queue (e.g. #2569585: Split incoming patches into psr0/psr4 tests and code and run just new tests first.). - Is there an issue for this for GitLab?

Although I created this followup I think it better to spend our time on existing concrete efforts. Shall we close this?

@annmarysruthy, I think each usage needs to be examined. For example, the usages in tests should probably not change, In may turn out that there are no places where making this change is an improvement. I have not looked closely at all the instances.

The Drupal core Accessibility → core gate states that a goal of core is to conform to WCAG 2.1. That standard has recommendations, https://www.w3.org/WAI/WCAG21/Techniques/general/G200, for this case.

There is an item here to add a sniff for target=_blank. But there are valid cases for using _blank so adding a sniff to to warn about it's use could be disruptive when running commit-code-check.sh.

Therefor, I think everything is done here.

Thanks everyone!

@walterp, If this is happening on 11.1.x then include that information in the issue summary. The version field reflects where the change will be made which is 11.x.

The section AI-Generated Content → of the Issue etiquette document was added after this issue was opened. Having that policy statement fulfills the proposed resolution of this issue. Therefor I think this can be closed.

Policy and documentation evolves, so if the existing statement needs adjusting I suggest making a new issue to focus on that.

quietone → created an issue.

Move to the contributed module guide.

It has been five years and the extra information that was going to be added has not been. Therefor, I am closing this issue.

The Ideas project is deprecated. If there is more to discuss here I suggest opening a feature request issue in the core issue queue.

The ideas project is deprecated.

It has been 8 years and there has been no support for this idea. Given that I think this should be closed.

The core ideas project is deprecated.

There is one open child issue here, which is in the core issue queue. By convention we can close issues with one remaining child. So, I am closing this issue.

The Ideas project is deprecated, moving this to core.

This has been fixed in #2721309: Fix Drupal.Commenting.FunctionComment.ParamCommentFullStop → and 📌 Fix Drupal.Commenting.FunctionComment.MissingReturnComment in core/tests Active ,

I skimmed the doc pages referred to in the issue summary and they have been updated. Therefor, closing this as outdated.

If that is incorrect re-open.

I think so. I closed that as a duplicate so this whole process uses the 'standard' templates developed over the last few years.

Out of habit I created the 'standard' set of issues for deprecating and removing a module from core. That makes this a duplicate of 📌 Deprecate the Field Layout module Postponed .