Thanks for the pointers, Scott, and also for the word of caution on the emails. I considered the possible impact of sending one email per subscriber on high-traffic sites but wasn't sure of any better alternatives. I thought maybe a queue might help, but a very active post could create quite a backlog. Is there any sense in sending emails with 10 or so BCC recipients at a time?
I seem to remember the subscribe2 plugin making use of a crontab. Did you ever come up with any best practices for sending out subscriber emails? I'd also thought of storing subscriber addresses in an array in a single record, but decided against it fearing one glitch while inserting new data could destroy the whole record. Maybe I'm being too paranoid though. Thanks again, Steve On Jan 12, 6:59 am, "Scott Merrill" <[email protected]> wrote: > On Sun, Jan 11, 2009 at 11:55 PM, Steve Love <[email protected]> wrote: > > Hi, everyone. I started using Habari about a week ago (loving it) and > > saw the need for a "Subscribe to Comments" plugin, so I'm giving it a > > shot. (If one already exists I'd love to know!) > > Mike Lietz and I have kicked around a few ideas for such a plugin. I'd > written some of the necessary underpinnings, but got hung up on > user-facing stuff. > > > Here's what I particularly would like help with: > > 1. I'm currently using inline SQL where I know I should be using > > something like Posts::get(array('info' => array('blah')). I just can't > > seem to get it to work, perhaps because of the next item. > > Let's tackle these in order. > > // Is this email address already subscribed to the comments on this post? > $query = "SELECT value > FROM " . DB::table( 'postinfo' ) . " > WHERE name=?"; > $result = DB::get_row( $query, array($comment->email) ); > $subscribed = ( ! empty($result) ); > > Our info records should permit you to query for this value directly. > You have a comment object, so from that you need to fetch the > corresponding post object. Then you can interrogate that post's > postinfo records. > > $post= Post::get( array( 'id' => $comment->post-id ) ); > $subscribed= $post->info->{$comment->email}; > > Note I'm note sure if the above will work, or if you need to stuff the > email into a temporary (non-object) variable. > > Similarly, for writing to a postinfo value: > $query = "INSERT INTO " . DB::table( 'postinfo' ) . " > (post_id, name, type, value) > VALUES (".$comment->post_id.", '".$comment->email."', 0, '".$s2c."')"; > DB::query( $query ); > > $post->info->{$comment->email} = 'SUBSCRIBE'; > $post->info->update(); // this is what commits your changes to the DB > > > 2. I originally wanted to add a new column to the comments table > > during activation. Couldn't get that to work, so I changed gears and > > now I'm adding entries to the postinfo table, but I'm not really happy > > about the way this is done. Since the name column is unique, I use it > > to store the subscriber's email address and set the value column to > > "SUBSCRIBE". Is that why I can't grab subscribers with Posts::get(array > > ('info' => array('value' => 'SUBSCRIBE', 'post_id' => $comment- > >>post_id))) ? > > Posts::get() returns post objects. Post objects do provide access to > their associated postinfo objects, but it sounds to me like you want > the postinfo objects exclusively, so you shouldn't be querying for > them using Posts::get() > > Incidentally, in my subscribe-to-comments efforts, I simply stored an > array of all the subscribed email addresses in a single postinfo > record. When a new subscriber signed up, their addresses was appended > to the array. This has its own set of benefits and drawbacks. > > > 3. There is no way to unsubscribe. Anyone have suggestions for > > implementing this? > > There is a way, but it's not very classy. Essentially, you need to > create an empty post, and then have a handler to generate your content > when that post is requested. It's not entirely intuitive. > > > 4. Any other comments or pointers would be helpful. :) > > In my work on the WordPress subscribe2 plugin, I learned the hard way > that hosting providers are absolutely insane when it comes to email. > Some hosts will limit the total number of messages you can send per > day. Some hosts will limit the total number of addresses any one > message can handle. > > Your code sends one email per subscriber, which is likely to work on > some hosts, and should work fine on low-volume sites. If several > hundred people subscribe to a single post, and that post gets frequent > comment activity, your code may result in a nastygram from the hosting > provider to the account owner. > > Of course, you can't simply BCC everyone, either, because hosts like > Dreamhost limit you to a total of 30 recipients per message. I > included huge amounts of code into susbcribe2 to account for Dreamhost > and other similarly broken hosting providers. > > Other than those caveats, it looks like this is a fine start! > > It might be worth taking a peek at our nascent ACL work. You could > conceivably create a new account when someone subscribes to a post. > You could then construct an admin form using FormUI to permit a user > to manage their subscriptions. Their account should only have access > to this subscription management interface, and not have access to > create new posts, etc. > > Cheers, > Scott --~--~---------~--~----~------------~-------~--~----~ To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/habari-dev -~----------~----~----~----~------~----~------~--~---
