How to Show All Users Who Liked Post?

[Butiks]

How may I elegantly exhibit a list of usernames, separated by commas, underneath a post indicating users who have liked it?

Currently, on my SMF forum running version 2.1.3, only the number of users who have liked a post is being displayed. I seek guidance on which script code requires modification to achieve the desired presentation format.

[Julius_2000]

To see the persons who like the post, you can click "# of persons liked that post" and a popup window would come up listing all members. Or do you wish to display members all the time?

[Aleksi "Lex" Kilpinen]

It is a lot lighter on resources to present the list on demand like it is now, than it would be to form a real time list of all likes on a page for every page load at once.

[Arantor]

It was deliberately written to not do that for efficiency reasons. Yes, I know other systems do it, other systems take more resources on your server to do it, and it's possible for those systems to even list the wrong names if users change their names.

Changing it is a huge deal, unfortunately, needs rewrites to quite a bit of the likes system. What I wrote was designed to be efficient, and there isn't actually an efficient way to do what you're asking. You can just paper over the efficiency cracks.

[Butiks]

It is imperative that the nicknames of forum users who express their approval of a post be consistently exhibited. Your discussion of the significant burden on the forum creates the impression that you are cautioning me against taking a detrimental action - one that may cause the server to overheat due to the overwhelming display of user nicknames. 

However, it is worth noting that there are various optimization techniques available, including forum caching. Therefore, I fail to comprehend why it would be impracticable to display user nicknames.

[Kindred]

1- because the system is not designed to do so.
2- The short answer is no - we will not do what you are asking, because redesigning the system to be LESS optimized is not something we ever encourage - and, in this case, would be wasted effort, better spent in improving things that actually need improving.

3- Sure, *YOU* could take our code and go hog-wild. You could do all sorts of things that would make YOUR forum significantly more resource heavy...  We're not gonna do that.

4- your comments prove that you don't understand...

The current architecture does not store the likes log in the same space as the message itself. It only stores a count.  This means that, in order to pull the list of people who have liked a post - the data must be JOINed from another table.
Any time you start working across tables, your resource consumption goes up.
Since the current design ONLY pulls the likes data when specifically requested by a user, the resource use spikes, briefly, but remains, over-all, decent,
If someone was to implement what you asked for (all likers displayed all the time) -- that means that the JOIN action would have to be done for EVERY message in the viewed thread...   so, that's a possibility of 25 JOINs run either simultaneously or in sequence...    if you have increased the number of messages displayed on a single screen that 25 would only go up.

That's bad design.
Hell, even facebook only shows 1-2 likers until you query the "likes count" directly.

[Arantor]

It is imperative that the nicknames of forum users who express their approval of a post be consistently exhibited.

Why?

Your discussion of the significant burden on the forum creates the impression that you are cautioning me against taking a detrimental action

I made a choice when I designed and implemented it to conscious use fewer resources than other implementations, knowing that the majority of users who install SMF do so on resource-constrained servers. I made that design choice, and I stand by it.

I am not asserting that you shouldn't do it - other platforms do - but it comes at a significantly higher resource usage to keep it present and correct. If this is not a concern to you, fine, go nuts and implement it. Or go use XenForo or Invision Power Services' Suite which implement these features this way.

one that may cause the server to overheat due to the overwhelming display of user nicknames.

Overheat? No. Serve fewer requests concurrently, yes.

However, it is worth noting that there are various optimization techniques available, including forum caching. Therefore, I fail to comprehend why it would be impracticable to display user nicknames.

What, exactly, would you cache? How long for? Under what circumstances do you refresh that cache?

Every scenario that involves caching also involves invalidation of that cache, more importantly it must be able to respond to change. If a person's account is deleted, every like they issued must be removed - and thus every cache combination must also be removed. At a simple case this means you have to refresh the cache for every topic that they posted in, in every combination of the number of posts per page that this is viewed in (since this is the granularity that is in any way usable for caching). You can't cache the totality of posts in a topic for likes; unless you're only going to have short topics - I've seen systems with topics of 100k posts in a topic, where people tried to break the like system with 30+ likes per post. That one topic alone has literal millions of records of likes, and caching combinations on it are borderline impossible. The only way the topic didn't grind to a halt was to have the software not pre-fetch the names of all the likes.

This sounds to me an awful lot like 'something I don't understand the internals of must be simple'.

@Kindred you wouldn't need 25 JOINs, but you'd really want to keep it as a secondary query to fetch all of the names and hope to $deity you don't blow out either the join buffer or the PHP memory limit since by definition you will end up with at least 3x the list of total likes for a slice of posts in memory; it's not _so_ bad if you're only shifting *names*.

I mean, there's XenForo's solution which is to keep a semi-static cache of them in a TEXT field in the message row but that becomes extremely painful if users change their display name, something XF has a whole bunch of stuff to deal with (and it's not something people can necessarily just do, unlike SMF by default which allows this, and it's another of those cache invalidation questions, which is always one of the hardest applied computer science problems to solve). But that also blows out how much space the messages table takes, popular topics slow down (and then you need other caching solutions to prop *that* up), busy sites have been known to blow out the packet limit trying to keep that cache maintained, plus unless you have a big server and can keep decent amounts of the table in memory, you run into the fact you're fetching so much more data from disk all the time.

And why doesn't XF have the problems I describe? It does. Just folks who can sink $160 into their software tend to have better servers than the folks running free software.

It's not like I didn't think about all of this when I implemented it. I had to design and implement for the typical SMF hosting environment. I'm sorry you're not happy with the choices I made, but I stand by them and I have no plans on rewriting the code to change this.

[Diego Andrés]

The only thing that ever intrigued me about the likes counter is that we used to have the language debate of users vs members.
Now we have users vs members vs people

[Arantor]

Wasn't a conscious choice to phrase it as 'people' in likes, but I think whatever I was thinking revolves around the fact that it's "3 people like this." and "You and 2 other people like this." I think, whatever conscious choice it was, was around humanising it rather than it being "You and 2 other members like this."

If you look at a lot of the real internal code - especially the oldest - code in SMF, you'll see quite a delineation between things that are members and users, specifically that users includes people not currently members, which is why it's $user_info because it includes *guests*, while it's $memberContext because it can only be members' data. A lot of the naming conventions got blurred over the years.

[Doug Heffernan]

And why doesn't XF have the problems I describe?

something XF has a whole bunch of stuff to deal with

Why do you keep mentioning xf all the time? Who cares about how xf does things. It 's a piece of overpriced you know what that it has been asleep for the past couple of years. We have our own way of doing things.

[Aleksi "Lex" Kilpinen]

I would assume that was just to compare different approaches to the same issue - Since, xF has what the OP was asking for, and Arantor is familiar with both.

[Arantor]

Because it's a useful point of comparison. It is instructive to have tried other platforms and observed the differences, and the similarities. You will also note I mentioned IPS which has the same feature but the price tag is... higher. But XF, IPS and Woltlab all transcended beyond likes some time ago into the reactions space some time ago.

Discourse doesn't show any names, just the total likes. Flarum shows the first few names but the comparative lack of features and steeper setup effort may be a deal breaker. phpBB doesn't have likes in core, MyBB has reputation (approximately = karma from 2.0)

Seeing what everyone else does is useful.

[Kindred]

It is definitely useful to consider what others in the market are doing....

(note, Doug, that does not mean that we should duplicate what others are doing, because, at times it does not fit our model (see likes, as discussed above))

That being said, I'd love to see a transition of likes to reactions in a future version of SMF.   It's one of the few things that Facebook's drunk monkey UI programmers actually started to do right (before apparently getting further drunk and screwing the pooch)

[Arantor]

Reactions was actually discussed in 2013 as a possibility instead of likes. Decision at the time was no one would use it. Then 2-3 years later Facebook did it, proving that decision wrong.

[Kindred]

yeah... hindsight is 20/20.   shouldn't keep us from doing it the right way in a future version.

[Steve]

I just woke up so I haven't looked but isn't there a reactions mod around here somewhere?

(and I get the point of having it be part of the core code vs. a mod)

[Shades.]

I just woke up so I haven't looked but isn't there a reactions mod around here somewhere?

(and I get the point of having it be part of the core code vs. a mod)

SMF Versatile Post Reactions

And SMFHacks has "Awesome Post Ratings" mod.

[Arantor]

Sure, we have these as mods just as we had likes mods before likes were core.

I have every belief a future version will include reactions as a core feature.

[Steve]

SMF Versatile Post Reactions

But that one needs updating and I looked at vbgamer's mod which looks interesting.


@Arantor - as I said, I get the whole point of having it as part of the core vs. being a mod and I agree, future versions should include it

[Arantor]

Just maybe not as late as 2034, mkay?