Конфигурация Ngnix для WordPress, Joomla, Drupal. Функционал панели ISPConfig.

Итак, сегодня я отойду далеко в сторону от того, что обычно пишу на своем сайте. Сегодня мы поговорим о технических аспектах.

Не так давно я полностью обновил сервер. Был выбран более стабильный релиз операционной системы и более приятный функционал для конечного пользователя. В частности вместо OpenPanel была установлена система управления ISPConfig, а вместо довольно тормозного Apache был выбран легкий и шустрый Ngnix. Должен сказать, что эти меры привели к изрядному увеличению производительности и отказоустойчивости. Только не надо проверять отказоустойчивость, имейте совесть 🙂 Так вот, заменив Apache на Ngnix я еще не знал, в какую глубокую лужу я сел. Однако глубину лужи мне наглядно продемонстрировали сайты мои и моих друзей, которые дружно послали меня нафиг и перестали адекватно работать. Проще говоря, все сайты, заведенные на Joomla, WordPress и Drupal перестали работать с так называемыми чистыми ссылками. 

Если бы речь шла об Apache, я бы сказал, что или пропали файлы .htaccess, или они каким-то образом обнулились, или не работает mod_Rewrite. Для начала я, как главный чайник страны, попытался прописать правила обработки ссылок в соответствии с правилами Apache. И был страшно удивлен, что эта мера не принесла никаких результатов. Пришлось засесть в гугле и упорно искать, в чем же причина. Десять минут поисков привели меня к мысли, что Ngnix просто не понимает команд Apache. Сказать, что я был этим сражен — значит не сказать ничего.

Для начала я поискал конвертер комманд Апача в команды Ngnix. И нашел его. Даже два. И оба выдали мне на гора пачку кодов. Печально на них посмотрев, я начал искать конфигурационный файл Ngnix. К счастью, я додумался залезть в панель ISPConfig и обнаружил, что к каждому сайту есть возможность записать свой отдельный конфиг. Немного поаплодировав программистам стоя, я гордо внес полученные коды в конфиг сайта.

Через минуту, опять встав со стула, я грязно матерился на внезапно упавший Ngnix. Еще полчаса поисков по сети дали мне готовую конфигурацию для Drupal. Вау! Сказал я и внес ее в конфиг вместо той ерунды, которую мне выдал конвертер. После чего мрачно полюбовался на ошибку 403, которую мне выдал сервер при попытке попасть на сайт.

Я могу еще долго описывать 2 дня мучений с конфигами реврайта для сайтов. Было выпито немеряное количество кофе, нервно скурено пачки три сигарет и весь пол в кабинете был покрыт толстым слоем мата. Однако решение было найдено, оно простое и элегантное. Его я и привожу ниже. Итак, вот они, конфиги для панели ISPConfig для сайтов на Drupal, WordPress и Joomla:

Drupal:

location / {
root /путь/к/вашему/сайту;
index index.php;
error_page 404 = @drupal;
}

location @drupal {
rewrite ^(.*)$ /index.php?q=$1 last;
}

Joomla:

location / {
try_files $uri $uri/ /index.php?$args;
}

WordPress:

location / {
root /путь/к/вашему/сайту;
index index.php;
error_page 404 = @wordpress;
}

location @wordpress {
try_files $uri $uri/ /index.php?$args;
}

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