Link to block configuration edit form after block config entity has been saved

Before i continue i want to know if i am on the right track

As i understand we want to do this for all configuration entities right?

For now i just did blocks and views save. I wonder if this makes sense for all configuration. I did these two because you you can get to the configuration form through the contextual links and are very common and useful.

Re-rolled patch for 9.2dev.

Verified by applying the patch #17 but it fails to apply.

Tested the patch #17 but fail to apply in drupal-9.5.x-dev.

Rerolled #16

I verified and tested patch #24 in Drupal 9.5.x-dev version. Patch applied successfully.
Thanks @ranjith_kumar_k_u

Re-rolled patch against #24 in Drupal 10.1.x

I'll review this patch

Applied patch #27 for Drupal 10.1.x version and working fine. adding screenshot for the reference.

I have reviewed the patch #27.
It's working fine in drupal 10.1.x

#27 was an unnecessary reroll that will not receive credit. As I've mentioned to you several times @Shubham Chandra - you can check if a patch truly needs a reroll by clicking "add test/retest" on the most recent patch and applying it to the most recent Drupal version.

This issue is being reviewed by the kind folks in Slack, #needs-review-queue-initiative. We are working to keep the size of Needs Review queue [2700+ issues] to around 400 (1 month or less), following Review a patch or merge request as a guide.

Seems like an excellent feature and helpful

#29 appears to have done the manual review so I'll do the code

No new functions so nothing to typehint.
Tests have been updated for the new link.

I don't think such a feature would need a change record but maybe?

Tagging for usability review as it is a UI change

Also tagging for screenshots to be added to the issue summary for before/after.

Thanks!

I embedded the screenshots provided in #29 into the issue summary and removed the screenshots tag.

I embedded the screenshots provided in #29 into the issue summary and removed the screenshots tag.

I am working on this issue at Drupalcon Barcelona 2024.

Reimplemented patch https://www.drupal.org/project/drupal/issues/2912703#comment-14819997 for Drupal 11.x.

left some comments.

Addressed comments on the MR, please review it.

Thanks!

The Needs Review Queue Bot tested this issue. It fails the Drupal core commit checks. Therefore, this issue status is now "Needs work".

This does not mean that the patch necessarily needs to be re-rolled or the MR rebased. Read the Issue Summary, the issue tags and the latest discussion here to determine what needs to be done.

Consult the Drupal Contributor Guide to find step-by-step guides for working with issues.

DrupalCon Nara 2025 we are reserving this issue for Mentored Contribution during the event. After November 19, this issue returns to being open to all. Thanks!

Hi, I have checked the MR and the requested changes are applied we're moving the status to Needs review.

Usability review

We discussed this issue at #3559145: Drupal Usability Meeting 2025-11-28. That issue has a link to a recording of the meeting. I am giving issue credit here to the attendees: @benjifisher, @sahilps6, @the_g_bomb, and @simohell.

It looks as though the "Needs usability review" tag was added in Comment #32 because this issue makes a UI change. I do not think that every UI change should get that tag, but since a review was requested, we looked at the issue.

We agree that this change is a useful improvement. In short, +1 for this issue.

If you want more feedback from the usability team, a good way to reach out is in the #ux channel in Slack.

I am adding the tag for an issue summary update for two reasons.

First, it will help future reviewers if the issue summary uses the standard Issue Summary Template.

Second, the title and the issue summary suggest updating the status message "when you save a configuration entity". Block configuration is just one example of a configuration entity, and the current merge request (MR) just handles this case. So either the MR should be updated to handle the full scope of the issue or the scope should be narrowed to match what the MR does.

Narrowing the scope might be the right choice. For one thing, most contextual links are for content entities or for blocks. Most content entity edit forms already provide a link in the status message when the entity is saved. (This is not implemented in the base classs.) If the most common use case is for editing config entities using their contextual links, then it makes sense to handle blocks. (But views also have contextual links, and the patch in Comment #6 handled views as well as block configuration.)

Another reason to narrow the scope is that the base class Drupal\Core\Entity\EntityForm does not currently set a status message. So handling all config entities is complicated. Either add a status message to every class that extends EntityForm or else update the base class to add a status message (which might be disruptive) and remove status messages from child classes.

I'm setting this to Needs Work because there are reproducible test failures in core/modules/block/tests/src/Functional/BlockTest.php. One of the failures mentions that it can't find the old status message, which makes sense because this MR changes it. Also, the issue summary needs to have the standard template applied as @benjifisher mentioned in #49.

I have not performed a code review.

Setting the status for real this time.

I performed Novice Triage on this issue. I am leaving the Novice tag on this issue because there are clear details for updating the issue summary provided by @benjifisher, and formatting the issue into an issue summary update. Remember to remove the tag when completing the issue summary update. There could be new remaining tasks and a new issue status based on updating the issue summary.

The Drupal Contribution Mentoring team is triaging issues for DrupalCon Chicago 2026, and we are reserving this issue for Mentored Contribution during the event. After Thursday 26th March 2026 + 1 DAY (13:00 UTC), this issue returns to being open to all. Thanks!

Rewrote the summary in the issue summary template
Added the steps to reproduce and remaining task section

@RishiKulshreshtha , ehlovader , there is still some confusion about the scope of the issue. I think the recommendation was to reduce the scope to only Blocks and to make sure that the title and the issue summary reflects that scope change. If you have a chance, can you review @benijifisher's comment again and clarify the scope of the issue?

Limiting the scope on original summary to block configuration.
Had added specific wording to my additions, like the steps to reproduce, when putting summary into template but hadn't done any additional changes to the original content until now.

Should concisely describe the scope of work and what has been done with the change.

Thank you for coming back to the issue and updating it, @ehlovader. I think the new issue summary makes sense based on the usability review. This will help reviewers and contributors seeking to fix the remaining tests work on the issue.

Ofc, sorry it took me a bit to catch up after the con to return.

The two(?) remaining failing tests appear to be related to the block structure view and returning to the list after saving a block configuration. Since this pertained specifically to the contextual links and returning to the page where the block was placed (at least in my interpretation) I wonder if that is also out of scope.

Should the status message be changed when returning to that page? is it just updating the test to match wording?

And also is something we've changed here breaking the block-placement query string?, which iirc scrolls down the page to the block row.