qool_loop

откройте терминал и введите git push -f origin master

Просто добавьте node-sass в зависимости

npm install node-sass -S

inline - когда стиль прописан не в отдельном файле/блоке, а непосредственно в коде.
то есть не
<div class="center"></div>
a
<div style="text-align: center;"></div>

https://vineetgupta22.wordpress.com/2011/07/09/inl...

Ох...

Model View Controller. Да ну его, ему уже 45 лет (придумали в 79-ом году). Давайте лучше про Model View Adapter погокорим. это то что все используют в популярных фреймворках последние лет так 10 так точно.



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

View - это не только HTML, но и вообще представление в целом, а так же логика его формирования. Шаблонизаторы, фильтры, различные функции/объекты помогаютщие нам сформировать view (например форматирование дат, сериализаторы и т.д.) В подавляющем большинстве случаев "представление" наших данных - это HTTP запросы и HTTP ответы. HTML - э то лишь часть HTTP ответа.

Model - Это целый слой, который может быть представлен в виде кучи отдельных объектиков, структур и т.д. Его задача - делать дела и хранить/менять состояние системы. Тут легко запутаться потому что термин "модель" много чего значит. Воспринимайте его как "слой логики" а не конкретные объекты. И да - база данных и прочая чушь - это детали реализации этого слоя. "не важные штуки" словом. Туда же и ActiveRecord, ORM-ки всякие. Это деталь реализации и все остальные чуваки (view и controller) о них знать ничего не должны (хотя иногда могут в целях упрощения).

Controller или адаптер. Это опять же не обязательно один объект. это может быть цепочка адаптеров (еще называют фронт-контроллером, middlewares и т.д.). Его задача весьма простая. Получаем представление данных на входе (HTTP запрос), определяем что надо делать, и просим модель что-то сделать (ни в коем случае не меняем ничего самостоятельно в контроллере, он только просит). Потом мы можем попросить модель вернуть нужный нам кусок состояния, и попросить View сформировать представление (HTTP ответ).

Как-то так. В целом же это я сейчас описал "идеальный мир". Вся суть этого подхода - разделение логики презентационной и логики приложения. Зачем это надо? что бы было проще жить! Обычно UI приложения или способы взаимодействия с ним меняются почаще логики или как минимум в разные моменты времени. Адаптеры в этом случае служат промежуточным слоем, они ничего сами не делают, это "переводчики". Они просто переводят то, что сказано в запросе в язык понятный приложению и обратно.

Но на начальной стадии можно слегка нарушать эти правила, делать толстые контроллеры и т.д. В этом случае бизнес логика будет потихоньку "вытекать" из модели. Это не хорошо, и на хоть сколько нибудь больших проектах может привести к проблемам. Потому важно находить баланс.

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

Контроллер - это посредник между моделью и видом. Он запрашивает данные (вызывает методы) у модели и затем передает их в вид.

Вид - с помощью полученных данных от контроллера рисует пользовательский интерфейс.

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

Нужна одна точка входа. Клиент всегда запрашивает только index.php, оно там внутри на основе данных из запроса решает какой контроллер создать и какой метод из контроллера выполнить. Всё.

В самом шаблоне все уже написано. Вот, например content-single-product.php и интересующий вас экшн.

<?php
			/**
			 * woocommerce_single_product_summary hook.
			 *
			 * @hooked woocommerce_template_single_title - 5
			 * @hooked woocommerce_template_single_rating - 10
			 * @hooked woocommerce_template_single_price - 10
			 * @hooked woocommerce_template_single_excerpt - 20
			 * @hooked woocommerce_template_single_add_to_cart - 30
			 * @hooked woocommerce_template_single_meta - 40
			 * @hooked woocommerce_template_single_sharing - 50
			 */
			do_action( 'woocommerce_single_product_summary' );
		?>

Здесь написаны все хуки из этого экшна. Их можно удалить, можно всунуть свои экшны с функциями. Каждый легко гуглится и вот здесь официальная документация: https://docs.woocommerce.com/wc-apidocs/index.html
Забиваем в поиск woocommerce_template_single_price и получаем функцию и ссылку на её расположение. Видим

if ( ! function_exists( 'woocommerce_template_single_price' ) ) {
    /**
     * Output the product price.
     *
     * @subpackage  Product
     */
    function woocommerce_template_single_price() {
        wc_get_template( 'single-product/price.php' );
    }
}

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

This template can be overridden by copying it to yourtheme/woocommerce/single-product/price.php.

Все поля продукта заполнены как кастомные. Можете к ним обращаться через get_post_meta();
Чтоб посмотреть все доступные поля, просто дампните результат этой функции без аргументов на странице товара. Но у продукта вуккомерс есть свои методы типа

$product->get_price(); 
$product->is_on_sale();

и т.д. полный список методов здесь