Вариантов тут несколько:
1) Указывать имена городов в заголовках в едином формате, а потом каким-то образом вырезать их при получении списка записей. Это вариант решения "в лоб";
2) Указать название города через дополнительное поле для записи. Этот вариант удобней, но он будет сильнее нагружать сервер и придется думать над кешированием результатов выборки;
3) Название города можно указывать в поле Цитата. Не самое лучшее решение, но в принципе также вариант;
4) В названии статьи оставить только город, а заголовок на странице записи выводить из доп. поля.
Да, действительно, в случае с WP это по большей части справедливо.
Связано это с тем, что разработчики движка используют в основном простые запросы пусть и в большем количестве. Как показывает практика, несколько простых выборок без JOIN-ов из таблицы даже с миллионом записей производятся значительно быстрее чем одна сложная. К слову, в Yii2 в модели также стали использовать этот принцип для выборки по связанным таблицам.
С другой стороны в любом случае нужно установить плагин для объектного кеширования, многие вещи в WP изначально кешируются на уровне движка. Самый яркий пример - это настройки в wp_options. Woo для их выборки генерирует несколько десятков запросов к БД. Да, они простые, занимают по несколько миллисекунд, но в сумме получается вполне себе ощутимая цифра.
Помимо этого в WP хватает своих тормозов на уровне самого движка. В свое время я его профилировал вдоль и впоперек. Хотел сделать WooCommerce быстрее OpenCart :)
Один из примеров, о котором мало говорят - это загрузка доменов локализации. Они увеличивают время загрузки на 0.050 .. 0.300 секунд. Иными словами, если просто указать в админке английский язык, то скорость сайта увеличивается :) Да, если вместе со страницей грузится еще несколько мегабайт картинок и скриптов, то это вряд ли заметно будет, но если все написано нормально, то прирост очевиден.
Еще один способ кардинально ускорить сайт - это перейти на PHP7.0. Скорость у меня на тестовой машине повышалась раза в 2 - 2.5. К счастью, актуальные версии WP и Woo эту версию более-менее внятно поддерживают.
Именно в том абзаце спрашивали о БД :)
А так я с вами полностью согласен, там основная причина медленной работы - не база данных как таковая, а не очень оптимизированный код шаблона и/или дополнений. Об этом косвенно говорит более 400 сотен SELECT-ов на страницу. Их ведь не только запросить из базы данных нужно, а еще и обработать, всякие там объекты на основе тех данных инициализировать.
Это да. За ресайз картинок в реальном времени без кеширования вообще расстреливать надо.
Да, есть. У вас отключен кеш запросов (query_cache_size = 0). Что это такое и чем грозит можно почитать тут: https://habrahabr.ru/post/41166/
Можно начать с включения кеша запросов, но в вашем случае это не самая основная проблема.
Я бы начал с включения объектного кеширования. 442 запроса для страницы - это, прямо скажем, много даже для WordPress.
Скорее-всего вы не установили какой-то из модулей для реализации кеширования. Это может быть Memcached, APC/APCu, Redis, XCache и прочие.
Самый простой способ - это установить https://ru.wordpress.org/plugins/query-monitor/ и посмотреть сколько выполняются запросы к базе данных.
На скорость работы БД влияет огромное количество факторов. Самые основные - это количество записей, сложность запросов, наличие индексов и кешируемость запросов на уровне query cache.
Для начала имеет смысл установить плагин для объектного кеширования вместе с соответствующим модулем PHP. Пример: https://ru.wordpress.org/plugins/apcu/
Это уменьшит количество запросов к БД в разы. После этого можно заняться оптимизацией базы данных: https://ru.wordpress.org/plugins/wp-optimize/
Оптимизация - это очень широкое понятие. Кто-то ограничивается просто установкой плагинов для кеширования и оптимизации, кто-то дополнительно проводит аудит темы оформления и оптимизирует ее.
Еще одна область - это клиентская оптимизация, которая может включать кеширование ресурсов на стороне клиента, объединение и минификацию скриптов, реализацию спрайтов для CSS.
Отдельно стоит упомянуть о серверной оптимизации.
Это можно сделать как через собственный шорткод, так и через плагины для вставки рекламы. В их код нужно добавить проверку относится ли запись к указанным рубрикам или нет.
Вот пример такого кода:
$categories = get_the_category(get_the_ID());$chosen_categories = array(1,2,3,4,5); /* Список ID-категорий */$found = false; /* Переменная, которая говорит о том, относится ли запись у указанным рубрикам или нет */if (!empty($categories) and is_array($categories)) { foreach ($categories as $category) { if (in_array($category->cat_ID, $chosen_categories)) { $found = true; break; } }}
Обычно для подобного рода функционала я создаю новый тип записей, назначаю им таксономию, привязываю к ним дополнительные поля через ACF, а потом через плагин User Role Editor настраиваю права доступа для пользователей, чтобы они могли добавлять через админку только товары.
Если требуется добавление товаров через фронтенд, то можно или создавать свои формы вместе с обработчиками, или использовать ACF: https://www.advancedcustomfields.com/resources/using-acf_form-to-create-a-new-post/ + https://www.advancedcustomfields.com/resources/create-a-front-end-form/
Вы можете создать статическую страницу со своим шаблоном. В коде шаблона вы просто принимаете те два GET-параметра, производите выборку записи через WP_Query, а потом или выводите ее на той же странице, или перенаправляете пользователя на страницу записи через редирект.
Если вам нужно получить трапецию на CSS, то можно прописать такие стили:
h1 { border-bottom: 100px solid red; border-left: 50px solid transparent; border-right: 50px solid transparent; height: 0; width: 100px;}
Ширина блока может быть любой, угол наклона определяется шириной border-ов, цвет фона - цветом нижней границы.
Вам фактически нужен фильтр по параметрам. Если у вас на сайте организован каталог с записями и доп. полями, то такой фильтр скорее-всего придется писать вручную. Да, готовые решения в принципе существуют, но их в любом случае придется допиливать.
Задачу можно разбить на несколько этапов.
На первом этапе вам нужно или указать вручную, или динамически генерировать список доступных параметров и диапазонов значений для фильтра. Во втором случае рекомендую использовать объектный кеш, поскольку поиск составление списка значений по доп. полям - это достаточно затратная в плане ресурсов операция.
Для после этого имеет необходимо написать функцию-обработчик AJAX-запросов от фильтра, который через WP Meta Query и смежные функции будет производить выборку. На выходе эта функция должна возвращать или готовый HTML-код, или данные в виде JSON для последующей обработки и генерации списка записей. Из нюансов вам придется немного заморочиться с пагинацией. Ее придется также делать только через AJAX. Фактически форма фильтра вместе со всеми параметрами будет передавать смещение (offset) или номер страницы.
В качестве альтернативы можно рассмотреть вывод записей на отдельной странице с использованием GET параметров для фильтрации. Это способ проще, он позволит обойтись без AJAX, но и тут также придется немного доработать пагинацию. Обработчик AJAX-запросов нужно заменить на обычную функцию-фильтр для события pre_get_posts
Если основная проблема, которую вы пытаетесь таким образом решить, заключается в увеличении производительности, то имеет смысл установить один из многих плагинов для постраничного кеширования, которые делают ровно то же самое, что вы описали. Все страницы сайта банально сохраняются в виде отдельных html-файлов, а потом отдаются клиенту в начале работы скрипта.
Если немного заморочиться с Memcached, то можно добиться, чтобы все страницы хранились в оперативной памяти, а их отдачей клиенту занимался веб-сервер напрямую без участия WP как такового.
Самое простое решение - это установить плагин ACF PRO, добавить поле "Повторитель" для рубрик и главной страницы. После этого в header.php для генерации заголовка подгружать значения того поля через get_field(), а потом среди них проверять есть ли заголовок с индексом get_query_var('paged') (номер страницы). Если таковой имеется, то выводить его, если нет - проверять больше ли 1 номер страницы и если да, то добавлять его к существующему заголовку.
Это делается элементарно. Можно использовать плагин ACF: добавить сколько угодно дополнительных полей к таксономии (рубрике) и выводить их как угодно.
Если не хочется возиться с этим плагином, то можно попробовать использовать соответствующий функционал, который появился в 4.4: https://www.smashingmagazine.com/2015/12/how-to-use-term-meta-data-in-wordpress/
Основная задача верстальщика - это сверстать страницы. Собственно, именно поэтому он называется "верстальщиком". Иногда в его обязанности входит разработка JS-части.
Создание и работа с темами оформления для CMS - это задача для программиста, она требует совершенно иных навыков и знаний. Да, часто верстальщики занимаются и программированием, предоставляя клиенту единую услугу по созданию шаблона, но это не значит, что нужно смешивать работу над фронтэндом (дизайн, верстка, скрипты) с работой над бекэндом (программирование на стороне сервера, настройка системы).
Именно в виде 15,48% - нельзя, а так 15.48% - можно. Разделителем должна быть точка, а единица измерения - не пиксель. Более подробно эта тема раскрыта в статье: http://nimbupani.com/using-decimal-percentage-values-in-responsive-design.html
При создании сеток (grid) часто требуется большая точность, чтобы избежать ситуации, когда какой-то блок не до конца заполнил или вообще не влез в текущий ряд, например. Примеры можно увидеть в том же Bootstrap.
