Topic Ratings Plugin

Yup. In fact the averages are already stored in the db rounded to 1 decimal place.

So this small change in the serializer should do the trick.

https://github.com/angusmcleod/discourse-ratings/commit/8f176955daa1f54d64745ad5e4e8de60838328d0

3 Likes

Are there any known issues with this plugin? I have had it installed for a while but never used it. Now when the first topic came up in a ratings-enabled category, it shows that rating is enabled under the topic title but when I reply, there is no way to actually submit a rating…

You can’t rate your own posts. Could that be it?

Good idea, but it’s not my own post. However, the topic owner created the post in a different category and I moved it. Maybe that has something to do with it?

1 Like

That is almost definitely it. As the same thing (used to?) throw off the topic-timers for auto close when moving from one category to another.

1 Like

Let’s hope so. But I thought this has been fixed since a while:

I’ve definitely upgraded several times since that commit.

That is not the same thing. This is Topic Ratings, not Polls. Topic Ratings might not be storing its data the same way Polls did.

I should have quoted the commit, which was not specific to any particular plugin

https://github.com/discourse/discourse/commit/5794ff53a197b35e67a8ecfbedc6d7d626e872be

But you are still right that we have a different issue here because we are not moving custom fields out of a topic but we are moving a post into a new topic and that’s probably where the necessary custom fields are not being created/populated. At least that is my guess about what is happening here.

Wait… you are still confusing me.

Are you talking about Polls or Topic Ratings? The PR you linked to was to specifically solve an issue with Polls, which stores its data in the custom_fields associated to a post.

Topic Ratings, stores ratings on a topic. I cannot say (without looking at the code), whether it is on the OP of the topic (thus associating it to the first post in a topic), or if there is another custom_fields variant that is specific for topics. If there is one specific to topics, then the PR you reference is irrelevant, as it only deals with posts.

Edit:
And looking at https://github.com/angusmcleod/discourse-ratings/blob/master/plugin.rb, I see custom_fields referenced on posts, topics, and categories.

I have a feeling this deals with the topic custom fields. Which the referenced PR does not handle (or possibly the category)

1 Like

If you’re talking about this plugin and not polls:

  • A user can only submit one rating per topic. Once you’ve submitted your rating, you can still post in the topic, but the rating controls will not appear in the composer again.
  • Rating controls will appear in:
    1. Topics in a category with ratings enabled
    2. Topics with a ratings tag

As @cpradio said, this plugin uses both TopicCustomFields and PostCustomFields, however I can’t see any reason why moving a topic from one category to another would affect the ratings control visibility logic. The logic for deciding whether to show the ratings controls in the composer is dependent on CategoryCustomFields which are not being migrated in this case.

Topic and post custom fields are used to store ratings and average ratings, not to decide whether to show rating controls.

Yes, it’s ratings, not polls.

So are you saying this is the reason why I’m not seeing the ratings controls? No, I think you’re saying that the CustomCategoryFields are not being moved because I moved the post into rather than out of a rating category.

Correct. CategoryCustomFields are not affected by topics being moved.

tbh, I haven’t tested the ratings client logic in the scenario you’re dealing with: moving an existing topic into a ratings category. I’ll take a look at that scenario this weekend. Thanks.

Can you add aggregated rating schema support to this plugin?

1 Like

If I understand correctly how schema.org works (which I’m still not sure I do, even after a using it a few times), the schema for AggregateRating will only work if it is within the scope of a ‘type’. It seems these scope types support AggregateRating:

As it (seems) to be type dependent, I’m not sure it makes sense to support it directly in this plugin as that would involve choosing a particular type, e.g. Product or Service. Not all users of this plugin will be using it for one particular type.

If someone else knows more about schemas and can confirm or deny this, that would help (@vinothkannans?)

You could still add schema support for AggregateRating within the scope of a particular type, by forking this plugin and adding a new file:

app/views/connectors/topic_header/aggregate_rating.html.erb

the contents of which would look something like one of the existing schema.org markup blocks in the topics/show.html.erb view e.g. the tags markup.

1 Like

We can add AggregateRating by default. In the allowed schema type list it have CreativeWork. In Discourse we are using DiscussionForumPosting as default schema type. It is a part of CreativeWork (CreativeWork > Article > SocialMediaPosting > DiscussionForumPosting). So it is 100% appropriate to use AggregateRating in topic ratings :+1:.

I manually tested this functionality in Google’s testing tool.

2 Likes

I cant edit post below a rating topic anymore.

Thanks for the report. Bug fixed.

https://github.com/angusmcleod/discourse-ratings/commit/b0b644ea85bcb43b8caf31603a23b1a865cfb742

As per @vinothkannans’s advice, I’ve added aggregateRating as part of CreativeWork.

https://github.com/angusmcleod/discourse-ratings/commit/85f82fc2e8843fc8a95847bc82be34eec2b38fc5

@vinothkannans You probably are already aware that Google’s structured data testing tool is complaining about the DiscussionForumPosting microdata for core Discourse topic views not having images. I’m not sure if that omission means the DiscussionForumPosting microdata blocks will be ignored?

Screenshot at Oct 05 08-25-58

4 Likes

I think it needs some changes in both on your code and Discourse core. I will create a PR once it changed in core. For now okay :+1:

4 Likes

Today I enabled this plugin for the first time on a pretty fresh discourse install and I don’t see the star-rating buttons in a reply box (composer) and I get the following error:
https://github.com/angusmcleod/discourse-ratings/issues/10

Update: after rebuilding the discourse app, I can no longer reproduce the TypeError... but I still don’t see the star-ratings buttons.

1 Like

Hey :). The addObject exception is actually unrelated to this plugin. It’s a Discourse exception. I’ve been meaning to report it.

As to the ratings buttons not appearing, I can’t repro it unfortunately. Can you send me some screenshots with the console open?

I tested it locally and on my sandbox here: https://discourse.angusmcleod.com.au/c/ratings

Composer:

Topic:

Topic List:

5 Likes