Drupal module to control user post frequency? - drupal

We've been having a new type of spam-bot this week at PortableApps.com which posts at a rate of about 10 comments a minute and doesn't seem to stop - at least the first hour or so (we've always stopped it within that time so far). We've had them about a dozen times in the last week - sometimes stopping it at 50 or 60, sometimes up to 250 or 300. We're working to stop it and other spam bots as much as possible, but at the moment it's still a real pest.
I was wondering whether in the mean time whether there's any sort of module to control the frequency a user can post at to e.g. 50 an hour or something like 10 in an hour for new users. That at least would mean that instead of having to clear up 300 comments 50 at a time in admin/content/comment we'd have a smaller number to clear. (A module to add a page to delete all content by a user and block them would also be helpful!)
I believe that there's a plugin to do this available for WordPress, but can't find any such thing for Drupal.

For your second question, i would have a look at the code of the User Delete module (click).
The module also disables the user account and unpublished all nodes/comments from a certain user. By extending the code, you could easily create another possibility to unpublish + delete all nodes/comments from a certain user and blocking the account.
After the unpublish code in the module, you should just put delete code (in sql if the module is selecting by a sql-query or by using the drupal delete functions).
Another option would be so make a view (using the view module) only to be viewed by administrators, where you choose a certain user using the filters and then lists his/her posts. Then in the node-contenttype.tpl.php you place a button that calls a function which deletes all nodes/comments and the user.
First problem (post frequency)
I've been thinking about the comment post limit. If I remember correctly Drupal stores comments in a seperate table and has comment specific functions.
I'd create a new module and using the comment_nodeapi function i would check in the operation 'insert' how much comments the current user has already made within a certain timeframe.
To check this I would write a custom sql query on the database which takes the count of alle comments made by uid where the post_date is larger then NOW-1hour. If that count is larger then 10 or 15 or whatever post frequency you want then you give a message back to the user. You can retrieve the user id and name by using the global $user variable.
(example: print $user->name;)
You have to check on your own for the sql query but here's some code when you have the amount:
<?php
function comment_nodeapi(&$node, $op, $arg = 0) {
switch ($op) {
case 'insert':
//PLACE HERE THE SQL TO GET THE COUNT
if($count > 15){
$repeat = FALSE;
$type = 'status'
drupal_set_message("You have reached the comment limit for this time.", $type, $repeat);
break;
}else{
db_query('INSERT INTO {node_comment_statistics} (nid, last_comment_timestamp, last_comment_name, last_comment_uid, comment_count) VALUES (%d, %d, NULL, %d, 0)', $node->nid, $node->changed, $node->uid);
break;
}
}
}
?>
(this code has not been tested so no guarantees, but this should put you on the right track)

I would suggest something like Mollom (from the creator of Drupal). It scans the message for known spam pattern/keywords/... and if this scan fails, it displays a CAPTCHA to the user to make sure that it's a real human that wants to enter content that has the same properties like spam.
They offer a free service and some paid solutions. We are using it for some customers and it's worth the money. It also integrates very well in Drupal.

Comment Limit is probably what you need.

http://drupal.org/project/spam
http://drupal.org/project/antispam - with akismet support

Related

Wordpress Plug-in - Trigger e-mail based on a specific date

I currently have a registration form for people to signup and pick a date for an "appointment". They get sent an e-mail right after filling it up with the details. I need another e-mail to be sent a day before their chosen date to remind them, but that can't be fulfilled by plugins I currently have.
Does anyone know of any Wordpress plug-in that allows the sending of an e-mail message (with a template and user specific data) based on a specified date?
Any piece of information or advice would be highly appreciated. Thanks!
How I would approach this would be with Wordpresses event scheduling. When a user submits the form to schedule their appointment, set a new action for the reminder email:
// Set this when you send the confirmation email
// Set the $unix_timestamp to be whenever you want the reminder to be sent.
// Args can be an array of the data you will need. Such as the users email/appt date
$args = array(
'email' => 'email#email.com'
);
wp_schedule_single_event($unix_timestamp, 'set_reminder', $args);
Now we have to catch that, and create a function to actually create and send the email (assuming you use a similar process):
add_action('set_reminder','do_reminder');
function do_reminder($args) {
// $email = $args['email'], etc.
// send reminder email.
}
I recommend Wysija Newsletters. You http://wordpress.org/extend/plugins/wysija-newsletters/. You can use template and user specific data in your email with this plugin.
If you are comfortable with writing your own code(I guess you are more or less ok with that), you can use the WordPress Schedule API(okay, maybe that's not the official name, but it works). Basically it's kind of a cron-job, but for WordPress. It has one downside though - it will only trigger on time, if WordPress is rendered(in other words accessed, so that it's code will execute). That can be easily fixed by adding a simple cron-job to your hosting account, that will simply access your home page every X hours.
You can find useful information on the API here.
Basically what you should have inside of your scheduled function is to get the records of people that should be sent reminder emails(you should probably store additional information about whether a reminder email has been sent or not) and send them the emails. I don't know what is the way you're storing the information from the registration form, but if you are using a Custom Post Type, then things should be pretty easy for you.

Change 'edit account' URL in Drupal

When going to edit account or edit profile in Drupal 7, the URL looks something like http://localhost/user/123/edit where 123 is the user id. Because of this, anyone can see how many users the site has, which I don't want. Is there a way that I can change it to something like http://localhost/user/edit or something without an ID?
I've tried setting up a menu entry in my module, that acts as the edit account/profile page, but had no success.
Also, I don't want to install a new module for this, I'd rather just write my code.
In theory, you could combine the Pathauto module (the widely-used module, used on over 250,000 D6 and D7 sites, which provides URL aliases for normal node and user paths, etc) with the Sub-pathauto module (a new D7 module, currently used on only a few hundred sites). The Sub-pathauto module is the only Drupal 7 module I'm aware of which will allow you to alias the user/uid part of a user/uid/edit -type path.
On the other hand, if your goal is simply to create the illusion that you might have more than a handful of users, when launching a new Drupal site, you could simply increment the UID index by adding (then deleting) a bunch of auto-generated users (with Devel generate), or since this is an auto-increment index, you could likely manually create a user entry in the database with an index of 1507 or something, and then any entry created by Drupal after that would start at 1508, even after you've removed the dummy entry from the table. (Caveat: I've never done this, but in theory it should work.)
Hope that helps. :-)
There is already a module that allows to do what you are trying to do, but as you want to avoid installing a module, you can create a module that contains the following code:
function mymodule_url_outbound_alter(&$path, &$options, $original_path) {
if (preg_match('|^user/([0-9]+)(/.*)?|', $path, $matches)) {
if ($user = user_load($matches[1])) {
$path = 'user/' . $user->name . $matches[2];
}
}
}
function mymodule_url_inbound_alter(&$path, $original_path, $path_language) {
if (preg_match('|^user/([^/]+)(/.*)?|', $path, $matches)) {
$uid = db_query("SELECT uid FROM {users} WHERE name = :name", array(':name' => $matches[1]))->fetchField();
if ($uid) {
$path = "user/$uid" . $matches[2];
}
}
}
This code works if usernames are unique, on your site. This is what normally happens on Drupal sites, where the username is forced to be unique; if a user tried to create an account using a username that already exist, he will get an error message.
The first hook rewrite paths such as "user/100" in "user/username," and the other hook make the inverse operation. This is necessary because Drupal expects user paths in the format "user/userid" and it would not be able to handle a user path containing the username (except when you are using a path alias).
As you are said you don't like that people can know how many users your site has, there is an easier way to avoid that. The fact people know that 123 is a valid user ID, though, doesn't mean they know how many users are registered in your site: You could have 1,000 users, 140,000 users. They just know that you could have 123 users, but if you have blocked users in your site, then some of the user IDs are not usable.
Create a user account that will never be used to log in, and create content on your site.
Editing the "users" database table increase the user ID of the account you created. Supposing that its user ID is 146, increase that number of 100.
Now, the next user that will register on your site will have a user ID equal to 247.
Increase the user ID of the dummy account you created incrementing the higher user ID.
In this way, if somebody notice that there is a user account with ID equal to 247, he will wrongly suppose you have 247 users.
What I did after all, was to create a hook_user_insert and to add 2 URL aliases in the urlalias table:
user/$user->uid/edit -> user/$user->name/edit
and
user/$user->uid/edit/profile -> user/$user->name/edit/profile
Hope this helps somebody.

Users last login date - Drupal

In drupal how to display the user's last login date and Time.I tried out the code
user->login
It displays the current login time, But I want users previous login time and date.
Take a look at the User Stats module, it might be something that could work for you. From the module's project page:
Provides commonly requested user statistics for themers, IP address tracking and Views
integration. Statistics are:
Days registered
Join date
Days since last login
Days since last post
Post count
Login count
User online/offline
IP address
These data are saved with module Login History
Drupal doesn't offer this natively. If you need to use it, you would probably want to add it to for example serialized $user->data array when user logs in (Using hook_user() for $op = "login") and save updated user object afterwards, and then you will be able to fetch it on the next login.
The solution I used: keep track of the last two log-in timestamps (the current and the previous one).
/**
* Implementation of hook_user()
*/
function your_module_user($op, &$edit, &$account, $category = NULL) {
switch($op) {
// Successful login
case 'load':
// If it's less than two it means we don't have a previous login timtestamp yet.
$account->custom_last_login = sizeof($account->custom_login_history) < 2
? NULL
: array_pop($account->custom_login_history);
break;
case 'login':
// If it's the first time, we don't have a history
$login_history = is_array($account->custom_login_history)
? $account->custom_login_history
: array();
// Get rid of the old value.
if (sizeof($login_history) == 2) {
array_pop($login_history);
}
// Add to the history the current login timestamp.
array_unshift($login_history, $account->login);
user_save($account, array('custom_login_history' => $login_history));
break;
}
}
Then in your template you just use $user->custom_last_login. If it's empty it means we don't have the previous timestamp yet, will be available after the next login.

add expiration date to a node in Drupal

i want to add an expiration date field to my custom content type in Drupal. it should specified by days (7-15-.... days after creating node) and after it reached the node should not display in site to visitors. but i need a renew option for it to allow creator renew it and activate it again.
is it too hard to impelmentation? how can i do it?
Have you already tried searching for modules?
Here's one that might do the trick http://drupal.org/project/auto_expire. There are others as well,but maybe you should check them out to see which one fits your needs (or can be altered easily if needed).
You can use Views to do that. Make a new View, specifically for a node or more nodes of that type, and put a filter on it with "Node:Updated". Then specify how many days you need.
You can create a View for the original poster and have him update the post, which will reset the counter.
A creative solution, but it should work.
Take a look at Node expire which sets up timers for nodes based on Rules. For a simpler approach, Scheduler can do it to. Both are linked from the Auto Expire module linked by wimvds, so there is some measure of duplication, though they do seem to have different approaches.
The following code may be of interest. It's a small snippet from a module i've had to create to auto expire adverts on an intranet site. The nodes simply unpublish after a number of days you specify in the code so could be hidden from your site and then the author of the content could simply just re -publish the nodes if they needed to.
/**
* Implementation of hook_cron().
*/
function auto_unpublish_pages_cron() {
//we only want to deal with all blog_post content type nodes
$c_type = 'blog_post';
//grab all nodes
$c_nodes = node_load_multiple(array(), array('type' => $c_type));
//setup time stamp for node expiry
$message_search_data = strtotime('- 7 days');
//now loop through nodes, & if they are old, expire them
foreach ($c_nodes as $m) {
$obj = entity_metadata_wrapper('node', $m);
//check when was last updated and if its still published
$last_update = $obj->changed->value();
$published = $obj->status->value();
//if it's still published & it's not recent, unpublish it
if (($message_search_date > $last_update) && $published<>0) {
$obj->status = 0;
$obj->save();
}
}
}

WordPress Write Cache Issue with Multiple Sessions

I'm working on a content dripper custom plugin in WordPress that my client asked me to build. He says he wants it to catch a page view event, and if it's the right time of day (24 hours since last post), to pull from a resource file and output another post. He needed it to also raise a flag and prevent other sessions from firing that same snippet of code. So, raise some kind of flag saying, "I'm posting that post, go away other process," and then it makes that post and releases the flag again.
However, the strangest thing is occurring when placed under load with multiple sessions hitting the site with page views. It's firing instead of one post -- it's randomly doing like 1, 2, or 3 extra posts, with each one thinking that it was the right time to post because it was 24 hours past the time of the last post. Because it's somewhat random, I'm guessing that the problem is some kind of write caching where the other sessions don't see the raised flag just yet until a couple microseconds pass.
The plugin was raising the "flag" by simply writing to the wp_options table with the update_option() API in WordPress. The other user sessions were supposed to read that value with get_option() and see the flag, and then not run that piece of code that creates the post because a given session was already doing it. Then, when done, I lower the flag and the other sessions continue as normal.
But what it's doing is letting those other sessions in.
To make this work, I was using add_action('loop_start','checkToAddContent'). The odd thing about that function though is that it's called more than once on a page, and in fact some plugins may call it. I don't know if there's a better event to hook. Even still, even if I find an event to hook that only runs once on a page view, I still have multiple sessions to contend with (different users who may view the page at the same time) and I want only one given session to trigger the content post when the post is due on the schedule.
I'm wondering if there are any WordPress plugin devs out there who could suggest another event hook to latch on to, and to figure out another way to raise a flag that all sessions would see. I mean, I could use the shared memory API in PHP, but many hosting plans have that disabled. Can't use a cookie or session var because that's only one single session. About the only thing that might work across hosting plans would be to drop a file as a flag, instead. If the file is present, then one session has the flag. If the file is not present, then other sessions can attempt to get the flag. Sure, I could use the file route, but it's kind of immature in my opinion and I was wondering if there's something in WordPress I could do.
The key may be to create a semaphore record in the database for the "drip" event.
Warning - consider the following pseudocode - I'm not looking up the functions.
When the post is queried, use a SQL statement like
$ts = get_time_now(); // or whatever the function is
$sid = session_id();
INSERT INTO table (postcategory, timestamp, sessionid)
VALUES ("$category", $ts, "$sid")
WHERE NOT EXISTS (SELECT 1 FROM table WHERE postcategory = "$category"
AND timestamp < $ts - 24 hours)
Database integrity will make this atomic so only one record can be inserted.
and the insertion will only take place if the timespan has been exceeded.
Then immediately check to see if the current session_id() and timestamp are yours. If they are, drip.
SELECT sessionid FROM table
WHERE postcategory = "$postcategory"
AND timestamp = $ts
AND sessionid = "$sid"
The problem goes like this with page requests even from the same session (same visitor), but also can occur with page requests from separate visitors. It works like this:
If you are doing content dripping, then a page request is probably what you intercept with add_action('wp','myPageRequest'). From there, if a scheduled post is due, then you create the new post.
The post takes a little bit of time to write to the database. In that time, a query on get_posts() may not see that new record yet. It may actually trigger your piece of code to create a new post when one has already been placed.
The fix is to force WordPress to flush the write cache appears to be this:
try {
$asPosts = array();
$asPosts = # wp_get_recent_posts(1);
foreach($asPosts as $asPost) {break;}
# delete_post_meta($asPost['ID'], '_thwart');
# add_post_meta($asPost['ID'], '_thwart', '' . date('Y-m-d H:i:s'));
} catch (Exception $e) {}
$asPosts = array();
$asPosts = # wp_get_recent_posts(1);
foreach($asPosts as $asPost) {break;}
$sLastPostDate = '';
# $sLastPostDate = $asPost['post_date'];
$sLastPostDate = substr($sLastPostDate, 0, strpos($sLastPostDate, ' '));
$sNow = date('Y-m-d H:i:s');
$sNow = substr($sNow, 0, strpos($sNow, ' '));
if ($sLastPostDate != $sNow) {
// No post today, so go ahead and post your new blog post.
// Place that code here.
}
The first thing we do is get the most recent post. But we don't really care if it's not the most recent post or not. All we're getting it for is to get a single Post ID, and then we add a hidden custom field (thus the underscore it begins with) called
_thwart
...as in, thwart the write cache by posting some data to the database that's not too CPU heavy.
Once that is in place, we then also use wp_get_recent_posts(1) yet again so that we can see if the most recent post is not today's date. If not, then we are clear to drip some content in. (Or, if you want to only drip in like every 72 hours, etc., you can change this a little here.)

Resources