Disabling Comment Moderation?
Braden
Is there a way to disable comment moderation, preferably while
preserving spam filtering?
Sorry if this is covered elsewhere, but it didn't come up in any of my
searches.
Thanks!
Braden
rick c
Habari Extras ( http://habariproject.org/dist/plugins/ ). This plugin
automatically approves comments from people who already have approved
comments in your database so they aren't held in moderation. Spam
filtering, if you have it activated, still continues. I hope this
helps.
Rick
http://sagrising.cockrumpublishing.com
Braden
Seems to be a fairly straight-forward plugin... presumably I could
modify it to just always approve new comments?
I ask just in case there is a particular reason why it would be bad to
make the plugin do this... other than the general problems that could
arise from not having moderation.
- Braden
On Apr 1, 4:13 pm, rick c <rickcock...@gmail.com> wrote:
> No, there isn't, Braden. However, there is a Preapproved plugin in
> comments in your database so they aren't held in moderation. Spam
> filtering, if you have it activated, still continues. I hope this
> helps.
>
rick c
From looking at the code you could modify Preapproved to always
approve comments. You would, of course, have the general problems you
talk about. Make sure you have your spam filters active. You could
also look into the Simpleblacklist plugin. It scans for specific
phrases, urls, and ip addresses you give it to mark as spam. With the
hooks they're using, the spam filters look at the comment first, then
the Simpleblacklist plugin, then at the end Preapproved gets its shot.
Rick
http://sagrising.cockrumpublishing.com
Michael C. Harris
>
> Seems to be a fairly straight-forward plugin... presumably I could
> modify it to just always approve new comments?
If you did do this, it might make senes to simply have it as a
configurable option in the PreApproved rather than as a whole separate
plugin. You might consider submitting a patch.
--
Michael C. Harris, School of CS&IT, RMIT University
http://twofishcreative.com/michael/blog
Braden
wrote:
>
> > Seems to be a fairly straight-forward plugin... presumably I could
> > modify it to just always approve new comments?
>
> If you did do this, it might make senes to simply have it as a
> configurable option in the PreApproved rather than as a whole separate
> plugin. You might consider submitting a patch.
One thing about the PreApproved plugin is that it seems to cause an
"Internal Server Error" when I activate it or (attempt to) deactivate
it. It seems to happen due to a call to EventLog::register_type in
its action_plugin_activation function, and also
EventLog::unregister_type in its action_plugin_deactivation function.
Do those need to be there...?
- Braden
Michael C. Harris
>
> One thing about the PreApproved plugin is that it seems to cause an
> "Internal Server Error" when I activate it or (attempt to) deactivate
> it. It seems to happen due to a call to EventLog::register_type in
> its action_plugin_activation function, and also
> EventLog::unregister_type in its action_plugin_deactivation function.
> Do those need to be there...?
That's an excellent question. I've CC'd this to the developers list.
There's a comment in the code that asks if we should be unregistering
the 'PreApproved' type. I haven't looked into the implications of
unregistering a type (yet); perhaps someone can now say if it's a bad
idea? The evidence above suggests it may be ...
Scott Merrill
<michael...@gmail.com> wrote:
>
> On Wed, Apr 02, 2008 at 12:42:16AM -0700, Braden wrote:
> >
> > One thing about the PreApproved plugin is that it seems to cause an
> > "Internal Server Error" when I activate it or (attempt to) deactivate
> > it. It seems to happen due to a call to EventLog::register_type in
> > its action_plugin_activation function, and also
> > EventLog::unregister_type in its action_plugin_deactivation function.
> > Do those need to be there...?
>
> That's an excellent question. I've CC'd this to the developers list.
> There's a comment in the code that asks if we should be unregistering
> the 'PreApproved' type. I haven't looked into the implications of
> unregistering a type (yet); perhaps someone can now say if it's a bad
> idea? The evidence above suggests it may be ...
I don't like the idea of unregistering log types when the plugin that
provides that log type is deactivated. It means that there could be
logs stored in the DB for which no log type is defined.
For the record, I also dislike the idea of removing statuses and
content type indicators when plugins that create them are deactivated.
Can someone provide a compelling argument for why it would be
beneficial to remove a log type, status type, or content type record
when the associated plugin is disabled?
Braden
Just to follow up here, the consequence to unregistering a log type is
that any log entries that reference that type get marked as
"Unknown". As such, I would think it is not desirable to remove the
log type when there still exist entries in the log associated with
that type.
As for adding log types, apparently they are added automatically when
writing to the log (by LogEntry::type() called by
LogEntry::insert()). So does one even need to register a log type
when activating a plugin?
BTW, the reason the PreApproved plugin was causing an internal server
error is because it passed only one argument to the two-argument
function register_type, which has the second argument ('module') set
to null by default, but the schema of the log_types table disallows
nulls for 'module' or 'type'.
- Braden