Turning off favorite notifictions?

Without really going deep I couldn't tell you how to mod the script, but I wonder if you delete the options out of fanfiction_panels if they would disappear from the Edit Preferences panel or if it would just cause errors.  Also, I have an already written SQL query to turn all the 1s to 0s for the various types of notifications (turn off notifications in everyone's profiles), which I had to do a while back.  That coupled with making the options disappear so they can't turn them back on might be a good solution that would keep you from having to mod any of the actual PHP files.

I can try out the first thing on my test site and let you know what happens.

Yuck, so, I should actually look at what I'm talking about before I say it.  No go on making it disappear easily.  Still looking for where what shows up in edit preferences is.  Doesn't look like it's one of the easy things that can be changed in a skin file or anything. : |

But, if you want to turn it all off now (although they can just turn it on again at the moment), then here is what I used.  (I had to run these after people who requested notifications started reporting them as spam to like Yahoo and my hosting company got a little irate.)

UPDATE `fanfiction_authorprefs` SET newreviews = 0 WHERE newreviews = 1
UPDATE `fanfiction_authorprefs` SET newrespond = 0 WHERE newrespond = 1
UPDATE `fanfiction_authorprefs` SET alertson = 0 WHERE altertson =1

Ugh, I figured it wouldn't be simple. But that you for the SQL, I can at least try that out as a temporary fix.

Yeah, I suggest using Lyndsie's solution for now. I'm not sure what you're asking -- you just don't want people to get e-mailed with new stories/chapters, correct? I checked out stories.php, but I'm not sure if that's the only place where story notifications get sent out. The function is sendemail(). It appears six times in the 3.4.3 stories.php version. If you go to the places where they are, it should be somewhat self-explanatory to what they do.

~line 292:

				if($alertson) {
$subject = _NEWSTORYAT.$sitename;
$mailtext = sprintf(_AUTHORALERTNOTE, $title, $penname, $summary, $sid);
$favorites = dbquery("SELECT "._UIDFIELD." as uid, "._EMAILFIELD." as email, "._PENNAMEFIELD." as penname, alertson FROM ".TABLEPREFIX."fanfiction_favorites as fav, ".TABLEPREFIX."fanfiction_authorprefs as ap, "._AUTHORTABLE." WHERE FIND_IN_SET(fav.item,'".implode(",", $au)."') > 0 AND fav.type = 'AU' AND fav.uid = "._UIDFIELD." AND ap.uid = "._UIDFIELD." AND ap.alertson = '1'");
while($favuser = dbassoc($favorites)) { 
sendemail($favuser['penname'], $favuser['email'], $sitename, $siteemail, $subject, $mailtext, "html");
}
}

That emails people when their favourite authors update/post a new story.

~line 301 (straight after the previous code quote)

			else if($alertson && $newchapter) {
$titlequery = dbquery("SELECT title FROM ".TABLEPREFIX."fanfiction_stories WHERE sid = '$sid' LIMIT 1");
list($title) = dbrow($titlequery);
$subject = _STORYALERT;
$mailtext = sprintf(_STORYALERTNOTE, $title, $penname, $sid, $inorder);
$favorites = dbquery("SELECT "._UIDFIELD." as uid, "._EMAILFIELD." as email, "._PENNAMEFIELD." as penname, alertson FROM ".TABLEPREFIX."fanfiction_favorites as fav, ".TABLEPREFIX."fanfiction_authorprefs as ap, "._AUTHORTABLE." WHERE fav.item = '$sid' AND fav.type = 'ST' AND fav.uid = "._UIDFIELD." AND ap.uid = "._UIDFIELD." AND ap.alertson = '1'");
while($favuser = dbassoc($favorites)) { 
sendemail($favuser['penname'], $favuser['email'], $sitename, $siteemail, $subject, $mailtext, "html");
}
}

That alerts favourites.

There's a couple more, but I think the ones in the new story function should be it? (There's a couple in the edit story function.)

I'd just get rid of the while loop to avoid it sending anyone e-mails ... (And get rid of the query if you're worried about query counts.)

Does eFiction split the list of recipients when it sends out notifications?  Like if there are 200 people, does it try all 200 at once?

If not, is there a way to get it to do that? We'd be willing to pay for someone's coding time if necessary.

I think it sends them out all at once.  I'd also be interested in a throttle for that.  Let me see what I might be able to come up with.  Can't promise anything superquick, though.

Back to your original request, I found the file that controls what appears in the account settings area: user/editprefs.php.

I've got rid of all three of those alerts.  They don't show up as options to select anymore, though you'd still have to run the SQL query above again to clear out the database once again after you make the changes.  You might want the new reviews and the response to reviews ones on, though?  Maybe you don't even want this off anymore. LOL.  Well, here's what I did.  (And if you want the new reviews and new response to reviews on, I can fix that up for you.  But really you just need to not change those sections following these instructions and it should work.)

Original, starting at line 27 (3.5).

$output = "<div id='pagetitle'>".($action == "register" ? _SETPREFS : _EDITPREFS)."</div>";
if(isset($_POST['submit'])) {
$useralertson = isset($_POST['useralertson']) && $_POST['useralertson'] == "on" ? 1 : 0;
$newreviews = isset($_POST['newreviews']) && $_POST['newreviews'] == "on" ? 1 : 0;
$newrespond = isset($_POST['newrespond']) && $_POST['newrespond'] == "on" ? 1 : 0;
$ageconsent = isset($_POST['ageconsent']) && isNumber($_POST['ageconsent']) ? $_POST['ageconsent'] : 0;
$tinyMCE = isset($_POST['tinyMCE']) && $_POST['tinyMCE'] == "on" ? 1 : 0;
$storyindex = isset($_POST['storyindex']) && $_POST['storyindex'] == "on" ? 1 : 0;
$sortby = isset($_POST['sortby']) && $_POST['sortby'] == 1 ? 1 : 0;
$skinnew = descript(strip_tags($_POST['skinnew']));
if($skinnew != $skin) $_SESSION[$sitekey."_skin"] = $skinnew;
dbquery("UPDATE ".TABLEPREFIX."fanfiction_authorprefs SET alertson = '$useralertson', newreviews = '$newreviews', newrespond = '$newrespond', ageconsent = '$ageconsent', tinyMCE ='$tinyMCE', userskin = '$skinnew', storyindex = '$storyindex', sortby = '$sortby' WHERE uid = '".USERUID."'");
$output .= write_message(_ACTIONSUCCESSFUL." "._BACK2ACCT);
}
else {
$result = dbquery("SELECT * FROM ".TABLEPREFIX."fanfiction_authorprefs WHERE uid = '".USERUID."' LIMIT 1");
if(dbnumrows($result) == 0) {
dbquery("INSERT INTO ".TABLEPREFIX."fanfiction_authorprefs(`uid`, `userskin`) VALUES('".USERUID."', '$skin')");
$result = dbquery("SELECT * FROM ".TABLEPREFIX."fanfiction_authorprefs WHERE uid = '".USERUID."' LIMIT 1");
}
$user = dbassoc($result);
$output .= "<form method="POST" enctype="multipart/form-data" style='width: 425px; margin: 0 auto;' action="user.php?action=editprefs">
<label for='newreviews'>"._CONTACTREVIEWS.":</label> <INPUT name="newreviews" type="checkbox" class="checkbox"".($user['newreviews'] ? " checked" : "")."> <A HREF=""#"" class="pophelp">[?]<span>"._HELP_NEWREV."</span></A><br />
<label for='newrespond'>"._CONTACTRESPOND.":</label> <INPUT name="newrespond" type="checkbox" class="checkbox"".($user['newrespond'] ? " checked" : "")."><A HREF=""#"" class="pophelp">[?]<span>"._HELP_NEWRESP."</span></A><br />";
if($alertson) 
$output .= "<label for='useralertson'>"._ALERTSON2."</label> <INPUT name="useralertson" type="checkbox" class="checkbox"".($user['alertson'] ? " checked" : "")."><A HREF=""#"" class="pophelp">[?]<span>"._HELP_FAVALERT."</span></A><br />";
$output .= "<label for='storyindex'>"._DISPLAYINDEX."</label> <INPUT name="storyindex" type="checkbox" class="checkbox"".($user['storyindex'] ? " checked" : "")."><A HREF=""#"" class="pophelp">[?]<span>"._HELP_TOC."</span></A><br />";
$output .= "<label for='tinyMCE'>"._USETINYMCE."</label> <INPUT name="tinyMCE" type="checkbox" class="checkbox"".($user['tinyMCE'] ? " checked" : "")."><A HREF=""#"" class="pophelp">[?]<span>"._HELP_TINYMCE."</span></A><br />";

New:

$output = "<div id='pagetitle'>".($action == "register" ? _SETPREFS : _EDITPREFS)."</div>";
if(isset($_POST['submit'])) {
$ageconsent = isset($_POST['ageconsent']) && isNumber($_POST['ageconsent']) ? $_POST['ageconsent'] : 0;
$tinyMCE = isset($_POST['tinyMCE']) && $_POST['tinyMCE'] == "on" ? 1 : 0;
$storyindex = isset($_POST['storyindex']) && $_POST['storyindex'] == "on" ? 1 : 0;
$sortby = isset($_POST['sortby']) && $_POST['sortby'] == 1 ? 1 : 0;
$skinnew = descript(strip_tags($_POST['skinnew']));
if($skinnew != $skin) $_SESSION[$sitekey."_skin"] = $skinnew;
dbquery("UPDATE ".TABLEPREFIX."fanfiction_authorprefs SET  ageconsent = '$ageconsent', tinyMCE ='$tinyMCE', userskin = '$skinnew', storyindex = '$storyindex', sortby = '$sortby' WHERE uid = '".USERUID."'");
$output .= write_message(_ACTIONSUCCESSFUL." "._BACK2ACCT);
}
else {
$result = dbquery("SELECT * FROM ".TABLEPREFIX."fanfiction_authorprefs WHERE uid = '".USERUID."' LIMIT 1");
if(dbnumrows($result) == 0) {
dbquery("INSERT INTO ".TABLEPREFIX."fanfiction_authorprefs(`uid`, `userskin`) VALUES('".USERUID."', '$skin')");
$result = dbquery("SELECT * FROM ".TABLEPREFIX."fanfiction_authorprefs WHERE uid = '".USERUID."' LIMIT 1");
}
$user = dbassoc($result);
$output .= "<form method="POST" enctype="multipart/form-data" style='width: 425px; margin: 0 auto;' action="user.php?action=editprefs">";
if($alertson) 
$output .= "<label for='storyindex'>"._DISPLAYINDEX."</label> <INPUT name="storyindex" type="checkbox" class="checkbox"".($user['storyindex'] ? " checked" : "")."><A HREF=""#"" class="pophelp">[?]<span>"._HELP_TOC."</span></A><br />";
$output .= "<label for='tinyMCE'>"._USETINYMCE."</label> <INPUT name="tinyMCE" type="checkbox" class="checkbox"".($user['tinyMCE'] ? " checked" : "")."><A HREF=""#"" class="pophelp">[?]<span>"._HELP_TINYMCE."</span></A><br />";

Or, more broken down.

Delete lines 29-31:

$useralertson = isset($_POST['useralertson']) && $_POST['useralertson'] == "on" ? 1 : 0;
$newreviews = isset($_POST['newreviews']) && $_POST['newreviews'] == "on" ? 1 : 0;
$newrespond = isset($_POST['newrespond']) && $_POST['newrespond'] == "on" ? 1 : 0;

Modify line 38 to remove these three from the insert into database:

dbquery("UPDATE ".TABLEPREFIX."fanfiction_authorprefs SET alertson = '$useralertson', newreviews = '$newreviews', newrespond = '$newrespond', ageconsent = '$ageconsent', tinyMCE ='$tinyMCE', userskin = '$skinnew', storyindex = '$storyindex', sortby = '$sortby' WHERE uid = '".USERUID."'");

becomes

dbquery("UPDATE ".TABLEPREFIX."fanfiction_authorprefs SET ageconsent = '$ageconsent', tinyMCE ='$tinyMCE', userskin = '$skinnew', storyindex = '$storyindex', sortby = '$sortby' WHERE uid = '".USERUID."'");

Delete lines 49 and 50.

<label for='newreviews'>"._CONTACTREVIEWS.":</label> <INPUT name="newreviews" type="checkbox" class="checkbox"".($user['newreviews'] ? " checked" : "")."> <A HREF=""#"" class="pophelp">[?]<span>"._HELP_NEWREV."</span></A><br />
<label for='newrespond'>"._CONTACTRESPOND.":</label> <INPUT name="newrespond" type="checkbox" class="checkbox"".($user['newrespond'] ? " checked" : "")."><A HREF=""#"" class="pophelp">[?]<span>"._HELP_NEWRESP."</span></A><br />";

IMPORTANT. Line 48 isn't closed.  You have to add the "; that was on line 50.
Or in other words replace

$output .= "<form method="POST" enctype="multipart/form-data" style='width: 425px; margin: 0 auto;' action="user.php?action=editprefs">

with

$output .= "<form method="POST" enctype="multipart/form-data" style='width: 425px; margin: 0 auto;' action="user.php?action=editprefs">";

Delete line 52.

$output .= "<label for='useralertson'>"._ALERTSON2."</label> <INPUT name="useralertson" type="checkbox" class="checkbox"".($user['alertson'] ? " checked" : "")."><A HREF=""#"" class="pophelp">[?]<span>"._HELP_FAVALERT."</span></A><br />";

This seems to be working well on my test site, but I haven't tested it too thoroughly, so no guarantees.  Don't forget, this only removes the options from people's profiles.  If they're already selected on, then the SQL queries a couple posts up will turn those all back to 0s so everything's off.

It has the benefit of removing the option of having these notifications sent out without tampering with the other areas of the site, such as the Lost Password function, that would also need to send out emails.  (Assuming that's all related.)

Thank you for the hard work. I'm almost positive that the e-mails are whats causing the huge spikes (and crashes) on our server. Everything else is running peachy and the spikes are almost exactly timed for when popular authors update.

I wasn't kidding about the money either, we're more than happy to pay someone if they can come up with a way to throttle it. Right now it's costing us ~$300 a month  😐 so even paying for someone's time would save us money.

It sends them all out at once.

Not sure how one would approach splitting (how do you mean, for example?). The only other method I can think of is based on a "credits" system... like Portkey, I think. You can "register" for notifications based on credits, although, you know, that only works if it's a minority. 😛

I think kali's talking about spacing out the emails.  Like, where I work, we sometimes send out newsletters and stuff to our subscribed customers.  We have customer management software that allows us to do it.  It's basically a database full of contact info (it also gives the sales & tech support guys reminders and that kind of stuff).  So when we send out the emails, to avoid crashing the mail server this software has a queue function.  It queues up all the emails and releases them gradually to the mail server, and the mail server is happy.

I have no idea what it would take to do something like that with eFic.  I know there are some stories that have been favorited loads of times at my site that I'm sure cause some havoc when they're updated.  Or at least did before I ran those SQL queries above.

I also wonder if an approach like that would matter.  Where I work, they didn't use the queue one time and it pretty much killed the mail server, so it's a good thing.  But we have a dedicated mail server, and a dedicated one for the CRM software as well.  Queueing on the typical shared hosting seems like it'd be just shifting the problem - it would still have to work to queue, and it's in the same place.  I don't even know how much extra effort on the part of the server is required to send the mails.  If it's significant, then maybe it would be worth it.  Have to think about what other approaches might work...

Have you run those queries to turn off all the notifications?  It sounds like you hadn't, if you're still experiencing problems?  Part of the reason I was okay with doing it at my site (13,000 members), besides the fact that the hosting company needed some resolution, was that I knew that a lot of the accounts are abandoned or duplicates.  I haven't yet had anybody ask me why they stopped getting notifications.  But if you think something like that wouldn't be the case for you (ie OMG what happened? emails from members), then it makes sense you need other options.

You pretty much hit the nail on the head.
Our users were too smart and as soon as we said we reset the defaults, they all went back in and changed the alerts back to on. We only opened a few months ago (and we're dealing with crazed teenybopper boyband fans) so we have a pretty darn active member base.

We can't use the admin 'mail members' function because it causes the server to go down in roughly 20 seconds. If we use the SMF function, it takes about... 45-60 minutes but the server doesn't choke. So I'm pretty confident that the e-mail server can only handle our massive communications in small chunks.

The actual owner of the site (I'm just tech help) went ahead and gave me the okay to take out the favorite notifications altogether, so I'm going to mess with it this morning when there are the fewest users on.

Ah! Yeah, "queuing" e-mails will probably be pretty extensive. :-/

Have you thought about eliminating e-mails in favour of personalised RSS feeds?

Yes, we can't use the mail members feature either.  We also couldn't use coauthors in the original format, back when it was calling up the entire author list every time someone went to post a story (now it's redesigned so it's better.)  I know our server is getting hammered, but the hosting company has never taken issue with it (yet), so I haven't really gotten into this stuff too deep.  They did once chmod authors.php to 000, calling it an 'exploit', as though we'd been hacked.  It wasn't hacked, but it was taking forever to actually load any pages.  Now that's better too.

I wonder what the difference between the eFic and SMF mailing features is.  Do you have comparable numbers of members for both?

Also, have you looked at the Tracker Module over at Tammy's site?  I've got it installed on my test site (3.5) and the live monster site (3.4.3) and it works excellently.  It allows members to track what they've been reading and it generates a list (via browse.php) for each member on what they're tracking, when they last read the story, and if the story's been updated since they last read, it tells them it's new.  BUT no emails go out.  It might be a good way to have a way for them to track that stuff but not kill your server resources.  The fanfiction_tracker table gets very little overhead at my site and we've currently got 796 tracks.  It's also a one-click install that only requires adding the {tracker} and {last_read} to the skins in order to use it.

Honestly, half the time our users are to dumb to use the site, I can't imagine them figuring out the RSS feeds.

I'll take a look at the Tracker Module though. I was thinking about it the other day, but I got it confused with the 2.0 mod and didn't realize it was out for 3.

Just make sure to read this: http://efiction.hugosnebula.com/forum/viewthread.php?forum_id=11&thread_id=68&pid=315#post_315

Once I did that it was a-okay.  I also added a panel so that it would show up in Account Info in addition to Browse.