Самописный сайт и ЧПУ

По мне так оптимально - единая точка входа index.php и там обработать $_SERVER['REQUEST_URI']

Например завести правила для 1 сегмента урла

 

...

"rules" : {

    "usr" : {

      "class" : "usr",

      "template" : "land.twig",

      "robots" : "noindex",

      "usr":"all",

      "content_type":"text/html"

    },

    "adm_xhr" : {

      "class" : "adm",

      "template" : "",

      "robots" : "noindex",

      "usr":"admin",

      "content_type":"application/json"

    },

}

...

и в зависимости 1 сегмента от правил выполнить соотв. действие

RewriteCond %{REQUEST_FILENAME} !-f

RewriteCond %{REQUEST_FILENAME} !-d

RewriteCond %{REQUEST_FILENAME} !-l

#Отдавать index.php  только если не файл/папка/ссылка

RewriteCond %{REQUEST_URI} !\.(png|css|js|jpg|gif|svg)$

#Не выполнять правило для урлов с такими расширениями, даже если они не -f,-d,-l  

RewriteRule ^(.+)$ /index.php [QSA]

[off]

простите, но вы все делаете не правильно :-\

если уж делать самопис, то с осознанием как все должно быть в идеале.

а в идеале nginx должен готовую статику раздавать моментально. и никаких php и уж тем более .htaccess не должно фигурировать между запросом и отдачей ответа.

с .htaccess ковыряются когда руки связаны какой-то жизненно необходимой cms, переделывать которую нет времени/возможности

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

и когда надо обновить - перезапускаете регенерацию. лучше конечно не всего, а лишь части изменившейся.

[/off]

mff, апач не умеет отличать страны от жанров - ему всё равно, что это, austria или animals.

Поэтому у Вас 2 варианта на выбор:

1. Делать адресацию вида

https://wc.ru/genre/animals/

https://wc.ru/country/austria/

2.Направлять запросы на index.php и там разруливать их.

На данный момент развития интернета, лучше всё разруливать в index.php

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

timo-71, большое вам спасибо! Прописал в htaccess ваши коды, но посему то всеравно показывает svg как страницу: http://mj2.ru/img/views.svg

EvGenius, я извиняюсь но зачем мне движок для простенького каталога веб-камер состоящего из 4 страниц и нескольких табличек в базе данных? И вообще я не любитель использовать готовые движки, модули. В них 90% не нужного и только 10% нужного. Перепиливай их потом и забудь про обновления... Максимум могу плеер какой нибудь использовать готовый.

Спасибо, но ни чего не понял :( Какой скрипт? Какой результат? Мне бы пример/кусок кода...

Этот вариант ни как не подходит. Много лишнего.

Не могли бы посоветовать какую нибудь статью по этой тематике, написанную доступным языком?

С ув.

Это самый вменяемый вариант из простых: есть имя коллекции/признака, есть имя элемента/значение признака.

Посмотрите мою статью Как сделать единую точку входа с ЧПУ? – как раз для начинающих.

---------- Добавлено 16.02.2019 в 19:15 ----------

Может вы просто не до конца поняли суть. Вас никто не заставляет добавлять к показанным адресам еще и слаг статьи. Это уже будет др. ветвь/ветви. Но в принципе можете глянуть на G-Drive. В нем можно прятать имя признака/обработчика за первым компонентом пути. Ваши два уровня поддерживаются непосредственно ядром. Правда, по-моему не оч. красиво дублирование компонентов в идентификаторах animals и animals/national_zapovednik.html. И, уже начиная со второго уровня, нужно дописывать разруливание в пределах осн. обработчика.

---------- Добавлено 16.02.2019 в 19:23 ----------

По-моему это два независимых признака. Гляньте демку в конце статьи Как сделать фильтрацию элементов по двум независимым признакам? Хотя это все условность. Можно наплодить и отдельные сущности "Страны и Жанры". Тогда у статей будет только одно связующее поле с категориями.

Ну перепиливай давай тогда свою самописку и то же про обновления забудь.

Коллега, большое спасибо за статейку. Немножко разобрался.

В общем я так понял, нужно делать в индексном файле единый обработчик и, как правильно сказать, роутер, то есть подгружать нужный файл php исходя из данных, полученных в URI? За одно там же проверить, есть ли такие данные в базе и если нету, выдавать ответ отличный от 200, то есть направлять на страницу 404? 🙄

С ув.

Зачем городить велосипеды? Давно уже написаны хорошие классы роутеров. С полноценным функционалом.

К примеру это https://github.com/bramus/router

По поводу статики выше правильно сказали, что лучше отдавать nginx. Связка апач и нжинкс показывает прекрасную скорость.

Если интересно, могу скинуть готовые конфиги для небольших проектов.

Единый обработчик – это фронт-контроллер. Роутер – обычно лишь его часть. Например, во фронте можно выполнять общие для всего сайта конфигурирование, авторизацию и т.п. Или выполнять какую-то общую финальную обработку после возврата из частного обработчика (работа роутера обычно заканчивается вызовом частного обработчика). Подгружать один файл – это слишком упрощенное представление. Обычно при формировании страниц/подготовке др. ответа участвует много файлов. Например, даже в простейшем движке по ссылке выше для сборки страницы помимо частного обработчика (который кстати может быть пропущен, т.к. фронт типичные действия по выборке данных из БД выполняет сам) обычно подключаются файлы частного и общего шаблонов – это как раз пример финальной обработки вне частного обработчика. Прочитать об этом более подробно, а также посмотреть на примеры частного и общего шаблонов можно тут.

Именно так. Это одна из задач роутера – инициировать выдачу 404-ой (необязательно выдавать самому) при «непопадании» адреса запроса под заранее заложенные правила. Например, движок по ссылке выше проверяет «попадание» под единственную заложенную маску для соответствия адреса общему предопределенному формату и отсеивания недопустимых символов в нем. А ведь можно выполнять такую проверку в цикле, обходя «роуты» в порядке приоритета и проверяя попадание под их маски.