Updated from #89.
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 something else. There is a patch at #27 to change all occurrences of the wording to "Promoted". Another suggestion is to call this "Featured content" (see #63, #65, #76).
This is the approach in the current patch, which changes the text "Promoted to front page" to "Promote".
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.
4. Remove the "promoted" checkbox altogether.
This has been mentioned a few times and gained support after #51 with first patch for this in #58 and rerolled latest in #85.
5. Make the "promoted to front page" checkbox either automatically hidden in the user interface (or automatically renamed) only when it doesn't apply (#23, #51).
For example, the Node module would do that by default, but the Views module could alter the form and show it as "Promoted to front page" in the case where (a) the front page is using a view, and (b) the view has filters which suggest that the node will actually appear on the front page if the box is checked (e.g., it uses a "promoted" filter). An advantage of this approach is that it should automatically do the "right" thing for a good number of use cases, but a disadvantage is that this won't be foolproof and would involve some ugly/complicated code.
Remaining tasks
Solution #1
- Decide on a term other than "Promoted". Current popular suggestion is to call this "Featured content".
- Fix the patch from #27 or #47.
- Add description to clarify the flag (see #21).
Solution #4
- Fix the patch from #85.
Other
- Determine if there is consensus for pursing another solution.
- Create a follow-up issue for other solutions.
Related Issues
#1201592: Front page settings cleanup
#1201580: Move Front page & Error page settings out of "Site information" and into their own respective config pages.
#2029199: Rename the 'Frontpage' view to 'Latest content' or 'Featured content'.
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.
Comment | File | Size | Author |
---|---|---|---|
#162 | interdiff#129-#160.txt | 47.84 KB | aarti zikre |
#162 | 987242_161.patch | 20.91 KB | aarti zikre |
#160 | interdiff#129-#160.txt | 48.12 KB | aarti zikre |
#160 | 987242_160.patch | 21.18 KB | aarti zikre |
#159 | interdiff#129_156.txt | 46.08 KB | aarti zikre |
Comments
Comment #1
Devin Carlson CreditAttribution: Devin Carlson commentedIt'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.
Comment #2
jenlamptonHm, 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 ;)
Comment #3
jenlamptonFor reference, other issues about front page settings:
#1201592: Front page settings cleanup
#1201580: Move Front page & Error page settings out of "Site information" and into their own respective config pages.
Comment #4
joachim CreditAttribution: joachim commentedI think we should have something a little more descriptive that 'promoted'. In most cases we mean 'Promoted to top of content lists'.
Comment #5
webchickNo, 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.
Comment #6
joachim CreditAttribution: joachim commentedOh... duh. Sorry!
Comment #7
cvdenzen CreditAttribution: cvdenzen commentedFor 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.
Comment #8
jenlamptonThe 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.
Comment #9
David_Rothstein CreditAttribution: David_Rothstein commentedThis 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...
Comment #10
webchickYeah, 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.
Comment #11
xjmAnd/or make it a proper field that is installed with Standard?
Comment #12
ditcheva CreditAttribution: ditcheva commentedI 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.
Comment #13
xjmAlrighty then.
Comment #14
xjmI 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.Comment #15
BerdirThe 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.
Comment #16
xjmTricksy storage controller. Attached fixes that and also uses the word "demote" consistently where appropriate.
Comment #17
xjmThat is not the right interdiff.
Comment #18
oresh CreditAttribution: oresh commentedPatch 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?
Comment #19
xjmBecause we already called it "status".
Comment #20
oresh CreditAttribution: oresh commentedOk, it was just uncertain for me.
If that's not an issue - all works ok.
Comment #21
webchickMissed a spot...
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.
Comment #22
webchickNeeds work for the screenshot, and possibly for the extra description somehow.
Comment #23
xjm"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, aDrupal::moduleHandler()->moduleExists('views')
? :PComment #24
catchThere'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.
Comment #25
xjmNot sure why I never marked this NR.
Comment #26
oresh CreditAttribution: oresh commentedSorry for me being so scrupulous, but found still some mentions of 'promoted to 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.
Comment #27
xjmAttached also changes those instances in #26.
Comment #29
Berdir#27: node-frontpage-987242-27.patch queued for re-testing.
Comment #30
BerdirRandom test fail due to #1965048: Frequent random test failure EntityTranslationUITest Invalid values generate a list of form errors.
Comment #31
David_Rothstein CreditAttribution: David_Rothstein commentedSomehow 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:
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.
Comment #32
oresh CreditAttribution: oresh commented@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:
Everything else looks great! Need some work and final review.
Comment #33
BerdirThe 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.
Comment #34
xjmI personally think #31 is needless complexity, but tagging for someone to update the summary with what does and doesn't have consensus.
Comment #35
peatonHey - Working on the issue summary #drupalcon portland
Comment #36
K.MacKenzie CreditAttribution: K.MacKenzie commentedLooking into failed patch, sitting next to peaton. #drupalcon Portland
Comment #36.0
peatonUpdated the issue summary to include comments through May 25, 2013
Comment #36.1
peatonadded links for related issues
Comment #36.2
peatonupdated links to related issues
Comment #37
K.MacKenzie CreditAttribution: K.MacKenzie commentedUpdated patch #27 with twig changes.
-- Just realized that my ChomeOS added headers to the patch file, will re-submit.
Comment #38
K.MacKenzie CreditAttribution: K.MacKenzie commentedHere is a patch without the headers, sorry about that. Still getting used to ChromeOS!
Comment #40
Berdir#38: node-promoted-987242-37.patch queued for re-testing.
Comment #42
Berdir#38: node-promoted-987242-37.patch queued for re-testing.
Comment #43
xjmExcellent, thanks @peaton and @K.MacKenzie!
Just one minor fix is needed here -- these comments should wrap before 80 characters. See https://drupal.org/coding-standards#linelength.
Comment #43.0
xjmsmall wording tweaks to proposed resolutions
Comment #44
pplantinga CreditAttribution: pplantinga commentedReroll patch, also with comments wrapped at 80 chars.
Comment #45
pplantinga CreditAttribution: pplantinga commentedSet to RTBC.
Comment #46
tim.plunkettThere are other places this occurs now, like http://drupalcode.org/project/drupal.git/blob/refs/heads/8.x:/core/modul...
Comment #47
hussainwebI 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.
Apart from the action plugin mentioned, I have changed this in schema definitions and action YML files.
Comment #49
hussainweb#47: node-promoted-987242-47.patch queued for re-testing.
Comment #50
pplantinga CreditAttribution: pplantinga commentedLooks good to me.
Comment #51
David_Rothstein CreditAttribution: David_Rothstein commentedWhat 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.
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.)
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.
Comment #52
hussainwebI 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.
Comment #53
pplantinga CreditAttribution: pplantinga commentedWhat 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.
Comment #54
ditcheva CreditAttribution: ditcheva commentedIt'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
Otherwise, this new 'Promoted' checkbox may end up being just as confusing as the first version....
Comment #55
tim.plunkettWithout the flag module, what #53 describes would be impossible with views. Views still needs this functionality.
Comment #56
BerdirWell, 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 ;)
Comment #57
pplantinga CreditAttribution: pplantinga commentedIf 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?
Comment #58
pplantinga CreditAttribution: pplantinga commentedHere 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".
Comment #59
pplantinga CreditAttribution: pplantinga commentedAlso, 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?
Comment #61
David_Rothstein CreditAttribution: David_Rothstein commentedWe 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.)
Comment #62
David_Rothstein CreditAttribution: David_Rothstein commentedJust 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.
Comment #63
cweagansWhy 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.
Comment #64
pplantinga CreditAttribution: pplantinga commented#58: node-promoted-987242-58.patch queued for re-testing.
Comment #65
David_Rothstein CreditAttribution: David_Rothstein commentedHm, 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 :)
Comment #67
pplantinga CreditAttribution: pplantinga commentedSo 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.
Comment #68
K.MacKenzie CreditAttribution: K.MacKenzie commentedI 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.
Comment #69
pplantinga CreditAttribution: pplantinga commentedRe-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".
Comment #71
pplantinga CreditAttribution: pplantinga commentedLet's try that again.
Comment #72
pplantinga CreditAttribution: pplantinga commentedForgot to set status to needs review
Comment #74
pplantinga CreditAttribution: pplantinga commentedAnd again.
Comment #75
klonosI 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.
Comment #76
klonos...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?
Comment #77
pplantinga CreditAttribution: pplantinga commentedI 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?
Comment #78
klonosYeah 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".
Comment #79
cweagansClosed #404300: "Promote to front page" is a misnomer as a duplicate.
Comment #80
Berdir#74: node-promoted-987242-74.patch queued for re-testing.
Comment #81.0
(not verified) CreditAttribution: commentedwas a random failure. passed tests. -c
Comment #83
alansaviolobo CreditAttribution: alansaviolobo commentedrerolled the patch.
Comment #85
hussainwebI am attempting a reroll from #74 as there seems to be something wrong with the reroll in #83. I don't expect this patch to work because it's just a reroll, and doesn't remove other new traces of promoted.
I just wanted to know if this issue is still being considered and if it is, I will continue working on removing the rest of the references.
Comment #87
hussainwebAll expected failures. I would love to hear from someone if we are still considering this and then take this forward.
Comment #88
webchickHm. Feels like we could really need an issue summary update here before going much further. I thought (and this is what the current issue summary says) that we were simply renaming the label from "Promoted to front page" to just "Promoted," possibly with a description that explained what this could be used for. But the latest patch actually removes the flag altogether. I'd like to understand how we arrived with that being the solution, and what sort of buy-in that has (for example, as late as #55 it looks like tim.plunkett was saying that Views needs this).
Comment #89
hussainwebI have tried my hand at updating the issue summary. From my count, there are roughly 50% more people agreeing to rename than to remove, however, I am not sure how relevant that is since most comments are over a year old. Further, reasoning to not remove in many places is that if we make it a field, we would have to specially handle this in the node add/edit form to show up on the right side of the form. This situation has changed with everything on a content entity becoming a field, right?
It would be great if you can review the issue summary and let me know if I have missed out something. If we can come to a conclusion, we already have patches for both solutions and little work left.
Comment #90
hussainwebMinor fixes in the summary.
Comment #91
LinL CreditAttribution: LinL commentedAdding related issue #987238: "Promoted to front page" for new content types should default to Un-Checked
Comment #92
ditcheva CreditAttribution: ditcheva commentedMy vote: I'm in favor of resolution #1 (rename the checkbox) and like the proposed "Featured content" label.
Comment #93
lauriiiI wouldn't consider this as a novice issue anymore.
Comment #94
BerdirJust renaming it sounds fine to me as well.
Additionally, #2226493: Apply formatters and widgets to Node base fields will make it a configurable widget, which means that it will be possible to disable the widget for content types.
It will be there by default, but it will allow site builders to hide it from users when it doesn't make sense in a certain context. Same for everything else, like sticky. So anyone who is interested in removing it completely, help testing that other issue so that we can get it in.
Comment #95
hussainwebIt seems that the general opinion is weighed towards renaming the checkbox rather than removing it. Now the question is does "Promoted" make enough sense (see #21) or should we call it "Promote as Featured Content" or something else (see #63, #65 and later comments).
If we begin seeing some consensus on this, I can start working on a patch for this (probably based on #27 or #47).
Comment #96
hussainwebBased on discussions with @Berdir on IRC, I am posting a simple patch which just renames it to "Promoted" and variations. We can decide if this looks good or should we rename it to featured content or something else.
Comment #98
hussainwebFixing the test failure.
Comment #99
BerdirThat's not correct ;)
Not sure how to write this..
This uses Demote instead of Remove, seems like we can use the same above?
Comment #100
hussainwebWhoa! Nice catch. I don't know how I missed that. Thanks!
Comment #103
dawehner@hussainweb
Try to post interdiffs, this makes life always a bit easier.
I really like to just rename the wording, given that people uses this flag for quite some different ways already with views.
Comment #104
hussainweb@dawehner - You are right. I keep forgetting this at times. I understand how difficult it is to follow-up. The funny thing is I kinda remember creating the interdiff but I don't see it anywhere now. :)
Comment #105
catchI also prefer changing the wording to removing - there's still performance advantages to having those basic fields on the base table of the site to avoid conditions/sorts across tables. We're close to the point where we could allow configurable fields to be added to the base table for cases like this (or at least have a contrib storage engine that provides this as an option), or automated denormalization per materialized views module, but not quite there yet.
Comment #106
David_Rothstein CreditAttribution: David_Rothstein commentedAlso:
The capitalization is wrong, and the overall phrasing is inconsistent with other parts of the form (for example, it's "Sticky at top of lists" not "Mark as sticky at top of lists")...
Wow, so isn't that kind of a solution to this whole issue? If it can be removed when it's not relevant, then there shouldn't be any reason to change the name from "Promoted to front page" ... should we hold off for a bit and see where that issue goes first?
Comment #107
David_Rothstein CreditAttribution: David_Rothstein commentedAdded option #5 to the issue summary, for automatically hiding or rewording the "promoted to front page" checkbox only when it doesn't apply.
Comment #108
hussainweb@David_Rothstein: Re: #106.1, what would you suggest? Does "Marked as promoted" sound better? It fits the tense with other phrases on the page.
Comment #109
BerdirI have no idea how option #5 could work reliably, there are so many ways you can change it works, by changing the view or having a different frontpage, or using the flag in a different way that might or might not affect the frontpage.
Exact wording aside, I still think that renaming it is the best option we have, especially in combination with the issue that I referenced, then site builders can decide between using promoted content in any way they want or not showing it.
Comment #110
David_Rothstein CreditAttribution: David_Rothstein commented@hussainweb, I think just "Promoted" (like the earlier patches); if that's the terminology being used in the patch no reason to make it different in that one location.
Comment #111
hussainwebMaking changes as per #106 and #110. Leaving it for review.
Comment #112
alansaviolobo CreditAttribution: alansaviolobo commentedComment #113
jhedstromPatch no longer applies.
Comment #114
Scionar CreditAttribution: Scionar commentedComment #115
Scionar CreditAttribution: Scionar commentedUnfinished while doing reroll.
Comment #117
lauriiiComment #118
alvar0hurtad0Rerrolled patch
Comment #119
lauriiiWe still need beta evaluation block to the issue summary
Comment #120
hussainwebI am rerolling from #111 again as the patch in #118 seems to have missed out on some of the files. I am removing the novice tag as well as this is really about the usability review.
Further, I guess this may not get in 8.0.x and pushed to 8.1.x. In any case, I am rerolling to help things go along when the time comes.
Comment #121
hussainwebOops, missed the patch.
Comment #122
Bojhan CreditAttribution: Bojhan commentedWhats there to review here? Is there a latest screenshot?
Comment #123
lauriiiNode update form looks good on bartik & seven:
There's still frontpage mention on the operations select on the node listing:
Comment #124
alvar0hurtad0Patch 121 whith 123 suggestions.
Comment #125
kattekrab CreditAttribution: kattekrab commentedI've just added a patch at related issue to change the help text on the promote and sticky options #2350013: Descriptions for Promotion Options are too technical
Comment #126
kattekrab CreditAttribution: kattekrab commentedI've suggested
"Show this content in featured regions or lists."
at #2350013: Descriptions for Promotion Options are too technical
Comment #129
eyilmazApplied the patch #124 again.
+ replaced few phrases after simple search on source code.
promoted_to_front-987242-129.patch as refreshed patch.
and interdiff.patch with new replaced phrases.
Comment #130
Bojhan CreditAttribution: Bojhan as a volunteer commentedI dont think we can easily add more meaning to this label, without going to the point of stating where this status effects. I am going to remove the needs usability review.
Comment #131
Anonymous (not verified) CreditAttribution: Anonymous commentedI see no point in "Promote to front page" check box to be added by default since views were made a default component of Drupal 8. In Drupal 7 it had some sense but not in Drupal 8. Think about it, since views are used by default users should adapt to the new functionality. We shouldn't keep something just because it was in Drupal 7. When you innovate you have to make changes. /node view can be modified. A "Promote to front page" boolean field can be added on any content type anyway. And if the default view isn't used "Promote to front page" only confuses people.
Comment #133
xjmSo this is not a major bug in terms of the node module itself; we can consider the "Promoted to front page" checkbox a setting for integrating with the front page view or other views, and that works as designed.
However, it could be a major bug for usability. @Bojhan said above:
The current proposed resolution though is to change the label to actually have less information (and therefore be less specific), from:
"Promoted to front page"
to:
"Promote"
or:
"Promoted"
So re-tagging for usability review on whether that is a good approach. @Bojhan (or another usability maintainer), can you clarify whether:
Deferring major triage on that information. Thanks!
Also, since this involves string/UI changes, we need to do it in a minor release.
Comment #134
xjmIf we do add this description, I'd change this to something like:
"Add this node to promoted listings (like the default front page)".
I think talking about the default front page is fine, since that view automatically becomes the front page when you enable node module, and this text is also a part of node module. They are designed to work together by default, but can also be used in other ways.
That said, though, we've gone to some effort to remove unnecessary descriptions from the UI since having lots of words negatively impacts usability, so this would work against that a bit.
Comment #135
Bojhan CreditAttribution: Bojhan as a volunteer commentedIt's difficult :) This approach would likely remove some of the confusion, but create some other. Not sure if there is a easy way around it.
If we need a description, we should rethink this. What about "Add to promoted listings (e.g. front page)".
We can continue to consider this a major issue, as it affects the 99% of our audience. Authoring activities relating to major content hubs like the front page, tend to be essential in authoring workflows - and therefor likely that this issue affects a good part of our user base.
Comment #136
Bojhan CreditAttribution: Bojhan as a volunteer commentedComment #147
PasqualleI vote for #29338: Promoted/Sticky fields are outdated and confusing, find an alternative for them
Comment #148
xmacinfoWe are trying to fix a usability issue, not removing features used by multiple Drupal sites.
Comment #151
xjmComment #152
sonam.chaturvedi CreditAttribution: sonam.chaturvedi at Salsa Digital commentedPatch #129 does not apply successfully on 9.5.x-dev. Need Re-roll.
Comment #153
aarti zikre CreditAttribution: aarti zikre as a volunteer and at QED42 commentedComment #155
aarti zikre CreditAttribution: aarti zikre as a volunteer and at QED42 commentedComment #156
aarti zikre CreditAttribution: aarti zikre as a volunteer and at QED42 commentedTry to resolve fail test
Comment #157
aarti zikre CreditAttribution: aarti zikre as a volunteer and at QED42 commentedComment #158
smustgrave CreditAttribution: smustgrave at Mobomo commented@aarti zikre can you please provide an interdiff so we can see what was changed.
Comment #159
aarti zikre CreditAttribution: aarti zikre as a volunteer and at QED42 commentedFew changes and updatehook is still remaining will provide today.
Comment #160
aarti zikre CreditAttribution: aarti zikre as a volunteer and at QED42 commentedFinal Patch.
To see changes please run drush updb
Comment #161
smustgrave CreditAttribution: smustgrave at Mobomo commentedSo question on the post_update hooks. Are they needed? If someone made changes to the views frontpage won't that update override changes.
Comment #162
aarti zikre CreditAttribution: aarti zikre as a volunteer and at QED42 commentedyes, smustgrave as drupal is providing 2 default content type for that we are not able to made changes. Additionally the site which is currently live, which has their own content type so we i think we need the update hook. If you have any other alternative than happy to view in that way too.
Attaching final patch without error with interdiff
Comment #163
aarti zikre CreditAttribution: aarti zikre as a volunteer and at QED42 commentedComment #164
aarti zikre CreditAttribution: aarti zikre as a volunteer and at QED42 commentedplease review this
Comment #165
smustgrave CreditAttribution: smustgrave at Mobomo commentedIf the hooks are just changing descriptions and labels should the hooks do that instead? Just think reimporting the config especially a view will mess with existing sites
Comment #166
smustgrave CreditAttribution: smustgrave at Mobomo commentedAlso for interdiffs it’s suppose to be between the patch you changed so 160 and 162
Current one it’s difficult to see what was fixed
Comment #167
Berdirthe description shows up as an explanation in the edit form.
Agreed on the update functions, although this doesn't seem to update a view? But yes, we must absolutely not replace the whole confiig either way. The first update also doesn't do what the description says (update all config, it just updates page and blindly assumes that exists, but page is from the standard profile.
Instead, we need to update all existing base field overrides for all node types for promote if and only if the current label is the default. We also need to consider translations.
This uses technical terms like boolean and doesn't actually say anything more than the label already does.
The problem is that the actual meaning of promoted is going to vary depending on the site and even the node type, but we currently don't have an UI to expose that level of configuration, you can manually edit the field override though. I'd propose to not have a description in core for this.