Problem/Motivation

The "Promoted to front page" checkbox is primarily only useful if people are using the river-of-news style front page display. As soon as the default front page is overridden, this label makes no sense, and the label either needs to change, or the checkbox should be removed.

Proposed resolution(s)

There are a few proposed solutions for this problem. The one with the most consensus (and work done) at this point is solution #1.

1. Change the wording from "Promoted to Front Page" to "Promoted"
There is a patch at #27 to change all occurrences of the wording.

2. Make the wording configurable per site (possibly also by content type). Likely by making it a configurable field. Or, by changing the title and hiding it when there's no title (field label)

3. Promoted to front page button should only exist if the administrator installs Drupal with the standard (not minimal) install.

Remaining tasks

Solution #1
- Fix the patch from #27

Other
- Determine if there is consensus for pursing another solution
- Create a follow-up issue for other solutions

#1201592: Front page settings cleanup
#1201580: Move Front page & Error page settings out of "Site information" and into their own respective config pages.

Original report by jenlampton

I would love to see the name of this flag changed. Most Drupal sites out there do not use the default front page, and it would be easier to reuse this flag for another purpose if the label were not so specific.

Files: 
CommentFileSizeAuthor
#74 node-promoted-987242-74.patch59.76 KBpplantinga
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch node-promoted-987242-74.patch. Unable to apply patch. See the log in the details link for more information.
[ View ]
#71 node-promoted-987242-71.patch60.1 KBpplantinga
FAILED: [[SimpleTest]]: [MySQL] 57,948 pass(es), 2 fail(s), and 0 exception(s).
[ View ]
#69 node-promoted-987242-69.patch56.37 KBpplantinga
FAILED: [[SimpleTest]]: [MySQL] 58,082 pass(es), 3 fail(s), and 0 exception(s).
[ View ]
#58 node-promoted-987242-58.patch56.46 KBpplantinga
FAILED: [[SimpleTest]]: [MySQL] 58,400 pass(es), 4 fail(s), and 1 exception(s).
[ View ]
#47 node-promoted-987242-47.patch15.82 KBhussainweb
PASSED: [[SimpleTest]]: [MySQL] 58,225 pass(es).
[ View ]
#44 node-promoted-987242-44.patch12.57 KBpplantinga
PASSED: [[SimpleTest]]: [MySQL] 58,359 pass(es).
[ View ]
#38 node-promoted-987242-37.patch15.98 KBK.MacKenzie
PASSED: [[SimpleTest]]: [MySQL] 55,915 pass(es).
[ View ]
#38 interdiff.txt2.72 KBK.MacKenzie
#37 node-promoted-987242-37.patch18.09 KBK.MacKenzie
FAILED: [[SimpleTest]]: [MySQL] Repository checkout: failed to checkout from [git://git.drupal.org/project/drupal.git].
[ View ]
#37 interdiff.txt3.37 KBK.MacKenzie
#27 node-frontpage-987242-27.patch16.63 KBxjm
PASSED: [[SimpleTest]]: [MySQL] 54,546 pass(es).
[ View ]
#27 interdiff-promoted.txt2.97 KBxjm
#23 node-frontpage-987242-22.patch13.67 KBxjm
PASSED: [[SimpleTest]]: [MySQL] 54,660 pass(es).
[ View ]
#23 interdiff.txt593 bytesxjm
#21 Screen Shot 2013-03-30 at 10.02.38 PM.png27.29 KBwebchick
#17 interdiff-16.txt1.78 KBxjm
#16 node-frontpage-987242-16.patch13.09 KBxjm
PASSED: [[SimpleTest]]: [MySQL] 53,754 pass(es).
[ View ]
#16 interdiff-7.txt1.29 KBxjm
#14 node-frontpage-987242-14.patch12.4 KBxjm
PASSED: [[SimpleTest]]: [MySQL] 53,638 pass(es).
[ View ]
#14 interdiff-14.txt4.75 KBxjm
#13 node-promoted.patch8.33 KBxjm
FAILED: [[SimpleTest]]: [MySQL] Setup environment: Test cancelled by admin prior to completion.
[ View ]

Comments

Version:7.x-dev» 8.x-dev
Issue tags:-D7UX usability+D8UX usability

It's too late to get this into Drupal 7, so I'm moving the issue to Drupal 8.

I think that even changing the text to "Promoted" won't solve confusion, as how is the content author supposed to know where the content is getting "Promoted" too? They way I solve the problem is by removing the promoted button and adding my own custom checkbox to each content type that includes a unique description (blog posts can be "promoted to homepage" while user images can be "promoted to website gallery").

I think that the Promoted to front page button should only exist if the administrator installs Drupal with the standard (not minimal) install profile. When they select this profile, a regular checkbox will be attached via fields api to the Article content type.

Also if the standard install profile is chosen then a view will be created and used for the default homepage. The view will only display "promoted to homepage" items.

If this was done then advanced Drupal users could easily remove the promote to homepage button and the default frontpage view while novice Drupal users who are looking to build a blog/news website would get the standard functionality that Drupal has supported for years.

Hm, I don't think views is going to get into core for D8, but now that you've painted this picture, I have some more ideas :)

The "Promoted to front page" checkbox is only useful if people are using the river-of-news style front page display. And that display has a other settings in strange places too (see #1201580: Move Front page & Error page settings out of "Site information" and into their own respective config pages.). What if we added an "allow front page promotion" checkbox as a setting that would determine if the Promoted checkbox appeared? Or we could go one step further, and administratively define a label for the checkbox too.

We could also go totally overboard and let it be customized by content type - which would also allow for your use-case (or maybe, leave that to contrib ;)

I think we should have something a little more descriptive that 'promoted'. In most cases we mean 'Promoted to top of content lists'.

No, that would be Sticky. Promoted is just a flag to differentiate one set of content from another, and by default the /node listing shows only content with that flag set to true.

Oh... duh. Sorry!

For me as a simple site manager the label "Promoted to front page" is a clear description. Please do not change it, that would confuse many Drupal users.

Title:Rename "Promoted to front page" to "Promoted"Rename or remove "Promoted to front page" checkbox if default front page is overridden

The label "Promoted to front page" is clear as long as you are using the *default* front page. I believe more than 80% of Drupal sites are not. (But I don't have any actual statistics on that - might be useful if we could find some)

As soon as the default front page is overridden, this label makes no sense, and the label either needs to change, or the checkbox should be removed.

I personally think the checkbox shouldn't be removed since I use "promoted" to promote to other places once my default front page is gone (hence the preivous name of the issue) but I could be convinced to switch to using flags if it makes more sense for the community at large to remove the checkbox based on front page settings.

Title:Rename or remove "Promoted to front page" checkbox if default front page is overriddenThe "Promoted to front page" checkbox doesn't do anything if the /node front page listing isn't used
Category:task» bug
Priority:Normal» Major

This now occurs more frequently - if you enable the Node module on its own (without Views) then you run into this issue right away. (For example, install with the Minimal profile and create some content; the "promoted to front page" checkbox does nothing.)

So in Drupal 8 right now, the Node module defines this checkbox but doesn't do anything on its own to ever make it work...

Yeah, that's a good point.

Maybe just shorten it to "Promoted." It's a meaningless word, but it's also a meaningless flag until you do something with it.

And/or make it a proper field that is installed with Standard?

I vote for 'Promoted' as well. Makes it more general, which would be in line with how its usage may have changed over the original intention.

Status:Active» Needs review
StatusFileSize
new8.33 KB
FAILED: [[SimpleTest]]: [MySQL] Setup environment: Test cancelled by admin prior to completion.
[ View ]

Alrighty then.

StatusFileSize
new4.75 KB
new12.4 KB
PASSED: [[SimpleTest]]: [MySQL] 53,638 pass(es).
[ View ]

I cast a wider grep net to find a few more. (I missed these on the first pass because of our willful neglect of articles in some of our UI text.)

Also noticed (again) that we need to get rid of node.settings.items_per_page eventually and the corresponding form alter to put it on the system settings form.

There's a reference to a (now and always misnamed) node_frontpage index in the Schema API docs, but not sure what if anything to do with that.

Status:Needs review» Needs work

The field would still have to be created in node.install because the frontpage view is afaik provided by node.module, not standard.profile. One way to solve that would be to only have a recent content view without promoted check in node.module, and a Promoted content view in standard.install that would use this field.

Making it a configurable field would mean that it could not be placed in one of the collapsed sections on the right, not without hardcoded checks in the code/our current manage fields fuctionality.

One advantage of a configurable field would be that it would be easy to decide per content type/bundle if you want that functionality or not. It is usually only used for a few content types on a site (if it's used at all). But it sounds to me that we can't easily make it a field while keeping it in the UI the same way.

So, Agree with simply renaming it. At least for now, as I think that takes care of the major part here.

NodeStorageController::baseFieldDefinitions() also needs to be updated, but looks good to me otherwise.

Status:Needs work» Needs review
StatusFileSize
new1.29 KB
new13.09 KB
PASSED: [[SimpleTest]]: [MySQL] 53,754 pass(es).
[ View ]

Tricksy storage controller. Attached fixes that and also uses the word "demote" consistently where appropriate.

StatusFileSize
new1.78 KB

That is not the right interdiff.

Patch applied, works as meant to.
But i have a small question:
I think that word 'state' is more appropriated then 'status',
Status is more like published, draft etc. But since you are giving 'promoted' a flag sense, it doesn't change the status of the page. Can you explain the word choice?

Status is more like published, draft etc. But since you are giving 'promoted' a flag sense, it doesn't change the status of the page. Can you explain the word choice?

+++ b/core/modules/node/node.views.incundefined
@@ -152,8 +152,8 @@ function node_views_data() {
-    'title' => t('Promoted to front page status'),
...
+    'title' => t('Promoted status'),

Because we already called it "status".

Status:Needs review» Reviewed & tested by the community

Ok, it was just uncertain for me.
If that's not an issue - all works ok.

StatusFileSize
new27.29 KB

Missed a spot...
Screen Shot 2013-03-30 at 10.02.38 PM.png

I think this is basically good as a first step. My main concern is whether or not "Promoted" actually is descriptive enough to explain that what we actually mean here is:

"An arbitrary boolean value which may or may not have any effect on the display of this content in any content listings, depending on how the site builder set them up."

We don't currently explain this concept, like, at all because even on the content types page, where one would expect an explanation of such things, the only description there is "Users with the Administer content permission will be able to override these options." The help page similarly doesn't do anything other than list it as something nodes can do.

Because many sites do have a concept of "promoted" content, and I coud expect content authors to believe that checking that box would cause it to trigger extra styling/etc. and I could see them being utterly perplexed when this doesn't happen.

OTOH, maybe naming this something more generic will cause site builders to use it more for this purpose? Not sure.

Status:Reviewed & tested by the community» Needs work

Needs work for the screenshot, and possibly for the extra description somehow.

StatusFileSize
new593 bytes
new13.67 KB
PASSED: [[SimpleTest]]: [MySQL] 54,660 pass(es).
[ View ]

"Promoted to _______ listings?" "Add to promoted listings"? Or we could add a description for the field only on the node form.

Meanwhile, here's the fix for the form controller. Not sure how it snuck through. I must have just closed the file without saving or something.

I agree with @jenlampton that "promoted to front page" was always a WTF for sites that did not use the default node front page.

Another option would be to do an if module_exists('views')? Sorry, a Drupal::moduleHandler()->moduleExists('views')? :P

There's an old issue for moving it to a field #514056: Move sticky, promote and user.blocked to flag field types in core., definitely agreed on just the rename here.

Status:Needs work» Needs review

Not sure why I never marked this NR.

Sorry for me being so scrupulous, but found still some mentions of 'promoted to front page' )

/var/www/drupal8/core/modules/forum/forum.install:
   14    // Forum topics are published by default, but do not have any other default
   15:   // options set (for example, they are not promoted to the front page).

/var/www/drupal8/core/modules/node/lib/Drupal/node/Plugin/Core/Entity/Node.php:
  137:    * Promoted nodes should be displayed on the front page of the site. The value
  138     * is either NODE_PROMOTED or NODE_NOT_PROMOTED

/var/www/drupal8/core/modules/node/node.api.php:
  434      'promote' => array(
  435:       'label' => t('Promote selected content to front page'),
  439      'demote' => array(
  440:       'label' => t('Demote selected content from front page')

/var/www/drupal8/core/modules/node/node.install:
   88        'promote' => array(
   89:         'description' => 'Boolean indicating whether the node should be displayed on the front page.',

May be i'm wrong in something - not so good in understanding all that stuff :) But that's what i found. Everything else seems working ok.

StatusFileSize
new2.97 KB
new16.63 KB
PASSED: [[SimpleTest]]: [MySQL] 54,546 pass(es).
[ View ]

Attached also changes those instances in #26.

Status:Needs review» Needs work
Issue tags:-Usability

The last submitted patch, node-frontpage-987242-27.patch, failed testing.

Status:Needs work» Needs review
Issue tags:+Usability

#27: node-frontpage-987242-27.patch queued for re-testing.

Somehow I'm uncomfortable with the idea that we've found ourselves in a corner where Drupal can't even use basic CMS publishing concepts like "on the front page" anymore...

Couldn't we do something like make the label of the checkbox configurable per content type (same way the label of the Title field is already configurable per content type)? This is basically what @jenlampton suggested in #2, but it didn't get any discussion.

That doesn't answer the question of what the default label should be, but at least lets the Standard and Minimal profiles configure it differently (e.g., "Promoted to front page" vs. "Promoted"), plus allows individual sites to tweak it however is appropriate. (And for extra bonus points, allow the checkbox label to be left empty, and if so don't show it on the node form for that content type.)

That does leave behind a lot of random places where this terminology is used besides the node form, like:

@@ -1443,7 +1443,7 @@ function node_ranking() {
       'score' => 'n.sticky',
     ),
     'promote' => array(
-      'title' => t('Content is promoted to the front page'),
+      'title' => t('Content is promoted'),

But even if we had to just use the generic "promoted" terminology on those but were able to keep using "promoted to the front page" on the node form when appropriate, I think that would be way better.

Status:Needs review» Needs work

@David_Rothstein - awesome!
Just discussed with some developers this question. The conclusion was - even if we change the name, there are still lots of people asking "What is this checkbox? do I have to click it?". I think the idea of changing the title and hiding it when there's no title(field label) is just awesome! We should surely do that! Let's create a follow-up issue for this ( cause it's a bit different from issue summary), but I totally agree with this idea.

For patch #27 - couldn't apply:

error: patch failed: core/themes/bartik/templates/node.tpl.php:29
error: patch failed: core/themes/bartik/templates/node.tpl.php:51

Everything else looks great! Need some work and final review.

The only sane way to support configurability/labels per bundle would IMHO be to make it a field. But as mentioned in #15, that has some drawbacks, like not being able to place it in the collapsible sidebar-thingy without custom code for a specific field.

I personally think #31 is needless complexity, but tagging for someone to update the summary with what does and doesn't have consensus.

Hey - Working on the issue summary #drupalcon portland

Assigned:Unassigned» K.MacKenzie

Looking into failed patch, sitting next to peaton. #drupalcon Portland

Issue summary:View changes

Updated the issue summary to include comments through May 25, 2013

Issue summary:View changes

added links for related issues

Issue summary:View changes

updated links to related issues

Assigned:K.MacKenzie» Unassigned
Status:Needs work» Needs review
StatusFileSize
new3.37 KB
new18.09 KB
FAILED: [[SimpleTest]]: [MySQL] Repository checkout: failed to checkout from [git://git.drupal.org/project/drupal.git].
[ View ]

Updated patch #27 with twig changes.

-- Just realized that my ChomeOS added headers to the patch file, will re-submit.

StatusFileSize
new2.72 KB
new15.98 KB
PASSED: [[SimpleTest]]: [MySQL] 55,915 pass(es).
[ View ]

Here is a patch without the headers, sorry about that. Still getting used to ChromeOS!

Status:Needs review» Needs work
Issue tags:-Usability, -Needs issue summary update

The last submitted patch, node-promoted-987242-37.patch, failed testing.

Status:Needs work» Needs review

#38: node-promoted-987242-37.patch queued for re-testing.

Status:Needs review» Needs work

The last submitted patch, node-promoted-987242-37.patch, failed testing.

Status:Needs work» Needs review
Issue tags:+Usability, +Needs issue summary update

#38: node-promoted-987242-37.patch queued for re-testing.

Issue tags:+Novice

Excellent, thanks @peaton and @K.MacKenzie!

+++ b/core/modules/node/templates/node.html.twigundefined
@@ -10,7 +10,7 @@
- *   - promote: Whether the node is promoted to the front page.
+ *   - promote: Whether the node will be displayed in views featuring promoted content, such as the default homepage.
@@ -46,7 +46,7 @@
- *   - promoted: Appears on nodes promoted to the front page.
+ *   - promoted: Appears on nodes flagged to be included in promoted content views.
+++ b/core/themes/bartik/templates/node.html.twigundefined
@@ -10,7 +10,7 @@
- *   - promote: Whether the node is promoted to the front page.
+ *   - promote: Whether the node is flagged to be included in promoted content views.
@@ -46,7 +46,7 @@
- *   - promoted: Appears on nodes promoted to the front page.
+ *   - promoted: Appears on nodes flagged to be included in promoted content views.

Just one minor fix is needed here -- these comments should wrap before 80 characters. See https://drupal.org/coding-standards#linelength.

Issue summary:View changes

small wording tweaks to proposed resolutions

StatusFileSize
new12.57 KB
PASSED: [[SimpleTest]]: [MySQL] 58,359 pass(es).
[ View ]

Reroll patch, also with comments wrapped at 80 chars.

Status:Needs review» Reviewed & tested by the community

Set to RTBC.

Status:Reviewed & tested by the community» Needs work

Status:Needs work» Needs review
StatusFileSize
new15.82 KB
PASSED: [[SimpleTest]]: [MySQL] 58,225 pass(es).
[ View ]

I have changed the text in the mentioned file to remove reference to front page. The only place where I have left the reference to front page is in examples.

Promoted nodes are displayed in certain listings of promoted content, e.g. on the default front page. The status is either NODE_PROMOTED or NODE_NOT_PROMOTED.

Apart from the action plugin mentioned, I have changed this in schema definitions and action YML files.

Status:Needs review» Needs work
Issue tags:-Usability, -Needs issue summary update, -Novice

The last submitted patch, node-promoted-987242-47.patch, failed testing.

Status:Needs work» Needs review
Issue tags:+Usability, +Needs issue summary update, +Novice

#47: node-promoted-987242-47.patch queued for re-testing.

Status:Needs review» Reviewed & tested by the community

Looks good to me.

Status:Reviewed & tested by the community» Needs review
Issue tags:-Usability+Needs usability review

What about the discussion above? There is no consensus that switching this to "Promoted" is going to help users. (In fact, depending on how you count the comments above, it seems like a majority may actually be opposed to the change, let alone any consensus.)

Tagging for usability review since I think we need help coming up with a better name than "Promoted"... which I'm pretty sure will mean absolutely nothing to most content creators (or worse, confuse them even further - see @webchick's comment in #21)! I think no checkbox at all is preferable, honestly.

The only sane way to support configurability/labels per bundle would IMHO be to make it a field. But as mentioned in #15, that has some drawbacks, like not being able to place it in the collapsible sidebar-thingy without custom code for a specific field.

I think fields are for data and properties are for metadata, and this seems like metadata. So ideally it would be left as a property.

Why is it insane to have configurable property labels? (We already have at least one.)

Another option would be to do an if module_exists('views')? Sorry, a Drupal::moduleHandler()->moduleExists('views')? :P

I think we should seriously consider this as well (idea from @xjm in #23). Or maybe more like, the Views module alters the form and changes the label back to "Promoted to front page" in the case where (a) the front page is using a view, and (b) the view has no filters besides "promoted" and "status" (so that every published node where this checkbox is checked is guaranteed to appear in the view). That would be ugly code, but sometimes ugly code is worth it for usability.

We'll still need to come up with a name for the checkbox in other cases, though.

I like the label "Promoted" as it is an apt description for what it does. I agree that we can make this configurable for site builders who would like a more appropriate term for their particular case.

I also agree for providing a brief description as mentioned in #21. However, I can't think of a concise description that provides value in minimal space.

The idea to check the front page view for filters and change the label to add " to front page" is interesting. I think it can build to be a lot of overhead and potential for spaghetti code. For example, if the filter also has a Content type = 'Article', then the checkbox label should be modified if adding/editing an article type. Then, we need to support taxonomy filters, etc...

Suppose we don't do any of the above checks, then it causes even more confusion. The user might see that it does not show "Promoted to front page" and will assume it won't go to the front-page, but in actuality, it might.

I think a concise description would serve better than all these intelligent checks, as I think that a site is more likely to be built with a more complex front page than the default view, or a view with just those two filters.

What if we just remove the "promoted" checkbox altogether? And just show all articles on the home page by default.

I mean, how many people are going to want the ability to show some articles but not others on the home page, and not be able to figure out how to do that with views? I think the configurability of views supersedes this checkbox.

Of course there are any number of ways to achieve this behavior using views. Two that come to mind right away: one could create a content type for the front page, or a front-page tag.

I suppose the advantage of the checkbox is that the user doesn't have to have a clue what views are, though I'd hope they would learn.

It's true. With Views making their way to Drupal 8, it almost seems silly to keep this checkbox around. Almost like we're keeping it around just because it *USED* to be around in the past.

It seems evident folks are using this checkbox in various ways that were not the originally intended function. As has already been suggested, flags
or boolean fields on the content type with views could be used instead. The point is that with Views in core, the original intention of the checkboxes to get folks up and running upon a clean site install can be achieved without these chechboxes. If that makes more sense, we could help new users with cleanly-installed sites by adding to the default front page text a short tutorial on creating a view for your front page.

What do you think? Drupal 7 didn't want to assume that the user had views installed, because it was a separate module, but in Drupal 8 - it'll be right there and is far superior in providing streams of content. So I suggest

  1. just remove the checkbox altogether and all associated functionality
  2. Include text on the default page that is a mini-tutorial on setting up your first front-page view.

Otherwise, this new 'Promoted' checkbox may end up being just as confusing as the first version....

Without the flag module, what #53 describes would be impossible with views. Views still needs this functionality.

Well, a "flag" doesn't have to mean flag.module. It can just as well be a boolean field.

Or just make it content type specific by default. standard.profile could alter the default view (which would not have a filter) and add a filter on article or it could provide the default view? Then those descriptions would actually make sense and not just be their default configuration ;)

If we do decide that this is the way we want to go, I'd be happy to take it on.

What would we do with the lonely "sticky" checkbox in the "Promotion Options"? Again, it would be possible to mimic this behavior with views, and without it, the "Create Article" page would be cleaner. Sorry for this n00b question, but do new views honor "sticky" by default? If not, then this may be another case of being superseded by views.

However, unlike the "promote" checkbox, this functionality does make sense with views, and it is slightly more complicated to simulate. Perhaps we could move the checkbox to another place?

StatusFileSize
new56.46 KB
FAILED: [[SimpleTest]]: [MySQL] 58,400 pass(es), 4 fail(s), and 1 exception(s).
[ View ]

Here is a (not-so) simple patch to just remove "promoted" checkbox and related functionality. It works, but it just looks a little weird to have the only option under "Promotion options" be "sticky".

Also, there are 4 files that can be removed, and I don't think that's reflected in the patch.

git rm core/modules/node/lib/Drupal/node/Plugin/Action/PromoteNode.php
git rm core/modules/node/lib/Drupal/node/Plugin/Action/DemoteNode.php
git rm core/modules/node/config/action.action.node_promote_action.yml
git rm core/modules/node/config/action.action.node_unpromote_action.yml

Is that info that should be contained in the patch? If so, how is it done?

Status:Needs review» Needs work

The last submitted patch, node-promoted-987242-58.patch, failed testing.

We should keep in mind that as mentioned in #15, if we get rid of this feature and assume people can replace it with a field, we'll be losing a couple concrete benefits of the current implementation, which is a property, not a field. (That said, it's possible to imagine contrib modules creating a UI for configuring new entity properties; ECK already does that even, although I don't believe it lets you do it for existing entity types like nodes, only new entity types.)

Just throwing around ideas for a different checkbox label, what about something like:

"Allowed on the front page"
"Recommended for the front page"
"Front page content"

(The idea is for the content creator to indicate that it belongs on the front page without necessarily implying that it is guaranteed to be there.)

I don't know if it's a good idea, though... we'd probably still want a way for sites not using this feature to turn it off entirely, and at that point we might as well just make the checkbox label completely configurable anyway.

Why not just ditch the "front page" nomenclature and call it something like "Featured content". This content can still be displayed on /node, but the label doesn't necessarily imply that it will be displayed on the front page.

Status:Needs work» Needs review

#58: node-promoted-987242-58.patch queued for re-testing.

Hm, I definitely think "Featured content" is way better than "Promoted"!

Any label that doesn't have the word "front page" in it still seems like a regression (of what still looks to me like a basic CMS publishing concept)... and we are evolving towards wishy-washy labels as a replacement, so I'd still vote for a configurable label but "Featured content" is absolutely a decent fallback :)

Status:Needs review» Needs work

The last submitted patch, node-promoted-987242-58.patch, failed testing.

Status:Needs work» Needs review

So the main thing we need to decide is whether we're keeping the "promoted" checkbox (see #53, #54) and if so, whether we want to change the name to "featured content".

I'm a fan of removing the checkbox, and if that gets shot down, changing the name.

Issue tags:-Novice

I suppose my vote is to remove the check box. From my experiences its a very unique use-case to have the front page set up like it is by default on a production site.

If we do remove it, then I suppose the out of the box installation would feature a view of all nodes on the front page, rather than only promoted ones.

Personally, I think this makes a lot of sense. Axe the check box.

StatusFileSize
new56.37 KB
FAILED: [[SimpleTest]]: [MySQL] 58,082 pass(es), 3 fail(s), and 0 exception(s).
[ View ]

Re-roll/fixup patch. Again, if we decide to remove the "promote to front page" checkbox, we're going to have to decide what to do with the "sticky" checkbox too. Remove it? Move it? Just keep it where it is?

Also, we would need to decide on what goes to the front page by default. My vote is all "articles".

Status:Needs review» Needs work

The last submitted patch, node-promoted-987242-69.patch, failed testing.

StatusFileSize
new60.1 KB
FAILED: [[SimpleTest]]: [MySQL] 57,948 pass(es), 2 fail(s), and 0 exception(s).
[ View ]

Let's try that again.

Status:Needs work» Needs review

Forgot to set status to needs review

Status:Needs review» Needs work

The last submitted patch, node-promoted-987242-71.patch, failed testing.

Status:Needs work» Needs review
StatusFileSize
new59.76 KB
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch node-promoted-987242-74.patch. Unable to apply patch. See the log in the details link for more information.
[ View ]

And again.

I believe that it would be useful to offer people two choices in place of the 'Promote to front page':

1. Include or exclude content from it's dedicated listing (assumes #1210366: Per-bundle node listing pages, blocks, feeds. is in).

This would be a 'Include in the {bundle_name} listing' checkbox that should be enabled by default, but still per-bundle configurable.

What this would do for example is to add a 'Include in the Articles listing' checkbox in the Article node edit form. Since the 'Promotion options' fieldset (do we still want to call it so?) is collapsed by default and this checkbox defaults to checked, the default action on node save would be to include the created article node in the 'Article listing' view. In reality, all this checkbox would be is a 'show in listing' flag that is set as a criterion in the Article view.

Now in the Article content type settings (as with every content type), there would be a toggle so that if admins could change this include-by-default in bundle listing option.

For any custom content types created after installation their bundle listing view will be auto-created (by #1210366: Per-bundle node listing pages, blocks, feeds. I guess). So another thing that should be auto-created is this 'show in listing' flag and should a) be set to enabled by default and b) added as a criterion to the bundle's listing view.

2. Include or exclude their content from the 'Featured content' listing (assumes #2029199: Rename the 'Frontpage' view to 'Latest content' or 'Featured content'. happens)

Similar to the previous option, but instead of applying to each bundle's auto-generated listing view it would apply to the 'Featured content' view (the view that is set as the site's home page after installation). In order to retain current functionality for the included content types, this flag should be enabled for the Article and disabled for the Basic page .It should also be disabled by default for all new custom content types IMO (but also still per-bundle configurable).

The respective checkbox in every content type edit form should be labeled 'List in Featured content' and that in turn would be a 'show in featured' flag that is set as a criterion in the 'Featured content' view.

Since the 'Featured content' view is not limited to any specific content type (unlike the per-bundle listing views), exists right after installation and already includes the 'show in featured' flag as a criterion, there would be no need to auto-generate anything after the creation of custom content types besides this 'show in latest' flag.

...In any case if people choose to include their content in either of these listings, the 'sticky to top of lists' flag makes sense so we should keep it in place.

Finally, we practically solve this issue here because:

a) In the UI there is no more misleading "Promoted to front page" text (it's gone with #2029199: Rename the 'Frontpage' view to 'Latest content' or 'Featured content'.).

b) If the 'Featured content' view is disabled, we can simply have the 'List in Featured content' checkbox in a disabled state or completely hidden from the node edit forms.

c) Even if the 'Featured content' view is removed from being the site's home page, it's still a valid listing page eligible for other parts of the site. So the 'List in Featured content' option still makes sense.

Alternatively, we could combine the above and alter the 'List in Featured content' label of the checkbox to 'Include in the Home page' if the 'Featured content' view is set as the site's Home page (#1201592-57: Front page settings cleanup)

Thoughts?

I guess I could go for "Include in Latest Content listing," though it seems a bit wordy and possibly confusing to a n00b. This basically amounts to renaming the field, yes?

So we still have basically three options:

- Remove the "Promoted to Front Page" checkbox entirely. Default homepage would show all articles (or all content).
- Rename the checkbox. Seems like popular options are: "Include in Latest Content listing" and "Featured Content".
- Change behavior (perhaps by doing something like in comment #75 option 1).

Thoughts?

...it seems a bit wordy and possibly confusing to a n00b.

Yeah the alternative I originally though was "List in Latest content listing", but using the same word ("list"/"listing") twice in a single sentence seemed odd. I like the term "featured" way better than "latest" because it's closer in meaning to "promoted". We could simply have it be "List in Featured Content" ;)

...I've updated my comments and related issues to mention "Featured" as the preferred alternative to "Latest".

Status:Needs review» Needs work

The last submitted patch, node-promoted-987242-74.patch, failed testing.

Issue summary:View changes

was a random failure. passed tests. -c