Михаил

У 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

Я, наверное, вас разочарую, но CMS/CMF-движки не имеют отношения к поисковой оптимизации (SEO). Поисковым роботам абсолютно безразлично, какую технологию вы используете, они учитывают другие параметры. Задача CMS — лишь помочь вам в этом. То есть «запороть» сайт и понизить его рейтинг можно на любом движке. На своём опыте могу сказать, что в MODX Revolution есть отличная система кэширования, которая положительно воспринимается поисковиками, т. к. увеличивает скорость генерации и загрузки страниц, система минификации и «склеивания» скриптов и стилей MinifyX (вообще, эти задачи должны решаться до выгрузки файлов на сервер, но если лень …), ЧПУ-генерация, коды ошибок 403 и 404, автогенерация Sitemap и прочее. По этому вопросу книгу можно написать, если честно — куча практик хороших и не очень.
WordPress — отличная CMS, но она в какой-то мере ограничивает разработчика дополнениями, если их функционал приходится изменять или расширять. Архитектура MODX позволяет контролировать вывод любого дополнения (если автор соблюдает парадигму, конечно), но я бы советовал, если выберите его, обратить внимание на Revolution-ветку, т. к. предшественник, Evo, официально прекратил свое существование и больше не развивается.
P. S. Кстати, MODX Revo гораздо безопаснее в плане защиты от взлома.

1. Laravel
2. WordPress + Javascript (а конкретнее - Ember, Angular и тд)

Подробнее по п.2 открываю "секрет" - совсем уж скоро в ядро будет включен REST API. И назревает серьезная революция тем и плагинов. Откроется масса новых ниш. Следите за процессом и оставайтесь в тренде - работы в этом направлении будет очень много.

1. Есть прекрасная чистая основа Underscores.me (_s на GitHub), в которой реализованы все best practices. Используйте ее как основу, сразу учитесь делать правильно.
2. Бутстрап, конечно, дело привычки. Но, ИМХО, это плохой инструмент, так как с ним ты становишься слишком ленив. Кроме того, бутстрап массивен, никак не утилизирует стандартные классы WordPress, требует добавления своих классов. В общем, каша. В _s уже включен SASS, разбитый на компоненты. Испольлзуйте его. Если вы без бутстрапа не можете сами написать свою сетку на 12-20 строк CSS - дело дрянь.
3. Custom post type.

1. Потому что надо использовать noConflict

jQuery(document).ready(function($) {
  App.Nav();
  App.Faq();
});

2. Вообще загружать свой jQuery - плохая практика, лучше загружать родной, который идет вместе с WordPress (именно из папки wp-includes). Иначе вы рискуете, что какой-то плагин подключит его повторно. Проще всего указать jQuery в качестве dependency

function enqueue_scripts() {
  wp_enqueue_script( 'fotorama', get_template_directory_uri() . '/bower_components/fotorama/fotorama.js', array('jQuery') );
  wp_enqueue_script( 'application', get_template_directory_uri() . '/javascripts/application.js' );
}

Получилось отредактировать через контексты
Система - Управления контекстами - выбираем контекст( в моем случае web ) - Меняем параметр site_url. Обязательно сохраняем кнопкой "сохранить"

Версия МодХ 2.2.16 Traditional

Sails не стал бы брать, ибо ruby way а не ноды.
Писал на нём проект, скорее мешала его мишура чем помогала.
Производительность - тоже не его конёк.
Наверное он хорошо подойдёт для совсем уж тривиального CRUD приложения.

React.js осваивается за 2 часа.
БД - монга за глаза. (mongoose как odm)

Сейчас вы циклом выводите все посты (posts_per_page равен -1). То есть, все посты у вас уже есть, аякс по большому счету не нужен - достаточно просто прятать ненужные элементы. Чтобы определить какой пост в какой рубрике, необходимо в вывод поста добавить дополнительный атрибут, через который вы ее будете отлавливать. Например

<?php $category = get_the_category(); // получить  ?>
<a href="<?php the_permalink() ?>" rel="bookmark" data-category="<?php echo $category[0]->cat_name; ?>">
    <?php the_post_thumbnail('thumbnail'); ?>
</a>

Далее уже в javascript при клике на ссылку в фильтре берете ее имя из $(this), проходитесь с помощью each() по всем постам, скрываете те, у которых data('category') не равен имени категории.

Еще раз, зачем аякс?

Вопрос старый, но может будущим поколениям будет полезно.
Да, можно. Принимаете данные через POST со своей формы и используете функции
wp_insert_post() / wp_update_post()
add_post_meta() / update_post_meta()

Если смотреть в сторону Node.js, то я лично хотел бы попробовать Sails. От слова "Rails", то бишь, создатели этого фреймворка стремились создать инструмент, по архитектуре и простоте своей подобный рельсам, но только на ноде. И среди всех node-фреймворков, как я понял, данный фреймворк наиболее полноценный, законченный и решающий большую часть задач веб-разработки.

Что касается фронтенд - то тут уже выбор намного более широк. Я лично писал бы всё на Riot.js, так как он просто обаял меня своей простотой и удобством разработки. Но большинство веб-разработчиков нынче смотрят на большие и мощные решения, вроде Ангуляра.

Ну... в Вашем случае, главное, чтобы инвестор не читал Тостер, а архитектуру можно сделать и после завершения проекта ))) А вообще моя лекция по архитектуре для ноды (но в ней есть много общих вопросов и полезных мыслей): https://youtu.be/Try7lmWikao И на Хабре есть специальный раздел "Анализ и проектирование систем" где проскакивают статьи по архитектуре, как например: habrahabr.ru/post/204958 Нарисуйте связь компонентов системы СУБД-сервер-клиент (трехзвенка, или больше компонентов, если есть), нарисуйте уровни по ISO/OSI, слои абстракций, дайте спецификацию API. Вот тут есть я даю расширенный план проектирования, он должен помочь: Как составить план проектирования проекта?

Есть хорошая книжка, которая может служить и учебником, и справочником. "Руководство Microsoft по проектированию архитектуры приложений, 2 издание" (download.microsoft.com/documents/rus/msdn/%D1%80%D...).
Если закрыть глаза на рекомендации по использованию именно технологий Microsoft, то будет вполне целостная картина того, как решаются самые разные вопросы проектирования, от самого верхнего уровня до деталей реализации. Рассматриваются, в том числе, и вопросы, связанные с реализацией web-приложений и сервисов, причём в общем контексте enterprise-системы.

Подписчикам, решил вопрос след.образом:

auth: function(skip, sub){
        if (!sub.userId) { return false; }
        var _serverFilter = {roles: 'user'};
        if(Roles.userIsInRole(sub.userId, ['admin'])) {
             //....
        } else if(Roles.userIsInRole(sub.userId, ['manager'])) {
            _serverFilter.manager_id = sub.userId ;
        } else {
            console.log('whaa?');
            return false ;
        }

        var userSettings = UsersPagination.userSettings[sub._session.id] || {};
        var uFilters = userSettings.filters || this.filters;
        var uFields = userSettings.fields || this.fields;
        var uSort = userSettings.sort || this.sort;
        var uPerPage = userSettings.perPage || this.perPage;
        var _filters = _.extend({}, uFilters, _serverFilter);
        var _options = { fields: uFields, sort: uSort, limit: uPerPage, skip: skip };
        return [ _filters, _options ];
    },