I Like This - Reset 'Likes' every month

50sQuiff

I'm using the excellent I Like This plugin as the basis for a simple reputation system. It adds two variables to the user table: 'Liked' and 'ILiked'. It's not the original intention of the plugin but I'm using 'Liked' to record the all-time score and 'ILiked' to track a monthly tally.

Is it possible to write a plugin that automatically resets everyone's 'ILiked' to 0 at the end of each calendar month? I will be happy to pay for the work because I don't know where to start on this one.

50sQuiff

I've solved part one of this problem: a cron job that executes at the end of each month:

59 23 * * * [ date -d tomorrow +%d -eq '01' ] && wget -q http://myforum.com/cronjob

Now I need to create a plugin that handles the request to that page, validates the IP address of the request, then resets everyone's ILiked count to 0.

x00

why are you using wget for a cronjob? just curious. If it is already on the server that is.

50sQuiff

I was thinking of triggering a pageload in Vanilla. But if the cronjob is running on the same server I guess I could just execute a "php randomtask.php" command? Just figuring these things out for the first time here.

HalfCat

You can write a plugin that uses the cronjob functionality of this plugin: http://vanillaforums.org/addon/cronjobs-plugin

The documentation should be pretty clear. In your plugin you will have to execute the corresponding SQL command.

x00

@50sQuiff

yes that would make more sense. Unless you want specifically to trigger a server request, to load the framework, in which case you can do an internal request. If you are not using the framework or server environment variables just standalone code then php randomtask.php would do.

50sQuiff

I'm at the stage now where I just need to issue the right SQL command but I can't figure out how from within the framework. I want to set the the entire ILiked column to 0 for all records in the User table. Can anyone help?

peregrine

UPDATEGDN_UserSETILiked= '0';

50sQuiff

Peregrine, I'm being a bit of a dunce but how do I execute that from within a Vanilla plugin? I've become familiar with building queries but I don't know how to run an arbitrary command like that.

I decided to go down the plugin route because cheap shared hosts won't allow cronjobs, so I'll need to trigger the reset remotely. I'm validating the IP address of the requestor so there shouldn't be a problem there.

By the way, the "I Like This" plugin can be gamed in its current form. If someone copies a 'Like' URL and loads it repeatedly they can increase the Like count of the recipient indefinitely. I've written a workaround for this that doesn't increase the number of DB queries. If anyone wants my (messy) code just PM me.

I've moved the query that grabs the Likes for a given post to earlier in the main Like handling function. This then enables you to validate the Like based on whether the user has already Liked the post or not. As a consequence, when it comes to rendering the Like counter we're dealing with a stale array that doesn't include the new Like. So I pass a flag to the rendering function and then fake the new Like by just adding 1 to the total.

I hope that helps someone.

HalfCat

This is how you should be able to execute SQL-commands in vanilla:

$SQL = Gdn::SQL();
$SQL
   ->Update('User')
   ->Set('ILiked', '0')
   ->Put();

50sQuiff

It works! Thank you sirs.

x00

if you are doing it per request then why don't you do it based on session? Just reset each user at a time, save some overhead. Save the purge date.

x00

Most cheap host don't have crontab, though many of them have some crappy cron job system, which could be adequate. Never used myself.

You could also use a remote cron service, but you would need secure it. Otherwise it could be abused.

50sQuiff

@x00 said:
if you are doing it per request then why don't you do it based on session? Just reset each user at a time, save some overhead. Save the purge date.

That would make it impossible to rank posters though. People who don't log in won't have their scores reset.

x00

true, if you have a small forum then fine. I'm just saying someone is going to wait a little bit longer.

The idea of crons is you do them when most people aren't around.

hbf

@50sQuiff said:
Peregrine, I'm being a bit of a dunce but how do I execute that from within a Vanilla plugin? I've become familiar with building queries but I don't know how to run an arbitrary command like that.

I decided to go down the plugin route because cheap shared hosts won't allow cronjobs, so I'll need to trigger the reset remotely. I'm validating the IP address of the requestor so there shouldn't be a problem there.

By the way, the "I Like This" plugin can be gamed in its current form. If someone copies a 'Like' URL and loads it repeatedly they can increase the Like count of the recipient indefinitely. I've written a workaround for this that doesn't increase the number of DB queries. If anyone wants my (messy) code just PM me.

I've moved the query that grabs the Likes for a given post to earlier in the main Like handling function. This then enables you to validate the Like based on whether the user has already Liked the post or not. As a consequence, when it comes to rendering the Like counter we're dealing with a stale array that doesn't include the new Like. So I pass a flag to the rendering function and then fake the new Like by just adding 1 to the total.

I hope that helps someone.

the loophole you identified can be shored up cleanly in the DiscussionController_Like_Create section just by checking if the user is allowed to like something or not. I patched that up for someone, but it was tied to karma rules and not really appropriate for re-distribution. If i get around to doing an update i'll apply a more generic patch.

BTW - if you have any intention of sharing your plugin, you should really change the data model so you aren't using my table columns. otherwise anyone who tries to run both plugins will encounter nothing but trouble. its super easy to do, just look at the bottom of the default.php and the likemodel.php

businessdad

@x00 said:
Most cheap host don't have crontab, though many of them have some crappy cron job system, which could be adequate. Never used myself.

You could also use a remote cron service, but you would need secure it. Otherwise it could be abused.

@x00 You're right, that's why the CronJob plugin supports an identification key, IP filtering and a throttling mechanism. I worked with framework providing unsecured cron functionality and I always got amazed on how easy it could be to bring the site down by just firing cron.php over and over again.

50sQuiff

Somewhat related to this topic: I'm showing a ranking of posters in the sidebar, by all-time Likes and monthly Likes.

Are the 'Liked' and 'ILiked' columns in the User table indexed automagically or are these queries going to be slow? If they're not indexed, how do I change that?

businessdad

I believe that it's quite easy to verify: check if the two tables have indexes on those columns. If they don't, then they are not going to have them, unlesse the plugin follows some special logic to decide when to alter the tables.

If you want to index these columns, just edit the table structure with your favourite tool, or even just run an ALTER TABLE statement.

50sQuiff

Confirmed - they're not indexed. Now, I wonder how I can get them indexed from within the Framework. I'll be exploring that this evening but if anyone already knows the answer...

businessdad

I'm not sure I understand what do you mean with "getting them indexed from within the Framework". Index are created, once off, on the table itself. If plugin doesn't do it, you either have to do it manually, or alter the code to add such indexes. However, such operation is normally executed on installation, therefore, even if you modified the code, you would have to disable/enable the plugin.