Promoted/Sticky fields are outdated and confusing, find an alternative for them

Just my two cents: for the love of god, get rid of them both. Please. I beg you.

Currently, we manage around 30 Drupal projects we've created for clients.
Only 3 of them implement a blog like funcitonality.
Literarally none of them use sticky or promoted.
Yes we had a blog where the client wished for some control to have some blog items on top.
That means more than one. In the order that he likes, like first node F, then node D, then the rest automatic on date.
But if your use case is give the client option to set more than 1 node on top of a view, then sticky or promote fields are useless.
You can add a 'Priority' field with default value set to 0 that you first sort on in the view for example to solve this use case. Or use the node_weight module so client can drag and drop nodes to set the order. But sticky or promoted are useless for having > 1 items on top.

If its really impossible to replicate this functionality with existing contrib modules (but I think it is) for the few projects that need them, then create a new contrib module that does this so we can remove this from core and those (few) that need it can use contrib modules (or just create a priority field for example and sort on that).

When I first started going to client meetings many years ago to present a project, those options confused all clients because they were there because its just core, but were not used for anything.
A beginner mistake to not heavily customize the drupal out of the box (backend) experience for customers if they need access to the backend, for example for content editing.

So then at first we had a custom module that removed these fields (for client user roles) via form alters I think - and did many other backend adjustments -, then later on we could hide them via the override_node_options module. But those useless (for most projects, not all projects in the world, I know) fields have been a pet peeve of mine for many years now.

We could move these out to a feature flag module, disable it by default on new installs but enable it on existing sites, and eventually move it out to contrib.

When this issue was opened we didn't have dynamic base fields, but now that we have hook_entity_base_field_info() it should be possible for a contrib module to provide these fields as-is. Only issue might be compound database indexes to replicate the core ones, but could fall back to the database API + field database schema for that bit.

#24 tells me that people don't don't that you can hide both promote and sticky through the manage form display page, since 8.0. No extra modules or custom code required.

Removing/moving those fields sounds like a very scary upgrade path issue to me. We know that people don't read and they also don't do backups, so upgrading means that we will drop their data.

What if we just do a very basic change for now, and that's to have those fields hidden by default. If you want to use them, make them visible, otherwise you likely won't notice that they still exist. That's as simple as removing two method calls in the field definitions and has very limited risk.

What if we just do a very basic change for now, and that's to have those fields hidden by default.

I vote for this so that I can keep those flags for current sites but hide those for sites I don’t need those.

+1 to #27. Removing them outright would be disastrous.

I use (or abuse) those fields on some sites, though I usually change their labels to reflect the specific outcome for each site.

+1 to #27: I don't want to be responsible for existing projects to fail after an update. Hiding is a good first step.
I would still like to see them deprecated and maybe moved to contrib over time. Or maybe sort of disabled for new installs, but I'm guessing thats almost the same as the proposal from #27.

Side note: I checked and we do actually just hide them in form display now. Still, would be nice if this is default behavior to improve the out of the box content editor experience in case you added a new content type or started a new project and you forgot to do this for the millionth time.

Changing issue title and summary.

Both of these properties are oddly specific and they make even less sense than they made in 2005 given how websites and uses of Drupal have evolved. I spent a few minutes on a quick PoC to test if we could dynamically delete these from new sites.

Given how websites and uses of Drupal have evolved.

Do you have some data about this?

We should hide those flags for new sites. But leave those discoverable to any developers who are asked to implement the sticky and promoted flags.

…test if we could dynamically delete these from new sites.

Will a new site developer still be able to add the flags (or one at a time) back?

From a release manager point of view #33 feels like it is going to cause us pain further down the line - we forever have to support the field tables that may or may not exist. I would prefer that we take this in more definite steps, and figure out how to hive off these fields to a separate module that can be moved to contrib.

Simply removing them from the form (as per the original intent of this issue) feels like an easier win and the most straightforward next step.