Post Ratings - taking likes to the next level [Deleted]

Hello, I have a problem with uploading my add-on into my forums.I have purchased it, however whenever I try installing the add-on. It says 'The provided file was not a valid XML file. Please provide a valid XML file.'

I am using FileZilla, if that helps, and I do not know how to obtain this "XML file".

Any help will be appreciated. Thank you!
 
@Luke F

1) Ban a member
2) Banned member is hidden from Notable Members lists except for Most Positive Ratings which still shows the banned member

Can you reproduce?
 
Have a question. How can i manually add rating to user? For example i want ti give +20 positive rating to user, how can i give? Or... what if i want to remove all negative rating from certain user?
 
I am testing migration from vbulletin and have few questions:
1. What is the status of mobile support? On desktop browsers icons are visible on mouseover. I am going to use only few ratings and they could nicely fit in one line on mobile. How can I enable them? I'd remove the mousover fading using css.
2. I have a very large board and I'm migrating from vb 4.2 and dragon byte advanced thanks. I am using 2 ratings at the moment - like and thanks. I can migrate ratings themselves using big board importer. But the counts table seems to need a recount and recount doesn't seem to support deferred procedures. Recount query locks tables and timeouts eventually. I don't want to wait for hours after importing the board for likes recount and so far it seems that the query will not finish until I reconfigure table locks limits. Is there a better procedure for migration like mine? Or any way to split the recount into faster "chunk" queries, so that the main tables wouldn't be locked fir extended periods?
3. Is there a way to use font awesome as icons?
 
Last edited:
@Luke F

Please add criteria for "user has received no more than x negative ratings". "User has received at least x% positive ratings" "User has received at least x% negative ratings" "User has received at least x% negative ratings" and I'll love you forever!
 
Xon said:
@Luke F could you add the 'skip_postrating' bits the Dark_PostRating_Model_User::prepareUserFetchOptions implementation ?
Click to expand...

Noted this to be added

silence said:
For some reason, in FireFox JS Console, I'm getting this:
too much recursion

And it disappears when disabling the addon. There's no further information besides that message so I'm not sure how to debug :(
Click to expand...

I've never seen that happen and there is nothing in the post ratings js code that I can think of that would cause infinite recursion. I think the most likely cause would be another addon changing how XF or jQuery functions behave

Tall__kidd said:
Hello, I have a problem with uploading my add-on into my forums.I have purchased it, however whenever I try installing the add-on. It says 'The provided file was not a valid XML file. Please provide a valid XML file.'

I am using FileZilla, if that helps, and I do not know how to obtain this "XML file".

Any help will be appreciated. Thank you!
Click to expand...

Make sure you follow the installation instructions - it sounds like you are trying to select the .zip file in the admin CP. You need to upload the contents of the upload folder using filezilla, then you need to extract the addon-PostRating.xml file from the zip file and select that in the admin CP when installing.

LandNetwork said:
What do I do? I lost the email with product info and cannot find the transaction in PayPal?
Click to expand...

PM me your purchase email address

markku said:
@Luke F

1) Ban a member
2) Banned member is hidden from Notable Members lists except for Most Positive Ratings which still shows the banned member

Can you reproduce?
Click to expand...

Will get this fixed in the next update

forummyforex said:
Have a question. How can i manually add rating to user? For example i want ti give +20 positive rating to user, how can i give? Or... what if i want to remove all negative rating from certain user?
Click to expand...

Manually adjusting rating totals is not supported. For SQL queries to do things like removing all a users' negative ratings, see the first post of this thread

janslu said:
I am testing migration from vbulletin and have few questions:
1. What is the status of mobile support? On desktop browsers icons are visible on mouseover. I am going to use only few ratings and they could nicely fit in one line on mobile. How can I enable them? I'd remove the mousover fading using css.
2. I have a very large board and I'm migrating from vb 4.2 and dragon byte advanced thanks. I am using 2 ratings at the moment - like and thanks. I can migrate ratings themselves using big board importer. But the counts table seems to need a recount and recount doesn't seem to support deferred procedures. Recount query locks tables and timeouts eventually. I don't want to wait for hours after importing the board for likes recount and so far it seems that the query will not finish until I reconfigure table locks limits. Is there a better procedure for migration like mine? Or any way to split the recount into faster "chunk" queries, so that the main tables wouldn't be locked fir extended periods?
3. Is there a way to use font awesome as icons?
Click to expand...

1. The fade effect is explicitly disabled on mobile
2. The recount does support the standard XF deferred system. If you are experiencing timeouts your server is likely misconfigured, as the default amount to process per batch is reasonably conservative. If you would like to decrease the amount to process per batch, edit the php files in library/dark/postrating/deferred - the 'PER_PAGE' values at the top control the amount to process per batch.
3. Yes see https://xenforo.com/community/threa...he-next-level-paid.28475/page-130#post-926118

Shiro said:
@Luke F

Please add criteria for "user has received no more than x negative ratings". "User has received at least x% positive ratings" "User has received at least x% negative ratings" "User has received at least x% negative ratings" and I'll love you forever!
Click to expand...

All noted for the next update :)
 
@Luke F
Thank you! After lowering the batch size in the php files it runs fine. I've had table lock timeouts and that would mean I cannot enable the forum while the recount is being done. Now, with smaller chunks I hope it might work in the backgroumd. As for the mobile - I will need to recheck my style as I don't see post ratings icons on mobile at all. Thank you for the information.
 
Probably a silly question, but does this add on integrate with the profile feed ratings yet? Because I use it, and people would like to see these ratings for profile comments and status updates too.

Is that planned for the future?
 
@Luke F the recount is progressing, but it takes AGES. After more than 24h it shows it's done recounting for 2.400.000 posts (out of 14 million). It's unbearably slow, much slower than any other type of recounts on likes I've done previously (I've been through 2 likes add ons for vbulletin) . The database server is fairly fast, but xf_posts is large, I have almost 2.4 million likes/thanks in dark_postrating table. Can you think of any way to speed it up?

I was looking into this a little more and it seems that the actual load on the database is cause by the folloing query:
Code: 
select post.post_id, post.thread_id , (select count(*) from dark_postrating pr USE INDEX (`post_id_rating`) where pr.post_id = post.post_id and pr.rating = 1) as dark_postrating_1_count , (select count(*) from dark_postrating pr USE INDEX (`post_id_rating`) where pr.post_id = post.post_id and pr.rating = 14) as dark_postrating_14_count , (select count(*) from dark_postrating pr USE INDEX (`post_id_rating`) where pr.post_id = post.post_id and pr.rating = 2) as dark_postrating_2_count , (select count(*) from dark_postrating pr USE INDEX (`post_id_rating`) where pr.post_id = post.post_id and pr.rating = 3) as dark_postrating_3_count , (select count(*) from dark_postrating pr USE INDEX (`post_id_rating`) where pr.post_id = post.post_id and pr.rating = 4) as dark_postrating_4_count , (select count(*) from dark_postrating pr USE INDEX (`post_id_rating`) where pr.post_id = post.post_id and pr.rating = 5) as dark_postrating_5_count , (select count(*) from dark_postrating pr USE INDEX (`post_id_rating`) where pr.post_id = post.post_id and pr.rating = 6) as dark_postrating_6_count , (select count(*) from dark_postrating pr USE INDEX (`post_id_rating`) where pr.post_id = post.post_id and pr.rating = 7) as dark_postrating_7_count , (select count(*) from dark_postrating pr USE INDEX (`post_id_rating`) where pr.post_id = post.post_id and pr.rating = 8) as dark_postrating_8_count , (select count(*) from dark_postrating pr USE INDEX (`post_id_rating`) where pr.post_id = post.post_id and pr.rating = 9) as dark_postrating_9_count , (select count(*) from dark_postrating pr USE INDEX (`post_id_rating`) where pr.post_id = post.post_id and pr.rating = 10) as dark_postrating_10_count , (select count(*) from dark_postrating pr USE INDEX (`post_id_rating`) where pr.post_id = post.post_id and pr.rating = 11) as dark_postrating_11_count , (select count(*) from dark_postrating pr USE INDEX (`post_id_rating`) where pr.post_id = post.post_id and pr.rating = 12) as dark_postrating_12_count , (select count(*) from dark_postrating pr USE INDEX (`post_id_rating`) where pr.post_id = post.post_id and pr.rating = 13) as dark_postrating_13_count , pr_cache.rating_cache, pr2.rating, (select count(*) from dark_postrating pr USE INDEX (`post_id_rating`) where pr.post_id = post.post_id and pr.rating = 1) as dark_postrating_1_count , (select count(*) from dark_postrating pr USE INDEX (`post_id_rating`) where pr.post_id = post.post_id and pr.rating = 14) as dark_postrating_14_count , (select count(*) from dark_postrating pr USE INDEX (`post_id_rating`) where pr.post_id = post.post_id and pr.rating = 2) as dark_postrating_2_count , (select count(*) from dark_postrating pr USE INDEX (`post_id_rating`) where pr.post_id = post.post_id and pr.rating = 3) as dark_postrating_3_count , (select count(*) from dark_postrating pr USE INDEX (`post_id_rating`) where pr.post_id = post.post_id and pr.rating = 4) as dark_postrating_4_count , (select count(*) from dark_postrating pr USE INDEX (`post_id_rating`) where pr.post_id = post.post_id and pr.rating = 5) as dark_postrating_5_count , (select count(*) from dark_postrating pr USE INDEX (`post_id_rating`) where pr.post_id = post.post_id and pr.rating = 6) as dark_postrating_6_count , (select count(*) from dark_postrating pr USE INDEX (`post_id_rating`) where pr.post_id = post.post_id and pr.rating = 7) as dark_postrating_7_count , (select count(*) from dark_postrating pr USE INDEX (`post_id_rating`) where pr.post_id = post.post_id and pr.rating = 8) as dark_postrating_8_count , (select count(*) from dark_postrating pr USE INDEX (`post_id_rating`) where pr.post_id = post.post_id and pr.rating = 9) as dark_postrating_9_count , (select count(*) from dark_postrating pr USE INDEX (`post_id_rating`) where pr.post_id = post.post_id and pr.rating = 10) as dark_postrating_10_count , (select count(*) from dark_postrating pr USE INDEX (`post_id_rating`) where pr.post_id = post.post_id and pr.rating = 11) as dark_postrating_11_count , (select count(*) from dark_postrating pr USE INDEX (`post_id_rating`) where pr.post_id = post.post_id and pr.rating = 12) as dark_postrating_12_count , (select count(*) from dark_postrating pr USE INDEX (`post_id_rating`) where pr.post_id = post.post_id and pr.rating = 13) as dark_postrating_13_count from xf_post AS post left join dark_postrating_post_cache pr_cache ON (post.post_id = pr_cache.post_id) left join dark_postrating pr2 on (post.post_id = pr2.post_id and pr2.user_id = 1) limit 2563200, 200
where 200 in limit is my own setting.

This query is a nightmare and is obviously result of a bug. The bug causes the doubling of sub-requests (columns for each rating count are doubled for each row). But even without duplicated columns this still is very unoptimized query in my eyes (so many sub queries!). With limit set to 20 rows it takes 12,5secs to return results. Wouldn't
Code: 
SELECT post_id, rating, COUNT(*) FROM `dark_postrating` GROUP BY post_id, rating;
query return the same results without a need to iterate and all rows would be returned in a fraction of the time needed to return a 100?
 
Last edited:
janslu said:
@Luke F the recount is progressing, but it takes AGES. After more than 24h it shows it's done recounting for 2.400.000 posts (out of 14 million). It's unbearably slow, much slower than any other type of recounts on likes I've done previously (I've been through 2 likes add ons for vbulletin) . The database server is fairly fast, but xf_posts is large, I have almost 2.4 million likes/thanks in dark_postrating table. Can you think of any way to speed it up?

I was looking into this a little more and it seems that the actual load on the database is cause by the folloing query:
Code: 
select post.post_id, post.thread_id , (select count(*) from dark_postrating pr USE INDEX (`post_id_rating`) where pr.post_id = post.post_id and pr.rating = 1) as dark_postrating_1_count , (select count(*) from dark_postrating pr USE INDEX (`post_id_rating`) where pr.post_id = post.post_id and pr.rating = 14) as dark_postrating_14_count , (select count(*) from dark_postrating pr USE INDEX (`post_id_rating`) where pr.post_id = post.post_id and pr.rating = 2) as dark_postrating_2_count , (select count(*) from dark_postrating pr USE INDEX (`post_id_rating`) where pr.post_id = post.post_id and pr.rating = 3) as dark_postrating_3_count , (select count(*) from dark_postrating pr USE INDEX (`post_id_rating`) where pr.post_id = post.post_id and pr.rating = 4) as dark_postrating_4_count , (select count(*) from dark_postrating pr USE INDEX (`post_id_rating`) where pr.post_id = post.post_id and pr.rating = 5) as dark_postrating_5_count , (select count(*) from dark_postrating pr USE INDEX (`post_id_rating`) where pr.post_id = post.post_id and pr.rating = 6) as dark_postrating_6_count , (select count(*) from dark_postrating pr USE INDEX (`post_id_rating`) where pr.post_id = post.post_id and pr.rating = 7) as dark_postrating_7_count , (select count(*) from dark_postrating pr USE INDEX (`post_id_rating`) where pr.post_id = post.post_id and pr.rating = 8) as dark_postrating_8_count , (select count(*) from dark_postrating pr USE INDEX (`post_id_rating`) where pr.post_id = post.post_id and pr.rating = 9) as dark_postrating_9_count , (select count(*) from dark_postrating pr USE INDEX (`post_id_rating`) where pr.post_id = post.post_id and pr.rating = 10) as dark_postrating_10_count , (select count(*) from dark_postrating pr USE INDEX (`post_id_rating`) where pr.post_id = post.post_id and pr.rating = 11) as dark_postrating_11_count , (select count(*) from dark_postrating pr USE INDEX (`post_id_rating`) where pr.post_id = post.post_id and pr.rating = 12) as dark_postrating_12_count , (select count(*) from dark_postrating pr USE INDEX (`post_id_rating`) where pr.post_id = post.post_id and pr.rating = 13) as dark_postrating_13_count , pr_cache.rating_cache, pr2.rating, (select count(*) from dark_postrating pr USE INDEX (`post_id_rating`) where pr.post_id = post.post_id and pr.rating = 1) as dark_postrating_1_count , (select count(*) from dark_postrating pr USE INDEX (`post_id_rating`) where pr.post_id = post.post_id and pr.rating = 14) as dark_postrating_14_count , (select count(*) from dark_postrating pr USE INDEX (`post_id_rating`) where pr.post_id = post.post_id and pr.rating = 2) as dark_postrating_2_count , (select count(*) from dark_postrating pr USE INDEX (`post_id_rating`) where pr.post_id = post.post_id and pr.rating = 3) as dark_postrating_3_count , (select count(*) from dark_postrating pr USE INDEX (`post_id_rating`) where pr.post_id = post.post_id and pr.rating = 4) as dark_postrating_4_count , (select count(*) from dark_postrating pr USE INDEX (`post_id_rating`) where pr.post_id = post.post_id and pr.rating = 5) as dark_postrating_5_count , (select count(*) from dark_postrating pr USE INDEX (`post_id_rating`) where pr.post_id = post.post_id and pr.rating = 6) as dark_postrating_6_count , (select count(*) from dark_postrating pr USE INDEX (`post_id_rating`) where pr.post_id = post.post_id and pr.rating = 7) as dark_postrating_7_count , (select count(*) from dark_postrating pr USE INDEX (`post_id_rating`) where pr.post_id = post.post_id and pr.rating = 8) as dark_postrating_8_count , (select count(*) from dark_postrating pr USE INDEX (`post_id_rating`) where pr.post_id = post.post_id and pr.rating = 9) as dark_postrating_9_count , (select count(*) from dark_postrating pr USE INDEX (`post_id_rating`) where pr.post_id = post.post_id and pr.rating = 10) as dark_postrating_10_count , (select count(*) from dark_postrating pr USE INDEX (`post_id_rating`) where pr.post_id = post.post_id and pr.rating = 11) as dark_postrating_11_count , (select count(*) from dark_postrating pr USE INDEX (`post_id_rating`) where pr.post_id = post.post_id and pr.rating = 12) as dark_postrating_12_count , (select count(*) from dark_postrating pr USE INDEX (`post_id_rating`) where pr.post_id = post.post_id and pr.rating = 13) as dark_postrating_13_count from xf_post AS post left join dark_postrating_post_cache pr_cache ON (post.post_id = pr_cache.post_id) left join dark_postrating pr2 on (post.post_id = pr2.post_id and pr2.user_id = 1) limit 2563200, 200
where 200 in limit is my own setting.

This query is a nightmare and is obviously result of a bug. The bug causes the doubling of sub-requests (columns for each rating count are doubled for each row). But even without duplicated columns this still is very unoptimized query in my eyes (so many sub queries!). With limit set to 20 rows it takes 12,5secs to return results. Wouldn't
Code: 
SELECT post_id, rating, COUNT(*) FROM `dark_postrating` GROUP BY post_id, rating;
query return the same results without a need to iterate and all rows would be returned in a fraction of the time needed to return a 100?
Click to expand...

Technically yes could do that in conjunction with another query fetching post_ids for pagination

I'm not quite sure how the subqueries have managed to double up like that, will look into that as it might be happening elsewhere

Also that query really should not be as slow as you are experiencing unless the post_id_rating index isn't fully in ram and so is being ignored in favour of hundreds of full table scans. I would look into increasing your innodb_buffer_pool_size setting as much as possible, because something is definitely wrong there. My fairly low spec server can execute the original 20000 limit query in less than 20ms. 12.5 seconds for 200 results is so many orders of magnitude higher that it must be repeatedly going to disk
 
Last edited:
Luke F said:
I would look into increasing your innodb_buffer_pool_size setting as much as possible, because something is definitely wrong there. My fairly low spec server can execute the original 20000 limit query in less than 20ms. 12.5 seconds for 200 results is so many orders of magnitude higher that it must be repeatedly going to disk
Click to expand...

Of course! Thanks for this tip - I should've checked it myself. innodb_buffer_pool_size was overflowed - I'm using a single DB server for an existing vbulletin site, a test snaphot of it's database for export tests and for my xenforo test database. Essentialy the innodb data (mainly post table) is tripled and I have only doubled innodb_buffer_pool_size. This is the reason for the server being slower than it should be. But it's not a gamechanger - speed is much better, but it still takes more than 3,5 seconds to run the query as it is (it return 200 rows). I'm sure the query should be optimized.
 
@Luke F

A member says that for a post that has received 30 ratings, they have only gotten 10 alerts about the ratings.

What could be the reason for missing alerts about ratings?
 
You must log in or register to reply here.
Back
Top Bottom