Использование «Ajax» является одним из самых распространенных методов создания и работы с пользовательскими интерфейсами.

Применение этой технологии позволяет выполнять незаметную фоновую обработку данных (без перезагрузки страницы), что значительно улучшает процесс взаимодействия пользователей с сайтом.

В качестве примера, работу Ajax в WordPress можно наблюдать в панели администратора если открыть консоль браузера и перейти во вкладку «Network», но, как и везде, в WordPress есть свои особенности работы с асинхронным JavaScript и в этой статье мы на их рассмотрим.

Что будем делать?

Осваивать работу Ajax в WordPress мы будем на реальном примере, а именно будем создавать «форму регистрации и авторизации пользователей», для вашего WordPress сайта.

Только реальная практика, только хардкор ?
WordPress лаборатория

Благодаря рубрикам осуществляется группировка связанных записей. Рубрика, к которой по умолчанию привязываются все новые записи — «Без рубрики» (Uncategorized), но ее можно легко изменить в настройках.

Формы, которые вы видите ниже, будут результатом нашей совместной работы. Они полностью рабочие, пробуйте.

Внимание

Так как это обучающие пособие, то все пользователи, которые зарегистрировались через эту форму, периодически удаляются!

Регистрация

Загрузка...

Внимание

Предполагается, что читатель уже обладает базовыми навыками работы с HTML, CSS, PHP и jQuery, так как мы не будем посимвольно разжёвывать каждый кусок кода.

Начать погружение в работу Ajax на WordPress сайтах следует с изучения теории, этим и займёмся.

Теория использования Ajax в WordPress

Начиная с бородатой версии ядра 2.8, WordPress позволяем создавать собственные события, используя встроенный Ajax, но стоит понимать, что есть ряд правил, которым нужно следовать:

  • Все запросы должны передаваться с использованием файла admin-ajax.php, не нужно писать собственные обработчики.
  • Права на использования событий обработки асинхронных запросов должны быть правильно разграничены.
  • Использование nonce (Hash, с определенным жизненным циклом), значительно уменьшает вероятность неправомерного использования события.
  • Событие должно заканчиваться функцией wp_die(), а не die() или exit(). Сторонние разработчики часто используют фильтрацию функции wp_die(), не лишайте их этой возможности. К тому же эта функция полезна при отладке кода.

Как видно, свод правил достаточно коротки и никаких критичных ограничений не несет.

Давайте уже переходить к практике.

Практика работы с Ajax в WordPress

Первое, что нам предстоит сделать – это создать HTML разметку форм для регистрации/авторизации и стилизовать их. Процесс этот описывать не будем, а сам код можно взять здесь.

Стоит учесть, что таблица стилей вашей темы может частично перекрыть стили форм, с которыми мы работаем, но в целом должно получиться примерно так:

Ajax в WordPress – HTML разметка для формы авторизации и регистрации
Ajax в WordPress – HTML разметка для формы авторизации и регистрации

Для начала, советуем не менять HTML разметку, которая используется в этом уроке, а просто скопировать и вставить в тело страницы, используя элемент HTML в редакторе блоков.

Скрипты в этом уроке будет опираться именно на эту разметку.

Событие инициализации JS скрипта

Вставляем этот код в functions.php вашей темы (желательно дочерней):

				
					// Добавляем событие в процесс инициализации JS скриптов
add_action( 'wp_enqueue_scripts', 'wplb_ajax_enqueue' );

//Описываем событие
function wplb_ajax_enqueue() {

    // Подключаем файл js скрипта.
    wp_enqueue_script(
        'wplb-ajax', // Имя
        get_stylesheet_directory_uri() . '/scripts/wplb-ajax.js', // Путь до JS файла.
        array('jquery') // В массив jquery.
    );

    // Используем функцию wp_localize_script для передачи переменных в JS скрипт.
    wp_localize_script(
        'wplb-ajax', // Куда будем передавать
        'wplb_ajax_obj', // Название массива, который будет содержать передаваемые данные
        array(
            'ajaxurl' => admin_url( 'admin-ajax.php' ), // Элемент массива, содержащий путь к admin-ajax.php
            'nonce' => wp_create_nonce('wplb-nonce') // Создаем nonce
        )
    );

}
				
			

Давайте подробнее рассмотрим это кусок кода:

Первое, что мы делаем, хукаем событие инициализации скриптов для регистрации собственного *.js.

Обратите внимание, что мы используем функцию get_stylesheet_directory_uri(), для того, чтобы указать путь к новому JS файлу так как работаем в дочерней теме. Если вы работаете в родительской теме, то используйте функцию get_template_directory_uri().

Благодаря функции wp_localize_script(), а в файле /scripts/wplb-ajax.js, будет доступен объект с данными которые мы отправляем из PHP. Имейте ввиду, что таким методом можно передавать любые, как статичные данные из БД, так и результаты отработки циклов ☝️

Изначальное тело подключённого скрипта

Для начала, содержимое файла wplb-ajax.js, который должен находится в папке wp-content/моя_тема/scripts будет таким:

				
					jQuery(document).ready(function ($) {
    'use strict';
    'esversion: 6';

    // Функция отправки форм.
    $('.wplb_holder').on('submit', 'form', function (ev) {
        // Определяем какую форму пользователь заполнил.
        let this_is = $(this);
        
        // Определяем кнопку.
        let button = $(this).find('input[type="submit"]');
        
        // Определяем тип формы.
        let type = $(this).attr('data-type');
        
        // Отправляем запрос Ajax в WordPress.
        $.ajax({

            // Путь к файлу admin-ajax.php.
            url: wplb_ajax_obj.ajaxurl,

            // Создаем объект, содержащий параметры отправки.
            data: {

                // Событие к которому будем обращаться.
                'action': 'wplb_ajax_request',

                // Передаём тип формы.
                'type': type,
                
                // Передаём значения формы.
                'content': $(this).serialize(),

                // Используем nonce для защиты.
                'security': wplb_ajax_obj.nonce,

                // Перед отправкой Ajax в WordPress.
                beforeSend: function () {}
            }
        })
        .always(function() {
            // Выполнять после каждого Ajax запроса.
            
        })
        .done(function(data) {
            // Функция для работы с обработанными данными.
            
        })
        .fail(function(errorThrown) {
            // Читать ошибки будем в консоли если что-то пойдет не по плану.
            
            console.log(errorThrown);
            
        });

        // Предотвращаем действие, заложенное в форму по умолчанию.
        ev.preventDefault();
    });

});
				
			

Давайте проясним некоторые моменты:

Обратите внимание, что используются две директивы:

  • use strict – это так называемый «строгом режиме», который заметно ограничивает синтаксис котором можно пользоваться. Благодаря этому можно на 100% быть уверенным, что скрипт будет правильно работать во всех браузерах. Защита от тираннозавров с кривыми ручками.?
  • esversion: 6 означает, что мы используем синтаксис ECMAScript версии 6, а так версия вышла аж в 2015 году, то за совместимость с браузерами сомневаться не приходится. Можно использовать и более новые версии вплоть до 11-ой (Дата релиза: Июнь 2020), но на свой страх и риск. Понижать версию не рекомендуется.

Вы наверное заметили, что используется функция .on(), вот так:

				
					$('.wplb_holder').on('submit', 'form', function (event) {});
				
			

Вместо простой и привычной:

				
					$( "form" ).submit(function( event ) {});
				
			

Дело в том, что функция .on() позволяет обращаться к динамически добавленным в DOM (объектная модель документа) элементам.

Если представить, что в результате какого-то события на странице появился новый блочный элемент с ссылкой:

				
					<div id="wplb_new_element">
    <a href="#" id="wplb_read_more">Читать дальше..</a>
</div>
				
			

Если по ссылке нужно будет кликнуть, то:

				
					// Так работать не будет:
$('#wplb_read_more').click(function(event){});

// Так будет:
$('#wplb_new_element').on('click', '#wplb_read_more', function (event) {});
				
			

Конструкция самой $.ajax({}) функции достаточно проста, а для каждой строки мы добавили комментарии. Но стоит обратить внимание, что мы используем объект <wplb_ajax_obj, который создали при инициализации самого скрипта.

Событие, которое будет обрабатывать Ajax в WordPress ядре, в нашем случае называется wplb_ajax_request.

Давайте его создадим.

Событие обработки Ajax в WordPress

Возвращаемся в functions.php добавляем следующий код:

				
					// Создаём событие обработки Ajax в WordPress теме.
add_action( 'wp_ajax_nopriv_wplb_ajax_request', 'wplb_ajax_request' );
//add_action( 'wp_ajax_wplb_ajax_request', 'wplb_ajax_request' );

// Описываем саму функцию.
function wplb_ajax_request() {

    // Перемененная $_REQUEST содержит все данные заполненных форм.
    if ( isset( $_REQUEST ) ) {

        // Проверяем nonce, а в случае если что-то пошло не так, то прерываем выполнение функции.
        if ( !wp_verify_nonce( $_REQUEST[ 'security' ], 'wplb-nonce' ) ) {
            wp_die( 'Базовая защита не пройдена' );
        }

        // Введём переменную, которая будет содержать массив с результатом отработки события.
        $result = array( 'status' => false, 'content' => false );
        
        // Создаём массив который содержит значения полей заполненной формы.
        parse_str( $_REQUEST[ 'content' ], $creds );
        
        switch ( $_REQUEST[ 'type' ] ) {
            case 'registration':
                /**
                 * Заполнена форма регистрации.
                 */
                break;
            case 'authorization':
                /**
                 * Заполнена форма авторизации.
                 */
                break;
        }

        // Конвертируем массив с результатами обработки и передаем его обратно как строку в JSON формате.
        echo json_encode( $result );

    }

    // Заканчиваем работу Ajax.
    wp_die();
}
				
			

Для создания самого события используется хук «wp_ajax_action_name», где action_name это название события, в нашем случае wplb_ajax_request, а вот префикса может быть два:

  • WP_AJAX_NOPRIV_ WPLB_AJAX_REQUEST, событие будет доступно только для НЕ авторизированных пользователей (гости).
  • WP_AJAX_ WPLB_AJAX_REQUEST – только для авторизированных пользователей.

Получается, что если нам нужен Ajax который будет работать как для гостей, так и для авторизированных пользователей WordPress сайта, то нужно создать оба события одновременно!?

Мы так же ввели переменную $result, которая будет содержать массив с результатами обработки, а сам массив конвертируем в строку JSON формата и отправляем обратно в браузер.

Пора начинать работать с пользователями.

Регистрация пользователей

При отправки формы, благодаря функции serialize(), в глобальную переменную $_REQUEST и как элемент массива, запишутся все данные заполненной формы.

Начнем с формы регистрации, а значит там где мы используем оператор switch нас интересует случай «registration».

Вставляем следующий код:

				
					case 'registration':
    /**
     * Заполнена форма регистрации.
     */

    // Пробуем создать объект с пользователем.
    $user = username_exists( $creds[ 'wplb_login' ] );

    // Проверяем, а может быть уже есть такой пользователь
    if ( !$user && false == email_exists( $creds[ 'wplb_email' ] ) ) {
        // Пользователя не существует.

        // Создаём массив с данными для регистрации нового пользователя.
        $user_data = array(
            'user_login' => $creds[ 'wplb_login' ], // Логин.
            'user_email' => $creds[ 'wplb_email' ], // Email.
            'user_pass' => $creds[ 'wplb_password' ], // Пароль.
            'display_name' => $creds[ 'wplb_login' ], // Отображаемое имя.
            'role' => 'subscriber' // Роль.
        );

        // Добавляем пользователя в базу данных.
        $user = wp_insert_user( $user_data );

        // Проверка на ошибки.
        if ( is_wp_error( $user ) ) {

            // Невозможно создать пользователя, записываем результат в массив.
            $result[ 'status' ] = false;
            $result[ 'content' ] = $user->get_error_message();

        } else {

            // Создаём массив для авторизации.
            $creds = array(
                'user_login' => $creds[ 'wplb_login' ], // Логин пользователя.
                'user_password' => $creds[ 'wplb_password' ], // Пароль пользователя.
                'remember' => true // Запоминаем.
            );

            // Пробуем авторизовать пользователя.
            $signon = wp_signon( $creds, false );

            if ( is_wp_error( $signon ) ) {

                // Авторизовать не получилось.
                $result[ 'status' ] = false;
                $result[ 'content' ] = $signon->get_error_message();

            } else {

                // Авторизация успешна, устанавливаем необходимые куки.
                wp_clear_auth_cookie();
                clean_user_cache( $signon->ID );
                wp_set_current_user( $signon->ID );
                wp_set_auth_cookie( $signon->ID );
                update_user_caches( $signon );

                // Записываем результаты в массив.
                $result[ 'status' ] = true;
            }

        }
    } else {
        
        // Такой пользователь уже существует, регистрация не возможна, записываем данные в массив.
        $result[ 'status' ] = false;
        $result[ 'content' ] = esc_html__( 'Пользователь уже существует', 'wplb_ajax_lesson' );
    }
    break;
				
			

Всё достаточно просто. При благоприятном стечении обстоятельств пользователь будет зарегистрирован и авторизован, а в противном случае, благодаря встроенному в WordPress обработчику ошибок, мы будем знать, что именно пошло не так.

Проще говоря, результат обработки вернется в файл wplb-ajax.js в 100% случаях.

Давайте посмотрим, что можно сделать с полученным назад данными.

Авторизация пользователя

Мы еж описали процесс авторизации в блоке относящемся к регистрации, а так плодить запросы Ajax в WordPress мы не собираемся, то просто скопируем кусочек кода и вставим его в нужное место:

				
					case 'authorization':
    /**
     * Заполнена форма авторизации.
     */

    // Создаём массив для авторизации
    $creds = array(
        'user_login' => $creds[ 'wplb_login' ], // Логин пользователя
        'user_password' => $creds[ 'wplb_password' ], // Пароль пользователя
        'remember' => true // Запоминаем
    );

    // Пробуем авторизовать пользователя.
    $signon = wp_signon( $creds, false );

    if ( is_wp_error( $signon ) ) {

        // Авторизовать не получилось
        $result[ 'status' ] = false;
        $result[ 'content' ] = $signon->get_error_message();

    } else {

        // Авторизация успешна, устанавливаем необходимые куки.
        wp_clear_auth_cookie();
        clean_user_cache( $signon->ID );
        wp_set_current_user( $signon->ID );
        wp_set_auth_cookie( $signon->ID );
        update_user_caches( $signon );

        // Записываем результаты в массив.
        $result[ 'status' ] = true;
    }

    break;
				
			
Внимание

Дублирование процедур в коде – это очень плохое решение и вам стоит создать отдельную функцию, описывающую процесс авторизации и вызывать её в нужных местах.

На этом процесс обработки входных данных закачивается, давайте вернёмся в JavaScript файл и поработаем с данными которые вернуться.

Визуализация вернувшихся данных

Ajax в WordPress – пример работы
Ajax в WordPress – пример работы

Прежде чем, что-то сделать с данными которые мы обработали и вернули обратно, давайте посмотрим что можно сделать перед изначальной их отправкой.

Описываем функцию beforeSend: function () {}):

				
					// Перед отправкой запроса Ajax в WordPress ядро.
beforeSend: function () {

    // Спрячем кнопку и покажем пользователю, что скрипт работает.
    button.hide();
    this_is.find('.wplb_alert').hide();
    this_is.find('.wplb_loading').show();
}
				
			

Всё просто, мы спрятали кнопку отправки формы и показали всевдоспинер, для визуализации процесса.

Теперь опишем процесс визуализации вернувшихся данных:

				
					.done(function(data) {
    // Функция для работы с обработанными данными.

    // Переменная $reslut будет хранить результат обработки.
    let $result = JSON.parse(data);

    // Проверяем какой статус пришел
    if($result.status == false){

        //Пришла ошибка, скрываем не нужные элементы и возвращаем кнопку.
        this_is.find('.wplb_alert').addClass('wplb_alert_error').html($result.content).show();

        button.show();

    }else{

        // Пользователь авторизован, покажем ему сообщение.
        $('.wplb_holder').addClass('wplb_alert wplb_signon').html('<p style="margin-bottom:3px;"><strong>Добро пожаловать!</strong></p>Ajax выполнил свою работу, вы в системе! Перезагрузите страницу и убедитесь.');
    }

})
				
			

Так как код очень простой и содержит комментарии, то описывать его смысла нет.

Послесловие и исходный код

Как видите использовать Ajax в WordPress очень просто, но учтите, что в рамках этого урока мы опустили несколько важных моментов и предлагаем вам разобраться с ними самостоятельно:

К этому уроку мы подготовили все исходники, а форму обернули в шорткод для более удобного использования. Скачать можно тут.

Инструкция:

  • Содержимое файла functions.php из архива добавьте в конец одноименного файла (functions.php) вашей темы.
  • Скопируйте файл wplb_ajax_template.php в коревую папку вашей WordPress темы.
  • В корневой папке вашей темы создайте папку scripts и положите туда файл wplb-ajax.js

Вставьте этот шорткод в тело страницы, любым удобным методом, удалив лишние пробелы:

				
					[ wplb_ajax_example ]
				
			

Если у вас есть вопросы спрашивайте в комментариях.

Спасибо.

Протокол «XML-RPC» был разработан для стандартизации взаимодействия между различными системами, что означает, что приложения вне WordPress (например, другие платформы для ведения блогов и клиенты) могут взаимодействовать с ядром вашего WordPress сайта.

 

WordPress использует «XML-RPC» с момента его создания и он проделал очень полезную работу. Без него WordPress был бы изолирован от остального Интернета.

 

Однако у  xmlrpc.php есть свои недостатки. Он способен открыть уязвимости вашего сайта WordPress, и теперь его заменил WordPress REST API, который намного лучше работает как связь между WordPress и другими приложениями.

 

В этом посте мы объясним, что такое xmlrpc.php в WordPress, почему

желательно бы его отключить, и поможем определить, работает ли он на вашем сайте.

 

Поехали…

Что такое xmlrpc.php в WordPress?

Итак, как вы уже знаете, «XML-RPC» – это протокол, который обеспечивает связь между WordPress и другими системами. Добились этого путем стандартизации этих коммуникаций с использованием «HTTP» в качестве транспортного механизма и «XML» в качестве механизма кодирования.

 

XML-RPC появился гораздо раньше чем сам WordPress: он присутствовал в программном обеспечении для ведения блогов «b2», одна из ветвей которого использовалась для создания WordPress в уже далёком 2003 году. Частично, код ПО «b2» хранится в файле с именем  xmlrpc.php в корневом каталоге сайта. Да, он все еще существует, хотя «XML-RPC» в значительной степени устарел.

 

В ранних версиях WordPress «XML-RPC» был отключен по умолчанию. Но начиная с версии 3.5 он вернулся. ? Сделано это было для того, чтобы мобильное приложение WordPress (iOS и Android) могло взаимодействовать с вашим WordPress сайтом.

 

Если вы использовали мобильное приложение до версии 3.5, вы, возможно, помните, что вам нужно было отдельно включить «XML-RPC» на сайте, чтобы приложение могло публиковать контент. Это произошло потому, что в приложении не взаимодействовало напрямую с WordPress, а существовало отдельное ПО, связывающееся с вашим сайтом с помощью xmlrpc.php.

 

Стоит уточнить, что «XML-RPC» взаимодействовал не только с приложением, он также использовался для обеспечения связи между WordPress и другими платформами для ведения блогов, он подключал, так называемые «Pingbacks» (обратные ссылки), а также работал с плагином Jetpack.

 

Но с приходом «REST API» и интеграцией его в ядро ​​WordPress, файл xmlrpc.php больше не используется для этого типа взаимодействий. Сейчас «REST API» используется для связи с мобильным приложением WordPress, с настольными клиентами, с другими платформами для ведения блогов, с WordPress.com (для плагина Jetpack) и с другими системами. Диапазон систем, с которыми может взаимодействовать «REST API», намного больше, чем в xmlrpc.php. Кроме того, «REST API» даёт гораздо больше гибкости для разработчиков.

 

Опираясь на то, что «REST API» заменил «XML-RPC», вам следует отключить xmlrpc.php на своем WordPress сайте. Давайте разбираться почему это нужно сделать.

Почему рекомендуется отключить xmlrpc.php?

Основная причина, по которой вы должны отключить  xmlrpc.php на своем WordPress сайте, заключается в том, что он может открыть уязвимости и стать целью атак.

 

Теперь, когда «XML-RPC» больше не нужен для связи вашего сайта со сторонними ПО, нет причин держать протокол открытым. Было бы разумно сделать ваш сайт более безопасным, не так ли?

Если xmlrpc.php уязвим и больше не нужен, почему он не был полностью исключен из WordPress? ?
Хороший вопрос да?

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

 

Но всегда найдутся веб-мастера, которые не хотят или не могут периодически все обновлять, а если они используют версию, предшествующую появленению «REST API», им требуется доступ к xmlrpc.php.

 

Давайте рассмотрим конкретные уязвимости более подробно.

1. DDoS-атаки через пингбеки XML-RPC

Одной из функций, реализованных в xmlrpc.php, были пингбеки и трекбэки. Это уведомления, которые появляются в комментариях на вашем сайте, когда другой блог или сайт ссылается на ваш контент.

 

Эта связь стала возможной благодаря протоколу «XML-RPC», но ее заменил «REST API» (как вы уже усвоили).

 

Если на вашем сайте включен «XML-RPC», злоумышленних потенциально может организовать DDoS-атаку на сайт, используя xmlrpc.php для отправки большого количества пингбеков на ваш сайт за короткое время. Это может перегрузить ваш сервер и вывести его из строя.

2. Brute Force атаки через XML-RPC

Каждый раз, когда xmlrpc.php делает запрос, он отправляет имя пользователя и пароль для аутентификации. Это представляет собой серьезную угрозу безопасности а вот «REST API» этого не делает. Фактически, «REST API» использует метод «OAuth», который отправляет токены для аутентификации вместо имен пользователей или паролей.

 

Поскольку xmlrpc.php отправляет информацию аутентификации с каждым запросом, злоумышленники могут использовать ее, чтобы попытаться получить доступ к сайту. Подобная атака может позволить им вставить контент, удалить код или повредить базу данных.

 

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

 

Вот почему, если вы используете последнюю версию WordPress, которая использует «REST API» для связи с внешними системами, вам следует отключить xmlrpc.php. В нём нет необходимости, а он может сделать ваш сайт уязвимым. ☠️

Работает ли xmlrpc.php на вашем WordPress сайте?

Первое, что вам нужно сделать, это определить, активен ли xmlrpc.php на вашем сайте WordPress.

 

Это непросто проверки наличия файла. Файл является частью каждой установки WordPress и будет присутствовать, даже если «XML-RPC» отключен.

 

Всегда делайте резервную копию своего сайта, прежде чем что-либо удалять. В нашем случае не удаляйте просто файл xmlrpc.php, потому что он сломает ваш сайт.

 

Чтобы проверить, активен ли xmlrpc.php на вашем WordPress сайте, используйте сервис проверки. Этот сервис автоматически проверит ваш сайт и сообщит, активен ли протокол или нет.

Вот результат, который вы получите если проверите wordpresslab.ru через этот сервис. «XML-RPC» отключен!

Итак, если вы запустите проверку и увидите, что xmlrpc.php все еще используется на вашем сайте, как вам его отключить?

Как отключить xmlrpc.php на своём WordPress сайте?

Допустим вы отправили сайт на проверку, как написано выше и получили вот такой результат:

Ну что же, протокол активен, давайте отключать.

Самым простым способом будет установка и активация плагина Disable XML-RPC, не смущайтесь что плагин не обновлялся больше года. Обновлять там нечего, так как он содержит всего одну строчку кода:

				
					add_filter( 'xmlrpc_enabled', '__return_false' );
				
			

Именно этот фильтр и отключает протокол «XML-RPC» на WordPress сайте. А если всё же не хочется использовать плагины, то достаточно вставить вышеупомянутый фильтр в файл functions.php вашей темы (желательно дочерней).

 

В качестве альтернативы можно отключить протокол через .htacess файл, добавив следующее условие:

				
					<Files xmlrpc.php>
Order Allow,Deny
Deny from all
</Files>
				
			

Как отключить xmlrpc.php на своём WordPress сайте?

В некоторых случаях xmlrpc.php может быть полезен и его не следует полностью отключать.

Это всё! Если ни одна из этих причин не является особенно веской для вас – смело отключайте.

Единственная причина, по которой этот файл все еще находится в WordPress – это обратная совместимость. Для всех, кто хочет поддерживать свои сайты в актуальном состоянии и работает с новейшими технологиями, отключение xmlrpc.phpлучший вариант.

XML-RPC когда-то был важной частью WordPress, но теперь протокол угрожает безопасности вашего WordPress сайта ?

Подведем итог

Протокол «XML-RPC» был разработан еще до создания WordPress как средство взаимодействия WordPress с внешними системами и приложениями. Ему присущи недостатки в плане безопасности, и он может сделать ваш сайт уязвимым для атак.

 

Начиная с версии 4.4 в WordPress ядро была интегрирована поддержка «REST API», что делает «XML-RPC» абсолютно не нужным. Если вы выполните описанные выше действия, отключив эту функцию, вы повысите безопасность своего сайта.

 

Если у вас есть вопросы – спрашивайте в комментариях и мы обязательно вам ответим.

 

Спасибо.

Вариативные товары WooCommerce – это товар с разными переменными, такими как цвета или размеры. Вы можете создавать разные вариации, комбинируя атрибуты. Например, если хотите продавать одежду. В этой статье вы найдете всё что нужно знать про вариативные товары в WooCommerce.

Как создать вариативный товар в интернет-магазине на основе WooCommerce?

Чтобы создать вариативный товар, перейдите в раздел Товары → Добавить новый. Добавление и управление вариативными товарами очень похоже на все стольные типы товаров в WooCommerce.

После того, как вы предоставите основную информацию, такую как название, описание, артикул и так далее, обратите внимание на выпадающий список «Данные товара». Вам нужно выбрать «Вариативный товар»

Создание вариативного товара в WooCommerce
Создание вариативного товара в WooCommerce

Настройка вариативного товара

Сама по себе смена типа товара на вариативный – достаточно простоя процедура. Пришло время для его настройки.

Перейдите на вкладку «Вариации». В этой вкладке и будут храниться все возможные вариации вашего товара.

Вы получите уведомление о том, что вам нужно сначала настроить атрибуты.

Вариации в вариативном товаре WooCommerce
Вариации в вариативном товаре WooCommerce

Затем перейдите на вкладку «Атрибуты». Выберите существующий или новый атрибут и нажмите «Добавить». В результате вы получите следующие параметры конфигурации:

Добавление атрибута и его значений для использования в вариациях
Добавление атрибута и его значений для использования в вариациях

Задайте имя атрибута и задайте его значения,разделяйте значения символом вертикальной черты «|» (в английской раскладке SHIFT+«/»). В качестве примера бы создан атрибут с именем «Цвет» и тремя его значениями «Красный | Зеленый | Синий».

Вы можете добавить к вариациям столько различных атрибутов, сколько вам нужно, например, можно еще добавить размер, тип или что-то ещё.

Давайте добавим еще «Размер» со значениями «M | L | XL»

Добавляем еще один атрибут к вариативному товару в WooCommerce
Добавляем еще один атрибут к вариативному товару в WooCommerce

Вам необходимо установить флажок «Используется для вариаций», а после этого нажать на кнопку «Сохранить атрибуты», и все готово!

На заметку

Помните, что вы также можете добавить атрибуты глобально в меню Товары → Атрибуты, а затем назначить их нескольким товарам.

Создание и настройка вариаций из атрибутов товара

После того как вы создали и сохранили атрибуты нужно вернуться на вкладку «Вариации».

Вы можете автоматически создавать вариации из всех настроенных вами атрибутов. Выберите «Создать вариации из всех атрибутов» и нажмите «Применить».

Создание вариаций из всех атрибутов
Создание вариаций из всех атрибутов

Но мы так делать ну будем, так как допустим, что цена нашего товара не зависит от размера, а зависит только от цвета.

В выпадающем списке выбираем значение «Добавить вариацию», нажимаем кнопку «Применить» и заполняем необходимые поля:

Создание первой вариации из атрибутов
Создание первой вариации из атрибутов

Как видно на скриншоте была создана вариация в которой размер не имеет значения но цвет «Красный», а кроме стандартных полей типа «Цены», «Описание» и «Вес» мы добавили изображение красной футболки для этой вариации.

Если не установить цену вариации, то этот вариант не будет отображаться на странице товара!

Продолжаем в том же духе и создаем еще две вариации с разными ценами и изображениями для двух, оставшихся цветов.

В конечном итоге у нас будет 3 различные вариации нашего товара с тремя различными изображениями, ценой и описанием:

Вариации с разными изображениями для вариативного товара в WooCommerce
Вариации с разными изображениями для вариативного товара в WooCommerce

Вы можете выбрать, является ли вариант виртуальным. С помощью этой опции вы можете продавать музыкальные альбомы в виде физических компакт-дисков или файлов MP3 для загрузки.

Тогда покупатель сможет выбрать один из этих двух вариантов на одной странице продукта!

Вариативные товары на странницах магазина WooCommerce

Итак, Если вы правильно настроили все вариации, то вариативные товары в вашем магазине будут выглядеть примерно так:

Вариативные товары WooCommerce на страницах магазина
Вариативные товары WooCommerce на страницах магазина

Как видно из анимации при выборе цвета товара меняется как цена варианта так и его изображение.

Альтернатива вариациям

Вариативные товары WooCommerce не всегда удовлетворяют всем потребностям.

Помните, что каждый вариант, по сути, является отдельным товаром, созданным в WooCommerce. Он просто сгруппирован с другими вариантами.

Вариативные товары добавляет несколько отдельных записей в базу данных для каждого отдельного варианта. Для 50 вариантов в базе данных будет 50 субпродуктов. У интернет-магазинов с большим количеством вариативных товаров могут возникнуть проблемы.

Кроме того, если вам нужны функции персонализации в вашем магазине, то вариации совсем не для этого. Они не позволяют вводить дополнительные текстовые поле, чекбоксы и так далее. Например в нашем варианте с майками было было не плохо добавить опцию удаления или загрузки своего логотипа.

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

Надеемся, что данная статья помогла вам понять что такое вариативные товары WooCommerce и как с ними работать. Если у остались вопросы – спрашивайте в комментариях ?

Спасибо.

7 июля 2020 года команда WordPress открыла WordPress 5.5 Beta 1 для массового тестирования. Выпуск версии 5.5 состоялся 11 августа 2020 года.

WordPress 5.5 стал вторым значимым релизом 2020 года и содержит в себе значительные улучшения и приятные плюшки. Конечно, многие исправления и улучшения сосредоточены редакторе блоков (Гутенберг), но общий список изменений выглядит многообещающим.

В этой заметке мы познакомимся с некоторыми основными дополнениями вошедшими в состав WordPress версии 5.5, но кое-что выделяется особенно.

Предварительный просмотр на разных типах устройств – Конечно, вы можете использовать инструменты разработчика в браузере Chrome (CTRL+U), но не проще ли нажать кнопку? Спросите любого, кто работает на плагине Elementor. Удобно же!

Возможность добавлять сторонние блоки прямо из редактора также интересна.

Генерация XML-карты сайта является частью ядра, как и отложенная загрузка изображений (Lazy load). Список дополнений также включает автоматические обновления тем и плагинов, где пользователь сам выбирает чему разрешать автоматически обновляться, а чему нет.

Изменения в редакторе блоков Gutenberg, появившиеся в WordPress 5.5

Изменения в редакторе блоков Gutenberg, появившиеся в WordPress 5.5
Изменения в редакторе блоков Gutenberg, появившиеся в WordPress 5.5
  • Редактирование изображений — кадрирование, поворот и масштабирование изображений через панель управления блоком /изображение.
  • Шаблоны блоков — создание сложных страниц стало легче благодаря встроенному шаблонизатору. Несколько шаблонов доступны по умолчанию.
  • Предварительный просмотр — возможность просмотра страницы на экранах разного размера.
  • Новая панель управления блоками — отображает упорядоченные категории и коллекции. В качестве бонуса поддерживает шаблоны и интегрируется с новым каталогом блоков.
  • Каталог блоков — находите, устанавливайте и вставляйте сторонние блоки из вашего редактора, используя новый каталог блоков.
  • Новые возможности редактирования:
    • Доведенная до ума концепция Drag-and-Drop.
    • Возможность выбора родительского блока.
    • Выделения значимых/фокусных частей контента.
    • Возможность одновременного изменения нескольких блоков.
    • Возможность копирования и перетаскивания группы блоков.
    • Улучшенная производительность (ну посмотрим, по тестируем).
  • Расширенный набор инструментов для дизайна тем
  • Можно установить фон и градиент для еще большего типа блоков.
  • Добавлена поддержка большего количества типов единиц измерения – можно задавать размеры в : em, rem, %, vh, vw.

Другие изменения в WordPress 5.5

  • Блок содержащий список ссылок можно конвертировать в навигационный блок, так называем «Table of Contents» – оглавления на странице с возможностью быстрого перемещения по странице.
  • Копирование ссылок с экрана редактирования файлов «Медиафайлы» и в модальных диалоговых окнах теперь можно выполнить одним кликом.
  • Мета-боксы теперь можно перемещать с помощью клавиатуры.
  • Логотип на главной странице больше не работает как ссылка.
  • Плагины и темы теперь можно обновить, загрузив ZIP-файл.
  • Обновлены несколько внешних библиотек, включая PHPMailer, rSimplePie, Twemoji, Masonry и другие.

Команда разработчиков ядра продолжает выполнять свои обещания, а именно совершенствовать стандартный блочный редактор и WordPress 5.5 тому доказательство!

Что будет через пару лет? Увидим ли мы смерть плагина Elementor, как это было с Visual Composer (WPBakery Page Builder)?

Спасибо.

Поможем вывести Ваш бизнес на новый уровень!

Проснувшись однажды утром после беспокойного сна, Грегор Замза обнаружил

Добро пожаловать!

Авторизуйтесь, чтобы продолжить

или

Забыли пароль? Восстановить

* Если аккунта у Вас еще нет, то он будет создан автоматически

Давайте составим техническое задание!
100% без риска
Нет обязательств по найму
Бесплатная оценка стоимости
Здравствуйте! Я асистент на основе искусственного интеллекта. Вы можете общаться со мной, как с человеком — задавайте вопросы, описывайте свои идеи и требования.

С удовольствием помогу вам составить техническое задание для вашего WordPress проекта. Если Вам нужна техническая поддержка по купленному у нас плагину или шаблону, то создайте тикет в личном кабинете.

Выберите подходящий вариант или опишите свою задачу в свободной форме, и я помогу вам составить четкий план действий, для оценки стоимости нашими разработчиками! 😊