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.

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

CommentFileSizeAuthor
#162 interdiff#129-#160.txt47.84 KBaarti zikre
#162 987242_161.patch20.91 KBaarti zikre
#160 interdiff#129-#160.txt48.12 KBaarti zikre
#160 987242_160.patch21.18 KBaarti zikre
#159 interdiff#129_156.txt46.08 KBaarti zikre
#156 987242_156.patch19.19 KBaarti zikre
#153 promoted_to_front-987242-153.patch20.96 KBaarti zikre
#129 interdiff.txt3.03 KBeyilmaz
#129 promoted_to_front-987242-129.patch16.17 KBeyilmaz
#124 promoted_to_front-987242-124.patch14.79 KBalvar0hurtad0
#124 interdiff.txt4.23 KBalvar0hurtad0
#123 Screen Shot 2014-11-28 at 3.26.31 PM.png128.32 KBlauriii
#123 Screen Shot 2014-11-28 at 3.28.02 PM.png63.32 KBlauriii
#123 Screen Shot 2014-11-28 at 3.26.09 PM.png63.39 KBlauriii
#121 promoted_to_front-987242-121.patch10.56 KBhussainweb
#118 the_promoted_to_front-987242-118.patch7.24 KBalvar0hurtad0
#115 the_promoted_to_front-987242-115.patch5.22 KBScionar
#111 promoted_to_front-987242-111.patch13.38 KBhussainweb
#111 interdiff-100-111.txt543 byteshussainweb
#100 promoted_to_front-987242-100.patch13.39 KBhussainweb
#98 promoted_to_front-987242-98.patch13.39 KBhussainweb
#96 promoted_to_front-987242-96.patch12.63 KBhussainweb
#85 the_promoted_to_front-987242-85.patch52.59 KBhussainweb
#83 interdiff.txt37.63 KBalansaviolobo
#83 the_promoted_to_front-987242-83.patch32.87 KBalansaviolobo
#74 node-promoted-987242-74.patch59.76 KBpplantinga
#71 node-promoted-987242-71.patch60.1 KBpplantinga
#69 node-promoted-987242-69.patch56.37 KBpplantinga
#58 node-promoted-987242-58.patch56.46 KBpplantinga
#47 node-promoted-987242-47.patch15.82 KBhussainweb
#44 node-promoted-987242-44.patch12.57 KBpplantinga
#38 node-promoted-987242-37.patch15.98 KBK.MacKenzie
#38 interdiff.txt2.72 KBK.MacKenzie
#37 node-promoted-987242-37.patch18.09 KBK.MacKenzie
#37 interdiff.txt3.37 KBK.MacKenzie
#27 node-frontpage-987242-27.patch16.63 KBxjm
#27 interdiff-promoted.txt2.97 KBxjm
#23 node-frontpage-987242-22.patch13.67 KBxjm
#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
#16 interdiff-7.txt1.29 KBxjm
#14 node-frontpage-987242-14.patch12.4 KBxjm
#14 interdiff-14.txt4.75 KBxjm
#13 node-promoted.patch8.33 KBxjm
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

Devin Carlson’s picture

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.

jenlampton’s picture

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 ;)

jenlampton’s picture

joachim’s picture

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

webchick’s picture

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.

joachim’s picture

Oh... duh. Sorry!

cvdenzen’s picture

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.

jenlampton’s picture

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.

David_Rothstein’s picture

Title: Rename or remove "Promoted to front page" checkbox if default front page is overridden » The "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...

webchick’s picture

Issue tags: -D8UX usability +Usability

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.

xjm’s picture

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

ditcheva’s picture

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.

xjm’s picture

Status: Active » Needs review
FileSize
8.33 KB

Alrighty then.

xjm’s picture

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.

Berdir’s picture

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.

xjm’s picture

Status: Needs work » Needs review
FileSize
1.29 KB
13.09 KB

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

xjm’s picture

FileSize
1.78 KB

That is not the right interdiff.

oresh’s picture

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?

xjm’s picture

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

oresh’s picture

Status: Needs review » Reviewed & tested by the community

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

webchick’s picture

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.

webchick’s picture

Status: Reviewed & tested by the community » Needs work

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

xjm’s picture

FileSize
593 bytes
13.67 KB

"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

catch’s picture

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.

xjm’s picture

Status: Needs work » Needs review

Not sure why I never marked this NR.

oresh’s picture

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.

xjm’s picture

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.

Berdir’s picture

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

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

Berdir’s picture

David_Rothstein’s picture

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.

oresh’s picture

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.

Berdir’s picture

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.

xjm’s picture

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

peaton’s picture

Hey - Working on the issue summary #drupalcon portland

K.MacKenzie’s picture

Assigned: Unassigned » K.MacKenzie

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

peaton’s picture

Issue summary: View changes

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

peaton’s picture

Issue summary: View changes

added links for related issues

peaton’s picture

Issue summary: View changes

updated links to related issues

K.MacKenzie’s picture

Assigned: K.MacKenzie » Unassigned
Status: Needs work » Needs review
FileSize
3.37 KB
18.09 KB

Updated patch #27 with twig changes.

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

K.MacKenzie’s picture

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.

Berdir’s picture

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.

Berdir’s picture

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

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

xjm’s picture

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.

xjm’s picture

Issue summary: View changes

small wording tweaks to proposed resolutions

pplantinga’s picture

Reroll patch, also with comments wrapped at 80 chars.

pplantinga’s picture

Status: Needs review » Reviewed & tested by the community

Set to RTBC.

tim.plunkett’s picture

Status: Reviewed & tested by the community » Needs work
hussainweb’s picture

Status: Needs work » Needs review
FileSize
15.82 KB

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.

hussainweb’s picture

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

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

pplantinga’s picture

Status: Needs review » Reviewed & tested by the community

Looks good to me.

David_Rothstein’s picture

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.

hussainweb’s picture

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.

pplantinga’s picture

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.

ditcheva’s picture

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

tim.plunkett’s picture

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

Berdir’s picture

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 ;)

pplantinga’s picture

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?

pplantinga’s picture

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

pplantinga’s picture

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.

David_Rothstein’s picture

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

David_Rothstein’s picture

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.

cweagans’s picture

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.

pplantinga’s picture

Status: Needs work » Needs review

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

David_Rothstein’s picture

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.

pplantinga’s picture

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.

K.MacKenzie’s picture

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.

pplantinga’s picture

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.

pplantinga’s picture

Let's try that again.

pplantinga’s picture

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.

pplantinga’s picture

Status: Needs work » Needs review
FileSize
59.76 KB

And again.

klonos’s picture

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.

klonos’s picture

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

pplantinga’s picture

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?

klonos’s picture

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

cweagans’s picture

Berdir’s picture

Status: Needs review » Needs work

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

Anonymous’s picture

Issue summary: View changes

was a random failure. passed tests. -c

alansaviolobo’s picture

Status: Needs work » Needs review
FileSize
32.87 KB
37.63 KB

rerolled the patch.

Status: Needs review » Needs work

The last submitted patch, 83: the_promoted_to_front-987242-83.patch, failed testing.

hussainweb’s picture

Status: Needs work » Needs review
FileSize
52.59 KB

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

Status: Needs review » Needs work

The last submitted patch, 85: the_promoted_to_front-987242-85.patch, failed testing.

hussainweb’s picture

All expected failures. I would love to hear from someone if we are still considering this and then take this forward.

webchick’s picture

Status: Needs work » Postponed (maintainer needs more info)

Hm. 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).

hussainweb’s picture

Issue summary: View changes
Status: Postponed (maintainer needs more info) » Needs work
Issue tags: -Needs issue summary update

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

hussainweb’s picture

Issue summary: View changes

Minor fixes in the summary.

ditcheva’s picture

My vote: I'm in favor of resolution #1 (rename the checkbox) and like the proposed "Featured content" label.

lauriii’s picture

Issue tags: -Novice

I wouldn't consider this as a novice issue anymore.

Berdir’s picture

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

hussainweb’s picture

It 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).

hussainweb’s picture

Status: Needs work » Needs review
FileSize
12.63 KB

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

Status: Needs review » Needs work

The last submitted patch, 96: promoted_to_front-987242-96.patch, failed testing.

hussainweb’s picture

Status: Needs work » Needs review
FileSize
13.39 KB

Fixing the test failure.

Berdir’s picture

Status: Needs review » Needs work
  1. +++ b/core/modules/node/config/install/system.action.node_unpromote_action.yml
    @@ -1,5 +1,5 @@
     id: node_unpromote_action
    -label: 'Remove content from front page'
    +label: 'Remove content'
    

    That's not correct ;)

    Not sure how to write this..

  2. +++ b/core/modules/node/src/Plugin/Action/DemoteNode.php
    @@ -14,7 +14,7 @@
      *   id = "node_unpromote_action",
    - *   label = @Translation("Demote selected content from front page"),
    + *   label = @Translation("Demote selected content"),
      *   type = "node"
    

    This uses Demote instead of Remove, seems like we can use the same above?

hussainweb’s picture

Status: Needs work » Needs review
FileSize
13.39 KB

Whoa! Nice catch. I don't know how I missed that. Thanks!

Status: Needs review » Needs work

The last submitted patch, 100: promoted_to_front-987242-100.patch, failed testing.

Status: Needs work » Needs review
dawehner’s picture

Status: Needs review » Reviewed & tested by the community

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

hussainweb’s picture

@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. :)

catch’s picture

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

David_Rothstein’s picture

Status: Reviewed & tested by the community » Needs review
Issue tags: +Needs usability review
  1. This was marked for usability review above (I think the tag was removed by mistake) but that hasn't been reviewed yet. "Promoted" still seems like a mostly meaningless label to me, whereas the current checkbox is really clear...

    Also:

    -      '#title' => t('Promoted to front page'),
    +      '#title' => t('Mark as Promoted'),
    

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

  2. The issue summary is missing the option that was previously discussed of trying to make Drupal smart enough to automatically show "promoted to front page" only when it applies. I'll add that.
  3. Finally:

    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.

    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?

David_Rothstein’s picture

Issue summary: View changes

Added option #5 to the issue summary, for automatically hiding or rewording the "promoted to front page" checkbox only when it doesn't apply.

hussainweb’s picture

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

Berdir’s picture

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

David_Rothstein’s picture

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

hussainweb’s picture

FileSize
543 bytes
13.38 KB

Making changes as per #106 and #110. Leaving it for review.

alansaviolobo’s picture

jhedstrom’s picture

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

Patch no longer applies.

Scionar’s picture

Assigned: Unassigned » Scionar
Scionar’s picture

Assigned: Scionar » Unassigned
Status: Needs work » Needs review
FileSize
5.22 KB

Unfinished while doing reroll.

Status: Needs review » Needs work

The last submitted patch, 115: the_promoted_to_front-987242-115.patch, failed testing.

lauriii’s picture

Issue tags: +Novice
alvar0hurtad0’s picture

Status: Needs work » Needs review
FileSize
7.24 KB

Rerrolled patch

lauriii’s picture

Issue tags: -Needs reroll

We still need beta evaluation block to the issue summary

hussainweb’s picture

Issue tags: -Novice

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

hussainweb’s picture

Oops, missed the patch.

Bojhan’s picture

Whats there to review here? Is there a latest screenshot?

lauriii’s picture

Node update form looks good on bartik & seven:

There's still frontpage mention on the operations select on the node listing:

alvar0hurtad0’s picture

Status: Needs work » Needs review
FileSize
4.23 KB
14.79 KB

Patch 121 whith 123 suggestions.

kattekrab’s picture

I'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

kattekrab’s picture

+++ b/core/modules/book/config/install/core.base_field_override.node.book.promote.yml
@@ -8,7 +8,7 @@ field_name: promote
+description: 'A boolean indicating whether the node should be marked as promoted.'

I've suggested

"Show this content in featured regions or lists."

at #2350013: Descriptions for Promotion Options are too technical

Status: Needs review » Needs work

The last submitted patch, 124: promoted_to_front-987242-124.patch, failed testing.

eyilmaz’s picture

Status: Needs work » Needs review
FileSize
16.17 KB
3.03 KB

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

Bojhan’s picture

Issue tags: -Needs usability review

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

Anonymous’s picture

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

Version: 8.0.x-dev » 8.1.x-dev

Drupal 8.0.6 was released on April 6 and is the final bugfix release for the Drupal 8.0.x series. Drupal 8.0.x will not receive any further development aside from security fixes. Drupal 8.1.0-rc1 is now available and sites should prepare to update to 8.1.0.

Bug reports should be targeted against the 8.1.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.2.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

xjm’s picture

Version: 8.1.x-dev » 8.2.x-dev
Issue summary: View changes
Issue tags: +Needs usability review, +D8 major triage deferred

So 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:

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

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:

  1. Changing the label to "Promote", "Promote", or something less specific would be desirable, since the front page is not necessarily the front page view
  2. Whether this should be considered a major usability bug or a normal one.

Deferring major triage on that information. Thanks!

Also, since this involves string/UI changes, we need to do it in a minor release.

xjm’s picture

+++ b/core/modules/book/config/install/core.base_field_override.node.book.promote.yml
@@ -7,8 +7,8 @@ id: node.book.promote
+description: 'A boolean indicating whether the node should be marked as promoted.'

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

Bojhan’s picture

It'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.

Bojhan’s picture

Issue tags: -Needs usability review

Version: 8.2.x-dev » 8.3.x-dev

Drupal 8.2.0-beta1 was released on August 3, 2016, which means new developments and disruptive changes should now be targeted against the 8.3.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.3.x-dev » 8.4.x-dev

Drupal 8.3.0-alpha1 will be released the week of January 30, 2017, which means new developments and disruptive changes should now be targeted against the 8.4.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.4.x-dev » 8.5.x-dev

Drupal 8.4.0-alpha1 will be released the week of July 31, 2017, which means new developments and disruptive changes should now be targeted against the 8.5.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.5.x-dev » 8.6.x-dev

Drupal 8.5.0-alpha1 will be released the week of January 17, 2018, which means new developments and disruptive changes should now be targeted against the 8.6.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.6.x-dev » 8.7.x-dev

Drupal 8.6.0-alpha1 will be released the week of July 16, 2018, which means new developments and disruptive changes should now be targeted against the 8.7.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.7.x-dev » 8.8.x-dev

Drupal 8.7.0-alpha1 will be released the week of March 11, 2019, which means new developments and disruptive changes should now be targeted against the 8.8.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.8.x-dev » 8.9.x-dev

Drupal 8.8.0-alpha1 will be released the week of October 14th, 2019, which means new developments and disruptive changes should now be targeted against the 8.9.x-dev branch. (Any changes to 8.9.x will also be committed to 9.0.x in preparation for Drupal 9’s release, but some changes like significant feature additions will be deferred to 9.1.x.). For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 8.9.x-dev » 9.1.x-dev

Drupal 8.9.0-beta1 was released on March 20, 2020. 8.9.x is the final, long-term support (LTS) minor release of Drupal 8, which means new developments and disruptive changes should now be targeted against the 9.1.x-dev branch. For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 9.1.x-dev » 9.2.x-dev

Drupal 9.1.0-alpha1 will be released the week of October 19, 2020, which means new developments and disruptive changes should now be targeted for the 9.2.x-dev branch. For more information see the Drupal 9 minor version schedule and the Allowed changes during the Drupal 9 release cycle.

Version: 9.2.x-dev » 9.3.x-dev

Drupal 9.2.0-alpha1 will be released the week of May 3, 2021, which means new developments and disruptive changes should now be targeted for the 9.3.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Pasqualle’s picture

xmacinfo’s picture

We are trying to fix a usability issue, not removing features used by multiple Drupal sites.

Version: 9.3.x-dev » 9.4.x-dev

Drupal 9.3.0-rc1 was released on November 26, 2021, which means new developments and disruptive changes should now be targeted for the 9.4.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.4.x-dev » 9.5.x-dev

Drupal 9.4.0-alpha1 was released on May 6, 2022, which means new developments and disruptive changes should now be targeted for the 9.5.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

xjm’s picture

Issue tags: -D8 major triage deferred
sonam.chaturvedi’s picture

Patch #129 does not apply successfully on 9.5.x-dev. Need Re-roll.

aarti zikre’s picture

Status: Needs review » Needs work

The last submitted patch, 153: promoted_to_front-987242-153.patch, failed testing. View results

aarti zikre’s picture

Assigned: Unassigned » aarti zikre
aarti zikre’s picture

Try to resolve fail test

aarti zikre’s picture

Status: Needs work » Needs review
smustgrave’s picture

@aarti zikre can you please provide an interdiff so we can see what was changed.

aarti zikre’s picture

Status: Needs review » Needs work
FileSize
46.08 KB

Few changes and updatehook is still remaining will provide today.

aarti zikre’s picture

Final Patch.
To see changes please run drush updb

smustgrave’s picture

So question on the post_update hooks. Are they needed? If someone made changes to the views frontpage won't that update override changes.

aarti zikre’s picture

yes, 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

aarti zikre’s picture

Assigned: aarti zikre » Unassigned
aarti zikre’s picture

please review this

smustgrave’s picture

If 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

smustgrave’s picture

Also 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

Berdir’s picture

+++ b/core/modules/node/src/Entity/Node.php
@@ -332,7 +332,8 @@ public static function baseFieldDefinitions(EntityTypeInterface $entity_type) {
 
     $fields['promote'] = BaseFieldDefinition::create('boolean')
-      ->setLabel(t('Promoted to front page'))
+      ->setLabel(t('Promote'))
+      ->setDescription(t('A boolean indicating whether the node should be marked as promoted.'))
       ->setRevisionable(TRUE)
       ->setTranslatable(TRUE)
       ->setDefaultValue(TRUE)
diff --git a/core/modules/node/src/NodeTypeForm.php b/core/modules/node/src/NodeTypeForm.php

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

Version: 9.5.x-dev » 10.1.x-dev

Drupal 9.5.0-beta2 and Drupal 10.0.0-beta2 were released on September 29, 2022, which means new developments and disruptive changes should now be targeted for the 10.1.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 10.1.x-dev » 11.x-dev

Drupal core is moving towards using a “main” branch. As an interim step, a new 11.x branch has been opened, as Drupal.org infrastructure cannot currently fully support a branch named main. New developments and disruptive changes should now be targeted for the 11.x branch, which currently accepts only minor-version allowed changes. For more information, see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.