The block/add path is not redirecting

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

I added redirection to the Available block type "Add Block Content" page.

For Example:

If the "Basic" block type is available in the block types list then the URL will look like "/block/add/basic"

If the "Test" block type is available in the block types list then the URL will look like "/block/add/test"

Kindly review

Thanks

MR appears to have test failures

I added a dedicated test case. I also fixed the other test failures. The cause of those failures was a destination query parameter on the "Add content block" local action link. It resulted in a redirect loop when trying to use the action link. I expected to reply here saying "This seems like a feature request to me." Except then this business with the destination happened and it does seem like a bit of a bug. The destination is used for forms. So it's no wonder that it behaved strangely when combined with another redirect on an ordinary page.

So I think it's ok to simply remove the destination. The existing tests agree with me as they're all still passing. Or at least there's no coverage for this anomaly. It's worth noting that the node/add action link (which this issue is trying to emulate) does not have a destination.

Small nitpicky comment

But NW for the issue summary.

Also not 100% I see the issue?

Small nitpicky comment

Applied suggestion

But NW for the issue summary.

Updated.

Also not 100% I see the issue?

Like I said in my last comment, this is a feature request. Nothing is broken. I'd call it a UX improvement.

That said, I did uncover what seems like a minor bug while fixing the tests. There's an unnecessary destination parameter on the action link, but I'm reclassifying the issue as a Feature Request anyway so it won't cause more confusion.

I realized that $request property isn't even used. Maybe it was from early draft of the MR or something.

In fact, let's add the Usability tag too.

Looking good, thanks!

As a minor feature request committed to 11.2.x so it will be part of 11.2.0 even though we are in alpha. This is very low disruption.

Committed and pushed ed28d46cb09 to 11.x and 176346e770b to 11.2.x. Thanks!