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

Drupal 7 now includes the ability to specify default publishing options using the configure content types interface.

This is not fixed in Drupal 7. When creating a new content type, the "promoted to front page" checkbox is still checked by default, but this issue proposes having it unchecked by default.

Reopening and moving to Drupal 8.

Well, if you set the default value to FALSE, some people would argue that it should be TRUE. People will always have different needs, and I think the current defaults are sensible in most cases.

I think the solution to this would be to allow the site builder to modify the default content type settings (not only publishing status) so that next time he adds a new content type those settings would be used. This might be accomplished by adding a "settings" menu tab to "admin/structure/types"

If you agree, we might change the issue title to reflect this.

FYI: There is now a contributed module that allows you to change the default content type settings:
Content Type: Extras.

Agree with approach in #4.

While I agree with #4, I would like some actual data to prove that most people want the check box un-checked. I for one would love to see it default to un-checked for everything but articles. How many people are going to promote the about us page to the front page? Also "Page" content types don't work well for the default /node home page long list of articles.
Thoughts? Someone feel like putting up a poll somewhere or some UX testing? It seems to me that most sites are not going to use /node for their home page and will use some other mechanism (workflow, taxonomy, panels) to determine home page content.

book.install:

  // Default to not promoted.
  variable_set('node_options_book', array('status'));

forum.install:

  // Forum topics are published by default, but do not have any other default
  // options set (for example, they are not promoted to the front page).
  variable_set('node_options_forum', array('status'));

You might consider removing these statements, as with your patch they are now the default for a new node type.

Re-rolled patch from #11 to fix failing book module test.

Kim

Marking needs review

I think that this needs another review, but +1 from me.

Also tested this patch, works fine!

I think this is good, but still needs some more work.

1. Removing the Book module part of the patch looks like working around the failing test rather than fixing it. We need to find the root cause.
2. With the patch applied, I still see one place in node.module that uses array('status', 'promote') as the default value of the variable. That needs to be changed also. I would say this is a good candidate for the actual cause of the Book module failing test...
3. Don't we need an update function to explicitly set these variables, for sites that were relying on the previous default behavior?

We do need update functions

Example:

+  // Default "Article" to be promoted.
+  variable_set('node_options_article', array('status', 'promote'));

This is the code that will b in a D8 install (the variable will be set, in D7 sites upgraded to D8 the variable will not be set, and will fall back to using node.module's default of not promoted.

Edit:

The variable * may * not be set, so the update function should check for that and only set the variable if it is not set. I think we only need this for Article, as I believe it is the only promoted by default. I'm not sure if install profiles can implement hook_update_N(), if so it should goo in standard.install.

#20 applies clean and works as expect. No checkbox. Just need update function and good to go I think.

The variable * may * not be set, so the update function should check for that and only set the variable if it is not set. I think we only need this for Article, as I believe it is the only promoted by default.

"Article" might be the only example in core where this can happen, but there could be issues with non-core content types also. Basically, this scenario can arise for any content type that was programmatically installed (by a module or install profile) and did not set this variable, and then the site admin never saved the edit form for this content type so it never got saved to the database that way either.

So I think the update function needs to loop through all content types and check each one using the method you described.

Marked #1005244: Sensible default workflow options for new node types as a duplicate of this issue.

I'll attempt to make the changes to the update function as described in Comment # 23.

Hm. Without something views-like in core, this strikes me as a rather bad idea. All nodes will default to ending up in the node orphanage. :\ I wonder if we should postpone this on #1210366: Per-bundle node listing pages, blocks, feeds..

Also, I don't think this behaviour change is back-portable to D7. For better or worse, this behaviour has been baked in not only for 10+ point releases of D7 but since time immemorial. Doesn't mean we shouldn't change it in D8, but it does mean it's a fairly jarring difference that we shouldn't just spring on people during a stable release.

I think the node orphanage problem needs to be solved in a way that makes more sense than "we'll just put everything on the home page by default"

Well I certainly can't argue with that. :) Thanks for removing the backport tags. I think as long as this is not on the table for D7, it can be evaluated on its own merits in D8-land.

PS: And with ponies??

Reading this I could not find an explanation of what 'the node orphanage' is supposed to mean. What does it mean? Thanks :)

I think the "node orphanage" is where you create a node and can't find it anywhere on your site... But, I thought that was a Drupal 6 problem, pretty much dealt with in Drupal 7?

Either way, this issue is definitely Drupal 8 only.

The node orphanage is admin/content/node. Users' first encounter with the node orphanage is when they create a Basic page without a menu attached. You go through the steps to create a node, then navigate away, then your content is lost. Befuddled, you go wandering around looking for it, perhaps re-creating your content again since it seems like the system ate it. Finally, in desperation you click "Find content" where you will see your content sitting in amongst the other poor pieces of content with no home and no family. *queue the tragic cello music*

@aLearner is about to come up with a freakin' patch! :)

I'm grateful to sun for helping me create the patch step-by-step. The credit for the patch truly goes to sun.

Special thanks to jenlampton, webchick and xjm for their support throughout this process.

Hello,

Here's an update detailing what I did to manually test the patch. I've broken the post up into several sections:

[a] Setup
[b] Pre-Patch Application Observations
[c] Application of Patch
[d] Post-Patch Application Observations
[e] Update
[f] Post-Patch Application and Update Observations

Setup

I installed a fresh copy of D8. This included dropping all the tables in the database. Then, I proceeded to reset the git repo by typing the command

git reset --hard

from the root directory of the D8 installation.

Pre-Patch Application Observations

[1] Then, on the site, I navigated to

Content --> Add Content --> Article --> Publishing options

I noticed that the following

Published was checked
Promoted to front page was checked
Sticky at top of lists was not checked

[2] I then clicked on 'Add content' (left-hand corner) and then on

Basic page --> Publishing options

I noticed the following

Published was checked
Promoted to front page was not checked
Sticky at top of lists was not checked

[3] Then I clicked on

Structure --> Content types --> Add content type

I filled up only the 'Name' field with the following name

Content Type 1

and hit

Save content type

at the bottom of the screen.

Then I navigated to

Content --> Add Content --> Content Type 1 --> Publishing options

I observed the following

Published was checked
Promoted to front page was checked
Sticky at top of lists was not checked

I then scrolled back up and filled up the following title

A Sample of Content Type 1

and then scrolled back down and hit 'Save'.

[4] Using the steps detailed in [3] I created another content type and called it 'Content Type 2'.

Then I navigated to

Content --> Add Content --> Content Type 2 --> Publishing options

I observed the following

Published was checked
Promoted to front page was checked
Sticky at top of lists was not checked

I then scrolled back up and filled up the following title

A Sample of Content Type 2

Then, I unchecked

Promoted to front page

and then scrolled back down and hit 'Save'.

This marked the end of
[a] Setup
[b] Pre-Patch Application Observations

Application of Patch

I took the following steps to apply the patch. From the root directory of the D8 installed, I typed in

wget http://drupal.org/files/drupal8.node-type-promoted.33.patch

and then

patch -p1 < drupal8.node-type-promoted.33.patch

I noticed that the patch was successfully applied.

Post-Patch Application Observations

[1] Then, on the site, I navigated to

Content --> Add Content --> Article --> Publishing options

I noticed that the following

Published was checked
Promoted to front page was not checked
Sticky at top of lists was not checked

Result: 'Promoted to front page' went from being checked to not checked for 'Article'.

Question 1: Is this a problem?

[2] I then clicked on 'Add content' (left-hand corner) and then on

Basic page --> Publishing options

I noticed the following

Published was checked
Promoted to front page was not checked
Sticky at top of lists was not checked

Result: There was no difference after the patch was applied.

[3] I then clicked on 'Add content' (left-hand corner) and then on

Content Type 1 --> Publishing options

I noticed the following

Published was checked
Promoted to front page was checked
Sticky at top of lists was not checked

Result: There was no difference after the patch was applied.

I then clicked on 'Content'

A Sample of Content Type 1 --> Edit --> Publishing options

I noticed the following

Published was checked
Promoted to front page was checked
Sticky at top of lists was not checked

Result: There was no difference after the patch was applied.

[4] I then clicked on 'Content'

A Sample of Content Type 2 --> Edit --> Publishing options

I noticed the following

Published was checked
Promoted to front page was not checked
Sticky at top of lists was not checked

Result: There was no difference after the patch was applied.

[5] Then I clicked on

Structure --> Content types --> Add content type

I filled up only the 'Name' field with the following name

Content Type 3

and hit

Save content type

at the bottom of the screen.

Then I navigated to

Content --> Add Content --> Content Type 3 --> Publishing options

I observed the following

Published was checked
Promoted to front page was not checked
Sticky at top of lists was not checked

Result: 'Promoted to front page' went from being checked to not checked.

This marked the end of
[c] Application of Patch
[d] Post-Patch Application Observations

Update

To perform an update, I typed in

http://localhost/myDrupalInstallDirectory/update.php

then I clicked on 'Continue'. I saw

1 Pending Update

with the following description

node module

8001 - Change default promoted flag of node types to disabled. The default for 'Promoted to front page' was changed from enabled to disabled. Since enabled was the implicit default previously, and may not have been explicitly configured as such, this update ensures that the old implicit default is still the default. @see http:drupal.orgnode987238

I then clicked on

Apply pending updates.

The update ran successfully.

Post-Patch Application and Update Observations

[1] Then, on the site, I navigated to

Content --> Add Content --> Article --> Publishing options

I noticed that the following

Published was not checked
Promoted to front page was checked
Sticky at top of lists was not checked

Result:
'Published' went from being checked to not checked for 'Article'.
'Promoted to front page' went from being not checked to checked for 'Article'.

Question 2: Is this a problem?

[2] I then clicked on 'Add content' (left-hand corner) and then on

Basic page --> Publishing options

I noticed the following

Published was checked
Promoted to front page was not checked
Sticky at top of lists was not checked

Result: There was no difference after the patch was applied.

[3] I then clicked on 'Add content' (left-hand corner) and then on

Content Type 1 --> Publishing options

I noticed the following

Published was checked
Promoted to front page was checked
Sticky at top of lists was not checked

Result: There was no difference after the patch was applied.

I then clicked on 'Content'

A Sample of Content Type 1 --> Edit --> Publishing options

I noticed the following

Published was checked
Promoted to front page was checked
Sticky at top of lists was not checked

Result: There was no difference after the patch was applied.

[4] I then clicked on 'Content'

A Sample of Content Type 2 --> Edit --> Publishing options

I noticed the following

Published was checked
Promoted to front page was not checked
Sticky at top of lists was not checked

Result: There was no difference after the patch was applied.

[5] Then I clicked on

Structure --> Content types --> Add content type

I filled up only the 'Name' field with the following name

Content Type 4

and hit

Save content type

at the bottom of the screen.

Then I navigated to

Content --> Add Content --> Content Type 4 --> Publishing options

I observed the following

Published was checked
Promoted to front page was not checked
Sticky at top of lists was not checked

Result: There was no difference after the patch was applied.

This marked the end of
[e] Update
[f] Post-Patch Application and Update Observations

and concluded my testing.

The two outstanding questions revolve around the behavior of 'Article'. Hopefully, this can be cleared up.

Hi, my observations were:

1) Installed Drupal8.x.dev
- Content Type Article Published=Yes Promoted=Yes
- Content Type Basic Published=Yes Promoted=No

2) Apply Patch http://drupal.org/files/drupal8.node-type-promoted.33.patch

3) Reports - Status - Update DB
- Content Type Article Published=NO Promoted=Yes
- Content Type Basic Published=Yes Promoted=No

4) Create Content Type Test
- Content Type Test Published=Yes Promoted=No

Summary = The patch is accidentally changing existing Content Type Article from Published to NOT Published, so we need to look at the patch code/instructions. Other than that it seems to work...:)

Dig1,

Thanks very much for your help. Also, thank you for confirming that 'Article' is indeed behaving not as expected.

Thanks all. Seems this needs work :)

Thanks for all the testing.

Question #1 seems like expected behavior since the update function had not run yet. So it does seem like the only problem is that the default is being changed from published to unpublished. I guess this can be fixed by setting $options['status'] in the update function?

Another thought:

+ *
+ * @see http://drupal.org/node/987238

Normally there's no reason to @see the issue unless there's some specific discussion that needs to be referenced, which I don't think is the case here? However, I see you copied this directly from node_update_8000() which has a @see also... Honestly, it should probably be removed from both places - both update functions are pretty straightforward and in my opinion the code comments explain the rationale for them just fine on their own :)

yoroy,

Thank you for your input.

David_Rothstein,

Thank you for your insight. I'll make the changes as you suggested. Thanks again.

I do have one question though.

Question #1 seems like expected behavior since the update function had not run yet.

But do we really want 'Article' to change its behavior when the patch is applied? I thought that, by default, 'Article' should always have 'Promoted to front page' checked.

Note: My question was answered by David_Rothstein on IRC. Thank you.

OK. Per David_Rothstein's suggestion, I added in the line

$options['status'] = 'status';

in the function

function node_update_8001

A big thank you to David_Rothstein for all his help.

Also, a shout-out to cweagans and volkman for their assistance in creating the patch and interdiff files.

Hi,

These are the steps I took to test my patch:

[1] Installed Drupal8.x.dev

[2] Went to

Content --> Add Content --> Article --> Publishing options

Noted that

Published was checked
Promoted to front page was checked
Sticky at top of lists was not checked

[3] Applied the patch located at

http://drupal.org/files/drupal8.node-type-promoted.43.patch

[4] Updated the site by navigating to

mySiteURL/update.php

and applied the one pending update.

[5] Went to

Content --> Add Content --> Article --> Publishing options

Noted that

Published was checked
Promoted to front page was checked
Sticky at top of lists was not checked

Result: There was no difference after the patch was applied. This is the expected behavior. The bug seems to be fixed.

[6] Then I clicked on

Structure --> Content types --> Add content type

I filled up only the 'Name' field with the following name

Content Type 1

and hit

Save content type

at the bottom of the screen.

Then I navigated to

Content --> Add Content --> Content Type 1 --> Publishing options

I observed the following

Published was checked
Promoted to front page was not checked
Sticky at top of lists was not checked

Result: 'Promoted to front page' went from being 'checked' to 'not checked'. This is the expected behavior.

Conclusion

It would be great if someone could-cross check my work to make sure the bug is fixed.

Also, should we be also adding a line like

$options['sticky'] = 'sticky';

to make sure that this doesn't have the same bug caused by not having the line

$options['promote'] = 'promote';

previously. So, I'm asking if the if-conditional inside the function

function node_update_8001() (around Line # 535)

located in the file

core/modules/node//node.install

Should look something like this

...
 if (!isset($options)) {
      $options['promote'] = 'promote';
      $options['sticky'] = 'sticky'; // Wondering if this line should be included just like the above line was added
      $options['status'] = 'status';
      variable_set("node_options_$type", $options);
    }
...

I reviewed this latest patch and tested it, and I think it's ready to go. I don't think we need a line for $options['sticky'] since that was not previously set by default (only 'status' and 'promote' were).

The only remaining question is the "node orphanage" issue mentioned above. I don't think we should postpone this issue on that (we need other issues to solve that problem either way; probably something like #504012: Use a queue for node create/update indexing is at least part of the solution?). It's less of a problem in Drupal 7 than it was in Drupal 6, and hopefully it can be even better in Drupal 8... Nonetheless, I didn't mark the patch RTBC yet because that discussion didn't seem quite finished.

Oh, as an aside... if you have the "interdiff" command line tool installed on your system (it's easily available in Linux for example), you can generate an easier-to-read interdiff file using that, e.g. interdiff -p1 patch1.patch patch2.patch > interdiff.txt

David_Rothstein,

Thank you for testing the patch. Thank you also for answering my question. This makes sense. I'm glad you think that the patch is RTBC.

I don't really understand the orphanage issue but if there's something I can do to help, I'm glad to do it.

Thanks for the pointer regarding the 'interdiff' command line too. I do have it installed. Next time I'll use the command you suggested to generate the 'interdiff.txt' file.

+++ b/core/modules/node/node.installundefined
@@ -525,6 +525,28 @@ function node_update_8000() {
+ * Change default promoted flag of node types to disabled.

This seems to disagree with the rest of the comment, and the function itself. Doesn't the function actually set the promoted flag of existing not types to enabled?

I think you're right, the comment wasn't correct. The patch attached has the correct comment. I also had to rewrite the patch because a lot has changed since February.

Mmmm, strange... Even if I didn't touch the aggregator module, the test fails. I'm a newbie, anaybody any suggestions how to fix this ? Thx!

#48: drupal8.node-type-promoted.48.patch queued for re-testing.

It has something to do with the function node_update_8004() -- it looks like testbot objects to the mysql update as it is making a change that is affecting the RSS feed items (which makes sense, as things that weren't promoted before are promoted now.)

Not sure how to go about reassuring it, though...

re-roll

#56: drupal8.node-type-promoted.56.patch queued for re-testing.

This patch applied fine locally and on simplytest.me so I'm confused why it's failing testing here.

Oops, sorry, switching back to needs work.

Ah, the node update ID was wrong.

Attaching a new patch and interdiff, since it was just one character that changed.

Rerolling patch.

Re-rolling the #64.

Re-applying a tag.

#67: drupal-node_type_promoted-987238-67.patch queued for re-testing.

I don't know why but this code makes to fail the test :

diff --git a/core/modules/node/lib/Drupal/node/NodeFormController.php b/core/modules/node/lib/Drupal/node/NodeFormController.php
index 4bc59fe..986c50d 100644
--- a/core/modules/node/lib/Drupal/node/NodeFormController.php
+++ b/core/modules/node/lib/Drupal/node/NodeFormController.php
@@ -28,7 +28,7 @@ class NodeFormController extends EntityFormController {
-    $node_options = variable_get('node_options_' . $node->type, array('status', 'promote'));
+    $node_options = variable_get('node_options_' . $node->type, array('status'));

Added new patch that change update_N() and remove this change, But i think that this needs work.

Here's a new patch now that #111715: Convert node/content types into configuration has landed.

Only the article type is promoted by default, any new content types added will default to not promoted.

Manual testing seems OK, let's see...

Can I just change the AggregatorTestBase.php test?

Sorry, messed up interdiff in #76. Here it is again.

Bump. (I was actually looking for the issue that disabled comments on new content types but that is solved now with comments-as-fields :-)

This issue here would still be a nice tweak towards more sensible defaults.

(Merging "node system" and "node.module" components for 8.x; disregard.)

I am working on rerolling this patch to latest version of 8.x.

I reroll this patch to latest version of drupal 8. By default add content type form Promote to front checkbox is un checked, but for article content type it will be checked default.

I am working on updating the issue summary by following the instructions at https://drupal.org/contributor-tasks/write-issue-summary

May be we don't need this to be changed in tests.

Setting to needs review for testbot.

90: 987238-Promoted to front page should be false by default.patch.patch queued for re-testing.

90: 987238-Promoted to front page should be false by default.patch.patch queued for re-testing.

90: 987238-Promoted to front page should be false by default.patch.patch queued for re-testing.

This issue needs an summary update, here the instructions:
https://drupal.org/contributor-tasks/write-issue-summary

I'm working on this.

Here's a new patch. The path changed from /core/modules/node/lib/Drupal/node/Entity/NodeType.php to /core/modules/node/src/Entity/NodeType.php

Seems like the tests will have to be updated to match — they must assume promote to front page being on.

Working on fixing the test.

Un-assigning from myself as I don't have enough time to fix this today. The Aggregator is working functionally but failing tests. The thinking is that it's using rss.xml, but content isn't going there automatically because nodes are no longer auto-promoted on new content types.

I will attempt to look into the problem at the drupalcon sprint.

Found a way to patch this. Thanks Dan!

Last patch combined my patch with the previous one by mistake. Here is the patch again.

Trying to see if using FALSE instead of 0 as an argument makes a difference in having this patch pass the automated tests.

As D8WTF! at drupalcon sprint and footwork in #105 suggested, some of the automated tests need maybe to be rewritten?

Yes, you'll need to make an adjustment to the Aggregator test base, but it should be a small one.

Aggregator's tests rely on the RSS feed generated by the default front page. It's the easiest way to get an RSS feed for import testing. Of course, it's relied on the nodes it creates being automatically promoted to the front page. This change is disrupting that.

Check out createSampleNodes() in /core/modules/aggregator/src/Tests/AggregatorTestBase.php. Add a line to the $edit array which checks the Promote to Front Page checkbox. Then I bet everything will start passing.

I've reviewed the path from #113 and I thought that it is a little bit workaround solution. So I've decided to search for a better place for setting the promotion field value.

I went through the first few comments in this thread and the recent patches. It seems that we are not caring about the defaults on new node type forms (or I might have missed a comment about that).

Anyway, here is the patch with a test change for aggregator. It fixes various tests in aggregator. I hope it fixes all. More fixes later.

doing https://www.drupal.org/contributor-tasks/update-allowed-beta
evaluating https://www.drupal.org/contribute/core/beta-changes

also removing novice tag per https://www.drupal.org/core-mentoring/novice-tasks
this is a bit more difficult that a straight forward novice task.

Adding related issue #2350013: Descriptions for Promotion Options are too technical

This issue is like time travelling :)

This issue would still be nice to include in D8 I think. Patch attached.

This should fix the remaining tests.

I'm filling this comment on behalf user PawelGorski87, who has some problems with form submission (untrusted user). Pawel is working on reported problem.

Patch #127 don't apply with latest codebase 8.0.x branch. Patch needs re-roll. I'm working on it.
git apply -v /c/patch/987238-127.patch

Checking patch core/modules/aggregator/src/Tests/AggregatorTestBase.php...
Checking patch core/modules/node/src/Entity/Node.php...
Checking patch core/modules/node/src/Tests/Views/NodeLanguageTest.php...
Checking patch core/modules/taxonomy/src/Tests/RssTest.php...
 error: while searching for:
  protected function setUp() {
     parent::setUp();
    $this->admin_user = $this->drupalCreateUser(array('administer taxonomy', 'by
 pass node access', 'administer content types', 'administer node display'));
     $this->drupalLogin($this->admin_user);
     $this->vocabulary = $this->createVocabulary();

Rerolled

I fixed last patch version. Patch tested with latest codebase 8.0.x branch.

Updated the test with the changes from #2396717: Clean-up taxonomy module test members - ensure property definition and use of camelCase naming convention

+++ b/core/modules/taxonomy/src/Tests/RssTest.php
@@ -42,7 +42,8 @@ class RssTest extends TaxonomyTestBase {
-    $this->drupalLogin($this->drupalCreateUser(['administer taxonomy', 'bypass node access', 'administer content types', 'administer node display']));
+    $this->admin_user = $this->drupalCreateUser(array('administer taxonomy', 'bypass node access', 'administer content types', 'administer nodes', 'administer node display'));
+    $this->drupalLogin($this->admin_user);

Why is this changed? Is there a admin_user property on the class? This does not look related to the issue on hand either.

@hussainweb You are correct, nice catch :). This change was introduced in #131 in a reroll.

I changed the code back to its current version and added the 'administer nodes' permission that is necessary for admins to be able to promote a node to the frontpage.

Here are screenshots of the behavior--

Add new content type without patch:

Add new content type with patch:

Note this patch also changes the default behavior of the Article content type on a Standard install to not posting on the front page. I'm not sure if that's intentional or not.

Here's Add Article without patch:

And Add Article with patch:

Should we bump this forward to 8.1.x or is it still an 8.0.x contender?

At any rate, this needs a reroll.

Also - did we end up getting any data on majority preference for the default?

Here's the reroll to the 8.1.x branch.

Sorry, the status.

Tagging.

Manual test.

Needs work.

Article promotion options should still default to promoted to front page.

But the new content type no longer has that option ticked, which is great!

Updated the title to make it clear this change is for NEW content types.

@kattekrab but that's what is required. isn't it?

Content types should define default options on creation. If one content type has been created previously have this options yet configured.

:)

@alvar0hurtad0

Not quite.
This is about changing the default setting when we create NEW content types.

The existing content type, "Article" should stay as it is. When new users start with Drupal, they are encourage to add content to their site. It is likely to be confusing if that new content doesn't appear on the front page.

The patch above changes the default setting for the existing out of the box "Article" content type, and it should not do that.

It should only change the default setting when creating a new content type.

Thanks for rerolling the patch though! It was great to be able to test it again after so long.

To make a product management call, the issue summary needs an actual problem/motivation. ;) The table mentions "usability" as the main reason for this proposed, but I don't quite understand that rationale.

I totally agree that this checkbox is a kludge, but it's arguably a useful one. It means new Drupal users always have a way to find the content that they posted; they don't disappear into the ether, only accessible at admin/content (which only admins have access to). Without some kind of replacement (e.g. a View that automatically creates tabs per content type?) if this checkbox is unchecked by default, it seems like the workflow becomes: 1) post a piece of content, 2) navigate away, 3) PANIC because your content is gone.

I'm sure I'm missing something, so let's get the full rationale in the issue summary.

Ok - I think we need some kind of evidence to support opinion.

Frankly - I feel this one is 50/50... I don't have a strong sense that I always prefer the default to be other than it is, some probably do, other probably want the default to promote to front page.

There were other issues though about whether the "promote to front page" flag itself makes sense...

I know I've used it as a quick and dirty way to do stuff in views in places other than the front page.

So... before we update the Issue Summary - should we conduct a quick sitebuilder poll?

When creating a new content type, would you prefer to see the "Promote to front page" checkbox on or off?
A. On! I like to see all new content appear on the front page so I can check it is ok.
B. Off! I like to choose whether or not new content should appear on the front page.

Or something like that...

The patch did not apply cleanly.
So had to re-roll it.
Uploading the re-rolled patch.

Uploading the rerolled patch again for testing

Go go Drupal testbot

Whoops, sorry for the cross-post. Back to needs work since it didn't apply.

The patch is working fine on my local.. I am not able to get why it is failing the testings

It could be because the branch where this patch has been tested.

I just queued the test in the 8.1.x branch let's see what the testbot says.

I viewed the output at the console..Its probably due to path conflict..Let's see whether this modified patch works....

Uploading the rerolled patch with changes..

Here’s a highly unscientific poll: https://twitter.com/royscholten/status/707697307173720065

I think this shows that it’s enough for only the default Article content type to have promoted on by default.

Verified the patch ' Unchecked-promoted-front-page-987238-170-8.patch' in comment #172 and the observations are as follows:
1.Warnings are displayed while applying the patch
2.Even after the patch is applied 'Promoted to front page' checkbox is still by default selected on Add Content type and Add Article page
Attached snapshot for reference.

Hi Truptti,
The patch worked fine for me

I applied the patch on a clean drupal install...It works... do not know why 3 tests fail..looking into it

We also need to update the default value in few failing testsCommentFieldsTest, ContextualDynamicContextTest, FrontPageTest

@yoroy ++

Hi,
i try to fix the failing tests. Hope it works!

looks good

We still need a "Needs product manager review" and there is still no rationale for change in the issue summary. Also I think changing a default behaviour should have a change record.

Actually given that the product manager asked for an issue summary update in #149 setting to needs work for that.

Reviewed in #149; feel free to re-add the tag once the rationale is explained, esp. how to deal with the "node orphanage" problem that it will inevitably cause.

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.