Introducing Like feature

Hi everyone,

this is a proposal to introduce a Like button in XWiki documents. The motivation behind this is to provide some more social engagement on XWiki pages. A design page has already been documented with some details about the usecases:

Note that to start the Like feature will be only implemented for Pages but there’s already a request to make Likes available for comments. This is important to be taken into account for development choices.

Here’s some ideas about the technical choices behind this feature.


The main UI is a Like button allowing to perform a Like and displaying the number of Likes on the page.
Preliminary discussions about the feature led to put this button at the bottom of the Page content, next to the tags.
The design of the button itself is still in debate, some designs are proposed on and can be voted for on

Along with this button, an interaction should be available to display the list of users who liked the page. I propose to use a modal available when clicking on the button to display clearly this information.
And so I also propose a configuration mechanism allowing to chose which kind of behaviour should be available when clicking on the button:

  • immediately like when clicking and open the modal once like (with a possibility to unlike from the modal)
  • open the modal when clicking, and display the possible action on the modal (like if not liked already else unlike)
  • never open the modal (so never be able to see the list of likers) and always perform action when clicking: immediately like if not, or unlike with a confirmation if already liked.

Besides this button, a new UI should appear in User Profile to display the list of pages liked.
This UI will take the form of a new dedicated entry in the User Profile Menu leading to a table listing the Liked pages.

Finally, the page indexes should also be able to display the Like numbers.


Likes as Ratings

Some preliminary discussions about that feature led to the idea of reusing the Ratings for storing Likes.
This has pros and cons.

  1. Ratings extension already exist so we can reuse already existing APIs
  2. it’s a feature request to be able to migrate existing Ratings to Likes with a provided threshold (e.g. Ratings > 3 are considered as a Like)

3. the Ratings extension is not exactly in good shape: it’s very badly tested and the existing store are not really scalable
4. Ratings and Likes are not exactly the same thing: for Ratings the idea is to always display in the UI an average number of Ratings, while for Like we want the exact number of Likes. Besides that depending of the configuration we might want to retrieve the full list of likers or not when displaying the button.


Besides the question of using Ratings or not for storing Likes, there’s also the question of storing Likes in a NoSQL DB, or in XWIKI standard DB.

First choices

As a start, I first implemented a Like based on Ratings and for scalability purpose I introduced a dedicated Solr Store for ratings.
This will allow:

  1. to migrate easily Ratings to Like
  2. to be scalable for the Like storage which can be quickly very large

What we usually do and I find that very useful is to list the Use Cases (or requirements) in a bullet list so that we’re sure that the implementation proposal supports them. And have an ID for each requirement/usecase (e.g. UC1, UC2, etc). This allows us to discuss about them and refer to them easily.

So this needs to be added as a requirement.

I just added them.

On your button screenshot proposals, I don’t see where the user would click to see the display the list. It cannot be on the button itself as that should like/unlike the page. I think it’s missing a visual proposal for it. One idea would be a drop down with an arrow, similar to the Edit button in xwiki (in advanced mode).

Sounds good. I propose a LT UI so that it can be filtered/sorted. With 2 column: Location + Actions. And have a Like/Unlike action to do it right from the LT.

This one should be done with a UIXP or XClass, so that it’s not hardcoded and so that the Like extension can be installed/uninstalled. I wouldn’t add this feature until we can do it cleanly (i.e. I wouldn’t hardcode it). If you still hardcode it then please schedule it with top priority to be fixed in the next release, and create a jira. This is adding technical debt so we’ll need to fix it ASAP.

I still believe it’s the same thing and that Like = Ratings with a scale of 2 (0 and 1). Being able to retrieve how many users have selected a number in the scale is needed for Ratings too (not just for Like). Retrieving the full list of likers is also covered since we also need to be able to retrieve the full list of users who rated N.

See also

About I’d have liked to see proposal with like being on the same like as Tags and “created by”. I think we might need to change the visual for Tags too to be consistent with Likes. Or use “+” for both.

But I’d prefer them to be on the same line to save vertical space and for consistency and better look. I’d put likes before tags probably since tags can take more horizontal space.

This is also missing the RDBMS vs NoSQL discussion for storing ratings and likes. See the comments at

That’s why I introduced the configuration I explained. One of the configuration is to allow acting as you propose, and you don’t have access to the likers. But another config is always displaying the modal with information about the likers, and you can like from it. Finally the latest default configuration, is to like first when clicking and when clicking again to display the modal with the information about likers (and to allow unlike).

I think it’s really a bad idea since the list of likers can be really long.

So right now I hardcoded it but with a check to verify if the like extension is installed or not. Note that right now we cannot support this easily: it needs a big refactoring for LT, especially if Likes are stored in Solr (since the current index info are coming from the main DB).

Ok so I can provide this general API.

This is already covered by the Ratings API.

See @mflorea comment about this and my answer on

Why a modal? Why not a popover?

Same here. Moreover, I really think that the like feature shouldn’t be too intrusive / distracting. It should follow the styles of the rest of the page meta data.

So we just performed a brainstorm with @vmassol about all that, so here’s a quick sum-up.
The big direction of the Like feature is to be an instance of a Rating: i.e. to have in Ratings API all features needed for Likes and to just need it to be instantiated with few information such as the name of the “Rating module” (e.g. “like” for like) and the scale for rating (e.g. 1 for like). All the remaining stuff would be only UI.
I will work on that way, and I’ll make another proposal about the needed refactoring on Ratings module in order to achieve that properly.

Right now, we are a week away from the 12.7RC1 release, Likes are already committed on master, they rely for most of their code on Rating and on a dedicated Solr store.
The proposal is to keep that for the 12.7RC1: we can keep discussing about the need for using Solr or another kind of storage for future release, but it would imply a migration system for the new storage. (Or we could decide to drop the migration if we want). In any way, I will inform on the release note of 12.7RC1 about the possibility of a storage change.

Now about the UI, we still need to find an agreement about the design of the button itself: on that purpose, I’ll make new propositions soon on the design page more aligned with what Vincent and Marius want, and I’ll keep you informed here.

About the modal for displaying the Likers, Vincent made a proposal to create a new dedicated “viewer” for it, that we could link on the “Other actions” menu. I like this idea so I’ll go in this direction if you’re ok. We could improve it later by displaying it also in the doctab along with History etc, I won’t do it right now since I don’t think it’s a mandatory information. I want first to have some users’ feedback.