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

1. Статические генераторы.
2. WordPress как бекэнд + WP REST API + фронтэнд на каком-нибудь Angular.

У AddThis есть родной плагин для WP, который все делает как надо. Установите и не страдайте.

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

Стандартный подход:
1 Таблица - товар и его стандартные характеристики
2 Таблица - дополнительные характеристики (цвета, размеры, габариты, наличие/остатки и прочее)
3 Таблица - связи между первыми 2мя таблицами
Выборка из этих таблиц с помощью LEFT JOIN / INNER JOIN, например.
Бывает еще промежуточная таблица "типы связей", тогда в таблице 2 хранятся только сами опции и внешний ключ на поле ID из таблицы "типы связей". То есть, Т1 - товары, Т2 - типы связей (цвет, размер, вес, наличие и тд), Т3 - характеристики (все варианты цветов, размеров и тд), Т4 - связи. Такие схемы встречаются, но, ИМХО, редко имеют смысл. Стандартной модели обычно достаточно.

Вы про этот список ссылок на версии игры? Это обычный список объектов (предполагаю, постов или custom post type), который выводится в html обычным списком OL, но обернут в div с фиксированной высотой и принудительной прокруткой (overflow-y: scroll).

Уточните, что вам нужно - получить список из БД средствами WP или как эти результаты вывести в HTML именно в таком виде.

Медленно, потому что идет перебор по всем строкам в таблице wp_postmeta, в которой отсутствуют индексы. И если у вас постов 5-6 тыщ, то postmeta у вас будет в разы больше. Но все равно такая скорость - это слишком долго. Видимо, беда все-таки и в сервере. Упомянутый где-то в комментах Sphynx решает задачу со сложными запросами по метаданным.

Похоже на какие-то макароны в виде костыля. Суть задачи (зачем это надо) опишите, уверен все делается одним простым циклом с подстановкой ID страницы / поста / другого объекта динамически, и сравнивать ничего с текущим адресом (url) не придется, проверку текущего объекта по-другому делается. В общем, задачу нормально опишите.

Есть такая волшебная функция human_time_diff( $from, $to );

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

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

Да у любого адекватного хостера возьмите облачный VPS, тот же Digital Ocean. Подняли сервак, сделали что надо, грохнули. Заплатите по итогу пару копеек.

Александр Зеленин дело говорит. query_posts - это утилитная функция, ее в этом случае юзать не стоит. Оптимально - хук в pre_get_posts, установить нужные параметры (категория, количество постов на страницу), тогда стандартный луп (WP_Query) сам по себе выдаст нужный результат, и больше ничего править не надо.

Вообще, если в wp-config.php константу домена куки прописать пустой, то авторизация по умолчанию будет работать так как надо, до тех пор пока подсайты являются поддоменами основного домена (без использования маппинга других доменных имен). Авторизовавшись на любом из сайтов сети пользователь остается авторизован на любом другом сайте сети, включая главный сайт. По умолчанию в куку прописывается тот домен/поддомен, на котором пользователь авторизовася, поэтому авторизация слетает на другом сайте сети.

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