• Resolved uxtora

    (@uxtora)


    Привет. Данный плагин супер, но есть один минус в плане работы с WooCommerce и любыми языками кроме англ. Дело в том, что он автоматом таки переводит ВНУТРЕННИЕ атрибуты в товаре, ровно как и глобальные. Хотя не должен этого делать, ибо тогда ломается стандартный вывод вариантов товара в корзине. Т.е допустим я добавил внутренний(!) атрибут “Цвет”. По итогу он будет выводить его как tsvet. Хотя из коробки WooCommerce выводит так, как написали, ибо это не сущность.

    Почему is_wc_attribute() ВСЕГДА возвращает false для внутренних атрибутов:

    is_wc_attribute_taxonomy() → проверяет глобальные атрибуты WooCommerce
    Внутренний атрибут “цвет” → НЕ глобальный → false

    is_wc_product_not_converted_attribute() → сломанная логика:

    php
    protected function is_wc_product_not_converted_attribute( string $title ): bool {
    global $product; // ← ПРОБЛЕМА 1: часто NULL

    if ( ! is_a( $product, 'WC_Product' ) ) {
        return false; // ← Часто срабатывает здесь
    }
    
    $attributes = (array) get_post_meta( $product->get_id(), '_product_attributes', true );
    // ... проверяет уже сохранённые атрибуты

    }
    Почему global $product часто NULL:
    При сохранении товара из админки WooCommerce не всегда устанавливает эту глобальную переменную. При AJAX-обработке атрибутов она точно не установлена
    Метод вызывается из контекста sanitize_title(), а не из страницы товара

    Итог:
    is_wc_attribute_taxonomy(“цвет”) → false
    is_wc_product_not_converted_attribute(“цвет”) → false (потому что global $product = NULL)
    is_wc_attribute(“цвет”) → false
    transliterate(“цвет”) → “tsvet”

    Ошибка в коде: Метод is_wc_product_not_converted_attribute() пытается определить атрибут по уже сохранённым данным, но не учитывает, что:

    НОВЫЙ атрибут ещё не сохранён

    Глобальная переменная $product не установлена в нужном контексте

    Надо проверять не метаполя, а $_POST данные или контекст сохранения товара

Viewing 2 replies - 16 through 17 (of 17 total)
  • Нет, в версии 6.7.0 проблема с русскими кастомными Ву-атрибутами сохраняется. Плагин Cyr-to-lat вмешивается в названия кастомных кириллических атрибутов уже при вычитке из БД.

    1. Отключем Cyr-to-lat
    2. Создаем пользовательский атрибут с кириллческими буквами. На этом шаге Ву сразу создает вариации, если атрибут сделали вариативным. Давайте после активации плагина Cyr-to-lat попробуем выбрать для вариации значение по умолчанию.
    3. Включаем плагин. Затем только обновляем страницу редактора товарной карточки и на вкладке Вариации значения атрибутов name в HTML-элементах select уже транслитерировались. В БД в сериализованном представлении объектов атрибутов хранятся URL-кодированные ключи: %d…, но до SELECT’ов доезжают уже преобразованные в латиницу значения 🙂

    В текущей версии остается только определять контекст вызова функции sanitize_title() и вешатся на хук 'ctl_pre_sanitize_title', чтобы вместо false вернуть оригинальную строку и тем заставить плагин оставить в покое строки, которые Ву отправил в sanitize_title() 🙂

    Plugin Author kaggdesign

    (@kaggdesign)

    Спасибо за подробное описание.

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

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

    В таком случае данные уже могут быть сохранены WooCommerce в одном формате, а после активации Cyr2Lat часть значений может проходить через стандартные механизмы sanitize_title() / обработки slug’ов и отображаться иначе. Мы не можем гарантировать корректное восстановление или автоматическую совместимость для атрибутов, сохранённых до включения плагина.

    Иными словами: новые WooCommerce-атрибуты, создаваемые при активном Cyr2Lat, должны обрабатываться корректно; но существующие атрибуты, сохранённые до активации Cyr2Lat, могут потребовать ручной корректировки или отдельной миграции данных. Такой migration scenario сейчас находится вне рамок поддержки плагина.

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

Viewing 2 replies - 16 through 17 (of 17 total)

You must be logged in to reply to this topic.