Спасибо.
Пакетные решения для WordPress и WooCommerce от топовых Российских авторов!
Использование «Ajax» является одним из самых распространенных методов создания и работы с пользовательскими интерфейсами.
Применение этой технологии позволяет выполнять незаметную фоновую обработку данных (без перезагрузки страницы), что значительно улучшает процесс взаимодействия пользователей с сайтом.
В качестве примера, работу Ajax в WordPress можно наблюдать в панели администратора если открыть консоль браузера и перейти во вкладку «Network», но, как и везде, в WordPress есть свои особенности работы с асинхронным JavaScript и в этой статье мы на их рассмотрим.
Осваивать работу Ajax в WordPress мы будем на реальном примере, а именно будем создавать «форму регистрации и авторизации пользователей», для вашего WordPress сайта.
Благодаря рубрикам осуществляется группировка связанных записей. Рубрика, к которой по умолчанию привязываются все новые записи — «Без рубрики» (Uncategorized), но ее можно легко изменить в настройках.
Формы, которые вы видите ниже, будут результатом нашей совместной работы. Они полностью рабочие, пробуйте.
Так как это обучающие пособие, то все пользователи, которые зарегистрировались через эту форму, периодически удаляются!
Авторизация
Регистрация
Предполагается, что читатель уже обладает базовыми навыками работы с HTML, CSS, PHP и jQuery, так как мы не будем посимвольно разжёвывать каждый кусок кода.
Начать погружение в работу Ajax на WordPress сайтах следует с изучения теории, этим и займёмся.
Начиная с бородатой версии ядра 2.8, WordPress позволяем создавать собственные события, используя встроенный Ajax, но стоит понимать, что есть ряд правил, которым нужно следовать:
Как видно, свод правил достаточно коротки и никаких критичных ограничений не несет.
Давайте уже переходить к практике.
Первое, что нам предстоит сделать – это создать HTML разметку форм для регистрации/авторизации и стилизовать их. Процесс этот описывать не будем, а сам код можно взять здесь.
Стоит учесть, что таблица стилей вашей темы может частично перекрыть стили форм, с которыми мы работаем, но в целом должно получиться примерно так:
Для начала, советуем не менять HTML разметку, которая используется в этом уроке, а просто скопировать и вставить в тело страницы, используя элемент HTML в редакторе блоков.
Скрипты в этом уроке будет опираться именно на эту разметку.
Вставляем этот код в 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();
});
});
Давайте проясним некоторые моменты:
Обратите внимание, что используются две директивы:
Вы наверное заметили, что используется функция .on(), вот так:
$('.wplb_holder').on('submit', 'form', function (event) {});
Вместо простой и привычной:
$( "form" ).submit(function( event ) {});
Дело в том, что функция .on() позволяет обращаться к динамически добавленным в DOM (объектная модель документа) элементам.
Если представить, что в результате какого-то события на странице появился новый блочный элемент с ссылкой:
Если по ссылке нужно будет кликнуть, то:
// Так работать не будет:
$('#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.
Давайте его создадим.
Возвращаемся в 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, а вот префикса может быть два:
Получается, что если нам нужен 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 файл и поработаем с данными которые вернуться.
Прежде чем, что-то сделать с данными которые мы обработали и вернули обратно, давайте посмотрим что можно сделать перед изначальной их отправкой.
Описываем функцию 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('Добро пожаловать!
Ajax выполнил свою работу, вы в системе! Перезагрузите страницу и убедитесь.');
}
})
Так как код очень простой и содержит комментарии, то описывать его смысла нет.
Как видите использовать Ajax в WordPress очень просто, но учтите, что в рамках этого урока мы опустили несколько важных моментов и предлагаем вам разобраться с ними самостоятельно:
К этому уроку мы подготовили все исходники, а форму обернули в шорткод для более удобного использования. Скачать можно тут.
Инструкция:
Вставьте этот шорткод в тело страницы, любым удобным методом, удалив лишние пробелы:
[ wplb_ajax_example ]
Если у вас есть вопросы спрашивайте в комментариях.
Спасибо.
Протокол «XML-RPC» был разработан для стандартизации взаимодействия между различными системами, что означает, что приложения вне WordPress (например, другие платформы для ведения блогов и клиенты) могут взаимодействовать с ядром вашего WordPress сайта.
WordPress использует «XML-RPC» с момента его создания и он проделал очень полезную работу. Без него WordPress был бы изолирован от остального Интернета.
Однако у xmlrpc.php есть свои недостатки. Он способен открыть уязвимости вашего сайта WordPress, и теперь его заменил WordPress REST API, который намного лучше работает как связь между 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 на своем WordPress сайте, заключается в том, что он может открыть уязвимости и стать целью атак.
Теперь, когда «XML-RPC» больше не нужен для связи вашего сайта со сторонними ПО, нет причин держать протокол открытым. Было бы разумно сделать ваш сайт более безопасным, не так ли?
Причина этого в том, что одной из ключевых особенностей WordPress всегда будет обратная совместимость. Если вы грамотно управляете своим сайтом, то вы знаете, что крайне важно поддерживать ядро WordPress в актуальном состоянии, а также любые плагины или темы.
Но всегда найдутся веб-мастера, которые не хотят или не могут периодически все обновлять, а если они используют версию, предшествующую появленению «REST API», им требуется доступ к xmlrpc.php.
Давайте рассмотрим конкретные уязвимости более подробно.
Одной из функций, реализованных в xmlrpc.php, были пингбеки и трекбэки. Это уведомления, которые появляются в комментариях на вашем сайте, когда другой блог или сайт ссылается на ваш контент.
Эта связь стала возможной благодаря протоколу «XML-RPC», но ее заменил «REST API» (как вы уже усвоили).
Если на вашем сайте включен «XML-RPC», злоумышленних потенциально может организовать DDoS-атаку на сайт, используя xmlrpc.php для отправки большого количества пингбеков на ваш сайт за короткое время. Это может перегрузить ваш сервер и вывести его из строя.
Каждый раз, когда xmlrpc.php делает запрос, он отправляет имя пользователя и пароль для аутентификации. Это представляет собой серьезную угрозу безопасности а вот «REST API» этого не делает. Фактически, «REST API» использует метод «OAuth», который отправляет токены для аутентификации вместо имен пользователей или паролей.
Поскольку xmlrpc.php отправляет информацию аутентификации с каждым запросом, злоумышленники могут использовать ее, чтобы попытаться получить доступ к сайту. Подобная атака может позволить им вставить контент, удалить код или повредить базу данных.
Если злоумышленник отправляет на ваш сайт большое количество запросов, в каждом из которых содержится пара с именем пользователя и паролем, то есть вероятность, что в конечном итоге он ударит по правильному, получит доступ к сайту.
Вот почему, если вы используете последнюю версию WordPress, которая использует «REST API» для связи с внешними системами, вам следует отключить xmlrpc.php. В нём нет необходимости, а он может сделать ваш сайт уязвимым. ☠️
Первое, что вам нужно сделать, это определить, активен ли xmlrpc.php на вашем сайте WordPress.
Это непросто проверки наличия файла. Файл является частью каждой установки WordPress и будет присутствовать, даже если «XML-RPC» отключен.
Всегда делайте резервную копию своего сайта, прежде чем что-либо удалять. В нашем случае не удаляйте просто файл xmlrpc.php, потому что он сломает ваш сайт.
Чтобы проверить, активен ли xmlrpc.php на вашем WordPress сайте, используйте сервис проверки. Этот сервис автоматически проверит ваш сайт и сообщит, активен ли протокол или нет.
Вот результат, который вы получите если проверите wordpresslab.ru через этот сервис. «XML-RPC» отключен!
Итак, если вы запустите проверку и увидите, что xmlrpc.php все еще используется на вашем сайте, как вам его отключить?
Ну что же, протокол активен, давайте отключать.
Самым простым способом будет установка и активация плагина Disable XML-RPC, не смущайтесь что плагин не обновлялся больше года. Обновлять там нечего, так как он содержит всего одну строчку кода:
add_filter( 'xmlrpc_enabled', '__return_false' );
Именно этот фильтр и отключает протокол «XML-RPC» на WordPress сайте. А если всё же не хочется использовать плагины, то достаточно вставить вышеупомянутый фильтр в файл functions.php вашей темы (желательно дочерней).
В качестве альтернативы можно отключить протокол через .htacess файл, добавив следующее условие:
Order Allow,Deny
Deny from all
Это всё! Если ни одна из этих причин не является особенно веской для вас – смело отключайте.
Единственная причина, по которой этот файл все еще находится в WordPress – это обратная совместимость. Для всех, кто хочет поддерживать свои сайты в актуальном состоянии и работает с новейшими технологиями, отключение xmlrpc.php – лучший вариант.
Протокол «XML-RPC» был разработан еще до создания WordPress как средство взаимодействия WordPress с внешними системами и приложениями. Ему присущи недостатки в плане безопасности, и он может сделать ваш сайт уязвимым для атак.
Начиная с версии 4.4 в WordPress ядро была интегрирована поддержка «REST API», что делает «XML-RPC» абсолютно не нужным. Если вы выполните описанные выше действия, отключив эту функцию, вы повысите безопасность своего сайта.
Если у вас есть вопросы – спрашивайте в комментариях и мы обязательно вам ответим.
Спасибо.
Вариативные товары WooCommerce – это товар с разными переменными, такими как цвета или размеры. Вы можете создавать разные вариации, комбинируя атрибуты. Например, если хотите продавать одежду. В этой статье вы найдете всё что нужно знать про вариативные товары в WooCommerce.
Чтобы создать вариативный товар, перейдите в раздел Товары → Добавить новый. Добавление и управление вариативными товарами очень похоже на все стольные типы товаров в WooCommerce.
После того, как вы предоставите основную информацию, такую как название, описание, артикул и так далее, обратите внимание на выпадающий список «Данные товара». Вам нужно выбрать «Вариативный товар»
Сама по себе смена типа товара на вариативный – достаточно простоя процедура. Пришло время для его настройки.
Перейдите на вкладку «Вариации». В этой вкладке и будут храниться все возможные вариации вашего товара.
Вы получите уведомление о том, что вам нужно сначала настроить атрибуты.
Затем перейдите на вкладку «Атрибуты». Выберите существующий или новый атрибут и нажмите «Добавить». В результате вы получите следующие параметры конфигурации:
Задайте имя атрибута и задайте его значения,разделяйте значения символом вертикальной черты «|» (в английской раскладке SHIFT+«/»). В качестве примера бы создан атрибут с именем «Цвет» и тремя его значениями «Красный | Зеленый | Синий».
Вы можете добавить к вариациям столько различных атрибутов, сколько вам нужно, например, можно еще добавить размер, тип или что-то ещё.
Давайте добавим еще «Размер» со значениями «M | L | XL»
Вам необходимо установить флажок «Используется для вариаций», а после этого нажать на кнопку «Сохранить атрибуты», и все готово!
Помните, что вы также можете добавить атрибуты глобально в меню Товары → Атрибуты, а затем назначить их нескольким товарам.
После того как вы создали и сохранили атрибуты нужно вернуться на вкладку «Вариации».
Вы можете автоматически создавать вариации из всех настроенных вами атрибутов. Выберите «Создать вариации из всех атрибутов» и нажмите «Применить».
Но мы так делать ну будем, так как допустим, что цена нашего товара не зависит от размера, а зависит только от цвета.
В выпадающем списке выбираем значение «Добавить вариацию», нажимаем кнопку «Применить» и заполняем необходимые поля:
Как видно на скриншоте была создана вариация в которой размер не имеет значения но цвет «Красный», а кроме стандартных полей типа «Цены», «Описание» и «Вес» мы добавили изображение красной футболки для этой вариации.
Продолжаем в том же духе и создаем еще две вариации с разными ценами и изображениями для двух, оставшихся цветов.
В конечном итоге у нас будет 3 различные вариации нашего товара с тремя различными изображениями, ценой и описанием:
Вы можете выбрать, является ли вариант виртуальным. С помощью этой опции вы можете продавать музыкальные альбомы в виде физических компакт-дисков или файлов MP3 для загрузки.
Тогда покупатель сможет выбрать один из этих двух вариантов на одной странице продукта!
Итак, Если вы правильно настроили все вариации, то вариативные товары в вашем магазине будут выглядеть примерно так:
Как видно из анимации при выборе цвета товара меняется как цена варианта так и его изображение.
Вариативные товары 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). Список дополнений также включает автоматические обновления тем и плагинов, где пользователь сам выбирает чему разрешать автоматически обновляться, а чему нет.
Команда разработчиков ядра продолжает выполнять свои обещания, а именно совершенствовать стандартный блочный редактор и WordPress 5.5 тому доказательство!
Что будет через пару лет? Увидим ли мы смерть плагина Elementor, как это было с Visual Composer (WPBakery Page Builder)?
Спасибо.
Авторизуйтесь, чтобы продолжить *
Пакетные решения для WordPress и WooCommerce
Ещё один сайт на WordPress 💛