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

I see a "promote" field but not a "promoted" field in 6.2.
If you mean the "promote" field I think it used to mark a node as promoted to the front page.

Moving to 7.x

I think 'promote' and 'sticky' are both pretty lame as core features. They could be changed into fields that come with the main profile.

I think this is a great idea!

Some discussion about doing this has been discussed in issue #987242: The "Promoted to front page" checkbox doesn't do anything if the /node front page listing isn't used.

Time to close. This is a duplicate now. See previous comment as to where the main discussion is.

I would rather go with this issue, as I do not remember ever using the "promote" and "sticky" options from the node entity, and I have started using Drupal when this issue was created.

If such feature is needed on a Drupal site, then I suggest using the flag module as replacement.

- Forum module will be removed.
- The default front page should not be a listing page (in 2022).

So I guess these base fields will not be used in core, therefore should be removed.

https://www.drupal.org/docs/user_guide/en/menu-home.html

I don't see how that's possible. This is data, we can't just remove it. We could attempt to convert them to configurable fields for existing sites, but that's pretty complex.

We use these fields quite often for custom views filter and sort option and I'm sure many others do that too.

I am using both features and many Drupal sites, from personal to entreprise sites.

Closing.

Reopening as it's not a duplicate and so that discussion can continue. As Berdir pointed out one possible option is to convert them to configurable fields which would allow sites that are using them to continue to do so. The motivating factor behind this is probably because it adds configuration burden for every content type when it's infrequently used for many developers, maybe there's a way to ease that burden without changing how the data is stored.

@damondt How can you say that these feature are used “infrequently” while Berdir says that “we use these fields quite often”.

I'm fine with keeping this open to discuss "maybe there's a way to ease that burden without changing how the data is stored.".

One simple option would be to have them hidden by default on form display but still configurable, then it's an opt in and you only need to configure them when needed. We can still keep it available for the default node types in the standard profile.

“Promote” and “Sticky” serve two different purpose and only “promote” gives some confusion.

For discussion, we should rename this issue to :

Discuss removing 'promote' field from {node} as the implementation is confusing on modern Drupal usage. But then again, that would be a duplicate of #987242: The "Promoted to front page" checkbox doesn't do anything if the /node front page listing isn't used, #2514794: Frontpage view is confusing when only one node is promoted to the default front page or #987238: "Promoted to front page" for new content types should default to Un-Checked.

“Sticky” is a well-known behavior on multiple platform and it must be kept as is.

With Twitter, any user can make a post sticky. With Mattermost, Discord and multiple CMS, to stick a post is common usage. With Drupal, that feature is often required by the clients when building a new page.

I am not confused by the features, we do not need to discuss that problem in this issue.
The implementation of these fields is simply not how it should be done in current Drupal.

I like the "hidden by default on form display but still configurable" plan which will allow current implementations to continue to work, and only add configuration burden on new sites for those who want to use the fields, like how other fields work. Are there other issues with the implementation we should discuss?

Cross-linking #514056: Move sticky, promote and user.blocked to flag field types in core. which I've just marked as duplicate.

The fields are a bit confusing, it's not the worst usability issue in core, but it's a bit redundant.

If we were adding node module now, we wouldn't have added these. The features that used to use them (forum) are on their way out or quite minor (default front page).

If we convert from base fields to configurable fields, it'll break custom code looking for the old properties unless we added a bc layer, and also be a performance regression for queries using them, and require an upgrade path both for the data and for views etc. Seems like a lot of work for little benefit.

They can't just be removed from core either, because there's sites using them with data, and because the front page + forum still use them (at least until they don't, but there's no alternative default front page issue that I know of).

I can see a couple of options:

1. Add a new 'Content flag fields' module that defines the fields via hook_entity_base_field_info_alter(), this would allow them to be removed from sites that don't want them entirely, and then potentially the module could be moved to contrib if that's decided (once there's a default front page replacement, forum removed etc.). The module would be a bit weird, although it'd make a decent hook_entity_base_field_info_alter() example. This module would also have to add/remove the compound indexes on install/uninstall.

2. Try to make single value configurable fields more performant in filters, #3276818: [META] Add support for JSON field queries in entity queries might be an option (and is more likely than materialized views in core, which hasn't, um, materialized in 15 years). At one point we were discussing allowing single option configurable fields to be stored on the base table, but that would be very complicated in the entity storage code, and I don't think there's any good solution for compound indexes doing it this way.

#1 is a route to retiring them from core #2 is a route to bringing them up to date with the rest of core (and probably moving them to the standard profile-only for new sites, bc for existing sites would just be the new configuration).

#18.1 seems like a good idea. I thought previously that creating new sub-feature modules is a reasonable way of carving out features from core that we want to retire, so contrib can look after them if they wish, or they can just be removed gracefully.

> This module would also have to add/remove the compound indexes on install/uninstall.

Not just indexes, it would also have to install/uninstall the field storage definitions themselves, except in the initial case where the module is automatically installed and the fields are "migrated".

The features that used to use them (forum) are on their way out or quite minor (default front page).

They are actually also in use on blogs where a publisher wants to make a post or a limited number of posts sticky on top of the page. Removal of those node flags will break those sites, unless there is a clear “contrib” replacement.

@xmacinfo yes that's a site feature, I'm pretty sure I have sites that use the fields as well. If you just need a quick boolean flag on a node, they're more convenient and more performant than using flag or entityqueue or creating a boolean field in field UI. But they're not used as much by core as they were fifteen years ago. For example even though a blog might well use 'promoted', are they also going to use 'sticky'?

For example even though a blog might well use 'promoted', are they also going to use 'sticky'?

As a matter of fact, yes. For example, a contest post (or any other content) is “sticky” on top until the contest is over. Without the “sticky” flag, publishers will need to edit the publication date to move the item to the top, which does not make sense.