Пытаюсь создать CMS, и, с помощью .htaccess индексная страница сделана точкой входа для всех адресов, для которых отсутствуют реальные файлы. На индексной странице размещен вот такой код: Код (Text): file_put_contents('4.txt', $_SERVER['REQUEST_URI'] . "\n", FILE_APPEND); В текстовом файле получаем: /wowa/ /test.css /images/stydent03.jpg Первая строка - адрес в адресной строке. Остальные - несуществующие файлы. Несуществующие файлы могут всегда оказаться, поэтому так не годится. А что делать? Как вытащить адрес? .
Нормально вопрос задайте. --- Добавлено --- В текстовых файлах роуты не хранят. Или в БД, или прямо в коде. --- Добавлено --- Пример: Простая модель для «чайников»
Это понятно, что хранить нужно в базе. И у меня так задумано. Но проблема в том, чтобы получить адрес, набранный в браузере. Пока пишу в файл, чтобы с этим разобраться.
Так $_SERVER['REQUEST_URI'] Для проверки совпадения придется последовательно сравнивать со строками в файле. --- Добавлено --- ...с неполными строками, т.к. в строках еще могут быть имена контроллеров и т.п. --- Добавлено --- Лучше на ассоциативном массиве учитесь Типа: PHP: [ '' => 'home', 'page' => 'page', ]
Я пересмотрел несколько статей по роутингу и запутался окончательно. Квалификация у меня невысокая - РНР в классическом виде (не ООП). Я предполагал сделать CMS так: - .htaccess организует точку входа через index.php; - с помощью $_SERVER['REQUEST_URI'] я узнаю адрес страницы; - по этому адресу запрашиваю контент в базе. Если в базе для этого адреса контент есть, то вывожу его в index.php. Если контента нет, то вывожу header("HTTP/1.1 404 Not Found"); Так оно и работает, но только если на сайте присутствуют все файлы, используемые на странице. А вот если на сайте нет какого-то файла, например картинки, то $_SERVER['REQUEST_URI'] помимо основного, выдает адреса недостающих файлов (один или несколько адресов). Например, /wowa/ /test.css /images/stydent03.jpg Здесь /wowa/ - это адрес в строке браузера. А /test.css /images/stydent03.jpg - это файлы, которые запрашиваются на /wowa/, но которых нет на сайте. И вот я не пойму, как мне в этом потоке "ухватить" первое значение (адрес страницы)? И как 404 выдать именно для него? А потом 404 выдать поочередно для каждого из двух других запросов. Ведь запросы браузер присылает мгновенно. Вот этот алгоритм нигде не описан.
С адресом/маской адреса должен ассоциироваться не только контент, но и программный обработчик, т.к. контент может быть разбросан по разным таблицам БД и т.п. Это суть роутинга. Базовый контент, который сам роутер выбирает, даже не обязателен. Такая фишка обычно только у БД-шных роутеров имеется. Без обид, но у вас какая-то каша получается. Статик-файлы часто присутствуют на том же сайте. Просто они отдаются, минуя единую точку входа, прямо Web-сервером. Вы только ссылки впихиваете в контент /wowa/ или формируете их (контент с ними) динамически. Если их действительно «нет на самом деле», то они выдаются (или не выдаются – 404) через единую точку входа в ответ на отдельные запросы. Т.е. для них должны быть свои роуты и т.п. --- Добавлено --- Для тех, кто в танке. Браузер делает так: GET /wowa/ потом смотрит ссылки в полученной странице и делает отдельные запросы по соотв. адресам: GET /test.css GET /images/stydent03.jpg Последние два запроса обычно обрабатываются, минуя единую точку входа, но могут обрабатываться и в ней. --- Добавлено --- Короче вот: Как сделать единую точку входа с ЧПУ? Там в комментах тоже обсуждали отдачу статика и т.п.
Это всё я уже понял. Вот как обработать все запросы на индексной странице? Какой алгоритм? (Статью по ссылке я уже читал)
Во-первых, это уже не индексная, а единая точка входа (фронт-контроллер). См. алгоритмы роутинга. Если вернуться к вашему текстовому файлу, то последовательный перебор и сравнение адресов с запуском контроллера/экшина при совпадении. С БД/ассоциативным массивом поиск будет работать гораздо быстрее, но принцип тот же: если нашли ключ, запустили контроллер/экшин, иначе 404. --- Добавлено --- https://gency.ru/comment/152 Там null вместо ключа – это ненахождение ключа, которое в итоге приводит к echo 404 Это если без использования регулярок в роутах и т.п. Т.е. когда поиск чисто по ключу выполняется. В быстрых роутерах поиск может сначала по ключу выполняться а потом уже дополнительно какая-то регулярка проверяться.
А если совсем по простому? Без контроллеров и корневых таблиц. Вот есть база данных и файл index.php. На этом файле $_SERVER['REQUEST_URI'] . Какой алгоритм обработки инфы, поступающей с $_SERVER ? Чтобы выдать посетителю правильную инфу и браузеру правильные отклики.
Так не бывает. «Корневая таблица» – это по сути таблица роутов. Контроллер – любой обработчик, хоть в файле. --- Добавлено --- Хотя можете switch (if/else if) использовать --- Добавлено --- Вместо контроллера в принципе можете прямо в фронт-контроллере содержимое какого-то поля из БД выводить, но как выше писал, фронт не только страницы выдает. Он может и картинки выдавать, обрабатывать POST-запросы и т.п. Т.е. если хотите что-то выдавать прямо фронтом, все равно нужна возможность запуска контроллера при опред. условиях.
У меня нет никакой таблицы роутеров, все без нее работает. И контроллеров тоже нет. Просто воспроизводятся записанные HTML коды контента. Пока так. Сейчас не в этом суть. Нужно просто понять, какой алгоритм обработки инфы с $_SERVER. Просто алгоритм. Вот запрос $_SERVER['REQUEST_URI'] выдал /wowa/. С ним понятно. Вот $_SERVER['REQUEST_URI'] выдал /images/stydent03.jpg Что с ним делать?
Уже два раза написал. Повторяю в третий: лучше, чтобы картинка выдавалась прямо Web-сервером, а не попадала в точку входа. Иначе нужно обрабатывать точно так же, как и любой др. запрос, только в ответ выдавать не страницу, а картинку. --- Добавлено --- Хотя можно и страницу: http://g09.ru/sexygirl.jpg
Она и выдается Web-сервером, если ее файл существует. Об ином и речи нет. А если $_SERVER['REQUEST_URI'] выдал /images/stydent03.jpg , то файла картинки на сайте нет. Я все время только об одном этом и спрашиваю.
Я об этом тоже писал. Можешь, например, сделать роут для /images/, контроллер которого будет уменьшать разрешение одноименных файлов-картинок, хранящихся где-то в другом месте (если оригиналы существуют, иначе – 404). --- Добавлено --- Или вот из бинарника растрового шрифта динамически делается картинка: http://g09.ru/sansfont.png
Вы все время пишете о чем-то другом. А вопрос очень прост и конкретен. Вот $_SERVER['REQUEST_URI'] выдал /images/stydent03.jpg Что с ним делать? Что выдать браузеру? Вот $_SERVER['REQUEST_URI'] выдал /test.css Что с ним делать? Что выдать браузеру? Вот $_SERVER['REQUEST_URI'] выдал /abc.klmn Что с ним делать? Что выдать браузеру? (если Вам это неизвестно, то сорри за настойчивость)
Mля, отвечаю по-простому. Что надо, то и выдавай! Если ничЁ не надо, то выдавай 404-ую! Understand?! --- Добавлено --- Что выдавать по этим адресам, я, конечно, не знаю. Вам виднее. А как, уже писал – примерно так же, как и страницы, но есть нюансы. Для этого и нужны контроллеры! Можно хоть по каждому отдельному адресу запускать оригинальную, не похожую на др., «подпрограмму».
Хотя чаще контроллер отвечает не за один адрес, а за группу адресов, например выше был пример, когда контроллер как мин. отвечает за всю ветку /images/, причем его же можно дополнительно «навесить» и на др. ветку. --- Добавлено --- Надеюсь, все понятно. Успехов.