Remove promote/sticky fields from Node

I don’t think it advisable to remove those fields.

Umami is using those fields as well some or many websites (there are no exposed statistics on this, except personal preferences).

As the very minimum, a contrib module must be made to compensate the removal of those fields.

@xmacinfo I agree, but a follow up was asked for in the linked comment in the IS. I can't see how this would be viable to do tbh.

Would it be possible to remove the base field definitions from node module and move them to a separate module that implements hook_entity_base_field_info? Then we install that module for existing sites with an update hook. After a full major cycle we move the module to contrib. We would provide good documentation for how to remove the module if you're not using these fields.

There will likely be a lot to untangle:

• Getters and setters in Node class can be deprecated, and we can deprecate magic access in __get/__set
• Node constants can be deprecated and move to the new module
• Actions (system.action.node_make_sticky, etc) can move directly to the module
• Config entities (views, entity view displays, etc) that use these fields and actions will need a dependency on the new module
• Node views data moves to the new module
• Not sure about NodeStorageSchema
• Relevant parts of \Drupal\node\NodeAccessControlHandler::checkFieldAccess can be implemented in hook_entity_field_access[_alter]
• Other code paths will need to move to hook implementations in the new module
• We may need some new hooks

After a full major cycle we move the module to contrib

That's the piece I was missing piece I think, good idea.

Made a start as a proof of concept. There is a lot to do, and not sure there is any good way to split it up. Might be best to park it until we can decide if this is even something we want to do.

(Just adding tags. This was a proposal by @lauriii, but would need signoff and agreement from all the relevant stakeholders to move forward, including release managers, other product managers, and the node subsytem maintainers.)

Signing off from a subsystem pov, I can't remember the last time I used these flags on a project. It's going to be a complicated piece of work but will be worth the cleanup in the long run for (what I'm assuming is) majority of sites that don't use these features.

I just found #514056: Move sticky, promote and user.blocked to flag field types in core. → that was closed as a duplicate of #29338: Hide Promoted/Sticky fields by default in Form display → before that was rescoped to only hiding by default. Potentially it could be reopened now and we close this as a duplicate, but it's maybe cleaner to just continue on here.

Updated the proposed resolution based on #4. Note that the general idea was discussed early on in 29338. Also I guess this is no longer postponed, so setting to needs work, but noting the issue tags.

I can't remember the last time I used these flags on a project.

This is your point of view and there are no stats anywhere about the usage of those flags.

Umami and Drupal CMS are using those flags.

I regularly use those flags.

I see many sites built to use one or both of those flags.

Hiding those flags by default is a good compromise.

I guess we would need to determine what to do with the default frontpage view. It likely needs to move to the promote module. Perhaps node may need to ship a version without the promote filter and the promote module can override it. Or perhaps node should depend on promote initially until some of these things are solved.

Tests are mostly passing now by enabling promote module in failing tests. I'm now thinking that in order to make this easier to review we should initially make the promote module a dependency of node. We can then have a follow up to remove that dependency. That would also give us a bit of a safety net if there are edge case integrations that we haven't covered.

What is the more “modern” recommended way to implement these features if these are to be removed from Core? I read through the entire issue this was forked from and am not sure. Is it the Flag module? I’m preparing to launch a new site in the next few days and getting in the replacement now would be ideal considering the huge scale of content in it. I saw Flag and Entityqueue mentioned, but curious what others who aren’t using these base fields but do implement these features use. I saw on the original post that these base fields are more performant than adding a field like field_promoted manually. I’m particularly interested in the comment about how promoted and sticky are useless when more than one node is tagged with those in a Views list.