"Promote to front page" is a misnomer

I think this still gives the same problem - if the user isn't using /node as his front page, it is still confusing for them to know that it is in the 'main content listing' but not necessarily showing up on their front page. What is the 'main content listing' to them if they aren't using it?

I think we could do to keep the word 'promoted', and make the label read 'Promoted to main content listing'.
It's more descriptive than 'added' -- it's a good, meaningful word for users to latch on to.

Related to #270919: UB Usability : Labeling Front Page (might make sense to merge?)

This setting also decides whether content appears in example.com/rss.xml - i.e. http://drupal.org/rss.xml - so "main content listing" seems like a big improvement to me.

Also, there's sites out there which don't have /node as the front page, but use that setting to determine if content is shown in certain views (it's very efficient to have that information on the {node} table instead) - and 'promoted to main content listing' is a bit more consistent with that sort of abuse :)

I'm also not convinced by 'added' though - it's arguably worse than 'promoted', maybe "show in main content listing"?

I don't think 'main content listing' is any better, personally. I am OK with shortening to 'promoted' - thats all i can think of.

If a site is using the front page differently than core Drupal offers, then it is up to the devs of the site or contrib module authors to form alter the name of this checkbox to whatever it means on their own site.

Well /node is still available on the vast majority of sites even if they're using panels or something else for the front page - and the checkbox still means something in terms of rss.xml. Even if /node and rss.xml are overridden by views - then the view might still use the same criteria for filtering. So I think 'main content listing' while not beautiful, at least describes what the checkbox actually does. Promoted without any indication would have the advantage of brevity - but alongside 'sticky at top of lists' that fieldset starts to look a bit cryptic.

Moshe might be right. I would simply remove that checkbox if the frontpage is not node. And then anyone can form_alter it back.

I not convinced main content listing is any better than what we already have.

Just as the argument can be made that not every has the same idea of a front page; not everyone has the same idea for a main content listing. My main content listing may not even be at /node/ thus reindering the text confusing again.

Unfortunatley, I don't have an alternative idea.

I think the word default in here may work?

default node path?
default front page?
default content list?

I don't particularily like the word promote either.

I see add and show has been shot down, what about push?

I think the word default is needed in some way to differentiate itself from other paths that may be used.

Hmmm, "core" may be better suited as default may sound like it can be changed to send content elsewhere and that can't happen.

I like promoted to /node

what about promoted to /node (default content list) ?

:scratching head:

How about just "Promote"?

What about using a simple verb, "Promote", and leveraging Advanced Help or the translation layer to provide more information for those who are interested?

In almost all the sites I've built, /node !=
In other sites I've built, "promote" != "promote to " && "promote" != "promote to /node".

In other words, the only thing that absolutely stays consistent across sites is that $node->promote gets set to TRUE or FALSE.

How $node->promote is used is entirely up to the site and module developers,
and a broad instruction like "Promote" indicates that field can mean different things to different people.

</$.02>

I may have to dig through the forums. This question does come up often in support (can't speak for IRC) whereby the user has set up a front page in adminsiter -> site information then finally gets around to expanding the publishing options menu and promotes a node. Expecting it on their front page and it isn't there.

I can see an admin or developer understanding promote because of underlying code, but not run of the mill users.

+1 #16

Promoted to default content listing

I like that as well - but we need to open an issue for the node form losing all content when clicking off it then using the back button - shouldn't hold this up though.

Promoted to default content listing

Are you serious? That's useable? What the heck is a default content listing? What Moshe and I suggested was a lot, lot simpler: call it promoted, heck we could call it promoted to the front page once the site frontpage is not node, just remove the checkbox and then let people form alter.

chx, what happens to rss.xml then? What about sites which use /node for some other purpose (path alias it and call it news for example)?

I am against removing the checkbox if the frontpage is not set to /node. Several sites I've built use a view for the front page, and the view has filters for published, promoted to front page, and then other various filters (e.g. workflow status). I think simply using "Promoted" with some kind of help link is more in line with "Published". The setting is very useful for contrib, and it seems unreasonable to force them to put it back in place if they use it. Core shouldn't be "destructive" like that.

my apologies for making the waters muddier than they already were. : )

I am going to suggest we leave this as is. Most users more than likely do not change the default frontpage from /node to another page (i.e taxonomy/9).

I think a better way to solve this issue is the add a warning (or reminder) on the site information admin page. The message could be something like "If this is set to something other than /node, the "promoted to frontpage" option is useless".

What about: Promote.

@chx - that makes me think I can promote/demote the node by clicking on the link (ok it may be because I'm used to Fast Toggle), which could be confusing. If we really want the link to /node, then something like:

Promote: [contenttype] will appear here

would be less confusing, but goes back to the previous discussion.

Plus, /node isn't the only place that it shows up, so we then have to decide which do we list.

Personally, I think that Promote is enough, as I see it as a flag. /node is a special listing that just happens to only show the nodes that have been 'promoted', same with the default rss feed. If I create a view for the front page, I also may want to use only nodes that have been promoted, or those which are 'sticky' or maybe only those that are both. I see it as meta-data about the importance of the node, which can be used to filter down what is really important on the site.

sorry... ick, dont use "here" as a link. default content listing is better. I really dont like "click here"s and this is almost like that.

hmmm what about
Promoted to default content listing
from #16
and add a "?" help nearby that talks about all the issues, that front page is initially /node, that it can be changed, that rss also uses this setting by default, and that other contrib or custom changes can use promoted to do cool stuff like .... hmmm whatever example is appropriate.

We don't have any way to do inline help at the moment The promoted flag has sufficiently broad options for usage (views etc.) that it'd be useful to be able to link to a help page rather than trying to stuff it into the form though.

fwiw I reckon either 'promote' or 'promote to default content listing' are better than 'promote to front page' - since the current text is actually wrong in terms, being a bit cryptic is better than outright lying, but I'm not really sure what chx and Moshe's problems are with 'default content listing' yet.

Also see #126221: Make 'node' empty text themable..

I have to agree that both "Promoted to front page" and "Main content listing" are confusing for new users.

Rather than looking at what this flag is being used for, maybe look at it from another angle. It is used to add weight to the importance of the node. A term like "Featured content" or just "Featured" would be more understandable for newbs.

Without any inline help, this could be expanded to:

[ ] Featured. Used by the default content listing

This would free up the term "Promoted", which could be used to replace "Sticky", which is currently being used to promote nodes in a node listing.

Using these changes would result in the following options:

[ ] Published
[ ] Featured. Used by the default content listing
[ ] Promoted to the top of lists

PS: When I asked my partner what she thought "sticky" meant in relation to a content item, her answer was "it's broken"

These are all essentially flags, built-in flags for that matter, that pipes a node to some location or other, which can also be compared to a simple workflow. Views is a good example of how far we can go with these flags to create front pages, moderation pages, etc.

I would tend to use very short names for these options (flags) and agree with others here:

[] Published (?) // Adding a help icon could help newbies.
[] Promoted (?)
[] Glued at top of lists (?) // Changed sticky to a "-ed" word.

In the next generation of Drupal, or with modules, we could add other flags there.

Just my two cents. :-)

I have a hesitation with #31 in reusing an existing term to mean something different. People who have used D6 will be used to "promote" doing one thing, and to change that on them would be a bad thing. Also, I'm not convinced that featured better descibes it - I would tend to think that featured might be a better replacement for sticky, or we could use the universal "pin(ned)" which I think more people would understand than "glued"

Sticky is pretty common on forum software like vbulletin and phpbb - granted forums are less important than they were 5 or so years ago.

'Featured' is pretty good I think to replace promoted.

I think we should encourage people to change their front page. It makes for much richer Drupal sites. On mollom.com we promoted a regular page as the front page, and re-purposed ?q=node as our blog. Promote to front page now means promote to blog, and it also results in the rss.xml file being update. In Mollom.com's scenario, "show in main content listing" would make some sense but still not a whole lot.

Maybe it should become promote to [ select a listing |V|] (note that I tried to draw a drop-down menu). The best solution seems to have different containers or listings that can have custom names, and than give people to option to add nodes to certain views. A simple views module in core, anyone? :P

As per #32 and others, I think it makes the most sense to view these as flags. "Featured" seems to be the best succinct description of the promote flag.

Here's the names I would go for:

• Published
• Featured on [select a page |v| ]
• Pinned to top of lists

I would not get rid of the term 'sticky' as per catch in #34. It is a very common term.

Also, isn't 'promoted' just a flag and no real setting? /node fetches all nodes that are flagged 'promoted', not the other way around where nodes are pushed to some sort of listing (which we'd have to build in again).

Note that in comment #31, I was trying to view these options from the point if view of one of our clients. Many clients have never had any experience in any web based applications.

If "Promoted to front page" gets changed, I personally would not change the "Sticky at top of lists" field title for at least 1 or 2 major Drupal versions, otherwise you risk confusing existing users too much.

In regards to having the select option, will this be designed to update the selected view to use the {node}.promote flag as a filter? Just interested in what the direction of this line of thought is headed.

Xano's right that we don't 'push' nodes into listings - they're pulled into them depending on various attributes. The closest thing we have to pushing things into views is either flag or nodequeue (although it's quite possible to flag something and have it not show up simply by filtering / arguments on something else too).

I'd like to see flag in core (or at least editable / configurable / addable global flags instead of hardcoding sticky/promoted etc.), I'd like to see views in core (with lots of cool default views as opposed to a simplified interface). I don't really want to see a single word change dependent on either of those though.

So I'd still go for

Published []
Featured []
Sticky []

I read through the whole issue. The only argument against Show on /node was

What about sites which use /node for some other purpose (path alias it and call it news for example)?

well, we can find out it's path alias easily, can't we.

How about refactoring these status flags to real CCK fields by default? Then one could install the CCK UI and remove the whole field or change the label to what ever fits the site best?

The only drawback I see with this is that we are making node.module dependant on fields named/configured in a particular way.

Having these three status columns as fields would make all core queries with conditions and/or sorts on published, promoted and sticky (which is a lot of node queries) unable to use indexes. While having them more flexible would be good (either flag module or field api), we can't remove the special casing until there's a solution to deal with the performance implications.

Would working on getting Flag into core answer the questions of what to call them, and also Dries' comment of having a promote to dropdown list? Core could ship with defaults of say Published, Promoted and Sticky with the ability to add/remove/rename these to descibe how the site works and to tailor the names to what the specific site users might expect? I do realise that this would potentially break translations of the flag names however...

To #43 http://drupal.org/patch/review

No patch can save the world, not even a Drupal core patch. If it works and does something useful on its own, then it is good to go. One of the worst things you can do is elaborate on other, equivalent approaches and suggest complex extensions to the patch. Additional features can be added later. A scalpel is often better than a Swiss Army Knife.

I think #40 still stands and I coded it.

Chx, I agree with you that simplicity is probably better in this case. As I consider it more, I think just Published, Promoted, and Sticky would be the best names and the idea of a dropdown would be too complex. "Show on /node" would be OK, but I think it would become confusing in the context of how other modules (like Views) use the Promoted field to filter nodes.

Looks like "Sticky at top of lists" is becoming "Sticky (stays at top of content lists)", according to #197460-13: Replace "Sticky at top of lists" with a more meaningful equivalent.

To go with that style, I propose changing "Promoted to front page" to "Promoted (show on node)", where node is a link to the aliased path of the front page.

Attached is a patch, the first I have written for core. Thanks to chx and Senpai for the basic idea of it.

Note that I didn't change the text of the node actions, since that apparently breaks the triggers tests (see #197460-16: Replace "Sticky at top of lists" with a more meaningful equivalent).

I changed the formatting of the patch a bit, and resynced it with HEAD. (I had an old 7.x on my local machine.) Hopefully, the testing bot will like it now. If not, maybe someone can help a newbie by explaining what I'm doing wrong.

Why didn't the testing bot retest my patch? Do I have to give it a new name?

Ok, I saw that I had to reset it to "needs review". I'm really sorry to have cluttered up an already-long issue like this.

I don't know why I read this whole thread, but i did.. I am a noob and shouldn't even open my mouth, but, the one and only thing in Drupal that was a no brainer to me was 'promote'. i will go back to my cave now..

I think that promoted is simpler, and it's the more correct, IMO.

As already noted, Views can filter out the nodes that don't have the flag; to remove the checkbox when the front page is not /node would not allow me to set which nodes would appear in those views.

A select box would allow to decide just a place where a node should be promoted, when I could be interested in promoting a node in more places. If even I would be allowed to select more than one places, what would happen with Views? I guess that Views could not use promoted anymore.

I suggest you call it "Featured" and have a built-in URL alias that maps /node to /featured. Then, make /featured the default home page.

Featured makes sense when you look at other website, and even real magazines.

This is too late for 7.x at this point (string freeze). Bumping to 8.x.

"Featured" or just "Promoted" without the "main content listing" or "front page" part is better. is I find myself always re-creating this feature myself using Rules and the Flag module and add flag links for each node called "Feature This".

I suggest you call it "Featured" and have a built-in URL alias that maps /node to /featured. Then, make /featured the default home page.

This suggestion meshes well with some of the work going on in #1210366: Per-bundle node listing pages, blocks, feeds.. Might be a good opportunity for cross-pollination.

@eaton: Hmm...perhaps we should deprecate this in favor of that? Or is it still worthwhile to have one page that cuts across all content types? I would argue that /node was never a very helpful name for said page, though - talk about a Drupalism :)

FYI, the patch that I did in #51, made the text on the node edit form say "Promoted (show on /node)", where /node was whatever you had specified to be the site frontpage. But I think now that actually overloads the functionality of this checkbox too much, since a) sometimes (often?) the page that is "site_frontpage" doesn't actually list the nodes, b) Views also can use this, in arbitrary ways.

I think we should just rename it to "Featured" in this issue, and have /node become /featured, or something similar. That would give us a page that would cut across all content types, and then #1210366: Per-bundle node listing pages, blocks, feeds. could get into the more advanced features that Dries and others had mentioned earlier in this issue, which I think are out of scope for what should basically be a string change.

Sorry for not reading all of these, I stumbled across this post from http://drupal.org/node/1047762 but why is it that when a block is set to only show at front page it will only show on the home page [as supposed to] regardless of which hompage has been identified? Can drupal not do the same when a page is promoted to front page?

You can define any page to the Front page. It is then up to that page to handle this. The default "node" does this. And the views module can handle this by adding a filter "Promoted" to the content view. If you show something else, then the ball is in your court on how to handle this.

The forums are a better place for questions like this, post your details about what you are trying to do there and I'm sure that someone will help in a day or two IF you supply as mush details as possible. The blocks are checking the URL, so this is not checking internal content items, simply if the URL is "" (or equal to the URL of the page promoted to the front page to be more accurate, i.e. "active menu being used" == "node" )

With Views in core, does this feature still match the 80% rule?

There is no good way to describe the "promoted to front page" and there is no guarantee that it would actually be on the front page of the site.

Is it better to remove this feature so that it can be done better in contrib by a flag module?

For core, we now have views, and the front page is no longer so... static.

The main view can be altered to show posts of a specific content type (articles?) instead of "promoted" nodes.

It is too late in the cycle to remove important things. The 80% rule is counter productive and all should stop using it. There are high-end features that are used in less than 10% websites but we nevertheless keep them because they are powerful.

Closing this, as there's much more recent work and discussion at #987242: The "Promoted to front page" checkbox doesn't do anything if the /node front page listing isn't used