Likes and Ratings in Blog application's Card layout

Hi everyone,

We have the following situation in the Blog application:

  • Loading... introduced a new layout (Cards), for displaying blog posts, which shows the Ratings stars, among other information
  • there are some issues (1 blocker) reported as being caused by the Ratings API refactoring: Loading..., Loading...
  • since the Likes app has replaced the Ratings app as the default appreciations app, we could use it and display the Like button instead of Rating stars

I’d like to propose to use the appreciations data in the following order:

  1. if the Like feature exists, display Like button (which contains the number of likes)
  2. if the Rating feature exists, display the Rating stars (which highlights the average rating)
  3. if none of the above is available, do not display anything

The result would be:

  • from XWiki 9.2 to XWiki 12.7, the users will see Rating stars in the Cards layout
  • from XWiki 12.7+, the users will see Like button in the Cards layout

An issue could be if some XWiki instances uses Rating stars and after upgrade to a newer version, the stars will be replaced by the Like button which may cause some confusion and would make this change as a regression. Even more, some blog posts that could have been rated may end up in displaying the Like button with 10 likes instead of Rating stars with an average of 3.5 stars.

As an argument for this change, this Card layout was developed rather silently and the documentation does not mention anything about Ratings, so there would be a small change to have been adopted by the large masses. Actually, we make this feature public with this thread.

I would like to get some opinions from those using the Blog app, especially using this Cards layout, and from @vmassol (the project lead of the Blog app)


am I? :slight_smile: I have not been active on this repo forever so I’d be happy to give the leadership to anyone active. Would you like it @acotiuga ?

I agree with this strategy, with the mention that the ratings application would not be a dependency of the blog application anymore, in order to fix BLOG-161 . So for all users that would install this new version of the Blog application on an older version of XWiki, they would need to install the ratings application manually and configure it for the blog space that they want to rate.

Moreover, to me, this would be the right behaviour of this “stars on cards layout” feature, as opposed to the current one which is that the blog pulls the ratings app dependency but doesn’t actually use it unless configured.

Indeed. In order to fix this, we could change the order of the 2 first items in the appreciation data above: ratings first, if present, in order to preserve the ratings if any, likes second and then nothing.
However, this would create an issue if someone installs blog first without ratings and starts to use the like feature, then they install the ratings application (although I don’t see exactly how would that be useful if like is already present) and this would cause the blog appreciation to change from likes to ratings.

However, I think we don’t have to make this change of order. I think we could simply document that on more recent versions of XWiki the blog post appreciation does not use ratings anymore but uses likes instead. We could document this even as an admitted regression of the blog application and that any different behaviour should be seen as a customization of the application. To me it’s “normal” that this kind of changes appear, the applications are all made to run on a standard version of the xwiki platform, so changes in the features of the xwiki platform will impact the applications.

I guess you mean in the card view. Note that the button is clickable (it’s a button), do you want users to be able to modify the likes in the card view directly?

Note that the Rating feature still exist (it’s not been removed). Its API has just been refactored. The Like app is using the Rating API. So you could continue to show stars and have a rating of 1-5 even with recent XWiki versions.

If you wanted you could offer an Admin UI to configure whether to use Likes or Stars. It’s more work though.

I guess you’ll need to migrate the rating data (I don’t know the new Rating API/app code so maybe the conversion is done automatically). For example so that any rating >=3 is transformed into a Like and ratings < 3 are ignored (the user actually didn’t like the blog post).

For me it’s not about documentation (people don’t read anyway) but about usages of the Blog app in the version where the rating has been introduced. What you’re proposing is going to be a breaking change (and can be viewed by some as a regression). Which could be a decision we accept but it would need to be clearly indicated in the RN and maybe even in the app itself before doing the rating data migration so that the user/admin confirms this is what they want.

Unless you offer the possibility to continue using stars ofc (see above). Or that you do what Anca mentioned, i.e. change your logic and check if the old rating API exists and if it does, then use it instead of Likes. Users wanting to continue using stars would need to install the old rating apps. This is less good than refactoring the Blog app to use the new ratings APIs but it’s an option.


Ok. Maybe provide a link to the jira issue where it’s done, for reference. Thx

PS: When a thread is finished please mark it as solved on the forum.

Apparently something went wrong. I was expecting to reply to a given comment not to the entire conversation. The right thing to use seems to be quote. What is Done is the update of the leadership on the Blog application:

I? :slight_smile: I have not been active on this repo forever so I’d be happy to give the leadership to anyone active. Would you like it @acotiuga ?

About the rest of the conversation, about managing Likes and Ratings and configuring them + migration, for sure there is not time to do it at this point. As a mention, the Rating stars in the Cards layout was only used in a single project, where I fixed the problem, so no migration is needed. Unless somebody else reports a problem regarding this feature, I do not plan to work on it.


yeah it’s my fault. I cannot get used to the discourse UI for that. Which is why I always quote the part I’m replying to, to make it obvious.