On Jan 12, 8:59 am, "Scott Merrill" <[email protected]> wrote:
...
>
> $post->info->{$comment->email} = 'SUBSCRIBE';
> $post->info->update(); // this is what commits your changes to the DB
And all of that code looks fine.
What I would suggest, though, is what Arthus was talking about in his
prior message. Habari has a commentinfo table that allows you to
store metadata with each comment, just like you can with each post.
So while you're subscribing to a post, your comment is actually
attached to the post, and the comment has info on it saying that
you're subscribed. This is better for a couple of reasons.
The first reason has to do with a limitation of postinfo. As you
noticed, postinfo keys (like commentinfo keys) are unique. So you
can't have multiple "subscribed" values unless they're stored in an
array in a single key.
You can do this:
$post->info->subscribed = array('[email protected]',
'[email protected]');
But then you can't easily query for posts to which [email protected]
is subscribed because the array value is serialized into the table.
You've also noticed that using the email address as the key works, but
it's messy, since you can't easily query for all of the subscribers to
a single post.
If you instead store subscription status in commentinfo, things become
a bit easier.
To enable a subscription via comment:
$comment->info->subscribed = true;
And then when you want a list of users who are subscribed to a post
(for when a new comment is added):
$cc = array();
foreach($post->comments as $comment) {
if($comment->info->subscribed) {
$cc[] = $comment;
}
}
And you're mostly done. To unsubscribe, you'd need to unset (or set
to false) the subscribed value for every comment belonging to a
commenter with a specific email address on a specific post.
This might work, and if not, it's close:
$comments = Comments::get(array('email'=>$unsub_email, 'post_id'=>
$post_id));
foreach($comments as $comment) {
unset($comment->info->subscribed);
$comment->info->commit();
}
Some of this could be made more efficient via direct queries, but the
API makes it easy. And we could expand on this API in the future, for
example, to make it easy to find posts where the comments have a
specific value for a commentinfo key. (In other words, a Posts::get()
that returns posts to which an email address has subscribed.)
> > 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.
I'm not sure if you're talking about UI or logic here, but I'll take
on logic for a moment.
It's possible to grab the rewrite rule for posts and add a thing to
the end so that you can take a couple of arguments.
This is the default rule regex:
%^(?P<slug>[^/]+)(?:/page/(?P<page>\d+))?/?$%i
And you'd create a new rule that uses parts of it to create this:
%^(?P<slug>[^/]+)/unsubscribe/(?P<emailhash>[\da-f]+)/?$%i
The new rule responds to URLs that look like this:
/my-post-slug/unsubscribe/38f1ac6
You can dispatch URLs that match the new rule to a handler in your
plugin. If the hash is included (it's optional), code would search
for an email in the comments that matched the hash. If it doesn't
find a matching address, it displays an error. If it does find a
matching address, it displays a confirmation form. Upon confirming
that the user really wanted to unsubscribe, unsubscribe that address.
This format of URL (with the hash) would be useful for including in
the sent emails, so that users could two-click their way to
unsubscription.
If no hash accompanies the URL, the plugin could instead display a
template with a form that allowed the user to enter their email
address to unsubscribe, and then do the search that way. This format
would be useful for adding a link near the comment form to
unsubscribe.
I think the actual display of the form is what skippy's talking
about. What he's saying (it took me a minute to figure out) is that
you can't easily create a template that fits into a site layout to
display only static content. Here's what he proposes...
When you handle the request, you create a new post, fill it with your
static content, and then send it to display like it was any other
post.
Perhaps it would look something like this:
$form = $this->get_unsub_confirmation_form(); // Returns FormUI
$post = new Post();
$post->title = 'Unsubscribe to ' . $orig_post_title;
$post->content = $form->get();
$post->type = Post::type('page');
$theme->post = $post;
$theme->act_display_post();
exit;
As an aside: There definitely needs to be a better way to do this.
Should we perhaps institute some template like "static.php" that
outputs generic content? A full implementation of this template may
look like this:
<?php $theme->display('header'); ?>
<?php echo $content; ?>
<?php $theme->display('footer'); ?>
I digress.
> > 4. Any other comments or pointers would be helpful. :)
I haven't looked to see if you have, but if you have not and are
interested, sharing your work via the -extras repository is an easy
way to get collaborative help on your plugin. It also automatically
creates builds for distribution on habariproject.org. Or not, it's
entirely up to you.
Owen
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
