No, there isn't, Braden. However, there is a Preapproved plugin in
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.
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
> 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.
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.
On Tue, Apr 01, 2008 at 06:43:17PM -0700, 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.
On Apr 1, 7:37 pm, "Michael C. Harris" <michael.twof...@gmail.com>
wrote:
> On Tue, Apr 01, 2008 at 06:43:17PM -0700, 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.
That's a good idea, I'll try it!
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...?
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 ...
> 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?
> On Wed, Apr 2, 2008 at 4:43 AM, Michael C. Harris > <michael.twof...@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?
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'.
