Update block content type to not have add block link

I think we should wait for 📌 [policy, then docs] Change how we deprecate classes Fixed here so we can deprecate the whole class (Via the constructor)

Sounds like a plan. Will postpone until then

The blocker is in, so let's trigger a deprecation in the constructor

The policy has been adopted now, so let's move the deprecation to the constructor.

But wait, why are we removing this handy button? The IS doesn't say. This seems contrary to the whole pattern of making blocks have the same patterns as other content. The content administration page has a button, the content type administration page has a button, etc.

Updated IS

This issue isn't removing the button, but the text link that's inside the table.

> Block content's admin listing has a 'Add new block' link in the 'results not found' message.
> But there is already an 'add new block' action button like every other content entity list builder.

However, this issue disagrees with ✨ Add link to add a new entity in an empty entity list controller table Needs work , which wants to add the text link to ALL entity types.

However, this issue disagrees with #1798540: Add link to add a new entity in an empty entity list controller table, which wants to add the text link to ALL entity types.

That I can't answer. Maybe @xjm or @larowlan?

Added the deprecation to the listing class though.

Verified the patch #75 and tested it on Drupal version 10.1.x. The patch works fine and I have added the before and after screenshots for reference. But as mentioned in above comments, the problem statement of this ticket contradicts with the ticket ✨ Add link to add a new entity in an empty entity list controller table Needs work

I commented on ✨ Add link to add a new entity in an empty entity list controller table Needs work - personally I think that we shouldn't have a specific block-content views area plugin for when things are empty, but instead a generic one. However ✨ Add link to add a new entity in an empty entity list controller table Needs work does not address that, it only addresses ListBuilders which in reality or normally overridden with a view for content entities. I've asked over there for an issue summary update to outline if that issue intends to tackle that question too.

From my point of view, I think it makes sense to remove the specific block-content one and provide a generic one, but it'd be good to see confirmation that is possible in ✨ Add link to add a new entity in an empty entity list controller table Needs work first.

Less single-use entity things™️ and more generic is the direction I think we should be going in. What do others think? I imagine given the work @joachim has done to make generic entity menu link/action/task handlers he may feel the same way.

As mention in issue the patch #75 works fine but no links are there for new entity.

@saket-001 that is the intention of the issue

I think we should postpone this on ✨ Add link to add a new entity in an empty entity list controller table Needs work , until it at least gets the issue summary update

Can agree with that.

Retitling per #74 since I almost posted a comment like #72 a second time. :)

Hoping we can unblock this issue based on https://www.drupal.org/project/drupal/issues/1798540#comment-16136875 ✨ Add link to add a new entity in an empty entity list controller table Needs work

I've done some testing and reviewed the approach here which seems to be based on #62 and #63

The problem is as soon as we remove the entry from BlockContentViewsData the plugin is no longer functional. Any existing views will not be able to load the plugin and will get a "Broken/missing handler" link on the views UI admin page. We want to remove it so it doesn't leak into new config after being deprecated so I think really the only option here is to write an update hook to update existing views.

I think the upgrade path should be pretty straightforward given we have ViewsConfigUpdater.

With that, I think we can just leave the class as is (not empty it out) so that if for some reason someone is extending it in a way they will at least get the deprecation error and functionality will remain the same?

ViewsConfigUpdater is pretty hard to grok and quite inconsistent, I based this new stuff on needsTableCssClassUpdate which still goes through processDisplayHandlers for seemingly no reason? In any case this is working.

Tests are failing because of a deprecation triggered by a different views upgrade path in 🐛 Add ViewsConfigUpdater deprecation support for update_table_css_class Active :(