Liking module?

[Tyssen]

Are there any modules for Processwire which allow site visitors to 'like' pages or content?

And unrelated but for the same site I'm building, I need to be able to output entries/pages in different layouts on the front end. It's for a photographer's site with photos (each linking to a gallery so each would be a page or entry) and the layout calls for photos to be displayed in three different layout formats:

• full width image
• half width image floated left with two other half width images equal to half the height of the left floated image
• same layout as above but with the larger image floated right

So other than the full width images, other entries have to be in groups of three (one larger image left or right next to two smaller ones).

If it was always going to be in the same sequence, then it would be no problem, but the site author needs to be able to control the presentation.

Any idea how to approach it?

[onjegolders]

Hi Tyssen, regarding the likes module. I've recently implemented a liking system that isn't as yet moduralised but that works well. I'd be happy to point you in the right direction.

[Tyssen]

Yeah, that'd be great if you could. But before going there, I guess I need to determine whether PW is the right fit for this job and there's another requirement that's come up which I'm unsure about.

As well as liking pages/entries, there's a requirement that individual images can also be shared on social networks, but each image should have its own page (other than just a URL to the image itself) so something like domain.com/image/entry_id/image_id/ and then the image template would know to find an entry ID from segment 2 of the URL and image based on the value of segment 3. As files don't actually have IDs in PW, not sure if that's possible.

[Tyssen]

Looks like the social media requirement has been shelved, so if you have time to explain a little about how you implemented your liking system André, that'd be great.

[ryan]

As well as liking pages/entries, there's a requirement that individual images can also be shared on social networks, but each image should have its own page (other than just a URL to the image itself) so something like domain.com/image/entry_id/image_id/ and then the image template would know to find an entry ID from segment 2 of the URL and image based on the value of segment 3. As files don't actually have IDs in PW, not sure if that's possible.

Individual images may not have a dedicated ID, but the page ID they belong to + the filename is always unique, so that's all you'd need. Of course, you could always manage pages-to-images on a 1-to-1 basis, but if you wanted to have a page with multiple images on it, each with their own URL, you could also enable URL segments for your template and output them like this:

$filename = $input->urlSegmentStr; 
$image = $filename ? $page->images->get($filename) : null;

if($image && $image instanceof Pageimage) {
  // output your image content
  echo "<img src='$image->url' alt='$image->description' />";
  echo "<p>$image->description</p>";

} else {
  // output your regular content
  echo "<h1>$page->title</h1>$page->body";
}

With regard to a likes system, is what you are looking for something similar to the likes system you see in our sites directory or the recommendations system in our modules directory (both are actually the same system). If so I can pass along a little more info on how that was done. 

[Martijn Geerts]

The trickiest part is the uniqueness of the person who triggers the action. I don't know how to do that, something that should work in 80% of the times.

Sometimes I think you've to do it with Social Media, but thats probably a to big dependancy. Double opt-in is not the way to go. Browser sniffing & cookie methoses maybe.

Really I'm just guessing here.

[Tyssen]

With regard to a likes system, is what you are looking for something similar to the likes system you see in our sites directory or the recommendations system in our modules directory (both are actually the same system). If so I can pass along a little more info on how that was done. 

Yeah, the likes in the site directory.

[Tyssen]

Hi Ryan, would you be able to follow up with the info about the sites directory and liking that you mentioned above?

[marcus]

In case you're looking for a system that allows logged in users to flag/like and unflag/unlike certain pages, please have a look at my rudimentary site profile here: https://processwire.com/talk/topic/5984-release-rudimentary-knowledge-base-site-profile/ - unfortunately it isn't a module ( - yet, since I'm planning to rewrite this profile from scratch)

[Tyssen]

I actually need it for guests (not logged in) to be able to like content.

[mr-fan]

http://www.phpgang.com/how-to-create-like-unlike-system-in-php-mysql-and-jquery_410.html

while the DB and php part have to modified to PW usage...i've not the time to dive deeper into this time - but i' think the use of a hidden integer field that could set +1 as counting the entries would do the trick.

regards mr-fan

[Tyssen]

The way you can like entries in the PW sites directory is pretty much the way I want it to work, so ideally, would like to find out how that's done. Ryan?

[LostKobrakai]

What you can see by inspecting the page is, that if you click the link, which just points to the to-be-liked-page. The pagereload is then prevented with jQuery and I think the like is saved via a ajax call. Uniqueness is done via cookies. "likes_likes" & "likes_likes_ready" which exist two times, one for "processwire.com" (sites) and one for "modules.processwire.com". "likes_likes_ready" seems to be a ";" seperated string of just the ids of the liked pages, while "likes_likes" is a ";" seperated string of what seems like "id.timestamp". 

Guessing from a logic standpoint and the expiration dates, "likes_likes_ready" is written before the ajax call, in case it fails. "likes_likes" is written, if the ajax call responds or I think at the next pagereload, at least not before the like is saved to the database. The timestamp should be there to avoid duplication. 

As I don't get a undo option if I visit the same module in a different browser it seems like cookies are the only way to limit the option to like a page. That's not the most "secure" way of doing it, because as you can see I could at least like three times with the three browsers on my computer, I could remove the cookies and even some people let the browser automatically trash all cookies with closing the browser. I don't know if Ryan has any backend solution to limit spam liking of modules, but I think there's to less benefit in liking sites and modules, to justify the efforts for the user to do so. 

That being said to the less technical part. Most people do not really know or care about cookies. Maybe some kill them while resetting their browser history, but for the most part this way should work. If there isn't much benefit from having the likes I don't think much people would care about it being exploitable. But with laws, that say the user needs to confirm, that you're allowed to save cookies, at least they are aware that you save stuff to cookies. That's missing here on processwire.com, but google and many other sites are now asking before saving cookies. 

So it's up to you if you want a maybe save way of knowing if someone already liked your page or if you need a login (social media or own) to like your pages. Even browser sniffing and advanced stuff aren't more secure than cookies, as modern developer tools can pretend nearly everything.

[ryan]

FieldtypeLikes is a module I've been working on (it's what is used here on the PW sites, as well as on CMSCritic). I've just been trying to find the time to finish it up so that others can use it, and hopefully can here soon. Tyssen I was thinking I could get you to beta test since you've got a more immediate need?

Here's a section from the documentation which may answer some of the questions above:

Likes Fieldtype for ProcessWire

 

This Fieldtype enables you to have a "like" button that users can click on to like a particular page and have that be remembered. The fieldtype itself stores a single integer representing the number of likes each page has in total. As a result, the field can be used for the purpose of sorting pages, i.e. "most liked pages."

 

FieldtypeLikes also adds a $session->getLikedPages(); that returns a PageArray of pages that the current session has clicked Like on. The liked pages are  remembered with a cookie for up to 30 days. This enables you to have a separate page (or perhaps a sidebar on every page) that for example shows the user bookmarks of pages they liked.

 

Before deciding whether this Fieldtype is suitable for your particular application, be sure to read the section on preventing duplicate likes.

Preventing duplicate likes

 

FieldtypeLikes is not connected with the user system, and may be used anonymously via any page on your site. The benefit is that anyone visiting can "like" things and generate a list of likes (for their own review), without having to login or create an account. That makes it much more likely that users will participate in liking pages and making use of what this module provides.

 

The drawback to this approach is that it may be difficult to prevent one user from trying to manipulate the quantity of likes, perhaps trying to boost the rank of a page they have some interest in. Beyond cookies (which we use), in order to limit the potential for duplication, FieldtypeLikes connects likes IP addresses and remembers them (server side) for a week. As a result, there is a limit of 1-like, per page, per IP address, per week. While not ideal, this is a necessary compromise in order to have some protection for the data.

 

Note that a very determined person could still use proxy servers or other methods of obtaining unique IP addresses. So we have also implemented some additional methods of protection. But ultimately you should always remember that if someone is determined enough, its impossible to prevent them from finding some way to manipulate the quantities of likes. As a result, do not use likes data for making decisions on hiring/firing, awards, grants or anything to be taken too seriously. That being said, I do feel the solutions we have implemented here are stronger than other anonymous rating systems I have come across, thus far. But always remember that any anonymous voting tool is open to manipulation and the results should always be take in that context, whether from this tool, or any other you've ever used or seen. 

 

 

[LostKobrakai]

An addition to the "Preventing duplicates" topic. In Germany providers are forced by law, to change the IP of their users at least every 24h. In Austria, if I remember correctly it's even once per 8 hours. So while saving the IP is a usable way of preventing to much spam, you should always be aware, that you could also prevent the wrong user to like your stuff. 

[ryan]

So while saving the IP is a usable way of preventing to much spam, you should always be aware, that you could also prevent the wrong user to like your stuff. 

Relying on cookies alone is just not enough. Everything you do to trying to maintain uniqueness with anonymous requests is a compromise. I think remembering the IP for some length of time (which is configurable, btw) is a necessary and worthwhile compromise for most. 

[LostKobrakai]

Sure, I didn't intent to criticize your implementation, but it's good to know such things, if one plans to use/configure such a likeing system.

[Tyssen]

That sounds fine Ryan. Preventing determined people from liking content over and over isn't really an issue for the site in question.