Replace "Sticky at top of lists" with a more meaningful equivalent

Marking as a GHOP task so people know not to work on it.

Oh nevermind. :) I see what you're doing. Unmarking as a GHOP task. But yeah, if folks could give marco.robotangel a couple days to work on this that'd be swell. :)

Tested and working fine. The patch applies cleanly. Good work! I even like the way you worded it, and there are some around here who know how hard that is to do! ;-) I'm RTBC'ing this, so unless there are any objections to the text, it should probably get committed.

A note for you, though Marco. You should learn how to patch against core files from the root of the drupal directory. There's more info in the http://drupal.org/patch section of the Handbooks.

Are there other places where this might appear? The content overview page's filter form might not be the best to apply this change as well, but a bit of a look around would help in achieving consistency.

I didn't even think of that, but upon consideration, it seems like that's the only place I've ever seen it. Marco, mind doing a search through core for that phrase or others like it?

Very nice patch, Marco, and good catch, Gabor.

A quick grep through core (sorry I did Drupal 5, I realize now, but I didn't have 6 on my computer)

/drupal-core/drupal-5.3 ben$ grep -nHR sticky .

comes up with one important spot, other than the content overview page's filter (which should probably be changed also? Not really a space consideration is there?)

That spot is the default settings provided by content_types:

./modules/node/content_types.inc:162: 'sticky' => t('Sticky at top of lists'),./modules/node/node.module:1296:

And the admin filter:

'sticky' => array(
./modules/node/node.module:1297: 'label' => t('Make sticky'),
./modules/node/node.module:1298: 'callback' => 'node_operations_sticky',
./modules/node/node.module:1300: 'unsticky' => array(
./modules/node/node.module:1302: 'callback' => 'node_operations_unsticky',

Again, ignore line numbers but I bet the files are the same in D6.

will need to wait for d7 now with the lang code freeze. tag for newbie

It's been 1.5 years since Marco worked on this, think I can take over and close it out? :)

Patch Testing Instructions
This patch changes the label text of several things pertaining to making a node 'sticky'. There's five pages that this patch affects:

URL #1: /admin/build/types/add

Look in the Workflow Settings fieldset for Default Options and check the text for "Sticky (stays at top of content lists)".

URL #2: /admin/content/node

Look in the Update Options dropdown menu for a "Make sticky (stays at top of content lists)"

URL #3: /node/1/edit

Look for the changed text, "Sticky (stays at top of content lists)", under the Publishing Options [vertical tab].

URL #4: admin/settings/search

Near the bottom of the page, look for the "Sticky (stays at top of content lists)" beneath the Content Ranking factor.

URL #5: /admin/

blahblah.

Simpletest
Now that I've written out all of these instructions, it's starting to look like a Simpletest might be in order? Holla if you want one, and I'll add it.

Adding tags.

Woops! Apparently, one cannot change the text of

function node_action_info() {
  'node_make_sticky_action' => array(
    'type' => 'node',
    'description' => t('Make post sticky'),

to add a (stays at top of content lists) clause without messing up the Triggers simpletest line of

// Test 3: The action should be able to be unassigned from a trigger.
  $this->assertRaw(t('Action %action has been unassigned.', array('%action' => ucfirst($info['name']))), t('Check to make sure the @action action can be unassigned from the trigger.', array('@action' => $info['name'])));

so we'll just go without that one because I don't want to rewrite triggers' tests tonight. :)

I think it's unnecessary to write a test that accompanies the changes in this patch, since there are no functional changes introduced by this patch, only changes to texts wrapped in t(). Further, we need to update the simpletest that failed so that it knows about the new text, not the other way around.

Otherwise, this is great! :D

When you change the text for the "make sticky" action, you may also want to change the text for the "make unsticky" action to match.

If this has been approved by the Usability Team, what else needs to happen for it to get in to 7.x?

subscribing

Will have to try this again in D8.

No time to work this one, so freeing it up.

Why don't we ditch the sticky field in favor of a more general weight field?

This would provide the following advantages:

• The meaning of the term is more natural and consistent with Drupal usage elsewhere.
• It allows more choices than just "sticky" and "non-sticky".
• It doesn't use any more storage nor require any more overhead.

If anyone agrees, I'll roll a patch.

Removing tags which are no longer applicable.

I'm not sure anyone uses the sticky flag on nodes any more -- like the OP says, it's a throwback to Drupal's bulletin board-style origins.

And I'm not sure nodes should be carrying a weight flag either. If you wanted to weight nodes, that should be done via a FieldAPI weight field, surely?

We could just remove this from core completely, and if you actually want a 'sticky' flag you use flag module.

Re-titling then.

The problem is the upgrade path. Drupal promises to not lose any data between major versions. Discarding the sticky column/field requires we also discard the data. In order to remove it completely, we could add an upgrade-time option to remove the data completely. And the upgrade path defaults to converting it to a flag or weight field. That makes this non-trivial.

If you use the core forum module (or Advanced Forum, which is based on it), then you might use the sticky field still. I don't think it should necessarily be removed. That was not the original intent of this issue - it had a very minimally invasive patch when initially proposed.

If people really don't like the sticky bit on nodes, it could just be removed from the node form the way that the moderate bit was (and possibly added back in by forum.module?)

Those are both very good points -- the perfect is the enemy of the good :)

Let's wind this back down to the original issue, get this simple improvement in, and bikeshed the bigger picture in a new issue later.

Thanks, joachim. I just would hate to see another issue that was close to being resolved drag on for another few months...or years.

So it looks like there are two possible approaches:

1) Revise the text as in the patch for D7 that was approved previously (#197460-16: Replace "Sticky at top of lists" with a more meaningful equivalent)
2) Hide the sticky column from the node form, in light of #197460-24: Replace "Sticky at top of lists" with a more meaningful equivalent, and add it back in via hook_form_alter() for those using forum.module/Advanced Forum.

I would advocate simply for #1 for now. That patch simply needs a re-roll, the tests to be removed, and for the text to be changed on "make unsticky" action as well as "make sticky".

It would be a shame if this isn't fixed for D8. I'd like to briefly re-open the discussion of wording here, then get a new patch rolled that works for D8.

The latest patch in this issue changes the text to "Sticky (stays at top of content lists)". In a duplicate issue #1562804: "Sticky on top" is hard to understand, some other options were suggested:
1. "Pin to top of content lists"
2. "Sort at top of content lists"
3. "Always show at top of content lists"

I'm sceptical of the value of the word 'sticky'. It's not used in any UIs that I'm aware of except bulletin boards, which most users will not know. It's simply another jargon word. In terms of new verbs, [1] "pin" is more concrete (think corkboard) and familiar from the Windows taskbar and several other common UIs. [2] Sort is definitely not jargon, but the phrase "sort at top" is ambiguous because sorting usually involves all things in a list, but this is a one-off override. With [3], there is the problem that having this unchecked may somehow imply that the item may be hidden otherwise.

My suggestion is to change this to 'Pin to top of content lists', and remove the term 'sticky'. I'd love to get feedback from anyone who has observations on users working with this feature, or similar concepts in other applications.

EDIT for clarity and trying to be brief.

'Pin to top when shown in lists'
'Always at the top when shown in lists'

I find 'content lists' still quite abstract wording because what is content has such vague boundaries. Maybe my wording projects a bit clearer what the setting does and when it applies?

I would also love the possibility to disable this field depending on my needs like explained here:
http://drupal.stackexchange.com/questions/4612/how-to-disable-promote-to...

This should just be a standard field from the core Field API, or, just removed completely since you can replicate this functionality trivially for any fieldable entity in D8.

Removing it wouldn't allow for an upgrade path from Drupal 7.

Re #34: That's not true. We could certainly add a 'sticky' field on all nodes and update e.g. the /node view accordingly. It'd be a bit of work, but the upgrade path sometimes is. So if we decide we want to remove it, we can and should.

I am in agreement with the removal, BTW. Not changing title back, though, as there doesn't seem to be consensus around tha t(yet).

Also even if its just removed and nothing added back in place, the data can still be placed in a "temporary" table, eg. 'node_sticky_drupal_7' with nid and sticky. Similar plans are there for the node-copy translation module removal which will not have a core upgrade path. See #1952062: Remove legacy translation module in favor of content translation.

If we don't allow ourselves to do something like #35 and/or #36, we'll be stuck with things like this forever.

#36 is similar to how content migrate works for cck fields in D6 to D7.

This issue keeps swinging back and forth between a simple renaming of the label of an existing feature and removing the feature all together.

The original report is about the not-so-clear wording of the label, so discussing it's removal is not in scope here but needs it's own discussion. See #28 from 2.5 years ago :-)

@tstoeckler, Oh I see. I misunderstood "just removed completely".

Yoroy, I sort of disagree. Some UI issues are indicative of much larger problems: in this case, I don't think changing the wording of this feature is going to make the feature any more "usable" because the feature itself is redundant and irrelevant for most usability cases.

I'm in favour of removing this feature - it routinely confuses users in my experience. Maybe the fact that you can't keep your sticky content is not too much of an issue. If we keep this feature around, we just create a future where people think Drupal is an old-fashioned, message-board style CMS and it is far from that.

Thanks, I agree with that assesment Meeli. My comment was about trying to keep this issue limited to the original report, but that is indeed too narrow a discussion. There's no consensus around whether to keep the feature at all.

How do you think we could find out whehter to keep it or not?

"Sticky" is not good -- it is a techy term. Use instead "Pin". This is a term that has logic, and users are familiar with it because of Twitter, Pinterest, Windows, etc. usage.

"Pin to top of page". (alt: "Pin to top of list.")

Also, the verbage used on the node options are not consistent with that used on the Content page filter dropdown. They should match identically.

Hmmm...

Only tried this on one Notice that I wanted promoted to the top of the list, and it appeared that although I made it "sticky" - under Publishing - it did not seem to promote the item up the list. Is this a simple fix?

Literally from a client.

If the query or the view doesn't take "sticky" into account it is a useless feature. +1 for removing completely.

Hi

@i.bajrai : - The sticky at top of lists feature is still available and is working correctly , please check if your content was published or not as it works on published content.

after going through the whole issue , and following the original concept of changing the text to "Pin to top of content lists" from "Sticky at top of lists" .

This issue is being reviewed by the kind folks in Slack, #needs-review-queue-initiative. We are working to keep the size of Needs Review queue [2700+ issues] to around 400 (1 month or less), following Review a patch or merge request as a guide.

After so long this seems more like a feature request.

Tagging for usability review for the text change.
Also could use screenshots of the before and after

It seems like many websites use the idea of "pin" as mentioned previously, I'm +1 on renaming it "Pin to top of lists" or similar.