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.

A 5 digit issue almost 20 years old!

Totally agree, we can hide these by default very easily. Manually tested the MR change by:

1. Installing Standard
2. Creating a new content type and NOT changing the default form display settings
3. Making the changes in the MR
4. Clearing cache
5. Checking form display settings.

The result is as follows:
- Any content type that already had a form_display config is preserved - i.e basic page and article created by Standard
- Any content type that had no form_display config (i.e the one created in step 2 above) will have its promoted and sticky flags automatically hidden
- Any new content type created after the change will have its promoted and sticky flags automatically hidden.

I think this is expected behaviour, the content type created in 2 still had the default form_display config so updating the base field definition just updated the default display. Once the form display settings are saved at least one time, that creates the core.entity_form_display.node.test.default config entity and after that, changes to the base field definitions will not affect the form display.

Therefore, this is BC safe.

I'm not sure if this should be postponed on 📌 "Promoted to front page" for new content types should default to Un-Checked Needs work or not (hopefully not).

I think this ticket and your MR will make 📌 "Promoted to front page" for new content types should default to Un-Checked Needs work outdated.

Marking as Needs work; some tests are failings.

Commented over there, they are 2 distinct issues.

I'm still working on the test failures.

Looks good. In a way, it would be nice if we could update standard page to have those hidden, but the default frontpage view doesn't limit by node type, so a promoted page would still show up.

Maybe we can update umami and remove it from those where it has no effect? But that could also be a follow-up, kind of easier to show BC behavior?

@berdir I think that sounds good for a follow up, would you mind creating an issue?

That's fair, created 📌 Hide promote/sticky fields on node types that do not use them Active and also pinged in #drupal-cms-development about reviewing the visibility and usage of those two fields in Drupal CMS recipes.

One thing I just realized is whether we want to update the description of the promote and sticky default value settings on the node type forms, currently it says "Users with sufficient access rights will be able to override these options.", I think it makes sense to extend that a bit and include something like "if they are enabled on the form display settings" or so, either as part of that sentence or an additional sentence. maybe also mention that some are not visible by default somehow.

I think that is a pretty good place to tell especially new site builders who click through those tabs to learn what's there that they might need to think about whether or not they should make those fields visible?

think it makes sense to extend that a bit and include something like "if they are enabled on the form display settings" or so, either as part of that sentence or an additional sentence. maybe also mention that some are not visible by default somehow.

I somewhat agree, but given this is a 20 year old issue, maybe we do that in another follow up? Because as we know wording can be hard to get right and would need a round of UX review.

+1 heavily as this is the first step I do with new content types

But seems like a behavior change that probably needs a CR.

Will keep on my radar so we can get this 20 year old issue through quickly.

Re #45. I see the concern about UX review, but unlike the umami suggestion, this change actively affects the experience for site builders and might be confusing. so I think it would be good to find a decent wording for that and do it here.

CR added

Updated the field description with the following:

As expected this complicates things quite a bit and is probably going to create a lot of churn on this issue. I think linking to the form display page is great for UX but complicates things a fair bit. Also what if field_ui is disabled? There is no manage form display so do we need to provide a different message again?

Anyway, it's there now so let's see what people think :)

Personally I’m a -1 for the description. Yes it does mention those fields are disabled but doesn’t mention why, so is it worth it?

Nice work!

I am also recommending to remove the description from the node edit page.

I was thinking to keep the description a bit more open, like "Control the visibility of those fields on the manage form display page". Also not linked, because you don't want people to jump away without saving, it also won't work yet on a new node type where it's most useful.

But anyway that's two -1 against my +1, so consider me overruled and lets revert this.

Reverted back to pre description changes. I asked the UX team to review this issue and they commented over here https://www.drupal.org/project/drupal/issues/987238#comment-16064921 📌 "Promoted to front page" for new content types should default to Un-Checked Needs work without any specifics on the description text. I'm happy to have a follow up to discuss further, especially if it's just some plain text added to the end as suggested in #51

Opened 📌 Discuss description text for Promoted to front and Sticky fields being hidden Active for discussion to continue there. Believe rest of the feedback has been addressed

Very basic test, created a new content type after applying the MR. Verified the fields were disabled.

Thanks for working on this. Should this be postponed on 📌 "Promoted to front page" for new content types should default to Un-Checked Needs work ? Because the default value for new content types is still promote=1. If this patch is applied and a new content type is created, it is set to promote automatically, but the field is hidden in form display, so it cannot be unchecked easily for content editors, unless brought back. I am not sure this is ideal.