支付后如何调用 gform_is_delayed_pre_process_feed？

2026-10-24支付老李

结论

gform_is_delayed_pre_process_feed 不是支付完成后主动调用的函数，而是 Gravity Forms 处理 Feed 时执行的 WordPress Filter。

当前代码有两个问题：

add_filter() 的第二个参数必须是可调用的回调函数，不能直接传入 true。
Gravity Forms 很可能在支付回调执行前就已经检查了这个 Filter，此时再注册不会改变之前的判断。

正确做法是在插件初始化阶段注册 Filter，并通过回调函数返回 true 或 false。支付完成后，再通过 Gravity Forms Payment Add-On Framework 的支付完成流程处理被延迟的 Feed。

正确注册 Filter

在插件加载时注册 Filter：

add_filter(
    'gform_is_delayed_pre_process_feed',
    array( 'My_Gateway', 'delay_pre_process_feed' ),
    10,
    4
);

然后定义回调函数：

class My_Gateway {

    public static function delay_pre_process_feed(
        $is_delayed,
        $form,
        $entry,
        $slug
    ) {
        // 只对指定 Feed 延迟处理。
        // 请将目标 slug 替换为当前 Add-On 实际使用的 slug。
        if ( $slug === 'your-feed-slug' ) {
            return true;
        }

        return $is_delayed;
    }
}

返回 true 表示延迟执行该 Feed，返回 false 表示立即执行。

如果不需要根据表单或 Feed 判断，也可以使用 WordPress 内置回调：

add_filter(
    'gform_is_delayed_pre_process_feed',
    '__return_true'
);

但这种写法会影响所有经过该 Filter 的 Feed，因此支付插件通常不应无条件使用。

为什么原来的代码无效

下面的写法不正确：

add_filter( 'gform_is_delayed_pre_process_feed', true );

add_filter() 的第二个参数必须是 callable，例如：

'__return_true'

或者：

array( 'My_Gateway', 'delay_pre_process_feed' )

即使改成下面这样，也仍然可能无效：

public static function Verify() {
    add_filter(
        'gform_is_delayed_pre_process_feed',
        '__return_true'
    );
}

Verify() 是在客户从支付网关返回后才执行的，而 Gravity Forms 通常会在最初提交表单、处理 Feed 时判断是否延迟。Filter 不会追溯修改已经完成的判断。

支付完成后的正确处理方式

如果支付网关插件基于 GFPaymentAddOn 开发，建议使用 Payment Add-On Framework 的标准回调流程：

提交表单时，通过 gform_is_delayed_pre_process_feed 将目标 Feed 标记为延迟。
用户前往支付网关完成付款。
网关服务器回调或返回请求到达插件。
插件验证签名、订单号、金额和支付状态。
插件向 Payment Add-On Framework 返回或提交“支付完成”的结果。
框架更新 Entry 的支付状态，并处理延迟的 Feed。

典型的回调结构如下：

public function process_callback() {
    $entry_id = absint( rgpost( 'entry_id' ) );

    $entry = GFAPI::get_entry( $entry_id );

    if ( is_wp_error( $entry ) ) {
        return false;
    }

    if ( ! $this->verify_gateway_callback( $entry ) ) {
        return false;
    }

    return array(
        'type'           => 'complete_payment',
        'entry_id'       => $entry_id,
        'transaction_id' => sanitize_text_field(
            rgpost( 'transaction_id' )
        ),
        'amount'         => (float) rgpost( 'amount' ),
    );
}

具体的返回字段和回调入口取决于插件继承的 Gravity Forms 支付基类及所用版本，应以当前版本的 Payment Add-On Framework 回调契约为准。支付回调要做的是通知框架付款已经完成，而不是重新注册 gform_is_delayed_pre_process_feed。

如果插件没有使用 Payment Add-On Framework

如果支付插件只使用自定义 WordPress 回调，没有接入 GFPaymentAddOn 的支付完成机制，Gravity Forms 不一定会自动重新处理延迟的 Feed。

此时需要明确调用目标 Add-On 提供的 Feed 处理接口，或者将支付插件接入 Payment Add-On Framework。不要直接调用：

apply_filters( 'gform_is_delayed_pre_process_feed', true );

这段代码只会计算并返回过滤结果，不会执行 Feed，也不会更新文章。

注意事项

Filter 必须在 Gravity Forms 开始处理表单前注册，通常应放在插件初始化代码中。
add_filter() 的第二个参数必须是合法的 callable。
返回 true 表示延迟 Feed，并不表示立即运行 Feed。
$slug 必须使用目标 Add-On 实际注册的 Feed slug，不能直接使用显示名称。
支付完成状态应以服务端回调或可靠的支付查询结果为准，不能只信任浏览器返回的参数。
调试时可以记录 $slug、Entry ID 和支付状态，但不要将密钥、签名原文或完整的支付信息写入日志。