Extended version breaking JetFormBuilder Formless action endpoints

Hi @dcsupport,

Thanks for getting back to me on this. JetFormBuilder’s formless action endpoints are essentially a way for users to perform front-end actions such as “Delete Post”, “Save Draft”, or “Update Profile” without displaying a visible form on the page. These actions are handled through the WordPress REST API or admin-ajax.php, depending on configuration. You can find out more about it here.

In this setup, there’s no actual element rendered on the front end — the submission happens via JavaScript using a REST or AJAX request. That means WP Armour’s JavaScript layer never has access to a form where it can inject its honeypot field, which in turn causes the request to fail the spam check since those expected fields aren’t present.

Here’s the temporary workaround I’m using at the moment, which disables WP Armour’s spam protection for logged-in users (who are already authenticated). This ensures that form submissions using formless endpoints work correctly:

<?php
/**
 * Disables WP Armour spam protection for logged-in users.
 * Logged-in users are already authenticated, so honeypot protection is not necessary.
 * Version: 1.3.0
 */

/**
 * Main approach: Inject the required honeypot fields into $_POST for logged-in users
 * This must run AFTER user authentication but BEFORE WP Armour checks the submission
 */
add_action( 'init', 'wparmour_bypass_logged_in_users', 1 );

function wparmour_bypass_logged_in_users() {
    // Only process for logged-in users making POST requests (not in admin)
    if ( ! is_user_logged_in() || is_admin() ) {
        return;
    }
    
    // Only for POST requests
    if ( ! isset( $_SERVER['REQUEST_METHOD'] ) || $_SERVER['REQUEST_METHOD'] !== 'POST' ) {
        return;
    }
    
    // Get the WP Armour honeypot field name
    $wpa_field_name = get_option( 'wpa_field_name' );
    
    if ( empty( $wpa_field_name ) ) {
        return;
    }
    
    // Inject the required fields to bypass WP Armour's spam check
    // The wpa_check_is_spam() function checks for these fields:
    // 1. The honeypot field must exist
    // 2. The alt_s field must exist and be empty
    
    if ( ! isset( $_POST[ $wpa_field_name ] ) ) {
        $_POST[ $wpa_field_name ] = rand( 1111, 999999 );
    }
    
    if ( ! isset( $_POST['alt_s'] ) ) {
        $_POST['alt_s'] = '';
    }
    
    // Make sure the global is set for WP Armour's internal checks
    $GLOBALS['wpa_field_name'] = $wpa_field_name;
}

/**
 * Secondary approach: Remove JetFormBuilder validation hook for logged-in users
 * This is a failsafe in case the POST injection doesn't work
 */
add_action( 'jet-form-builder/form-handler/before-send', 'wparmour_remove_jetform_validation', 1, 1 );

function wparmour_remove_jetform_validation( $form ) {
    if ( is_user_logged_in() ) {
        // Remove WP Armour Extended's JetFormBuilder spam validation
        remove_action( 'jet-form-builder/form-handler/before-send', 'wpae_jetform_builder_extra_validation', 10 );
    }
    return $form;
}

/**
 * Performance optimization: Don't load WP Armour scripts for logged-in users
 * Since logged-in users bypass validation, no need to add honeypot fields via JavaScript
 */
add_action( 'wp_enqueue_scripts', 'wparmour_skip_scripts_for_logged_in', 999 );
add_action( 'login_enqueue_scripts', 'wparmour_skip_scripts_for_logged_in', 999 );

function wparmour_skip_scripts_for_logged_in() {
    if ( is_user_logged_in() ) {
        // Dequeue WP Armour base plugin scripts
        wp_dequeue_script( 'wpascript' );
        wp_dequeue_style( 'wpa-css' );
        
        // Dequeue WP Armour Extended scripts (to prevent JS errors)
        wp_dequeue_script( 'wpaescript' );
        wp_dequeue_style( 'wpae-css' );
    }
}

I completely understand WP Armour’s purpose in preventing automated submissions, but in scenarios like this, logged-in users are already verified, so additional honeypot validation doesn’t add security and only introduces conflicts with formless logic.

It might be worth adding a toggle in the plugin’s settings — for example, “Skip spam checks for logged-in users” — to avoid edge cases like this as more form plugins introduce dynamic or formless submission methods. 100% appreciate it must be complex accounting for these edge cases, as many of the form builders have become highly complex and nuanced in their functionality.

Happy to test any dev build or patch you’d like to try.

Best,
Tony