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

Красивый URL и его обработчик сделать можно, но сначала главный и основной вопрос - а зачем именно отдельная таблица? Имхо, можно (и нужно) обойтись стандартной таблицей (таблицами), создание своей - это уже прям для частных случаев.

UPDATE:

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

1. Сначала делаем урлы - для этого добавляем все необходимые схемы с помощью add_rewrite_rule()
2. Далее пишем обработчики для этих урл (тех, которые будут содержать ваши $matches[x])
3. Далее пишем helper функции - для генерации урл и вставки их в контент, для пагинации и тд
4. Далее хукаемся в template_include и подключаем нужные шаблоны
5. А теперь начинаем тестирование и отлавливаем вагон мелочей, устанавливаем все нужные глобальные переменные, чтобы WP не ругался и весь остальной функционал работал
6. Ну и админку ручками пилите.

Можно попробовать запилить свой кастомный WP_Query, что-то типа My_Query, основанный на родном. Но, как я уже писал в комментах, это танцы с бубном, которые не имеют никакого смысла. Делайте для ваших товаров обычный custom post type, создавайте ему таксономии, добавляйте произвольные поля с помощью Advanced Custom Fields Pro и не ищите себе проблем на пятую точку, на пустом месте. Из ваших комментов я так и не увидел объективной причины использовать свою таблицу. Если вы переживаете что база будет большая и будет тупить - зря, правильно приготовленный WP летает, а 30+15к записей это ни о чем. Если у вас много характеристик товаров и вы боитесь что они в виде meta_query в фильтрах будут тупить - для этого есть Elastic Search. Ну или на крайняк сами характеристики вынесите в отдельную таблицу, включить ее данные в стандартный WP_Query с custom post type будет проще и легче (см тут как пример)

Какой интересный вопрос... Ну что ж, приступим. У меня как раз вечер свободный выдался, можем и порассуждать.

Стал замечать, что разработчиков сайтов на Wordpress высмеивают и говорят, что это уже прошлый век.

Прошлый век? Не знаю, доля WordPress продолжает расти. Сейчас это почти 27% всего интернета, если мне не изменяет память. Немногим больше четверти всех сайтов в мире. И на пути к одной трети. Вдумайтесь. Осознайте. А еще на WP делают проекты с бюджетами и по 20, и по 50, и 150к условных единиц. И с ежемесячным саппортом в четырех-пятизначных суммах. Все это есть. Рынок огромен.

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

Да, и обратите внимание на то, кто смеется. Какой-нибудь фрилансер-нищеброд, пытающийся заработать жалкие $400-800 в месяц, сутками колупающий свой кастомный фреймворк и отлавливая в нем стремные баги? Хипстер-рубист? Престарелый ценитель-теоретик C и Java, в 40 лет живущий с матерью? Ну ок. Пусть хохочут. Я не встречал ни одного разработчика высокого класса, независимо от предпочитаемых языков / технологий, который бы смеялся. Потому что опытный человек понимает, что это всего лишь инструмент. Который, к тому же, прекрасно выполняет свои задачи. Так же как Laravel. Как Django. И все остальное.

Есть такие люди, которые Canon vs Nikon, Apple vs Android, Mercedes vs BMW и тд. Holy Warriors они называются, и встречаются в любой жизненной сфере, в любой профессии. Научитесь держать удар и не замечать их существования.

Пришел к выводу, что cms никто не пользуется при создании заказных сайтов, но неужели для каждого сайта пишется свой движок?

Неправильный вывод. Используются, повсеместно. Сплошь и рядом. Вообще, есть 3 подхода:

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

2. Фреймворк. Средне-долго, средне-дорого. Здесь используется готовая основа, необходимые модули, остальное пишется под конкретные задачи. Экономически целесообразно. Это хороший вариант. Но работы бывает много, и велосипеды встречаются, и модули напильником дорабатывать приходится. А если использовать много готовых модулей, то плавно перетекаем в 3й подход.

3. CMS/CMF. Дешевле, быстрее. Тут, если сайт сильно типовой и его можно собрать без особого кодинга - отлично. Но часто и на CMS/CMF бывают весьма объемные и сложные задачи, сильно выходящие за рамки возможностей движка "из коробки" или готовых плагинов. Та же разработка кастомного функционала, доработка напильником сторонних плагинов и тд. В общем, не типовые сайты на базе CMS/CMF делать можно и ничто не мешает это делать. Главное понимать зачем, почему и как правильно. Понимать архитектуру CMS/CMF и как в нее встроиться. Этот вариант сильно выгодный клиенту, особенно если речь о WP, с его огромным рынком специалистов (впрочем, часто сомнительного уровня. Но это везде так, я встречал проекты на Laravel и Yii где от кода тошнило фонтаном).

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

В общем, если WordPress нравится - изучайте его ядро, глубоко и качественно, изучайте глубоко и качественно сам PHP. SQL туда же. Те же фреймворки изучайте, там много интересного и полезного, что можно взять на вооружение. Учитесь решать задачи любой сложности элегантно, быстро, качественно. Учитесь документировать и рефакторить код. Оптимизировать. Использовать best practices. Учитесь создавать качественный продукт, решающий задачи клиента. И вот за это к вам будет стоять очередь, и будут хорошо платить. А не за то, что вы пишете на чистом си плюс плюс. Или на чем-то супер-современном. Enterprise-клиенты вообще такие legacy. А у них больше всего денег, кстати.

Определите в константу абсолютный путь до корня и подключайте шапку и футер через него.

define( 'SITEPATH', '/var/www/sitename/httpdocs' );
...
include( SITEPATH . '/templates/header.php' );
include( SITEPATH . '/templates/footer.php' );

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

1. Composer - это про PHP. Зависимости.
2. Gulp, Grunt и тд - это про фронтенд.
3. Параметр ?ver=4.5.3 - это cache busting от WordPress, 4.5.3 - это ваша версия WordPress.
4. bootstrap (js, css) - это фронтенд фреймворк, используется он в активной теме, грузится скорее всего из файла functions.php. Ищите по коду файлов темы функцию wp_enqueue_scripts

gulp-notify

У меня вот так (упрощенный пример):

var gulp = require( 'gulp' );
var sass = require( 'gulp-sass' );
var autoprefixer = require( 'gulp-autoprefixer' );
var notify = require( 'gulp-notify' );
/**
 * Compile styles
 */
gulp.task('sass', function() {
   return gulp.src( './assets/stylesheets/style.scss' )
       .pipe( sass({
           outputStyle: 'compressed'
       }) )
       .on( 'error', notify.onError({
           title: 'Sass Compilation Failed',
           message: '<%= error.message %>'
       }) )
       .pipe( autoprefixer() )
       .pipe( gulp.dest( './' ) );
});

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