"Promoted to front page" for new content types should default to Un-Checked

This issue still seems relevant, I'm surprised this default comes all the way from Node's field default value.

We'll need to start with a reroll of the changes onto an MR.

I also noticed that we have base_field_override config in the standard install profile that says the default value of this should be 0 but that doesn't seem to actually be used on install.

Based on #29338: Hide Promoted/Sticky fields by default in Form display → , we should be marking this ticket as “Outdated” or “Duplicate”.

@xmacinfo no - this is different. This is making the checkbox on the NodeType form itself to be unchecked.

Yes, but if we remove the checkboxes on new install, we do not need to worry about the checkbox being unchecked.

CR created https://www.drupal.org/node/3517642 →

We need an upgrade path here though unfortunately.

Currently if you:
1. Install Standard profile on 11.x
2. Check out this branch
3. Clear cache
4. Notice the Article node type no longer defaults to Promoted. Page correctly still defaults to Not Promoted because Standard ships with base_field_override config

Yes, but if we remove the checkboxes on new install, we do not need to worry about the checkbox being unchecked.

We aren't removing checkboxes, we're hiding them. It actually makes more sense to default to unchecked once we hide the fields, otherwise new sites will be creating "promoted" content without the checkbox even being visible. We have to do things in small steps (see the history of this issue) otherwise we'll never get anywhere :) Just look at how many tests in core assume things are promoted by default!

Added a basic upgrade path, needs tests though.

I added an update path test.

So I tested it out and pretty basic, creating a new content type and the promoted to front checkbox is unchecked

Hiding old patches
Tweaked the CR just slightly with an image for the visual people out there.

I imagine this may break some contrib tests (hopefully not a lot) but seems like a right step.

We discussed this issue briefly at 📌 Drupal Usability Meeting 2025-04-11 Active . That issue will have a link to a recording of the meeting. We were primarily discussing the related issue #29338: Hide Promoted/Sticky fields by default in Form display → .

We agree that this is a good idea. Thanks for working on this issue!

For the record, the attendees at the usability meeting were benjifisher, rkoller, and simohell.

There is still one @todo in the MR - do we need to discuss that? I do not see it mentioned anywhere in this issue. Thanks!

Yea I think we probably do need to batch it. Know it's not likely but I have worked with sites that had 100s of content types

Updated code to use the config updater service.
There were unrelated functional javascript test failures. Triggered the job again.

Believe that was the last outstanding question.

Thank you everyone!

Can we do a clean-up of the Issue tags? I think some of the tags are not relevant anymore.

The CI tests passed, but just because the "Validatable config" test is allowed to fail.

TL;DR: I think it is worth looking at that test, but I think it is OK for it to fail for this issue.

I am not familiar with that test, but it seems to compare the results of

vendor/bin/drush config:inspect --statistics

on the target branch (11.x) and on the feature branch.

On the target branch, the installs drush and the config_inspector module. Then it installs the Standard profile and enables all core modules (except sdc, which is obsolete) and config_inspector. On the feature branch, the test first applies database updates.

The test fails if any of the statistics are lower on the feature branch than they are on the target branch.

I went through similar steps, but instead of vendor/bin/drush config:inspect --statistics, I exported configuration. The only difference between the two branches is that the feature branch includes core.base_field_override.node.article.promote.yml. It looks as though this config entity is not fully validatable: the schema is in core/config/schema/core.data_types.schema.yml, and it is not marked as FullyValidatable: ~. So it makes sense that the statistics go down and the test fails.

Re #225 yes this is expected since we're adding new config.

The Needs Review Queue Bot → tested this issue. It fails the Drupal core commit checks. Therefore, this issue status is now "Needs work".

This does not mean that the patch necessarily needs to be re-rolled or the MR rebased. Read the Issue Summary, the issue tags and the latest discussion here to determine what needs to be done.

Consult the Drupal Contributor Guide → to find step-by-step guides for working with issues.

Rebased

Rebased again and fixed the performance tests.

Saving mentor credits as per #33.

I updated the issue credit, removing credit for a number of old rerolls where the contributor did not add anything else to the issue. I left credit for a couple people who were doing the reroll in the context of a mentored event as their first contribution. I also added credits for a number of reviewers.

I'm not able do do the review myself at the moment, but at least having the crediting in order should save some time.

The Needs Review Queue Bot → tested this issue. It no longer applies to Drupal core. Therefore, this issue status is now "Needs work".

This does not mean that the patch necessarily needs to be re-rolled or the MR rebased. Read the Issue Summary, the issue tags and the latest discussion here to determine what needs to be done.

Consult the Drupal Contributor Guide → to find step-by-step guides for working with issues.

Rebased. Restoring RTBC.