Артем Золин

тот отдаёт этот запрос серверу приложений, тот в свою очередь запускает WSGI сервер, которому передаются данные запроса

Нет, WSGI сервер запускается один раз.

в WSGI сервер есть обработчик, который обращается уже к самому веб-приложению

Нет, у WSGI сервера нет зависимостей от твоего приложения.

фреймворк получает ещё порции данных от WSGI сервера и переводит их в понятный для разработчика вид

Нет, фреймворк не получает ещё порций данных от WSGI сервреа, он получает ровно тоже самое что и приложение без фреймворка.

потом в приложении генерируется html страница, отдаётся WSGI серверу, тот отдаёт его обратно серверу приложений

Нет, WSGI серверу отдаются данные в формате определённом стандартом WSGI.

WSGI сервер это просто прослойка между "веб" сервером и питон приложением, которая позволяет не задумываться о выборе "веб" сервера и/или фреймворка, на котором будет написано приложение.

WSGI сервер запускается один раз, с натравливанием на специальный объект, определённый стандартом WSGI, этот объект написан разработчиком приложения, или разработчиком фреймворка, если используется фреймворк. (не всегда)
Когда с "веб" сервера приходит HTTP запрос, WSGI сервер обрабатывает этот запрос, разбирает его на структуру, определённую стандартом, и вызывает тот самый специальный объект, определённый стандартом WSGI, который делает вещи определённые стандартом WSGI, а именно - используя переданный в параметрах объект, отправляет WSGI серверу код HTTP ответа и заголовки ответа, после чего возвращает генератор, который будет возвращать тело ответа. WSGI сервер из всего этого дела варит HTTP ответ и возвращает его "веб" серверу.
Получать заголовки и тело можно как угодно - можно делать это используя фреймворк типо джанго/flask, или же просто читать из файла.

Просто прочти PEP:
https://www.python.org/dev/peps/pep-3333/#environ-...

...

<?php endwhile; ?>
<?php wp_reset_postdata(); ?>
 
....

wp_enqueue_style()
Правильно добавляет файл CSS стилей. Регистрирует файл стилей, если он еще не был зарегистрирован.
...
Возвращает
null. Ничего не возвращает.

Лайфхак: 40 минут дебага с легкостью заменяют 5 минут чтения документации.

HTML:

<div class="asdasd-1">
  <div class="asdasd">
    <div class="asdasd">
      <div class="asdasd">
        blabla
      </div>
    </div>
  </div>
</div>

<div class="dsadsa"></div>

JS:

const contentNode = document.querySelector('.asdasd-1');
const output = document.querySelector('.dsadsa');

output.innerHTML = contentNode.innerHTML;

<?php
$string = 'Нажми кнопку и получи @приз, чтобы принять участие';
$matches = [];
if (preg_match('/@[а-я]+/ui', $string, $matches)) {
  $word = $matches[0];
  echo $word, PHP_EOL;
}

preg_match('~(?<=@)\w+~u', $str, $match);

Читаем мануалы, учим матчасть...

Код, позволяющий добавить категории и теги к страницам

function add_taxonomies_to_pages() {
 register_taxonomy_for_object_type( 'post_tag', 'page' );
 register_taxonomy_for_object_type( 'category', 'page' );
 }
add_action( 'init', 'add_taxonomies_to_pages' );
 if ( ! is_admin() ) {
 add_action( 'pre_get_posts', 'category_and_tag_archives' );
 
 }
function category_and_tag_archives( $wp_query ) {
$my_post_array = array('post','page');
 
 if ( $wp_query->get( 'category_name' ) || $wp_query->get( 'cat' ) )
 $wp_query->set( 'post_type', $my_post_array );
 
 if ( $wp_query->get( 'tag' ) )
 $wp_query->set( 'post_type', $my_post_array );
}

В общем случае -- стоит.

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

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

В общем случае -- дробить код сайта на куски и отдавать их частями -- стоит. Но вмеру. А как именно делить -- зависит от вашего случая.

Не привязывать к id? 0_o

const app1 = new Vue({
  el: ".container-1",
})
const app2 = new Vue({
  el: ".container-2",
})
...

Aljo, Не нужно бороться с редактором. Подходов существует множество, все зависит от того, что ты умеешь, чему не прочь научиться, а что делать не планируешь.
Возьмем как базовый пример например лендинг из 5ти блоков. В одном из блоков слайдер с последними записями блога. В футере и хедере есть номера телефонов и ссылки на соцсети.
Уже если подумать просто редактора недостаточно, чтобы вывести из админки номера телефонов и соцсети.
Может быть несколько подходов. Самый простой - использовать плагин для метаполей, я пользую ACF Pro. С помощью него можно сделать страницу настроек и из нее получать номера телефона и социалки и выводить в хедере с футером. Также это можно сделать через API кастомайзера. Это встроенная система настроек. это уже чуть сложнее, но тоже ничего сверхъестественного. Третьим вариантом вижу виджеты. Регистрируем сайдбары где нужно и из виджетов выводим прямо верстку.
Перейдем к телу лендинга.
Самый простой способ это если есть готовая верстка создать шаблон страницы для этого лендинга и вкинуть в нее всю верстку. Можно разбить на отдельные файлики для удобства. Контент выводить через те же метаполя.
Можно поставить конструктор страниц и сделать на нем. Можно попробовать сверстать на встроенном гутенберге, но так как он довольно уныл из коробки нужно будет поставить пару плагинов, расширяющих его возможности.
Далее как вариант можно делать свои кастомные блоки для гутенберга из готовой верстки.
Вспоминаем что нам нужно в один из блоков вывести слайдер с последними записями. Тут не обойтись без знаний работы с циклами вордпресс и дальше снова либо код прямо в теле ленда, либо выносим в функцию, либо делаем блок для гутенберга либо смотрим умеет ли установленный нами редактор делать такие штуки.
И чем глубже, тем интереснее. Кастомные типы записей и таксономий, интеграция сложного меню с помощью класса wp_walker, создание шорткодов и виджетов, плагинов в конце концов. Кароч, желаю удачи

После endwhile(); допишите функцию wp_reset_postdata(); которая вернет глобальную переменную $post в исходное состояние.

endwhile(); wp_reset_postdata();

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

- убедитесь, что название кастомного поля repeater указано верно: slider_card
- убедитесь, что название кастомных полей указано верно: image_product и др
- обратите внимание на то, где именно вы создали кастомные поля и как его выводите. Если это ACF Option, то вторым аргументов нужно указать 'option', если вы создали кастомное поле для определенной страницы (например, для главной), а выводите этот блок на другой странице, то нужно ID главное передать в качестве второго аргумента.
- в полях, в которых вы выводите картинки обратите внимание на тип возвращаемого значения. Может быть вы не то возвращаете
- попробуйте убрать swiper и без него просто выведите блок ACF. Скорее всего проблема сохранится, а если нет, то проблема уже на стороне swiper.
- также может быть стили где-то переписываются и блок не видим или еще что...