Cyr to lat enhanced плагин для чего: Cyr to Lat enhanced — Плагин для транслитерации кириллических символов

Анализ кода плагина Cyr to Lat enhanced — Cyr to Lat enhanced

Текст видео

Здравствуйте, друзья. Рубрика “Под капотом” и это первое её видео. Сегодня разберем код плагина Cyr to Lat enhanced — очень популярным плагином по транслитерации кириллистических и грузинских символов в урле в латинские тире английские. Да что тут рассказывать, скорее всего вы о нём знаете.

Этот плагин не обновлялся 4 года, но им продолжают пользоваться, так как он до сих пор выполняет свои задачи. Имеет высокий рейтинг, но наряду с положительными отзывами имеет несколько отрицательных, весьма не беспочвенных. В этом видео постараемся во всём разобраться… изнутри. Для этого открою главный файл плагина, он же единственный, и сверну весь код для удобства изучения его структуры.

Сразу в глаза бросается отсутствие проверки среды WordPress. Обычно проверяют наличие константы ABSPATH. Если обратиться к этому файлу напрямую и сервер настроен так, что показывает ошибки (так не должно быть, но всё же), то сервер упадет с 500 ошибкой, так как интерпретатор php не нашёл функцию add_filter() или другую функцию WordPress, входящую в состав плагина. В этой ошибке будет указать путь, где хранится файл плагина, а это небезопасно.

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

Заглянем в эту функцию. А здесь на хуке shutdown вызывается еще одна функция ctl_convert_existing_slugs(). Возникает вопрос, зачем создана эта прокладка в виде хука, неужели нельзя было напрямую вызвать функцию ctl_convert_existing_slugs() при активации плагина? Можно, конечно, если бы эта функция выполнялась быстро и потенциально без ошибок. Но она может выполняться продолжительное время и это может привести к фатальной ошибке сервера. Допустим, функция выполняется 40 секунд. А у каждого сервера есть лимит на выполнение php скрипта, как правило это 30 секунд. Что произойдет, если этот лимит будет превышен? Правильно, сервер остановит выполнение php скрипта на 30 секунде, выдаст 500 ошибку, а плагин, естественно, не активируется. Но что произойдет, если запустить эту функцию через хук shutdown? Этот хук срабатывает в момент, когда PHP скрипт завершил все свои операции. Получается, плагин активируется, то есть отрабатывает весь дефолтный функционал WordPress и только в самом конце вызывается наша функция, которой снова дается 30 условных секунд на выполнение. И тут уже не важно, успеет она отработать или нет, с ошибками или без — плагин уже активирован и готов к работе.

Давайте теперь посмотрим, что из себя представляет функция ctl_convert_existing_slugs() и почему из-за неё такой сыр-бор. Итак, обращаемся к глобальной переменной с объектом класса для работы с базой данных. Видим, код функции разделен на 2 логические части. Судя по названиям переменных 1 часть работает с записями, а 2 с терминами.

Начнем с 1 части. С помощью метода get_results() мы делаем запрос, прочтем его: выбрать значения из колонок с именами ID и post_name из таблицы с постами, где значения из колонки post_name (именно на основе значений этой колонки формируется ссылка поста) должны удовлетворять следующему регулярному выражению, а именно в нем должен содержаться хотя бы один символ, не являющейся буквой английского алфавита в любом регистре, цифрой и знака “дефис”. Получается, что в эту выборку не попадут посты, которые уже прошли транслитерацию и обрабатывать их уже нет смысла. Но это не все условия запроса. На ряду с условием с участием регулярки значения колонки post_status (статус поста) должно быть из следующих вариантов — publish (опубликованные), future (запланированные) и private (личные). Подчеркну, метод get_results() вернет посты, удовлетворяющие сразу двум условиям.

Итак, мы сделали запрос и получили массив с записями, которые еще не прошли транслитерацию. Этот массив будет состоять из объектов записей, у которых будет всего два свойства — ID и post_name. По контексту напрашивается все эти записи транслитерировать, что и делается в следующей строчке. Значение свойства post_name передаем в функцию ctl_sanitize_title(), предварительно пропустив через функцию urldecode(). Зачем? Взглянем, какой post_name у записи, который был сформирован на основе ее заголовка с кириллическими символами (показываю бд). Именно urldecode() вернёт ей прежний вид, а дальше уже дело за функцией ctl_sanitize_title(), которую рассмотрим чуть позже, чтобы не отвлекаться, просто сейчас держим в уме, что она транслитерирует переданную строку. Теперь полученный результат сравним с тем, что был до транслитерации. Если изменения были, то делаем две вещи. Обновляем значение post_name у поста, теперь он будет открываться по новому транслетерируемому урлу. А также в метополе _wp_old_slug помещаем старое значение, благодаря этому, когда пользователь зайдет по старому урлу, движок перенаправит его на новый урл и отдаст 301 статус, в общем для сео говорят полезно. Это в теории, в реальности же из-за вмешательства самого же плагина в функционал движка перенаправления не происходит, этот момент разберем попозже, когда изучим работу плагина лучше. Подытог: первой частью кода находим посты с нетранслитерированными урлами и делаем это.

Переходим ко второй части и тут делаем тоже самое, только с терминами. Единственное значимое отличие — у терминов нет метаполя и, соответственно, функционала хранить старый урл и делать перенаправление тоже.

Итак. Мы узнали, что делает функция ctl_convert_existing_slugs(), которая запускается после активации плагина — транслитерирует урлы у постов и терминов, что есть на сайте одним махом. И именно это свойство плагина отразилось в негативных отзывах. Людям не понравилось, что плагин затронул урлы старых постов и терминов. Отсюда вывод, если вы создаете новый сайт, то волноваться не о чем, но если у вас уже есть посты и термины, то знайте — плагин при активации изменит их урлы, впрочем оригиналы у постов будут сохранены в метаполе. Также мы видим, что функция активно работает с базой данных, получая и сохраняя данные. Если на сайте было много постов и терминов, то перебор и обновление данных может занять продолжительное время, вот почему ее выполнение повесили на хук shutdown. Кстати, а вы в разработке пользуетесь этим хуком?

Идём дальше. Мы уже столкнулись с функцией ctl_sanitize_title(), предлагаю теперь и ее посмотреть, но прежде обратите внимание, что она также дополнительно вызывается на хук-фильтрах sanitize_title и sanitize_file_name. Фильтр sanitize_title срабатывает в одноименной функции, которая очищает переданную строку от недопустимых символов. Обратите внимание, что приоритет выставлен на 9, когда по умолчанию он 10, то есть функция плагина будет отрабатывать в первую очередь, а потом все остальные. Несмотря на название, ее часто используют для очистки slug’ов. Получается, когда мы сохраняем пост или термин, значение slug, которое затем используется при построении урла, очищается с помощью этой функции, тем самым задействуется данный фильтр и значение slug также проходит через функцию ctl_sanitize_title(), транслетируруя его. Тоже самое происходит и на фильтре sanitize_file_name, только это относится к файлам — при сохранении имя файла транслитерируется тоже.

Теперь, когда вроде как всю логику работы плагина разрулили, дело остаётся за малым — разобраться, как же происходит сам процесс транслитерации строки в функции ctl_sanitize_title(). Обращаемся к глобальной переменной с экземпляром класса по работе с бд, тут всё понятно. Далее идет массив с кириллическими символами и их аналогами из символов английского алфавита. Также имеется подобный массив, только с грузинским алфавитом. Объединяем массивы в один. Получаем локаль сайта и на ее основе делаем небольшие корректировки в исходном массиве.

Теперь с помощью функции debug_backtrace() получаем стек вызовов функций в виде массива. Если в этом стеке присутствует название функции wp_insert_term, значит функция sanitize_title() была вызвана при создании термина. В результате этой проверки в переменной $is_term будет или true — создаем термин, или false — в противном случае.

Если $is_term равно true, то делаем запрос на основе переданной строки, используя ее как заголовок термина и пытаемся получить slug термина. Сакральный смысл этого запроса я так и не понял. А вы? Обратите внимание, что переменная $title передается в sql запрос как есть, что по сути является потенциальной sql-инъекцией. В таких вещах используйте метод prepare() или функцию esc_sql(), чтобы избежать проблем. В результате этой конструкции в переменной $term мы получаем или slug термина или пустоту. Если slug термина есть, то без каких либо преобразований возвращаем его. Но если он отсутствует, то переданную строку нужно транслитерировать.

Это делается за несколько шагов. Первый шаг — самый главный. С помощь функции strtr() мы заменяем каждый символ переданной строки в соответствии с нашим массивом соответствий. Правда массив мы перед этим пропускаем через фильтр ctl_table, чтобы у нас была возможность извне изменить данный массив на основе своих нужд. К примеру, дополнить массив китайскими иероглифами.

Далее, если в системе поддерживается функция iconv(), то преобразуем переданную строку из кодировки UTF-8 в такую же, но со специальными, скажем так, флагами TRANSLIT и IGNORE. Строка TRANSLIT включает режим транслитерации. Это значит, что в случае, если символ не может быть представлен в требуемой кодировке, он будет заменен на один или несколько наиболее близких по внешнему виду символов. Если добавить строку IGNORE, то символы, которые не могут быть представлены в требуемой кодировке, будут удалены.

Далее идут мелкие, но не менее важные преобразования. С помощью preg_replace() и описанному регулярному выражению заменяем все символы в переданной строке, которые не являются английскими буквами любого регистра, нижним подчеркиванием, дефисом и точкой на знак дефиса. Затем тем же методом избавляемся от повторно идущих знаков дефис. Затем убираем дефис с начала строки, если таковой есть, а затем и с конца. Всё, транслитерация строки завершена. Под строкой, как правило, я подразумевал slug поста или термина, то есть часть ссылки.

Что же, друзья, весь функционал плагина мы вычитали и теперь можем поговорить о баге с перенаправлением, о котором я упоминал. Мы знаем как транслитерируется строка, а также знаем, что это происходит на хуке sanitize_title. И в этом вся проблема! Когда вы пытаетесь зайти на пост по старому урлу, движок по идее должен выдать 404 ошибку, но прежде он пытается с помощью функции wp_old_slug_redirect() найти пост, у которого возможно когда-то был такой урл и перенаправить туда с 301 ответом сервера. За нахождение id такого поста с таким вот “старым” урлом отвечает функция _find_post_by_old_slug() или _find_post_by_old_date(). Заглянем в первую. И видим запрос, который ищет пост, у которого есть метаполе с ключом _wp_old_slug и значением, которое берется из переменных запроса с помощью функции get_query_var(). Указано name, что по сути есть slug записи. Давайте завардампим это дело. Сейчас плагин отключен. Пробую зайти на пост со старым урлом. Вот такой slug у записи. Посмотрим, что хранится в метаполе — а в нем тоже самое. Уберу свой код, перезагружаю страницу и происходит перенаправление на эту же запись, но с новым урлом. А теперь включу плагин и сделаю тоже самое. И видим, что закодированный slug испорчен, исчезли знаки процента. Перенаправления тоже нет, ведь по такому slug естественно ни один пост теперь не находится. В какой же момент плагин всё портит? В момент создания основного запроса, когда параметр name передается функции sanitize_title_for_query(), которая в свою очередь передает строку уже известной нам функции sanitize_title(), а в ней что? Правильно, хук sanitize_title и тут плагин вступает в работу и избавляется от знаков процента. Получается, вроде плагин предусмотрел сохранение старого slug, но в тоже время не дает им воспользоваться. Такие дела.

Итак, друзья, что мы извлекли из чтения кода плагина Cyr to Lat enhanced, что мы узнали?
Если плагин ставится на сайт, у которого уже есть посты и термины, то он изменит их ссылки при активации, а это значит для поисковиков это будут новые страницы. Благо для постов при изменении ссылки будет автоматически проставлен 301 редирект, но у терминов такого функционала нет вовсе.
И это есть поправка к 1 пункту — плагин вмешивается в работу движка при создании основного запроса, что ломает функционал перенаправления со старого урла записи на новый, если тот был на кириллице или состоял из других неугодных плагину символов. Чтобы перенаправления заработали, надо деактивировать плагин, но тогда транслитерация новых урлов отключится. Замкнутый квадрат.
Плагин вносит изменения в базу данных безвозвратно. Да, старые версии slug’ов записей он сохраняет, но обычному пользователю от этого нет никакого прока. Если вам не понравится, как отработал плагин, остаётся надеяться лишь на бэкапы, вы ведь периодически их делаете, правда?
Плагин имеет потенциальную SQL-инъекцию. Шанс, что ею как-то воспользуются низок, но всё же.
У плагина имеется хук ctl_table, позволяющий изменить массив с набором символов для транслитерации, не редактируя код самого плагина.
Подсмотрели как вообще в целом выглядит процесс транслитерации, все аналогичные плагины работают плюс минус одинаково.
Если вам нужно транслитерировать что-либо ещё, то просто пропускаете строку через функцию sanitize_title(), а, как мы знаем, плагин, благодаря хуку в этой функции, сделает свое дело.

Конец списка. От себя добавлю, что если бы не подготовка к этому видео, я так бы и продолжал использовать данный плагин, но теперь серьезно задумался его везде сменить. Знаете достойные аналоги? Пожалуйста, посоветуйте. Заодно и их разберем. Также хотелось бы добавить, что подобного рода плагины желательно выбирать для сайта один раз, ведь каждый плагин может иметь свое понимание, как транслитерировать урлы. Сменили плагин и тот поменял их по своему разумению. Хотя, конечно, всё зависит от реализации конкретного плагина.

На этом всё. Если у вас есть замечания и дополнения по видео — добро пожаловать в комментарии, подискутируем. А может у вас есть предложения по подобному роду материалов — пишите, не стесняйтесь. Если видео вам понравилось, то не забывайте поддержать канал лайком и другими общепринятыми средствами, всё в описании к видео. С вами был Дмитрий. Берегите себя и свои сайты. Пока!

Преимущества Cyr-To-Lat — KAGG

Cyr-To-Lat — это плагин транслитерации, предназначенный для преобразования ярлыков в латиницу. Анализ показывает, что конкурентов нет.

Блог, Плагины KAGG Design

Cyr-To-Lat — это плагин транслитерации, предназначенный для преобразования ярлыков постов из нескольких кириллических и не латинских языков в латиницу. Чем он отличается от конкурентов?

Поиск по wp.org даёт ряд плагинов транслитерации (отсортированы по убывания числа установок):

• Cyr-To-Lat ( 200,000+ )
• Cyr to Lat enhanced ( 100,000+, устарел )
• Rus-To-Lat ( 100,000+, устарел )
• WP Translitera ( 40,000+, устарел )
• Cyr to Lat reloaded – транслитерация ссылок и файловых имен ( 30,000+, устарел )
• Cyrlitera – транслитерация ссылок и имен файлов ( 20,000+ )
• SrbTransLatin — Serbian Latinisation ( 4,000+, устарел )
• SP RTL (RusToLat) ( 3,000+, устарел )
• Ukr-To-Lat ( 3,000+, устарел )
• German Slugs ( 2,000+, устарел )
• Bulglish Permalinks ( 1,000+, устарел )
• wp-cyr-cho | Конвертира кирилски символи в латиниски ( 1,000+, устарел )
• Serbian Latinisation (Serbian Transliteration) ( 600+, устарел )
• Geo to Lat ( 500+, устарел )
• translit-it ( 300+, устарел )
• HyToLat ( 200+, устарел )
• Rus-to-Eng ( 100+, устарел )
• cyr-to-arabic ( 20+, устарел )
• Behnevis Transliteration ( <10, устарел )
• Custom Transliteration ( <10, устарел )
• RusEng ( <10, устарел )
• Transliterate Arabic ( <10, устарел )
• WP Nice Slug ( <10, устарел )

Мы видим, что большинство плагинов транслитерации более не поддерживаются, и нет никакой гарантии, что они будут работать с последними версиями WordPress. Так и есть — практически все устаревшие плагины не работают с Gutenberg.

Собственно, на этом анализ можно было бы и закончить. Ближайший поддерживаемый конкурент имеет в 10 раз меньшее число установок, что является показателем доверия пользователей и надёжности.

Однако давайте продолжим и оставим для анализа плагины со значимым числом установок ( > 10,000 ) и поддерживаемые, с любым числом установок. Сокращённый список выглядит так:

Название	Число установок	Возможность редактирования таблиц	Языки
Cyr-To-Lat	200,000+	Есть наглядное, в виде таблиц, с добавлением/удалением пар транслитерации	Русский, белорусский, украинский, болгарский, македонский, сербский, греческий, армянский, грузинский, казахский, иврит и китайский
Cyr to Lat enhanced	100,000+, устарел	Нет	Русский, украинский и болгарский
Rus-To-Lat	100,000+, устарел, весь функционал перенесён в Cyr-To-Lat	Нет	Кириллические, без привязки к текущей локали сайта
WP Translitera	40,000+, устарел	Есть неудобное вида я=ja	Русский, украинский, болгарский и грузинский
Cyr to Lat reloaded	30,000+, устарел	Есть неудобное вида Ё=Jo,ё=jo,Ж=Zh,ж=zh	Русский, украинский, болгарский, греческий, армянский и сербский
Cyrlitera	10,000+	Есть неудобное вида Ё=Jo,ё=jo,Ж=Zh,ж=zh	Русский, украинский, болгарский, греческий, армянский и сербский

По числу поддерживаемых языков снова выигрывает Cyr-To-Lat. А уж по удобству редактирования таблиц ему и близко нет равных:

Здесь видно, как можно добавить свою пару транслитерации, состоящую даже из нескольких символов: ‘пиво’ => ‘beer’. По клику на символ ‘+’ можно добавить очередную пару. По клику на кириллическую букву — отредактировать или удалить её из таблицы.

Всего два плагина из этого списка заявляют совместимость с WPML: Cyr-To-Lat и SrbTransLatin. Причём официальный сертификат и подтверждение на сайте wpml.org имеет только Cyr-To-Lat.

Только Cyr-To-Lat совместим с популярным плагином ACF для создания произвольных полей.

Некоторые из приведённых плагинов могут производить массовую конвертацию ярлыков постов и таксономий: Cyr-To-Lat, Cyr to Lat enhanced, WP Translitera, Cyr to Lat reloaded, cyrlitera. При наличии большого числа ярлыков для конвертации этот процесс прерывается в силу ограничений процессорного времени на сервере. И только Cyr-To-Lat осуществляет такую конвертацию через фоновые очереди, что позволяет надёжно преобразовать любое количество ярлыков — даже сотни тысяч и миллионы.

Также, Cyr-To-Lat — единственный плагин в обзоре, который транслитерирует имена файлов вложений и миниатюр при массовой конвертации.

Ни один из плагинов в обзоре, кроме Cyr-To-Lat, не может работать через wp-cli, что является ещё одним надёжным методом массового преобразования ярлыков.

Лишь код Cyr-To-Lat удовлетворяет стандартам кодирования WordPress, что позволяет вести разработку на современном уровне.

Ни один из плагинов в обзоре, кроме Cyr-To-Lat, не имеет тестов. В то время как php и js код Cyr-To-Lat на 100% покрыт тестами, что позволяет поддерживать надёжность плагина на самом высоком уровне.

Код Cyr-To-Lat вместе с тестами и средой разработки доступен сторонним разработчикам на GitHub. Запросы на улучшение кода приветствуются.

Суммируя, можно сказать, что в настоящее время у плагина Cyr-To-Lat просто нет конкурентов, и использование любого другого плагина транслитерации лишено какого-либо смысла. В силу того, что все перечисленные плагины являются в той или иной мере наследниками плагина Rus-To-Lat, созданного Антоном Скоробогатовым, переход с других плагинов на Cyr-To-Lat не вызывает никаких проблем.

1221 Просмотров

База данных устаревших плагинов WordPress

Плагины — одна из лучших вещей в WordPress и, несомненно, одна из главных причин его популярности. Фраза «для всего есть плагин» — не шутка. Приложив немного усилий, вы можете найти плагин для чего угодно. Только в репозитории WordPress размещено более 57 тысяч плагинов. К сожалению, многие из них были забыты их авторами и не обновлялись более двух лет.

Ситуация дошла до того, что репозиторий был вынужден поставить на эти плагины специальный баннер, уведомляющий пользователей, что они устарели и не обновлялись более двух лет. Этот факт сам по себе не означает, что эти плагины плохие, глючные или проблематичные, но WordPress постоянно развивается, и плагин, который так долго не обновлялся, вероятно, не на 100% совместим с последней версией WordPress. Что еще хуже, более 22 тысяч, или почти половина плагинов теперь помечены как устаревшие в репозитории .

Стоит ли избегать устаревших плагинов!?

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

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

Как определить, что плагин устарел или несовместим с моей версией WordPress?

Это просто. Если вы устанавливаете плагины непосредственно из репозитория WP, вы найдете все данные на правой боковой панели на странице плагина. Например, у Limit Login Attempts есть желтый баннер вверху, о котором мы уже упоминали, в котором четко указано, что он не обновлялся более 2 лет. Если вы посмотрите на метаинформацию справа, вы снова увидите эту информацию — « Последнее обновление: 4 года назад ». И, как и ожидалось, это «, совместимое до 3.3.2 », а текущая версия WP — 4.6. Обратите внимание, что информация о совместимости — это то, что утверждает автор. Это может быть или не быть правдой.

Если вы устанавливаете плагины непосредственно из административной панели WP, данные доступны под миниатюрой каждого плагина. Поиск «Facebook» вернет устаревший плагин Facebook в качестве первого результата, а прямо под ним находится нужная вам информация: « Последнее обновление: 3 года назад » и информация о совместимости: « Не проверено с вашей версией WordPress ».

Все могло (и должно) быть лучше

Новая основная версия WordPress выходит каждые 4 месяца – в апреле, августе и декабре. Однако приведенное ниже число показывает, что только 20% плагинов были обновлены за последние 4 месяца. Это означает, что лишь один из каждых пяти плагинов не отстает от ядра WP и проверяет, совместим ли он с последней версией.

Список обновляется раз в неделю.

Самые популярные устаревшие плагины

. 0050

Название плагина	Активные установки	Последнее обновленное
Limit Login. 11 лет назад
Facebook	200,000+	9 лет назад
Rus-To-Lat	200,000+	11 years ago
SEO Friendly Images	200,000+	8 years ago
WP No Category Base	200,000+	11 years ago
Acunetix WP Security	100 000+	8 лет назад
Ajax Thumbnail Rebuild	100 000+	9 лет назад
Орден категории	100 000	15 лет назад	0050
Cyr to Lat enhanced	100,000+	8 years ago
Exec-PHP	100,000+	14 years ago
Link Manager	100,000+	11 years ago
MCE Table Buttons	100 000+	9 лет назад
P3 (Plagin Profiler)	100 000+	8 лет назад
Platinum Seo Pack
Platinum Seo Pack
Platinum Seo Pack
Platinum Seo Pack
Platinum Seo Pack
Platinum Seo Pack
Platinum Seo Pac0050	100,000+	9 years ago
Post-Plugin Library	100,000+	14 years ago
Quick Adsense	100,000+	10 years ago
Title Remover	100,000 +	9 лет назад
Ultimate Tinymce	100 000+	8 лет назад
WordPress Firewawl 2	100 000+	12 лет назад

Список обновляется раз в неделю.

Поиск по полной базе устаревших плагинов

База обновляется раз в неделю.

Woocommerce Product Configurator — Builder для WooCommerce

• V1.8.7 (24 января 2023)
• Обновление. исправление символов «&» в терминах пользовательских атрибутов продукта больше не нарушает создание изображения

• v1.8.5 (5 декабря 2022 г.)
• исправление Предотвращена фатальная ошибка в PHP 8, когда изображения JPG (неправильно) используются для слоев конфигуратора
• исправление Предотвращено дублирование разметки конфигуратора при использовании избранного изображения снова в галерее

• v1.8.4 (18 ноября 2022 г.)
• исправить Предотвращение фатальной ошибки при получении метаданных продукта

• v1.8.3 900 framework update

• V1. 8.2 (5 октября 2022)
• Исправлена ​​фиксированная ошибка в вариационных образцах для совместимости Woocommerce для предотвращения рецирсийных проблем

• 2222222222222222222222222222222222222222229.8.8.8.1

• 222222222222222222222222229.8.8.19.1

• 2222222222222229.8.

• v1.8.0 (27 сентября 2022 г.) Обновление
• Улучшена совместимость с WPML Обновление
• Улучшенная логика для предотвращения ошибок при невыборе элементов с помощью data-attribute-name атрибут существует
• fix Решена проблема совместимости с темой Goya
• fix Решена проблема совместимости с Variation Swatches для плагина WooCommerce при извлечении сгенерированных URL-адресов изображений продуктов, вызванных некоторыми сторонними плагинами

• v1.7.0 (12 августа 2022 г.)
• исправить Совместимость с пакетами продуктов WC

• v1. 6.2 (29 июня 2022 г.)
• обновление Переработан интерфейс JavaScript для запуска при загрузке окна вместо готовности документа.

• v1.6.1
  (24 июня 2022)
• Обновление разработчика Обновление: Разрешить конфигуратор в качестве ненулевого индексированного элемента в галерее

• 2222222222222222222222.

21

2221

2222222222222222222222222222222222228

1

• 22222222222222229. В настройки плагина добавлена ​​новая вкладка «Начало работы».

• v1.5.2 (7 апреля 2022 г.) 9Обновление 0225
• Предотвращение фатальных ошибок, когда плагин пытается отобразить Конфигуратор продукта, когда объект $product недоступен, например, предварительный просмотр шаблона Elementor.
• update Обновление зависимостей

• v1.5.1 (1 марта 2022 г.)
• update Обновлен Freemius SDK.

• v1.5.0 (11 января 2022 г. )
• новый Совместимость с Yith Wishlist
• новый Совместимость с WooCommerce QuickTray от Iconic
• update Обновления среды настроек
• update Обновить зависимости
• update Удалить класс wp-post-image из изображений слоев Product Configurator
• fix Принудительно 100% ширина изображений Product Configurator в контексте галереи WooThumbs по терминам, не имеющим рекомендуемого изображения по умолчанию
• fix Исправлен класс-продукт, где (int) сравнивался со строкой и терпел неудачу
• fix Исправлено неработающее изображение корзины, когда любое из значений атрибута имеет символ амперсанда (&)

• v1.4.0 (03 марта 2021 г.)
• новые условные слои
• новая кнопка «Очистить кэш» галерея
• обновление Удаление загрузки Ajax в пользу методов загрузки JSON
• обновление Divi Compatiblity
• обновление Elementor Compatiblity
• обновление Change hook: jckpc-thumbnail-image-size to jckpc_thumbnail_image_size
• update Обновить зависимости
• fix Исправить html в уведомлении на вкладке Configurator
• исправление Санитизация имени атрибута ( Примечание : тест при подготовке, чтобы убедиться, что порядок сортировки и изображения правильно назначены на вкладке «Конфигуратор продукта»)
• исправление jckpc_defaults не сохраняется
• исправить Совместимость с WooThumbs при использовании другого имени папки
• исправить Невозможно удалить изображение по умолчанию для глобального атрибута
• исправить Старое изображение не удаляется, если новое изображение добавляется с помощью кнопки +
• исправить Увеличение изображения по умолчанию при загрузке страницы
• исправить Изображение Retina теперь загружается при загрузке страницы

• v1. 3.9 (17 августа 2020 г.)
• исправить Совместимость с WP 5.5
• обновление Совместимость темы Divi
• обновление Обновление зависимостей

• v1.3.8 (24 апреля 2020)
• Обновление обновления зависимости
• Обновление версии. Совместимость

• V1.3.7 (180228
  • V1.3.7 (180229 292221222219222225225252525252525252525252525252522221 29229222522221922222219225252525122522221 29229222219222219225252512252522122221
  • . 3.6 (1 августа 2019 г.)
  Обновление
  • Использовать маленькое изображение в корзине
  Обновление
  • Использовать полное изображение в масштабе/полноэкранном режиме
  • исправление Изменение startWith на indexOf для IE11
  • исправление Убедитесь, что параметры запроса добавлены эффективно
  • v1.3.5 (1 July 2019)
  • fix Freemius Fix
  • v1. 3.4 (2 March 2019)
  • fix Security Fix
  • v1.3.3 (9 Jan 2019)
  • update Обновить зависимости
  • update Совместимость с Woo 3.5.0
  • fix Обеспечьте повторную загрузку слоев после добавления в корзину столы
  • update Обновить POT-файл
  • fix Убедитесь, что проверка активных плагинов Iconic работает
  • fix Убедитесь, что масштабирование WooThumbs запускается после смены слоя
  • обновить имена хэш-изображений, чтобы они не были слишком длинными
  • исправление Убедитесь, что WooThumbs последней версии, прежде чем пытаться использовать
  • исправление 0 имена атрибутов значения не отображались на вкладке конфигуратора
  • исправить Добавить параметр «без значка мультимедиа» для WooThumbs
  • исправить Не перемещать конфигуратор в WooThumbs
  • исправить Убедитесь, что изображение с фиктивным масштабированием удалено при получении варианта через AJAX
  • исправить Исправить проблему совместимости с WooCommerce Variations Swatches and Photos Plugin
  • исправление Убедитесь, что база данных запасов создается даже после активации
  • v1. 3.0 (6 июня 2018 г.)
  • обновление Запасы: уменьшаются, даже если запасы продукта не управляются.
  • обновление Инвентарь: увеличивается, если заказ отменен/не выполнен/возмещен.
  • обновление Инвентаризация: проверьте запасы еще раз перед выпиской.
  Обновление
  • Обновление файла POT
  Обновление
  • Обновление Freemius
  Обновление
  • Совместимость с WooThumbs
  Обновление
  • Обновление классов и идентификаторов
  Обновление
  • Кэширование изображений по мере их загрузки для более быстрого переключения изображение при удалении выбранной опции
  • update Добавить предложения по плагинам
  • update Включить масштабирование и лайтбокс
  • исправить Исправить проблему полноэкранного просмотра миниатюр
  • исправить Исправить проблему с размером изображения в Woo 3+
  • исправить Исправить проблему с некоторыми символами в значениях атрибутов (&|.|@|и т. д. )
  • fix Улучшить загрузку слоя, чтобы его нельзя было «обмануть»
  • fix Исправить проблему с русскими/иностранными символами в слоях быть инвалидом
  • update Добавить шорткод [iconic-wpc-gallery]
  • update Обновление Freemius
  • update Совместимость с [product_page] шорткодом
  • update Улучшение сворачивания и сортировки слоев конфигуратора в админке
  • update Улучшение загрузки/удаления изображений в админке update
  • 5
  обновить файл POT
  • исправить Синхронизировать настраиваемые поля при использовании WPML
  • исправить Установить язык в запросах AJAX
  • исправить Получить правильные термины таксономии при переводе таксономии
  • исправить Исправление проблемы при использовании косой черты в имени значения атрибута
  • исправить Проверять изображение BG только при включенном конфигураторе
  • исправить Проблема с проверкой png для некоторых хостов
  • исправить Удалять строку запроса из URL-адресов изображения при создании
  • v1 . 2.1 (08.10.2017)
  Обновление
  • Добавление совместимости с WPML
  Обновление
  • Новая система лицензирования
  Обновление
  • Переименована папка плагина в соответствии с брендингом Iconic
  Исправление
  • Отсутствующие галереи
  • исправить Недопустимый URL-адрес изображения в электронных письмах
  • v1.2.0 (04.02.2017)
  • обновление Совместимость с WooCommerce 3.0.0
  • обновление Добавить функциональные возможности статического слоя и обновить фреймворк
  • 5
  • 5 Redux
  • обновление Аккуратный код и комментарии
  • исправление Исправление проблемы с сортировкой слоев
  • исправление Проблема с загрузкой медиа в атрибут
  • исправление Использовать WC ajax URL
  • исправление Скомпилированное изображение в письмах заказа
  • исправить Проблема с атрибутами продукта, не загружающими слой при загрузке
  • исправить Проблема с запросом на загрузку выбранного слоя с пробелами
  • v1. 1.5 (22/12/2016)
  • исправить Отсутствовали некоторые обновления, касающиеся создания изображений
  • update Средство обновления рынка Envato
  • update Добавить фильтр к уменьшенному изображению электронной почты для заказа
  • исправить Некоторые хосты не разрешают удаленные изображения в getimagesize, изменен на путь, чтобы изображения генерировались
  • исправить Ошибка, когда не установлено изображение по умолчанию, но это было до
  • исправить Убедитесь, что правильное изображение отображается в электронной почте, если оно включено
  Обновление
  • Добавить проверку для проверки изображений PNG
  • исправить Атрибут добавить кнопку изображения по умолчанию0006 (09.09.15)
  • обновить изменить часы на .variations select
  • v1.1.1 (09.09.15)
  • исправить Ошибки, когда $post не установлен
  • исправить Неопределенный параметр add_to_cart_inventory_check
  • исправить Отсутствующие термины при черновике продукта
  • v1. 1.0 (13/07/15)
  • исправить Слои изображения не загружаются
  • исправить Слой изображения2 исправить Загрузка изображения по умолчанию2 5 902 функциональность слоя
  • обновление Добавлены функции инвентаризации * Обязательно деактивируйте/повторно активируйте, чтобы установить новую таблицу БД
  Исправление
  • Удалены изображения из успешного заказа и электронного письма с заказом проверьте наличие woocommerce, чтобы попытаться исправить проблемы с заголовком
  • исправить Удалить недопустимую ошибку заголовка
  • исправить ошибки is_array
  • обновить лучший файл pot
  • v1.0.7 (27/04/15)
  • исправить Moved for woocommerce попытаться исправить проблемы с заголовком
  • v1.0.6 (19.02.15)
  • Обновление Добавить Cyr в Lat расширенная совместимость
  • v1.0.5 (14.01.25) Обновление для других (14. 01.25) lang) — предостережение: может повлиять на предыдущие конфигурации
  • Исправить Загрузить скрипты администратора только на странице редактирования продукта
  • Обновить Проверить, включен ли WooCommerce
  • Исправить Исправить совместимость с образцами и фотографиями вариантов WooCommerce v1.5.3
  • v1.0.4 (08.06.14)
  • Fix Исправлена ​​ошибка, из-за которой TGM не уведомлял о необходимости Redux Изображение по умолчанию» для атрибутов
  • Исправление Исправлена ​​ошибка, из-за которой конфигуратор отображался во внешнем интерфейсе, даже если он не был включен
  • Обновление Теперь работает с образцами вариантов WooCommerce и фотографиями Лукаса Старка
  • Обновление Добавлена ​​возможность упорядочивать параметры конфигуратора независимо, путем перетаскивания /дроп
  • v1.0.2
  • Fix Удалено Ошибка tgmpa_load_bulk_installer
  • v1.