Deprecate SyndicateBlock

I noticed the change record for this issue published. Since this issue not fixed I un-published it.

I don't think we should be adding @legacy to all those tests. The block should instead be removed from the profile and theme.

annmarysruthy → closed merge request !11835

annmarysruthy → changed the visibility of the branch 3518990-deprecate-syndicateblock to hidden.

@acbramley Can I skip deprecating the block and directly remove it? But what if the block is currently being used in sites.

You want to deprecate the block *plugin* and remove the block configuration from standard profile so it is no longer used.

This also is related to 📌 Create a way to declare a plugin as deprecated Needs work . Ideally, a deprecated block shouldn't show up anymore as a possible option in the UI, but you should still be able to view and edit a block that's already placed, possibly with a warning in the UI.

We had custom logic for this for the node type visibility plugin in D8 or 9.

Deprecated the block and removed it from theme and profile. still getting a few test failures in merge request !11835.

Most of the test failures were due to the block being in the update fixture which I've now removed.

The last failures are around performance tests.

StandardPerformanceTest is now failing with an additional query to the path alias table which is very strange since we're removing a block that renders a link to that:
SELECT 1 AS "expression" FROM "path_alias" "base_table" WHERE ("base_table"."status" = 1) AND ("base_table"."path" LIKE "/rss.xml%" ESCAPE '\\') LIMIT 1 OFFSET 0

Finally green.

Re #11 I think that'd be nice but I'm hoping since this block is most likely not used that much we probably don't need to block on that?

Opened 📌 Deprecate RSS usage in core Active to discuss if we want to deprecate RSS more broadly in core

Do we want to do something about #11? Specifically, do we want to indicate or completely hide this block when placing a new block? We don't have an official way to do that anymore and the referenced issue is actually going to be tricky to implement now with typed classes and constructors, but we could add a a hardcoded workaround.

Found a nice way to do #16 - there's a _block_ui_hidden key on the definition that BlockLibraryController uses to filter out definitions when adding a block. This doesn't affect existing blocks that have already been placed. Works perfectly for what we need here!

The Needs Review Queue Bot → tested this issue. It no longer applies to Drupal core. 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.

Rebased MR 11853