Hide Promoted/Sticky fields by default in Form display

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.

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.

I think we should 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. We have done something similar with phpass and agreed elsewhere that this is a good way to gradually remove features from core.

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 know 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 #987238: "Promoted to front page" for new content types should default to Un-Checked or not (hopefully not).

I think this ticket and your MR will make #987238: "Promoted to front page" for new content types should default to Un-Checked 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 #3518044: Hide promote/sticky fields on node types that do not use them 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 not display a description on 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 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 #3519114: Discuss description text for Promoted to front and Sticky fields being hidden 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 #987238: "Promoted to front page" for new content types should default to Un-Checked? 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.

Yes let's postpone it on that issue.

Blocker is in

From what I can see, this should not affect Umami.

I like what I see in #53.

Rebase after blocker seems good!

We should generally include both before and after screenshots, and embed them in the IS.

I was going to ask for product signoff, but #33 seems like that at least indirectly. However, since we've changed approach since then (to something much lighter weight and more BC), I'm going to confirm that @lauriii is okay with the new approach.

I definitely find the new approach to be the least disruptive proposal so far, and it's minor-safe with no need for an upgrade path etc. (Since sites own their config.)

Agreed on not adding a lengthy description; that would be a usability regression. (We already spend a lot of time deliberately removing as many descriptions as possible from core fields, so let's not add more.)

Should we also change the default form display of these for the page content type on new sites? (Meaning, change the default config, but no upgrade path, since once the content type is installed, it belongs to the site.)

It probably makes sense to leave article as it is regardless since the front page promotion is one of its "features".

@xjm: I think you mean #987238: "Promoted to front page" for new content types should default to Un-Checked. we did that and this was postponed on that. Ah no, I misread. I think changing standard profile makes sense, but I think that's a separate issue.

> We already spend a lot of time deliberately removing as many descriptions as possible from core fields

I think what we're doing is removing bogus/technical descriptions from entity fields that are exposed to editors. This is the description on the node type settings form, which explicitly states that users with enough permissions can override those checkboxes. The first sentence in the screenshot in #48 is in HEAD now. Except with the new default config, they no longer can. I'm fairly certain that site builders *will* be confused about this.

But I'm also not going to try and convince anyone about this. I like this change and it won't affect me and we can always add such a description later.

I think this is fine. I still find this feature as something we should try to remove but given that removing these fields is pretty difficult, our time is probably better spent elsewhere.

Thanks @lauriii and @berdir.

I am okay with a followup for my suggestion about changing the default of pages, and a bigger followup for #63 makes sense as well. Once those followups are added this can be moved straight back to RTBC.

Thanks!

Added #3538654: Hide promote/sticky fields for page content type on new sites - @xjm please confirm the scope of this issue. It's not clear where you want to hide them (there's many places in core).

Added #3538655: Remove promote/sticky fields from Node - I have no idea how this is doable, @lauriii please add notes if you have ideas.

Back to RTBC.

Saving nearly 20 years' worth of issue credits. (‼️)

I made some small edits to the CR, and did one final round of manual testing.

Committed to 11.x and published the CR. This is only the second issue I've ever committed with a five-digit node ID, and the first I've ever committed with killes attributed. (For those that don't know, killes was the Drupal 4.7 release manager.)

I'm tagging this for the release highlights as it could be a nice bullet in a list of various site builder and content author UX improvements for 11.3.

Great work everyone!

This is amazing! My muscle memory to always manually hide these can finally go away!

My first Drupal site was done with Drupal 4.x… a long time ago!

It’s nice to see the discussion evolving and the progress we made.