Артем Золин

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

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.
- также может быть стили где-то переписываются и блок не видим или еще что...

Создать то можно. Но его будет ждать судьба первого.

add_action( 'init', 'remove_my_action');
function remove_my_action() {
     remove_action( 'woocommerce_before_shop_loop','storefront_sorting_wrapper',9 );
}

$user_info['procent_second`']

Ошибку видите?

$user_info['procent_second']

а смысл?
используемые функции зависят исключительно от задач, а у разных людей они разные.

я каждый день использую array_splice, а кто-то даже не знает о ней. вам это помогло?

Вот хороший
https://wordpress.org/plugins/fakerpress/

Есть репозиторий с xml тестовыми данными для темы, готовые к импорту если необходимо
https://github.com/WPTT/theme-test-data

$key = 'shipping_address';
$_arr1 = array_combine(array_column($arr1, $key), $arr1);

$result = [
  ...array_map(fn($n) => $n + ($_arr1[$n[$key]] ?? []), $arr2),
  ...array_diff_key($_arr1, array_combine(array_column($arr2, $key), $arr2))
];