Запрос JavaScript => Wordpress, какой алгоритм?

Question

[Михаил Р.]

Приветствую!

Необходимо составить JS запрос к WP. Для примера, попробуем отправить и вернуть простые данные.
После некоторого гугления, написал примитивный вариант реализации этой задачи.

В WP создаем тестовую функцию, которая будет принимать запрос от JS и отправлять json в ответ:

// временно, разместил в function.php
function fn_test() {
    wp_send_json([$_POST["prop1"], $_POST["prop2"]]);
}

add_action("wp_ajax_fn_test", "fn_test"); // только авторизованные
add_action("wp_ajax_nopriv_fn_test", "fn_test"); // только НЕ авторизованные

1. wp_ajax_fn_ - если обратиться к функции могут только авторизованные пользователи. wp_ajax_nopriv_ - для НЕ авторизованных пользователей. На настоящий момент это актуальная практика?

JavaScript-ом шлем запрос к WP:

fetch("/wp-admin/admin-ajax.php", {
    method: "POST",
    headers: { "Content-Type": "application/x-www-form-urlencoded; charset=utf-8" },
    // body: { action: "fn_test", prop1: "a", prop2: "b" }, // не работает...
    body: "action=fn_test&prop1=a&prop2=b",
})
    .then(res => res.json())
    .then(json => console.log(json));

2. В body необходимо передавать строку action=fn_test, где fn_test - это часть названия функции в WP, к которой шлем запрос?

3. Если в body необходимо передавать объект, а не строку, то как ее передать? Ибо пример (выше) с закомментированым объектом в body не сработал.

Для усложнения задачи, используем функции плагина WooCommerce. Например, добавим товар в корзину:

function fn_test() {
    global $woocommerce;
    $woocommerce->cart->add_to_cart($product_id = 565, $quantity = 1, $variation_id = 0, $variation = [], $cart_item_data = []);
    // $product_id = 565 // единственный товар созданный в админке, для тестов прямо указал его id

    wp_send_json("товар добавлен в корзину");
}

add_action("wp_ajax_fn_test", "fn_test");
add_action("wp_ajax_nopriv_fn_test", "fn_test");

4. Нормально ли так взаимодействовать с API, например того же самого WooCommerce?

Хотелось бы услышать разные мысли, как и почему правильно использовать "то", а не "это". Любым замечаниям буду рад!

Answer 1

[Игорь Воротнёв]

Есть REST API - это более современная и более удобная практика, чем wp_ajax. Но и этот метод все еще активно используется и в целом вполне ок. Но, имхо, работать с wp_ajax привычнее и удобнее бекендерам. Фронтендерам будет значительно удобнее через REST API:

https://woocommerce.github.io/woocommerce-rest-api...
https://github.com/woocommerce/woocommerce-rest-ap...

Comments

[Пашенька]

С REST API те ещё приколы, если нужен шаг влево-шаг вправо)

[Игорь Воротнёв]

Пашенька, например?

[Пашенька]

Игорь Воротнёв, например у меня была ситуация, когда один и тот же код вёл себя по разному на локалке и в проде. На локалке endpoint /property, что соответствует пост тайпу, а на проде какого-то черта эндпоинт оказывался по роуту /properties, причём я попросту угадал его, хотя естественно я ожидал поведения как на локальной машине. Пришлось что-то явно где-то передавать, чтобы привести их к одному виду, не помню уже деталей.
Такая же ситуация была при регистрации нового поля, на локалке работало безупречно, а на проде ругалось, что видите ли не тот тип я передаю - здесь уже помню - пришлось в scheme явно указать тип, при регистрации поля.
Выяснение этих аномалий занято около 6 часов. После этого не рекомендовал бы связываться с рест апи, если нужно что-то кастомное на нём мутить.

[Игорь Воротнёв]

Пашенька, честно говоря звучит как фантастика и я уверен что всему этому есть прозаичные объяснения. Например, с /property скорее всего могло получиться так, что поменялся код регистрации post type, но на одном из серверов (локальном или проде - не важно) не сделали flush rewrite rules. И поэтому где-то был новый эндпоинт, где-то старый. По полям не совсем понятно о чем вы, более детальный пример помог бы. В общем, имхо, вы столкнулись с какими-то проблемами и сделали далеко идущие выводы о технологии в целом. Дай вам бог не влезть в отладку wp-ajax в подобных ситациях - там вообще черная магия местами, и 6 часов покажутся вам детским садом.

[Пашенька]

Игорь Воротнёв, начнём с того, что мы с тобой знакомы и общались за вордпесс и прочее лет 5-6 назад вне ресурса)

В том то и дело, что я прекрасно понимаю, что у всего есть объяснение, но я попросту его не нашёл для этих ситуаций. С пост тайпом я делал лишь следующее: поскольку в родной теме был вырублен show_in_rest при регистрации post_type, то в child теме, я фильтром его включил. Больше с пост тайпом ничего не делалось он был и на основе уже его существовала база данных.
Пришлось явно задать 'rest_base':

function houzez_custom_post_type_args( $args, $post_type ) {
    if ( $post_type === 'property' ) {
        $args['show_in_rest'] = true;
        $args['rest_base'] = 'property'; // specify hard to avoid issues with route URLs on local and live sites
    }

    return $args;
}
add_filter( 'register_post_type_args', 'houzez_custom_post_type_args', 20, 2 );

Насчёт второго:

function prop_update_crm_property_multiple_terms() {
    $fields = array(
        'property_feature',
        'property_status'
    );

    foreach ($fields as $field) {
        register_rest_field( 'property',
            $field,
            array(
                'get_callback' => function ( $post, $field_name, $request ) {
                    $terms_id = wp_get_post_terms( $post['id'], $field_name );
                    $arr = array();
                    foreach ($terms_id as $term_id) {
                        $term = get_term($term_id, $field_name);
                        array_push($arr, $term->name);
                    }
                    return $arr;
                },
                'update_callback' => function ( $value, $post, $field_name ) {
                    return wp_set_object_terms( $post->ID, $value, $field_name );
                },
                'schema' => array(
                    'type' => 'array'
                )
            )
        );
    }
}
add_action( 'rest_api_init', 'prop_update_crm_property_multiple_terms' );

Если не задать 'schema', то на продакшне ругалось матом, что мол для значения этих полей передан неверный тип, хотя разумеется передавалось то же самое, что и на локалке, на которой всё работало и без schema.

Что любопытно, похожих проблем я не нашёл во всём интернете, только что-то с вукомерц было подобное у пары человек, но лишь та же ошибка - ничего дельного.

Честно говоря, после этих эпопей проще по старинке wp-ajax'ом. Там никогда не было проблем и длительной отладки. Проблемы было только из-за отсутствия опыта, но это справедливо.

[Игорь Воротнёв]

Пашенька,

Если не задать 'schema', то на продакшне ругалось матом, что мол для значения этих полей передан неверный тип, хотя разумеется передавалось то же самое, что и на локалке, на которой всё работало и без scheme.

Оси разные? Версии php? Тут вопрос вероятнее всего в чем-то выходящем далеко за пределы REST API как такового. Эксклюзивность проблемы как бы указывает на то, что это что-то экзотическое и связано именно со средой, в которой код исполняется. И да, указывать schema явно это как бы хорошая практика изначально.

В общем, не совсем понятно о чем мы спорим :) Баги и/или непонятки которые сложно дебажить бывают везде. То, что тебе пришлось столкнуться с какой-то дичью не означает, что REST API плох. Имхо, с ним работать все-таки значительно удобнее, в том числе его намного удобнее дебажить. И тесты под него удобнее делать. И быстрее он. В общем, одни положительные стороны.

[Пашенька]

Игорь Воротнёв, Да, разная среда исполнения - это единственное, что могло бы что-то объяснить.
Пыхи 7.0 и 7.1, Ubuntu и MacOS, ВордПрессы были уровняны до 5.3(на локалке первично был последний из 4-ой ветки. Я подумал, может и на локалке после обновления перестанет работать, но нет).

Да мы не спорим, я просто жалуюсь :)
Ну когда круги ада пройдены, боятся нечего, можно и в REST. С некоторой стороны это конечно удобнее, но писанины под него больше, чем классичесского wp-ajax approach.

[Пашенька]

Игорь Воротнёв, вспомнил ещё немаловажный момент: на проде был вордпресс от bitnami, сто пудов, это из-за него всё. Там ещё какие-то ишьюз возникли из-за этого bitnami по части конфигурации, советую сторониться его.

[Игорь Воротнёв]

Пашенька, о, bitnami это адский пелелац. Его стоит избегать, да.

[Михаил Р.]

Игорь Воротнёв, подскажите, как передать объект, вместо строки? В данный момент, передаю строку вида body: "action=fn_test&prop1=a&prop2=b",

[Игорь Воротнёв]

Mike Ro, я вообще не понял зачем вы body передаете.

В JS:

let form = $('[data-role="form"]');
$.ajax({
    url: siteObject.ajaxUrl,
    method: "POST",
    data: {
        "action": "php_action_name",
        "nonce": siteObject.ajaxNonce,
        "payload": form.serialize(),
    },
    success: function (response) {
        // ...
    }
});

В PHP:

function form_callback()
{
	if ( ! check_ajax_referer( 'ajaxNonce', 'nonce' ) ) {
		wp_send_json_error( new WP_Error( 'nonce', 'Invalid nonce' ) );
		die;
	}

	// Get form data payload from request into array.
	$data = [];
	parse_str( $_REQUEST['payload'], $data );
	
	// Дальше работаем с массивом $data. 

}
add_action( 'wp_ajax_php_action_name', 'form_callback' );
add_action( 'wp_ajax_nopriv_php_action_name', 'form_callback' );

Разумеется, в форме должна быть nonce, а siteObject создается с помощью wp_localize_script()

[Михаил Р.]

Игорь Воротнёв,

я вообще не понял зачем вы body передаете

Если jQuery не используется, а запросы отправляются через fetch (как в примере), то как быть?

[Игорь Воротнёв]

Mike Ro, А, сорян, не обратил внимание. В любом случае, нет смысла строку вручную строить, запилите какой-то сериализатор. Ну и я уверен для этого есть какой-то готовый package.