Глобальная кастомизация магазина с использованием дочерней темы

[Stork.71]

В процессе доработки магазина приходится уж слишком много разного затачивать напильником: и тему, и плагины, и functions.php, и шаблоны разных страниц, и переводы, и стили. Самое обидное, что большинство из этого при обновлении теряется. Обновляешь тему - теряются правки темы, обновляешь WC - терояются правки в шаблонах WC, и т.д. Даже ведя записи всех правок, порой запутываешься, что именно надо заново подправить после очередного обновления.
В общем, показалось мне, что в таких условиях наиболее адекватным инструментом является создание дочерней темы.
Как я понял, с ее помощью можно править все и сразу, не теряя изменений при разных обновлениях.
Почитал кое-что по этому вопросу. В частности, документацию на сайте WordPress, статью на Wpnice, перевод статьи о внесении изменений в шаблоны с оффсайта Woothemes на этом форуме, статью на еще одном сайте.
Но тут вся инфа обрывками, очень хочется ее систематизировать: как правильнее всего организовать комплексный подход к ручной кастомизации своего интернет-магазина.
Что вы скажете, действительно можно с помощью дочерней темы объять необъятное?
Может есть еще какие-то интересные ссылки по поводу дочерних тем и их возможностей?
А может этот подход все же не очень хорош?
Не нашел инфы по поводу переводов. Можно ли как-то создать один файлик перевода, чтобы он редактировал и родной перевод Woocommerce, и перевод Saphali WC Lite, и переводы темы, и плагинов? Как это правильнее сделать? Имеется в виду не глобальная замена всех переводов, а лишь отдельных строк.
Опять таки, вопрос по поводу .css. Раньше я редактировал в своей теме custom.css. Что делать с дочернее темой? Кидать все стилевые условия в style.css дочерней темы после @import'a стилей из родительской? Или точно так же создать custom.css в дочерней теме? Как они будут работать, если учесть, что в custom.css и еще вношу и изменения, касаемые стилей некоторых плагинов?
Давайте вместе систематизируем инфу!

 

[D&B]

Дочернюю тему создать можно конечно. Часть проблем касательно самой темы это может и решит. Но относительно плагинов не поможет. По поводу перевода - как можно объединить переводы разных плагинов и темы? Да и зачем?

 

[Stork.71]

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

 

[D&B]

Переводы и не теряются при обновлении. Если вы создадите новый файл локализации для русского языка типа ru_RU то он так и останется. В обновлениях то его нет. Другое дело - можно обновить файл с оригинальным языком, а потом уже в POEDIT запустить "Обновить" и файлы по идее, синхронизируются. То есть например в ваш RU добавяться новые поля если они появились в новой версии.
А вообще вы правы конечно , раздел с переводами не помешает.

 

[Stork.71]

эммм... не совсем понял, как это не теряются при обновлениях? в папке \woocommerce\i18n\languages\ каждого нового обновления лежат файлы локализации, они же тоже переписывают старые файлы (с измененными переводами), точно так же как и шаблоны, стили ну и т.д.
а если я в той же папке (ну или в другой) создам свой файл, к примеру, perevod-ru_RU.po, то он ведь с ходу не подключится и не будет работать.
Или я где-то не прав?

 

[D&B]

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

 

[Stork.71]

в тему о дочерних темах ( ).
Интересная статья о неочевидных особенностях срабатывания пользовательских функций из functions.php, и о том, ка с этим бороться:

remove_action или remove_filter не работает в дочерней теме WordPress, если пытаться удалить хуки родительской темы
Вот такая засада.
В родительской теме определен ряд хуков, которые мешают мне и хочется их удалить в дочерней теме.
Логично предположить что нужно просто вставить remove_action или remove_filter в function.php дочерней темы.
Но не тут то было!
Это не работает.
Как оказывается, function.php дочерней темы грузится перед тем же файлом родительской темы. И если использовать обычную схему, то получится что попытка удаления хука произойдет перед его добавлением. Что как мы знаем по кодексу оказывается безрезультатным.
Таким образом нам нужно добиться ситуации, когда удаление хука произойдет после его определения.
Как это сделать?
Все очень просто Нужно удаление хука зацепить на более поздний хук, который выполнится после определения хука родительской темы. О как
Но все просто. Самый элементарный хук init вполне нам подойдет.
И делаем так:

add_action('init','removeOldFunction');
function removeOldFunction(){
remove_action( 'template_redirect', 'alienship_nice_search_redirect' );
}

Этим кодом мы удалим хук alienship_nice_search_redirect, который определен в родительской теме, при помощи function.php дочерней.
Проверено
Все хорошо, пока дело не касается сайдбара. Там хук инициализации виджетов работает еще позднее чем init, потому нужно вешаться на хук after_setup_theme.
Ну и в других случаях. Удаляя тот или иной хук не забудьте проверить его порядок загрузки и убедиться что он грузится позднее, чем тот который вы удаляете.

Оригинал статьи: casepress.org/kb/web/remove_action-ili-remove_filter-ne-rabotaet-v-dochernej-teme-wordpress-esli-py-tat-sya-udalit-huki-roditel-skoj-temy/

 

[searchingman]

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

Немного подумал про файлы переводов.
Действительно, не совсем удобно каждый раз править оригинальные файлы переводов, которые при обновлении плагинов затираются. Особенно неприятно, когда сделано несколько правок в нескольких десятков файлов переводов плагинов, темы и каждый раз после обновления их нужно заново вносить с помощью POEDIT.

Немного теории.
Если в темах и плагинах строки выводятся с учетом локализации, то используются функции esc_html_e(), esc_html__(), _e(), __(), которые работают на основе translate().

Вариант решения. Собрать все свои правки переводов в одном месте.
1. В functions.php своей темы вставляем код для перехвата переводов.

add_filter('gettext','my_gettext',10,3);
function my_gettext($translations, $text, $domain) {
    switch ($text) {
        case 'Proceed to Checkout':
            $translations = 'Оформить заказ';
            break;
        case 'Cart Totals':
            $translations = 'Итого';
            break;
  
        default:
            break;
    }
    return $translations;
}

2. В примере выше показано 2 варианта для замены в корзине

• текст кнопки "Перейти к оформлению" на "Оформить заказ"
• текст "Сумма в корзине" на "Итого".

3. Как этим быстро воспользоваться.
Н-р,если нужно изменить кнопку "Перейти к оформлению", то ищем поиском в файле локализации woocommerce-ru_RU.po
Находим

msgid "Proceed to Checkout"
msgstr "Перейти к оформлению"

что означает, что нашей фразе соответствует фраза "Proceed to Checkout".
В вышеприведенном коде подставляем фразу для поиска и нужную нам фразу перевода примерно так.

        case 'Proceed to Checkout':
            $translations = 'Оформить заказ';

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

 

[Stork.71]

Вариант классный! Как раз собираюсь обновляться, надо будет все плагины так попереводить.
Вижу тонкое место. Теоретически может быть такое, что одна и та же исходная фраза есть в нескольких плагинах, но используется в разных местах, и переводится в них по-разному. Например, в Плагине1 есть фраза "Add to cart" и в Плагине2 есть фраза "Add to cart", но в Плагине1 она переводится как "В корзину", а в Плагине2 - как "Добавить в корзину". Хотя это наверное очень редкий случай. Но всякое может быть.

 

[searchingman]

Вариант классный! Как раз собираюсь обновляться, надо будет все плагины так попереводить.
Вижу тонкое место. Теоретически может быть такое, что одна и та же исходная фраза есть в нескольких плагинах, но используется в разных местах, и переводится в них по-разному. Например, в Плагине1 есть фраза "Add to cart" и в Плагине2 есть фраза "Add to cart", но в Плагине1 она переводится как "В корзину", а в Плагине2 - как "Добавить в корзину". Хотя это наверное очень редкий случай. Но всякое может быть.

Для разделения плагинов существует 3й параметр функции $domain, который для разных плагинов разный.

 

[Stork.71]

а уточните тогда, как правильно прописывать переводы с учетом этого domain?

 

[Ardizan]

add_filter('gettext','my_gettext',10,3);
function my_gettext($translations, $text, $domain) {
    switch ($text) {
        case 'Proceed to Checkout':
            $translations = 'Оформить заказ';
            break;
        case 'Cart Totals':
            $translations = 'Итого';
            break;
 
        default:
            break;
    }
    return $translations;
}

Чет не переводит. Не видит кириллицу- знаки вопроса в ромбе рисует.
$domain можно узнать нажав ПКМ в редакторе (Poedit), Связи. Для Вукомерс будет woocommerce.
Нашел еще пару способов, но не смог реализовать (может из за мультисайта?)
Вот ссылки, может будет полезно: Ссылка 1, Ссылка 2
У кого получится, отпишитесь пожалуйста- очень нужен свой перевод на постоянно и без плагинов.

 

[searchingman]

Чет не переводит. Не видит кириллицу- знаки вопроса в ромбе рисует.
$domain можно узнать нажав ПКМ в редакторе (Poedit), Связи. Для Вукомерс будет woocommerce.
Нашел еще пару способов, но не смог реализовать (может из за мультисайта?)
Вот ссылки, может будет полезно: Ссылка 1, Ссылка 2
У кого получится, отпишитесь пожалуйста- очень нужен свой перевод на постоянно и без плагинов.

Сохранять файлы нужно в кодировке UTF-8 без BOM, н-р, в редакторе NotePad++

Попробуйте плагин из темы Плагин 'Say What' (описание) - изменение перевода "на лету" без правки файла перевода.
Если нужно без плагина, то возьмите код из плагина. Хотя не ясно в чем преимущество, т.к. на скорость сайта код оформленный через functions.php или через плагин не влияет. Влияет в том случае, когда функциональность плагина превышает необходимые требования решаемой задачи, т.е. избыточна.

 

[Ardizan]

Сохранять файлы нужно в кодировке UTF-8 без BOM, н-р, в редакторе NotePad++

Попробуйте плагин из темы Плагин 'Say What' (описание) - изменение перевода "на лету" без правки файла перевода.
Если нужно без плагина, то возьмите код из плагина. Хотя не ясно в чем преимущество, т.к. на скорость сайта код оформленный через functions.php или через плагин не влияет. Влияет в том случае, когда функциональность плагина превышает необходимые требования решаемой задачи, т.е. избыточна.

Больше плагинов - больше уязвимостей. Параною, наверное, но уже взламывали.
Спасибо за совет, но - чтобы установить Say What, нужен еще один плагин, чтобы начал работать на мультисайте. Получается слишком жестко- установить плагин, чтобы работал плагин Say What для плагина WOO

 

[Ardizan]

Сохранять файлы нужно в кодировке UTF-8 без BOM, н-р, в редакторе NotePad++

Огромное спасибище! Ваш совет сохранять в UTF-8 без BOM просто спас, всё получилось.
Не удалось перевести только:
#: templates/product-searchform.php:28
msgctxt "placeholder"
msgid "Search Products…"
msgstr "Поиск товаров…"
Но это не беда- одно выражение можно и руками поправлять.