Name and email comment requirement blocks Mastodon replies

[averymd]

Howdy! I found that attempts to reply to posts via Mastodon were disappearing into the void. Apache access logs revealed that there was first a 202 reply, then a 500 error, but no details made it into my Wordpress debug log. In fact, nothing ended up in my Apache error logs, either, but that might be a hosting problem.

I added some manual debugging to this plugin's code and was able to find out that my blog's requirement for a name and email address on comments was causing the error.

I see that that's supposedly accounted for in the handle_create() and handle_reaction() methods:

// do not require email for AP entries
\add_filter( 'pre_option_require_name_email', '__return_false' );

$state = \wp_new_comment( $commentdata, true );

\remove_filter( 'pre_option_require_name_email', '__return_false' );

Based on an old StackExchange answer, I changed those to __return_null and a quick Postman test resulted in a comment (in spam probably thanks to Akismet, but not completely lost).

I didn't submit a PR because it's been a long, long time since I've done anything other than basic theme dev in WP and I haven't done extensive testing on this, but hopefully this fix is correct.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[Cambridgeport90]

Still an issue from what I can tell.

From: stale[bot] @.> Sent: Thursday, September 22, 2022 10:10 PM To: pfefferle/wordpress-activitypub @.> Cc: Subscribed @.***> Subject: Re: [pfefferle/wordpress-activitypub] Name and email comment requirement blocks Mastodon replies (Issue #154)

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

Reply to this email directly, view it on GitHubhttps://github.com/pfefferle/wordpress-activitypub/issues/154#issuecomment-1255728928, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ADS4MAEADONNABPZLC4TG4DV7UGP5ANCNFSM5W6K7DMA. You are receiving this because you are subscribed to this thread.Message ID: @.@.>>

[jaschaurbach]

I would love to be able to have the requirement for comments on the website while the comments from the fürdiverse come through. I use to have a gigantic spam problem after blogpost which go around a lot and the hurdle keeps away at least a few...

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[pfefferle]

Keep!

[janboddez]

Based on an old StackExchange answer, I changed those to __return_null and a quick Postman test resulted in a comment (in spam probably thanks to Akismet, but not completely lost).

I think, from what I understand from https://developer.wordpress.org/reference/hooks/pre_option_option/, that false is in fact the default value and skips the "shortcut." I.e., __return_false is the same as not doing any filtering. That may explain why returning null instead does work.

Indeed, WP core does do a strict check against false:

if ( false !== $pre ) {
	return $pre;
}

So __return_null or __return_zero or anything that doesn't evaluate to, I think, '1' would work.

That said, I'm not facing the issue. I guess because the "flood check" is disabled, which has the same effect?

[github-actions[bot]]

This issue is stale because it has been open 120 days with no activity. Remove stale label or comment or this will be closed in 5 days.

[mediaformat]

A while back I test using webfinger in this field, predictably comments were no longer systematically held. Even the Comment author must have a previously approved comment setting worked.

It seems like a hack, but ultimately a the user@domain paradigm is compatible.

[pfefferle]

I think this is no longer an issue, please re-open if it is.