Алексей Николаев

Читал недавно случай, что плагин Revolution Slider для WP послужил причиной утечки секретных данных. Так что поиск уязвимостей в WP не ограничивается движком - плагины тоже могут быть к этому причастны.
Обновите все до последних версий, добавьте htaccess с deny from all во все админские и системные директории.

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

Аякс в wordpress работает иным способом.

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

В wordpress страницы создаются через админку. А новые шаблоны создаются в папке темы.

Как лучше реализовывать дополнительный функционал

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

Структура WP похожа на дерево, где каждая ветвь - фильтр или экшен. Плагины всего лишь добавляют ссылку на метод \ функцию в список действий для каждой ветви, которые движок должен будет выполнить. Сам по себе плагин, таким образом, не влияет на производительность - все зависит от того, какие именно функции должен будет выполнить WP. В среднем, если у вас штук 50 плагинов среднего размера, беспокоиться не о чем - скорее всего, вы даже не заметите замедления работы. 20-30 плагинов и меньше вообще ни о чем, как летало, так и будет летать. Плюс можно установить плагин кэширования для ускорения работы, а то и вовсе перейти на php7 и ускорить WP в 2 раза. На одном корпоративном сайте (~30 плагинов с весьма широким функционалом + самопис) так и сделано, открывается практически моментально.

Конечно, многое зависит от самого плагина и от того, насколько криво он написан - постоянно встречаю как отказ следовать рекомендациям в dev guide, так и просто адский код, на который без слез не взглянешь (хотя не исключено, что быстрый в плане производительности). Но этим и хорош WP: если какой-либо плагин слишком сильно влияет на работу системы, почти всегда можно найти лучший аналог.

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

Ошибка в шаблонах главной и блога - в шаблоне блога должен быть цикл записей, а в шаблоне главной - просто вывод the_content(). Посмотрите, как реализованы эти файлы в одной из стандартных тем Wordpress.
Кроме того, в самой CMS должны быть созданы специальные страницы для блога и главной соответственно, они будут пустыми (нужно просто для того, чтобы WP распознал url).

Лично я, поработав со всеми тремя указанными, рекомендовал бы Wordpress. В крайнем случае, если у вас очень много свободного времени и высокая стрессоустойчивость, Drupal.

Как ответили выше, хорошим вариантом будет сперва "потыкать" интересующие CMS и попытаться сделать на них базовый функционал.

Либо создайте еще одно поле текстового типа, в котором будете указывать название вручную, либо получайте объект страницы по ее url.

Ну так и напишите,

data-content="<?php echo do_shortcode('[shortcode id=aaa title=bbb]') ?>"

Если ваш участок кода - контент страницы, который редактируется через админку, писать do_shortcode не нужно.

Это не так. На Wordpress можно делать высокопрофессиональные и высоконагруженные сайты. Поскольку функционал расширяется за счет плагинов, то вам потребуется и ООП, и SQL, и вот это вот все.

И напротив, разрабатывать без CMS хотя бы на 50% типовое решение - дело гиблое.

По моему мнению это бессмысленно и напоминает скорее костыль, нежели работающую защитную меру. Из того же разряда - назвать директорию с админкой не /admin, а /adminpanel. Борьба с последствиями, т.е. со слабой защитой самого ядра системы, а не усиление защиты этого самого ядра.

Если в системе есть защита от брутфорса и DDOS (или блок в htaccess по htpasswd на адреса логина \ админки) и администратор использует хорошие пароли (а не свою дату рождения, к примеру), никакие учетки ни менять, ни удалять не имеет смысла.

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

Рабочий вариант. Скрипты \ стили всегда должны подключаться через wp_enqueue_scripts \ wp_enqueue_styles соответственно.

function my_scripts() {
    wp_enqueue_script(
        'fitness_calc', 
        plugins_url('fitness_calc/fitness_calc.js'), 
        array(), null,
        false // этот - последний - параметр указывает, в футере выводить или нет
    );
}
add_action('wp_enqueue_scripts',  'my_scripts', 100);

Соответственно , моя разметка грузится быстрее , чем нужный JS

А вообще, это нормально, равно как и размещение скриптов в футере. Почему бы не активировать js-логику (табы, как пример) только когда DOM будет готов к этому, а скрипты загрузятся?.. До этого момента показывать пользователю разметку + начальное активное состояние (выделенный таб, например), либо, если это невозможно - прелоадер. Например, добавить класс .loader, и убирать его при загрузке.

Выносить скрипт в шапку в подавляющем большинстве случаев костыль и неправильно.

Best practice при разработке на wordpress является ООП и синглтон. Далее - по своему усмотрению. Исключение, разве что, когда у вас пара функций и один хук, грубо говоря. Тут собраны хорошие советы, в большинстве общего характера.

Процедурно ни в коем случае не рекомендую, это путь всяких друпалов, не дает никаких преимуществ и смотрится \ рефакторится \ читается ужасно.