achbed

	global $wp_plugin_bnblocker;
	if ( method_exists( $wp_plugin_bnblocker, 'is_botnet' ) ) {
		if ( $wp_plugin_bnblocker->is_botnet() ) {
			status_header( 203 );
			// Do other changes here
		}
	}

General note: this mas merged to the master branch of the github repository today.

Patch to add this behavior:

Index: includes/classes/admin/mapping/base.php
===================================================================
--- includes/classes/admin/mapping/base.php	(revision 1576743)
+++ includes/classes/admin/mapping/base.php	(working copy)
@@ -174,10 +174,11 @@
 				break;
 			case 'post_status':
 				$select_options = array(
-					'publish' => __( 'Published', 'gathercontent-import' ),
-					'draft'   => __( 'Draft', 'gathercontent-import' ),
-					'pending' => __( 'Pending', 'gathercontent-import' ),
-					'private' => __( 'Private', 'gathercontent-import' ),
+					'publish'  => __( 'Published', 'gathercontent-import' ),
+					'draft'    => __( 'Draft', 'gathercontent-import' ),
+					'pending'  => __( 'Pending', 'gathercontent-import' ),
+					'private'  => __( 'Private', 'gathercontent-import' ),
+					'nochange' => __( 'Do not change', 'gathercontent-import' ),
 				);
 				break;
 			case 'post_type':
Index: includes/classes/sync/pull.php
===================================================================
--- includes/classes/sync/pull.php	(revision 1576743)
+++ includes/classes/sync/pull.php	(working copy)
@@ -223,7 +223,9 @@
 		}
 
 		if ( $status = $this->mapping->get_wp_status_for_item( $this->item ) ) {
-			$post_data['post_status'] = $status;
+			if ( $status != 'nochange' ) {
+				$post_data['post_status'] = $status;
+			}
 		}
 
 		$backup = array();

All blocks still get reported as an Apache-level return value (404 if you use the built-in blocking mechanism). You can track things from there. The one thing you won’t see is that the 404 was caused by this plugin.

On one of my sites I’m using the plugin to cause a 203 result instead of a 404, and returning alternate (less server taxing) set of data to the visitor/bot. I can then check my Apache logs to see the portion of results returned this way (since I had almost no 203 results before, this makes the most sense and least effort on the plugin).

Adding an internal logging mechanism could be handy, but presents all sorts of log rotation/clearing, external log, and reporting/analysis issues. Not something I can dive into right now.

Marking resolved.

This should be fixed in v1.2.3.

The issue was that we were blocking during an action that was before the global wp_query object was set up. We now check for bots in the pre_get_posts action, and set the query to a 404 at that point instead.