User self-registration plugin, comment behavior

[Don Chambers]

The user self registration plugin (serendipity_event_adduser) has the ability to limit the posting of comments to logged in users. Non logged-in users see a message that only registered users can post comments.... but they also receive a message as if the entry does not allow comments at all:

"The author does not allow comments to this entry".

This second message is misleading, especially if there are existing comments to that entry. Is it possible to revise the plugin so that it does not emit this second message?

[garvinhicking]

Hi!

Sadly not; this is the message that is reserved for when commenting is rejected and/or closed.

The template itself could override this, but then the plugin would be template-dependant.

The only way I see is to alter the message string itself, reading something like "Comments are not enabled" or whatever else, which needs to suit in all cases.

Regards,
Garvin

[Don Chambers]

hmmm... the only time it really applies is if a specific entry has comments disabled, and that option is set in the entry table for that specific entry. Any chance something could be changed so that message is only displayed if it was read from the database? Just thinking out loud here...

[garvinhicking]

Hi!

The template only checks for one variable ("comments closed") and since this is the only variable that plugins can also set to disable comments, the template cannot differentiate between "closed due to entry setting" or "closed due to plugins". This is not possible without changing every template.

So I really think the only way is to change the wording more globally. Any suggestions?

Regards,
Garvin

[Don Chambers]

Well, I tried! Thanks for the explanation Garvin. Can a template override a global language constant?

[garvinhicking]

Well, I tried! Thanks for the explanation Garvin. Can a template override a global language constant?

I think stm9x9 in the past did some work on this so that this would work. However I don't remember if it worked. Since the constants are constants and not variables, once they are set, they cannot be overwritten - so the order of if a template gets first or the system language would be important...

[Don Chambers]

Another issue - if comments are limited to logged in users, that restriction also applies to the contact form. this is a REAL problem for me. Is there any way to have an option for this (either in the user self-registration plugin or the contact form plugin) so true comments are limited to logged in users only, but contact form submissions can be made by anyone?

[garvinhicking]

Another issue - if comments are limited to logged in users, that restriction also applies to the contact form. this is a REAL problem for me. Is there any way to have an option for this (either in the user self-registration plugin or the contact form plugin) so true comments are limited to logged in users only, but contact form submissions can be made by anyone?

Sadly not, because the contact form plugin actually uses the internal s9y hooks for "commenting".

You can patch serendipity_event_contactform.php by removing line 231 and 324:

serendipity_plugin_api::hook_event('frontend_saveComment', $ca, $commentInfo);

This will remove all anti-spam methods applied to contact form submissions.

Regards,
Garvin

[Don Chambers]

You can patch serendipity_event_contactform.php by removing line 231 and 324:

serendipity_plugin_api::hook_event('frontend_saveComment', $ca, $commentInfo);

This will remove all anti-spam methods applied to contact form submissions.

Regards,
Garvin

So no way to allow contact form submission without disabling all anti-spam? I have experienced plenty of spam abuse of contact forms.

If your option above is the only choice, how about a plugin option to override those lines rather than hack the plugin to remove them (so future plugin updates don't overwrite the modifications)?

[garvinhicking]

Hi!

So no way to allow contact form submission without disabling all anti-spam? I have experienced plenty of spam abuse of contact forms.

If your option above is the only choice, how about a plugin option to override those lines rather than hack the plugin to remove them (so future plugin updates don't overwrite the modifications)?

[/quote]

Sadly, that's not how plugins work; a plugin cannot override another plugin. Plugin event hooks are always passed along. You would then need to patch both involved plugins and make them listen on a distinct variable.

I could see if there's a way to patch contactform, spamblock and adduser all together to add a distinction variable there; you'll need to use s9y 1.7 alpha then though and updated versions of the two non-core plugins (or you'd need to fetch the spamblock plugin from the 1.7 trunk into your version). I'll try to check into that tomorrow.

Regards,
Garvin

[garvinhicking]

Hi!

Might be easier than I tought, the adduser plugin already had the option I was thinking it needed to implement.

I just committed version 1.14 of the contactform plugin to github, which has a simple change to make the adduser plugin think that it does not need to check for "registered author".

HTH,
Garvin

[Don Chambers]

Thanks Garvin - should that be version 1.15? Version I am already using is 1.14.

[garvinhicking]

Thanks Garvin - should that be version 1.15? Version I am already using is 1.14.

Sorry, yeah, 1.15 then

[Don Chambers]

Works great! Thanks Garvin!