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

get_terms( $args );
Документация: eng (официальная), рус. Примеры кода есть по ссылкам. Остается только вопрос как и где у вас хранятся картинки. Это плагин какой-то или кусочек кода из инттернетов, который вы вставили в functions.php?

GitHub / BitBucket. В общем, репозитории (открытые и приватные), Gist'ы, Wiki для репозиториев. Обычный MarkDown, что очень удобно. Если уж сильно надо в виде сайта в какой-то момент - через Jekyll прогнать.

А вообще если уж совсем с умом подходить и делать большую базу знаний - GitBook. Можно бесплатно у себя.

На той, которую лучше всего знаете вы или тот разработчик, которого вы наймете. CMS, CMF - это всего лишь инструмент. С его помощью можно сделать все, что угодно. И чаще всего в реальной жизни ограничения и грабли возникают не из-за ограничений CMS, а в силу недостаточной квалификации / ровности рук разработчиков.

Что касается WordPress - на его базе как раз есть не один подобный проект. Есть готовые платные и бесплатные решения именно для подобных сайтов. На вскидку я вижу 2-3 способа, как это реализовать. Возьмете Drupal - там выше порог входа, больше углубляться в программную часть надо (сам по себе Drupal для таких кастомных проектов очень даже неплох). Джумла - адский треш. Это если по популряным CMS пройтись. Готового решения, так чтобы скачать и запустить вы не найдете. В любом случае придется пилить под себя, и WordPress, учитывая наличие всех упомянутых вами модулей, мне кажется оптимальным решением. И не говорите, что он "слабоват", если не понимаете о чем речь.

Я если использую комменты, то всегда родные WP с небольшими модификациями - авторизация через соцсети, уведомление о комментах, отключение лишних полей и тд. Если клиент настаивает на внешней системе - для запада и всего не-школоло - Disqus. Если же аудитория четко вконтактиковская - тогда модуль ВК.

Причин на использование встроенной системы комментов несколько:

1. Скорость загрузки и возможность кеширования
2. Возможность индексации комментов и поиска по ним (в том числе и поисковики могут индексировать)
3. Более полный контроль над самими комментами, их дизайном, функционалом формы комментирования (например, разрешить загружать картинки или вставлять oEmbed)
4. Возможность использования виджетов "последние комменты" и тд
5. Возможность использовать количество комментов как одну из метрик для определения популярности постов
6. Отсутствие блокирующих внешних скриптов и запросов. Стараюсь вообще избегать использования внешних запросов с целью сокращения времени загрузки страниц
7. ... и другие мелкие выгоды, в зависимости от типа сайта

Что касается спама, то Akismet прекрасно справляется со своей задачей.

Если от мелкого до вполне крупного - WooCommerce очень даже неплох. Ну а если онлайн-гипермаркет уровня Enterprise - тогда лучше что-то узкоспециализированное. Тот же Magento на западе не просто так популярным стал.

Если надо сделать быстро - только готовая CMS. При всей моей любви в WordPress, в данном случае взять специализированную типа OpenCart, PrestaShop и подобных. Под WordPress есть хорошие решения, тот же WooCommerce, но чтобы там что-то доделывать - нужно хорошо знать и PHP, и архитектуру WP + WC. Зачем лишние сложности?

А еще есть другой вариант. Если вы не программист, а манагер / владелец этого магазина, то воспользуйтесь SaaS-площадкой, таковых на рынке масса. Через годик-другой работы магазина возможно перейдете на свое решение, возможно - нет.

WordPress + JSON REST Api (пока это системный плагин, скоро будет в ядре).
Сама админка имеет адаптивный дизайн, также есть мобильное приложение. Ну а REST Api позволяет общаться с проектом по JSON в оба направления.

ulogin неплох, получше loginza имхо.

WordPress позволяет использовать стороннюю таблицу wp_users, но тогда надо класс WP_Users переписать под свою структуру и данные (наследовать или заменить). Можно сделать свой oAuth сервер, один общий на все ресурсы - сайт, форум, WP. Во избежание дополнительных танцев с бубном над форумом я бы использовал BBPress - движок форума на базе WordPress. Он будет использовать тот же механизм юзеров, что и WP, а значит работы меньше.

Нужно модифицировать запрос. Если это основной 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();
?>

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

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

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

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

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

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

Не надо подключать всякие 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 выводится только список пользователей (мемберов), никаких комментов. Что для залогиненых, что для анонимных юзеров.