Skinnable-cacheable

Придумал неболшую идею. Наверняка не я первый.

Идея заключается в том, что страницы кэшируется. Но при этом хочется сделать их Skinnable. То есть чтобы можно было «шкурки» менять. Как кэшировать в таком случае — не совсем понятно.

Простой и забавный (полу)выход. Везде в документах пишем и документы, естественно, кэшируем полностью. И выдаем кэш. А вот css.php — нет, не кешируем и выдаем в нем нужную css-ку в зависимости от содержимого cookies-ов.

ЧПУ и PHP (revisited)

ЧПУ — это термин, придуманный командой НовоКиберска, обозначает он «Человекопонятный УРЛ». Термин нигде широко не употреблялся, пока я не написал 5 сентября 2000 года заметку «ЧПУ и PHP». За эти три года термин довольно неплохо раскрутился.

За эти годы очень многие ссылались на эту заметку, поэтому я взял на себя труд переписать ее, добавив еще несколько способов сделать ЧПУ и убрав всякий мусор. Итак...

В принципе, ничего нового и оригинального в идее понятного УРЛа нет. Про это писал и Лебедев, и другие товарищи. Вообще, мне всегда нравились УРЛы такого, например, вида: php.resourceindex.com/Complete_Scripts/Guestbooks/

Итак, как это сделать в домашних условиях?

Способ раз

Вообще, самая первая мысль — это создавать для каждой заметки поддиректорию с соответствующим именем и помещать в нее index.html, то есть сделать так, чтобы по адресу spectator.ru/technology/php/user_friendly_urls лежал бы реальный файл. Разумеется, так дело не пойдет.

Способ два

Думаем дальше. Раз страница не существует, то она выдает 404. Так что вторая идея — прописать в фале .htaccess страницу, которая будет выдаваться при ошибке 404, а уже эта страница будет смотреть на текущий УРЛ и выдавать нужный документ

То есть, в .htaccess пишем:


------------------------------------
ErrorDocument 404 /index.php3
ErrorDocument 401 /index.php3
------------------------------------


Пользователь набирает spectator.ru/technology/php/user_friendly_urls, такая страница не найдена, и загружается файл index.php3. Дальше — все просто. Переменная $REQUEST_URI дает нам адрес вызываемой страницы (в данном случае это будет /technology/php/user_friendly_urls), вывести на экран соответствующий документ — дело техники.

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

Итого: прописываем в .htaccess страницу, которая, собственно, за все отвечает (у меня это index.php3). В этой странице пишем php-скрипт, который работает с $REQUEST_URI, шлет заголовок «http/1.0 200 Ok» и отображает то, что надо.

Плюсы: Очень простой способ. Работает почти везде.
Минусы: При таком способе нельзя постить содержимое формы на несуществующие псевдоурлы. И если в Апаче ведется лог 404-ых ошибок, то он будет забит.

Способ три

Для этих (и не только) целей есть специальный модуль в Апаче, который называется mod_rewrite. Он позволяет «переписывывать урлы», то есть, преобразовывать их «на лету» по правилам, которые вы ему опишите.

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

Module mod_rewrite URL Rewriting Engine.
A Users Guide to URL Rewriting with the Apache Webserver.
Модуль Apache mod_rewrite.
Mod_rewrite для чайников.

Плюсы: Очень мощный способ.
Минусы: Может не хватить мозгов. На хостинге может быть не установлен этот модуль.

Способ четыре

Основан на директиве FilesMatch, которая в Апаче является core feature. Все просто. Пишем опять же в .htaccess

Action throw /index.php


ForceType throw



ForceType application/x-httpd-php


После этого все УРЛы, которые подпадают под условие «^([^.]+)$», (то есть все урлы, в которых не содержится точка) будут передаваться на index.php. Вы можете написать свое условие, разумеется.

Подробности: тут, тут или тут.

Плюсы: Простой и удобный способ.
Минусы: Говорят, что для того, чтобы ForceType работал, php должен быть подключен к апачу в виде модуля. Если php вызывается, как обыкновенный CGI — ForceType работать не будет.

Save changes?

Вот еще идея: есть админский интерфейс — или любая форма — и в ней есть Критичные Поля (КП). После того, как содержание КП изменилось (т.е. было отредактировано) пользователь не может уйти со страницы по любой ссылке, потому что выскакивает диалог «Вы не сохранили изменения. Действительно хотите уйти отсюда?».

А то у многих такая проблема: либо при редактировании случайно уходишь по ссылке, либо забываешь — постил ты изменения или не постил.

Народ уже вовсю обсуждает. Я представляю, как это сделать, но в javascript я совсем не программирую.

Картинки возвращаются-2

«When using a normal web server setup, images should be stored as files. That is, store only a file reference in the database. The main reason for this is that a normal web server is much better at caching files than database contents. So it it’s much easier to get a fast system if you are using files». (С) Официальная документация MySql, «5.2.12 Other Optimisation Tips».

Господа, вы, извините, заебали... удивляете своей тупостью и особенно — упрямством. Когда с вами спорят, должно же хотя бы закрасться подозрение, что вы не правы, или нет?.. Не надо говорить всякие вещи, которые вы не понимаете, про «а вот ext2fs занимает столько-то, а MySql — это три файла» и прочее. И не надо говорить, что 10000 файлов не кэшируется, а если это запихать все в одну базу данных — оно сразу же отчего-то начнет кешироваться. Следуя вашей логике, нужно завести Специальную Базу Данных и хранить все маленькие файлы именно в ней, одним файлом — чтобы рабтало все быстрей. Ну так заведите ее на своем компьютере. И вообще, не храните у себя много файлов — система будет тормозить. Точно говорю.

Перечитайте еще раз главу пять (MySQL Optimisation) и плюс к этому механизм работы BLOB’ов — чтобы понять, какие они тормозные.

PS. Тесты MySql vs Files