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

Вордпресс очень уязвим и его взлом — дело времени

Самое уязвимое место WordPress - это юзер. Около 90% взломов - примитивный брутфорс пароля для логина admin. Из оставшихся 10% - 9,99% это установка "зануленных" тем и плагинов из ненадежных источников, установка просто низкокачественных плагинов и тем (в том числе тех, которые используют дырявые сторонние библиотеки типа timthumb), копипаста некачественного кода из интернетов чтобы "добавить эту фишечку" etc. И только 0,01% - это действительно, какие-то редкие баги в самом WP или качественных и популярных плагинах. Обычно по мере обнаружения о них трубят на каждом углу и заплатки выходят в считанные часы. Учитывая, что WP движет четверть сайтов в мире, а WP+WooCommerce - треть интернет-магазинов - количество попыток взлома колоссальное. Так что несколько найденных и быстро прикрытых дырочек в год - это как раз очень хороший показатель безопасности системы, а не наоборот.

Дмитрий Маринин все правильно написал, от себя добавлю - установите какой-то плагин для отладки, который показывает, какой шаблон используется, например
https://wordpress.org/plugins/display-template-name/
https://wordpress.org/plugins/what-template/
и зайдите на ту свою страницу, которую вы назначили "страницей с записями". По идее должен использоваться index.php, убедитесь в этом. Его, собственно, и нужно будет редактировать.

Найдите любой плагин который дает поддержку qTranslate (кстати, используйте более новый форк qTranslate X) для другого плагина, например WooCommerce, Advanced Custom Fields и тд и посмотрите как он устроен внутри. На самом деле там нет ничего сложного.

Например, вот:
https://plugins.trac.wordpress.org/browser/qtransl...
https://plugins.trac.wordpress.org/browser/qtransl...

Учим матчасть:
wp_reset_postdata()
wp_reset_query()

Ответ уже как бы есть, я только не могу понять, зачем городить сторонние файлы, делать редиректы и тд. Есть же такая удобна штука как хуки. Например - init, template_redirect, template_include. Вместо целого файла регистрируете query_var, можно даже rewtie_rule свой (example.com/auth/). При попадании на этот урл в хуке init или template_include стартуете авторизованную сессию, если есть токен, делаете что надо (например сверяете токен с таковым в таблице wp_usermeta), дальше отправляете на нужную страницу (откуда начали авторизацию). Гибкость фантастическая. И все - родные фичи WP, а не костыли. Да, это более advanced topic, чем просто сторонний файлик, но и более гибкий в результате, более надежный и безопасный. Вот в вашем случае, например, а что, если токен левый отправить? Проверки есть? Какая-нибудь API key pair есть? Так чтобы один ключик на том сервисе где логинитесь, а второй - на самом сайте. Понятно, что вы детально не раскрыли механизм авторизации, но со стороны здесь просматривается не очень надежное место.

Плагин:
www.woothemes.com/products/variation-swatches-and-...

Документаци к нему:
docs.woothemes.com/document/woocommerce-color-and-...

Бесплатные плагины, найденные за пару минут гугления:
https://wordpress.org/plugins/smart-variations-images/
https://wordpress.org/plugins/woocommerce-molds/

Доступ непосредственно к MySQL у вас вряд ли есть, так что используйте PHPMyAdmin или HeidiSQL. Синтаксис команд:

ALTER DATABASE databasename CHARACTER SET utf8 COLLATE utf8_general_ci;
ALTER TABLE tablename CONVERT TO CHARACTER SET utf8 COLLATE utf8_general_ci;

Означает ли фраза "натянуть HTML-шаблон на WordPress" что в итоге должен получиться полнофункциональный сайт под управлением WP?

Да, именно это и означает. Это означает что нужно взять статический html, разбить на php-шаблоны (header.php, footer.php, sidebar.php, index.php, archive.php, single.php, page.php, search.php, 404.php и так далее). В самих шаблонах все динамические данные и все, что "захардкожено" перевести на соответствующие template tags, подключить вывод контента (через WordPress Loop, Widgets и тд). Поставить и настроить нужные плагины или дописать свой кастомный код (в functions.php или в свой собственный плагин(ы)) чтобы функционал был именно такой, как надо по ТЗ. Но эта часть (кастомный функционал) уже начинает выходить за рамки "натянуть шаблон".

В общем, на выходе после этой "натяжки" у вас вместо статического html должен быть работающий динамический сайт, контент которого клиент может редактировать в админке, и все изменения будут сразу отображаться на сайте.

И еще вот этот мой ответ почитайте.

И чуть-чуть под другим углом спрошу: при покупке готовой WordPress темы и ее установки на WP получится ли готовый сайт под управлением WP?

В целом - да. Но, большинство платных тем - это здоровенные тяжелые комбайны "на все случаи жизни", и банально установить тестовые данные (чтобы у вас было так, как в рекламе - то есть в демо на сайте продавца) бывает проблематично для не-специалиста. На любой фриланс бирже туча заказов на это ежедневно. Точно так же и на "кастомизацию" или допиливание напильником платных тем. Почему? Потому что эти универсальные комбайны, они как средняя температура по больнице. Подходят вроде очень многим под разные задачи, а на самом деле полностью не подходят никому.

Поэтому, действительно получить хорошую, качественную работу на базе WordPress можно только в одном случае - заказать под конкретно свои задачи у опытных wp-разработчиков. Только помните, разработчики - это php-программисты, которые умеют писать кастомный код под WordPress. Программисты, которые хорошо знают именно внутренности WordPress, и пишут под него, а не свои костыли сверху и сбоку. И не путайте с имплементаторами (не программисты, а "вебмастера", которые умеют найти говноплагин и установить его, максимум - пофиксить стили или копипастой вставить какой-то код, найденный в гугле).

То есть фактически получается что техзадание заменяется шаблоном (макетом)?

Нет. Если функционал хоть немного выходит за пределы стандартных (встроенных) фич WP - дальше придется допиливать руками, устанавливать (и часто затачивать) чужие плагины или писать свои. Готовых пллагинов - десятки тысяч, но далеко не все нормально написаны и на 100% подойдут под ваши задачи. В общем, для сайта, чуть сложнее чем блог, будет достаточно много кастомной работы, и для нее необходимо готовить ТЗ. Если кто-то вам говорит, что может за пару часов засетапить любой сайт на WP и сделать что угодно за 500-1000 рэ - вам попался имплементатор, который нихрена не понимает из того что делает, и все, что он выдаст - это очередной говносайт, проблем с которым будет больше, чем пользы.

У WordPress нет шаблонизатора в его общепринятом понимании - как Smarty, Twig, Dwoo, Savant и тд. Есть набор шаблонов (templates), которые WP подключает / использует в зависимости от того, что было запрошено. Есть четкая логика использования этих шаблонов.

Сами эти шаблоны - html-файлы, в которых все динамические данные (контент страниц/постов, ссылки, меню, аватары, комментарии, заголовки страниц, медиафайлы и тому подобное) вставляются с помощью Template Tags. Можно создавать и свои. По сути Template Tags - это php-функции, которые выводят или возвращают определенные значения.

Еще один важный момент - есть плагины и файл functions.php - эти части призваны отвечать за функционал. Например, функция в functions.php получает какие-то данные из базы, обрабатывает и возвращает результат. Этот результат можно вывести в шаблоне.

Также, одними из важнейших составляющих (и секретом гибкости WordPress) являются хуки - фильтры и экшны (filters and actions). Их, кстати, тоже можно свои создавать.

Документация, она же Theme Developer Handbook.

А также:

https://codex.wordpress.org/Theme_Development
https://codex.wordpress.org/Function_Reference
https://codex.wordpress.org/Plugin_API

Ну первоначальный сетап придется сделать вручную, не вижу смысла писать какую-то автоматизацию. Зашли в админку сети, создали новый сайт сети, назначили админов, активировали нужные плагины. Доустановили плагины, которых еще нет в сети (в том числе site-specific плагины), тему. Ну а дальше уже есть варианты..

У нас так - кастомные темы и плагины висят в git-репозиториях, над ними обычно работает несколько человек. На сам сервер они заливаются не через админку WP или FTP, а через SSH делается git clone репозитория. Соответственно, в процессе дальнейшей работы тимлид мерджит код в одну ветку и релизит. Тут есть возможность и автодеплой сделать, или вручную.

Да, и еще. Если есть возможность держать локальное зеркало вашего мультисайта, то можно использовать плагин WP Sync DB. Несмотря на название, он синхронизирует не только базу, но и файлы.

Еще есть такая крутая штука как WP CLI.

Есть плагин Revisr. Тоже крутая штука.

Тема вроде как и решена, но не совсем корректно. Оставлю для будущих поколений.

dm: если конкретно этот, основной цикл надо видоизменить, то делается это так:

function my_modify_query( $query ) {
    // это главный запрос, мы не в админке, мы на архивной странице
    if ( $query->is_main_query() && ! is_admin() && is_archive() ) { 
        // конкретный пост по его ID
        $query->set( 'post__in', array(345) ); 
        // Устанавливать можно любые свойства объекта WP_Query
    }
}
add_action( 'pre_get_posts', 'my_modify_query' );

Документация:
на WordPress Codex (англ).
на WP-Kama (рус)