Максим Шарлаев

Есть плагины вроде "Custom Taxonomy Order NE". Оно?

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

1. Собираете все вариации - их ID и значения атрибутов (вероятно, можно ограничиться ID вариации, но тут нужно уже на уровне кода разбираться)
2. Отправляете AJAX-ом на сервер
3. Добавляете в цикле в корзинку через WC()->cart->add_to_cart

В качестве иллюстрации ссылка: https://businessbloomer.com/woocommerce-custom-add...

Там описывается добавление через URL. В вашем случае не подойдёт, так как товаров несколько, но параметры, которые понадобятся для добавления, объясняются очень хорошо.

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

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

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

Правильный путь - следовать API wordpress и особенностям CMS.

Выкинуть всё из стандартной темы и забить туда свой код - это значит либо обречь тему на гибель после того, как кто-то нажмёт на кнопочку "обновить", либо сделать тему необновляемой. Ну и, соответственно, это не WP-way.

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

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

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

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

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

В плане того, что использоваться - ACF, фреймворки, или ещё что, логика примерно такая:
1. Общие элементы темы вроде лого, копирайта, контактных данных - это опции (свой код для страницы настроек), фреймворки опций (Redux, ACF-про ) или кастомайзер WP. Последнее кажется наиболее правильным и соответствующим развитию WP - там почти рукой подать до визуального редактирования уже.
2. Контент страниц - стандартный интерфейс для произвольных полей, ACF или другие решения. С ACF причём нужно быть аккуратным, он может упереться в ограничения сервера по количеству полей или давать неверные данные (писал бакенд для мобильного приложения через WP REST API и хлебнул лиха от сохранённых через ACF данных, привязанных к таксономиям)

В плане кода - всё, что должно решаться через API, решается через API. wp_enqueue_script/style для скриптов и стилей, wp_head(), wp_footer() в соответствующих местах. Вариантов превратить разработку темы в извращение тут очень много, доводилось видеть много всякого от неопытных разрабочтиков. И какого-то универсального решения всего этого избежать, возможно, просто нет. Кроме как учиться, смотреть гайды и лучшие практики, следить за обновлениями WP и рекомендациями для разработчиков.

Есть решения вроде www.appsgeyser.com - на входе веб-страничка или архив с ней, на выходе apk

Или есть PhoneGap/Cordova, например.

Если я правильно понял вашу ситуацию, вам нужно перехватить не всю страничку, а вывод wp_head()

Учитывая, как именно обрабатывается экшен wp_head, достаточно будет сделать

ob_start();
wp_head();
$head = ob_get_clean();

После чего что угодно делаете с $head и выводите результат обычным echo.

1. Делаем дорогие коммерческие (относительно, да) сайты на WordPress. А на Битрикс смотрим как на недоразумение;
2. Однажды я попробовал понять, какое место занимает Битрикс на мировой арене. Зашёл сюда - https://trends.builtwith.com/shop - и не нашёл его.

Хотя, в целом я подошёл к мысли, что нужно уходить с WordPress, если
а) предполагается большой объём данных (WC очень дискуссионно рулит базой в 40к товаров на средненьких VPS)
б) предполагается какой-нибудь хайтек, для которого нужно решение начиная с архитектуры.