Игорь Воротнёв

Нужно модифицировать запрос. Если это основной Loop - через хук pre_get_posts, если это кастомный Loop, то прямо в нем, естественно:

/**
 * Custom loop с сортировкой по мета
 */
$upcoming_args = array (
    'post_type'         => 'event', // тип поста, если стандартный, то 'post'
    'posts_per_page'	=> '20', // сколько записей на страницу
    'order' 		=> 'ASC',
    'orderby' 		=> 'meta_value', // сортировка по значению мета-поля
    'meta_key' 		=> 'date_from', // ключ (название) мета-поля
    'meta_query' 	=> array (
        array (
            'key'     => 'date_from', // ключ (название) мета-поля
            'value'   => date('Ymd'), // текущая дата, в формате хранимого значения, от нее будем проверять
            'compare' => '>=', // сравнение "больше или равно"
        ), 
    ),
);
$upcoming = new WP_Query( $upcoming_args );
if ( $upcoming->have_posts() ) : 
    while ( $upcoming->have_posts() ) : $upcoming->the_post(); 
        // Здесь выводим посты
    endwhile;
endif;
wp_reset_postdata();
?>

Функция the_field() принимает 2 аргумента, второй из них - это ID поста или значение 'option' если поле нужно забрать со страницы Options (модуля ACF). Если поле вызывается в стандартном loop, то ID передавать не нужно, он его сам подхватывает. Если нужно вывести вне стандартного loop - передавайте принудительно ID поста:

the_field( 'field_name', $post_id );

В справке все есть.

Проблема 100% на уровне MySQL, WordPress тут вообще ни при чем. Простая переустановка не факт что поможет. С обычным MySQL давно не работаю, советую сделать то же самое - установить MariaDB 10 (и модуль php-mysqlnd понадобится).

1. Здесь выбираем свою версию убунты и MariaDB, полученные данные добавляем в список репо
2. Удаляем MySQL
3. Устанавливаем MariaDB и php-mysqlnd
4. Делаем mysql_secure_install
5. Профит

Читаем документацию к функциям switch_to_blog() и restore_current_blog().

Список магазинов - это просто несколько полей в таблице Options или это Custom Post Type? Задача описана очень поверхностно, сложно что-то советовать.

Основных подхода два:
1. Плагин Advanced Custom Fields Pro (есть бесплатная версия, но девелоперская безлимитная Pro за $100 - это мегаполезный инструмент для разработчиков и просто must have на всех сайтах, если они чуть сложнее яем блог). У него есть модуль создания своих страниц настроек, создания на них любых комбинаций полей, созданиие полей для юзеров, таксономий, постов и та далее. Все, что душе угодно. Есть свои функции для создания форм на frontend, задача добавления формы и ее обработки сводится, по сути, к вызову 2х функций в шаблоне.
2. Использование своих собственных форм. Создается плагин, он может работать 2мя путями:
2.1. При активации создаем необходимые страницы, регистрируем и вписываем для каждой свой шорткод, а уже функция шорткода делает все, что нам нужно - обрабатывает данные, выводит форму на странице и так далее.
2.2. Все обработчики и шаблоны находятся в самом плагине, добавляем кастомные правила и переменные для rewrite, и тогда по нужным нам урлам будет вызываться наш файл-обработчик с разными параметрами. В зависимости от параметра делаем то, что нам нужно. С выводом формы, думаю, все понятно, а вот ее обработка - хукаемся в "init", а дальше как обычно с данными $_POST. Приняв и проверив данные дальше стандартными средствами WP записываем все изменения в базу.

Документация по все этим моментам есть в Codex.

Никогда не включайте jQuery со сторонних сервисов (хоть jQuery.com, хоть Google CDN), потому что:

1. В комплекте с WordPress уже идет jQuery, подключается стандартными средствами (wp_enqueue_scripts)
2. Многие плагины рассчитывают на этот встроенный jQuery, если скрипт плагина требует наличия jQuery, при подключении скрипта всего лишь указывается аргумента dependency - 'jquery'.
3. Вместе со штатным jQuery подключается jQuery Migrate, который может быть необходим для некоторых плагинов, использующих старые библиотеки скриптов
4. Зачем ради одного файла добавлять на страницу сторонний запрос, который добавляет 1 лишний DNS Resolving + полный цикл RTT, а это виновники самых больших задержек по времени при загрузке страницы, а учитывая, что CDN Google будет отдавать файл скорее всего из Ирландии, а CDN jQuery - из США, резолвинг DNS будет порядка 100-300мс, RTT - еще столько же, плюс время на получение файла. Итого, железно получаем 200-600мс задержки только из-за одного jQuery, который, к тому же, еще и блокирует рендеринг страницы. Тоесть Time to First Byte будет задержан дополнительно на этот период времени. Если же подключить штатный jQuery, DNS Resolving не делается вообще (уже сделан при запросе страницы), RTT короткий, а если на сервере правильно настроен keep_alive_timeout, то RTT вообще мизерный и файл прилетает значительно быстрее.

Либо ручками в коде - поправить тему либо сделать дочернюю (см. ответ @korobochkin), либо, если все-таки надо чтобы оно было в админке, есть у WordPress для этого родная фишка, называется Customization API. Код можно подсмотреть в штатной теме twentyfourteen, в файле

/wp-content/themes/twentyfourteen/inc/customizer.php

Хотя зачем на статичную штуку, которая делается 1 раз, создавать настройку и дергать базу данных - непонятно.

Читать посты с других WP сайтов можно по RSS, а еще лучше - установить на всех сайтах JSON REST API. Тогда можно элементарно получать конкретные посты, целые архивы в JSON.

Что касается подмешивания - тут есть нюансы. Само подмешивание сделать не проблема, в свойстве $posts объекта WP_Query хранятся все полученные из базы посты по текущему запросу. Плюс имеем такой же массив или объект, полученный в JSON с других сайтов. Приводим все к одному формату (объект или массив) и перемешиваем, выводим.

Но тут всплывает несколько нюансов:

1. Постраничная навигация будет работать некорректно, либо количество постов на страницах будет всегда больше, чем в настройках (ведь будут родные Х + сторонние У)
2. Автор поста, метаданные (рубрика, метки и т.д.) постов с другого сайта в текущей БД отсутствуют, поэтому эти вещи лучше не выводить или выводить текстом (не ссылками)
3. Еще по мелочам вылезет что-то

Если делать Multisite - это удобнее, комфортнее, приятнее и т.д. Но там эта задача не будет сильно легче. У Multisite общая таблица пользователей, таблицы постов и метаданных - разные, у каждого сайта свои. Да, можно на лету переключаться на другой блог, запрашивать отттуда посты, возвращаться на текущий и перемешивать. Это вместо считывания постов с другого сайта по RSS или JSON. Но дальше те же нюансы. Есть решения по синхронизации метаданных (категорий, меток) между сайтами сети, но это все уже усложнение, не уверен, что это нужно в этом конкретном случае.

Есть у WP вот такая штука, pre_get_posts:

function my_modify_main_query( $query ) {
     $query->query_vars['posts_per_page'] = 5; // вносим изменения в запрос, таких строчек может быть много.
}
add_action( ‘pre_get_posts’, ‘my_modify_main_query’ );

Что делает: изменяет параметры основного запроса в БД до того, как он будет выполнен. Таким образом, полученные результаты будут доступны через стандартный wordpress loop - не нужно будет писать лишний код, да и темы вручную тюнить.

1. Перейти на Nginx, последняя версия ветки mainline
2. Перейти на последнюю версию PHP5-FPM с OPcache
3. Перейти на MariaDB 10
4. Установить Memcached, модуль php5-memcached (c буквой d в конце, НЕ php5-memcache)
5. Для профита от п.4 установить плагин Memcached Redux

Можно в обратном порядке - Memcached, MariaDB, свежий PHP c OPcache, потом уже Nginx. Кроме того, неплохо бы протюнить настройки MySQL (или MariaDB) - особенно кеши. Но для этого надо проработать в штатном режиме хотя бы недели две, чтобы накопилась статистика. Лучше месяц.

У вас, скорее всего, затык в связке php-mysql, запросы обрабатываются долго. Попробуйте поставить плагин Query Monitor и посмотреть узкие места.

Custom Taxonomy вам в помощь. Зарегистрируйте нужные таксономии и все. Будут у вас мухи отдельно, котлеты отдельно. Одну таксономию можно привязать к нескольким Post Types (как стандартным, так и Custom), например, к постам и аттачментам (медиа-файлам).

codex.wordpress.org/Function_Reference/register_ta...

Что касается дополнительных полей, если стандартных для таксономий не хватает - можно метаданные любые добавить, но судя по всему, у вас уровень разработки не очень высокий, поэтому проще сделать через нормальный интерфейс - установить Advanced Custom Fields и там все настроить.

Не надо подключать всякие BFI_thumb, TinThumb и прочую ересь, я вас умоляю! У WP есть родные средства!

Получить урл картинки:

<?php wp_get_attachment_image_src( $attachment_id, $size, $icon ); ?>

где $size - либо название размера (medium, large), либо массив из двух чисел - высота и ширина
На выходе получите массив:

[0] => url
[1] => width
[2] => height
[3] => boolean: true if $url is a resized image, false if it is the original.

codex.wordpress.org/Function_Reference/wp_get_atta...

Именно комментарии, именно все? Скорее всего в шаблонах косяки. Попробуй другую тему, стандартную какую-нибудь. У меня на /members выводится только список пользователей (мемберов), никаких комментов. Что для залогиненых, что для анонимных юзеров.

В конфиге включите WP_DEBUG и посмотрите что пишет. А еще не мешало бы обновить permalinks. Иногда они слетают.

Но, самый главный вопрос - с какой версии обновлялись? Если с какой-нибудь 3.5 или еще более бородатой, то @opium дело говорит.

https://facetwp.com/ - платный, но самый толковый
https://wordpress.org/plugins/search-filter/
https://wordpress.org/plugins/ultimate-wp-query-se...
https://wordpress.org/plugins/advance-wp-query-sea...
wordpress.org/plugins/relevanssi

ACF толковый плагин для кастомных полей, но не для поиска и фильтрации. Хотя если сами поля есть, функционал фильтрации дописать самому не проблема, WP_Query штука мощная и гибкая.

Слейте девелоперу бекап папки сайта и дамп базы, пусть себе локально разрабатывает, а на выходе даст архив с обновленным шаблоном, который Вы сами зальете и установите.

Перейти на VPS от DigitalOcean.com [ внимание: реф.ссылка:) ]