"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.

Overall this looks good but I think we can remove these overrides now?

core/profiles/demo_umami/config/install/core.base_field_override.node.page.promote.yml
core/profiles/standard/config/install/core.base_field_override.node.page.promote.yml
core/recipes/page_content_type/config/core.base_field_override.node.page.promote.yml

These seem to exist to set the promote default for these content types to false - but it's now false by default, so we shouldn't need to ship them any more?

Also I'm intrigued why the Umami performance stats have such an improvement; I don't see why just flipping the default results in so many fewer queries?

These seem to exist to set the promote default for these content types to false - but it's now false by default, so we shouldn't need to ship them any more?

Good catch, I've removed them.

Also I'm intrigued why the Umami performance stats have such an improvement; I don't see why just flipping the default results in so many fewer queries?

I would assume it's something to do with the base_field_overrides not being needed anymore since they match the default, I can try to dig into it further if needed.

I don't really understand these performance tests tbh, OpenTelemetryNodePagePerformanceTest was giving 450 query count on cold cache, it was passing locally then it jumped back up to 457 in CI, so I changed it locally and it still passed. I'm not even sure what I changed.

One tiny comment on the MR.

acbramley → credited mstrelan → .

Crediting @godotislate and @mstrelan for helping figure out the query count discrepancy.

Because we reversed the default, Demo Umami needed base field overrides for article and recipe content types. Without this, one of the articles had dropped off the homepage (I guess we have no tests for the actual content displayed on the umami homepage). This is what dropped the query count so drastically.

Feedback appears to be addressed

#239 explained the diff weirdnesses with Umami config that were making me scratch my head, thanks!

Saving reviewer credit for @longwave. Also looks like I had missed @smustgrave's changes and nontrivial rebase back in May so saving credit for that too.

longwave → closed merge request !11608

@acbramley thanks for the explanation, it did feel like the Umami change was too good to be true here, and it turns out that was correct; glad we did not break that - and technically it is tested here indirectly, because we spotted it via the performance tests!

So, after 14 years and 240 comments by many contributors, I am happy to finally be committing what is really a one line change:

--- a/core/modules/node/src/Entity/Node.php
+++ b/core/modules/node/src/Entity/Node.php
@@ -357,7 +357,7 @@ public static function baseFieldDefinitions(EntityTypeInterface $entity_type) {
       ->setLabel(t('Promoted to front page'))
       ->setRevisionable(TRUE)
       ->setTranslatable(TRUE)
-      ->setDefaultValue(TRUE)
+      ->setDefaultValue(FALSE)

One small step towards (possibly) removing this feature in the future!

Committed 6bfec5b and pushed to 11.x. Thanks!

Also finalised and published the change record.

Managed to crosspost with @xjm while we were both reviewing, committed her comment improvement as a followup.

Also a potential highlights thing, especially if we end up with other site builder UX tweaks.

Great to finally get this in, thanks both.