The plugin adds a new value to the comment in the comment database, the “Blocked Comment ID” number, which is a GUID-type number assigned to the comment form as a hidden field. If that value is not in the POST for the comment, then a bot is most likely trying to submit directly (via CURL or another automated process) to the comment-post.php page. So that bot-submitted comment (without that GUID value), is blocked as spam, and you get the “Go away spammer” message.
You can test this process by following the instructions on the plugin’s settings page. There is a CURL command that will ‘bot’ your comment form. You can then enable/disable the plugin to see how your ‘bot’ submission is blocked when the plugin is active.
The Comments list on the back-end (Admin) pages shows that GUID value in the last column. This is not the comment ID (which is normally not shown, but you can see it in the links for each comment on the comments list page), but the GUID that the plugin stores.
The intent of that extra column of GUIDs is to show you that the comment (if there is a GUID value in that column) was not a bot-submission. If the GUID is missing, then it’s probable that a bot submitted the comment…which means that the plugin was disabled, or not working correctly.
So, with the plugin enabled, a comment on the admin comments list page should show a value in that column. That tells you that the plugin is working properly.
In addition, the GUID value is not present in the form initially. It is changed via some JS after a delay after a click/focus in the comment textarea. That prevents a bot from knowing the GUID value and submitting it. That’s one of the tricks my FormSpammerTrap code uses (see the https://www.formspammertrap.com site for info).
BTW, still working on the other issue (the ‘reply’ not working on the admin/comment page). Still digging around trying to find the ‘hook’ that can be used to add the hidden field to the comment form on the admin back end.
Thanks for the explanation. I follow you. You are correct, the IDs are not normally shown, but the Reveal IDs plugin does show them.
With Reveal IDs active there is a box added to the end, in the last column. In my website Admin area, when looking at all the comments I get this;
image of reveal IDs plugin active
If I deactivate this plugin, and activate your plugin (Block Comment Spam Bots), it does as you say and adds a new box on the end, in the last column, just like the Reveal IDs plugin (but with a different value, the value you pointed out);
image of Block Comment Spam Bots plugin active
The issue is when both of them are active at the same time, and I get this;
image of both plugins active at the same time
It seems your plugin is showing up in the Reveal IDs’ little box too. The value seems to be the same if cut short. A duplicate. For some reason, the Reveal IDs plugin is pulling your value out of the database, or your plugin is over-writing the Reveal IDs’ value, or some other shenanigans.
Is there a way to correct this?
Thanks for the additional info and screen shots. I am able to duplicate the issue on my test system.
I will have to dig into the RealID code to see where they get the ID value, and why they are getting my GUID value as the comment ID.
Working on it…
Digging into this. Looks like the RealID code is grabbing the value of the comment meta values from the comment-meta table. If you look at this screenshot of a new comment with my plugin enabled, these values are in the comment-meta table for that new comment:
https://www.dropbox.com/s/509rk61f9p20oue/screenshot-showing-comment-meta-entries-for-reveal-id-problem.jpg?dl=0
You can see that I have stored the bcsb_hidden GUID value in the comment-meta table for that comment. And for some reason, the RealID code is grabbing that value when it does this function in their plugin:
/**
* Echo the ID for the column
*
* @since 1.3.0
* @author scripts@schloebe.de
*/
function column_value($column_name, $id) {
if ($column_name == 'ridwpaid') echo $id;
}
Not sure why they aren’t grabbing the ID value from the actual comment, rather than grabbing the last record in comment-meta and using the value in there. But it seems to be an issue with their code, not mine.
My code grabs the bcsb_hidden GUID value from the comment-meta table, using this code:
$bcsp_hidden = get_comment_meta($comment->comment_ID, 'bcsb_hidden', true);
which does a query on the comment-meta table for that comment ID value, looking for the entry for “bcsb_hidden” (the last entry shown in the screenshot of that table).
So, not an issue with my plugin, but appears to be an issue with their plugin. You might try another “reveal id” plugin and see if it works better for you.
Thanks for looking into this. I’ll contact the creator of the Reveal IDs plugin and see if they will update it.
If they do not, or will not, is there a quick and dirty fix for their function that will make it work correctly? Do I just have to change or term or something, or is it more involved?
Just for grins, I decided to try installing other ‘show id’ plugins, and they also show the GUID in their ID column.
So, perhaps it is my plugin. Unless the other plugins are getting the ID the same way.
Back to the drawing board for me.
Version 2.2 is now available. Fixes:
– using ‘reply’ link on Admin/Comments list no longer blocked as spam
– using a ‘show ID’ plugin does not duplicate the GUID value in the plugin’s column on the Admin/Comments list
– green checkbox shown instead of the GUID value (although you can hover over the checkmark to see the GUID value)
All changes in the Changelog (readme).
Thanks for your alert and assistance on this.
