RewriteEngine ON только один раз должен в файле быть.
Сразу после него следующие строчки редиректов вставить.
Если просто добавить строчку
RewriteEngine ON
ошибка будет?
RewriteEngine onRewriteRule ^11(\d\d)$ http://site1.ru/link/$1 [L]RewriteRule ^12(\d\d)$ http://site2.ru/link/$1 [L]RewriteRule ^13(\d\d)$ http://site3.ru/link/$1 [L]
Количество правил по количеству сайтов..
Если URL-ы отличаются - оставить одну, для остальных прописать 301 редирект
RewriteEngine on RewriteRule (.*)/([^/]+)\.(\w+) index.php?path=$1&page=$2&ext=$3 [L]
http://site.ru/ban/bamn/banhdn/hndfh.htmn
Array ( [path] => ban/bamn/banhdn [page] => hndfh [ext] => htmn )
А зачем разбирать в .htaccess, если в php $_SERVER['REQUEST_URI'] есть?
p.s. Если не будет расширения - правило не сработает.. если не будет пути - тоже.. ;)
А можно подробностей?
Вопрос был про возможность ajax-обращения... Для чего -
Случай уникальной информации совсем не рассматривался...
Теоретически, если исходить из того, что в результате выдачи заранее известное количество (10, к примеру) "повторяющихся" (с некоторыми отличиями) участков, которые обязательно содержат определённую информацию (№ позиции, Title, URL, сниппет), задача решаема. Однако, для конкретного случая - соглашусь с Леонидом - проще раз в год подправить регулярку..
Любой десктопный (delphi, c++ builder/.net и тд) парсер, в котором используется компонент "веб-браузер" (или аналогичный) выполнит любой js,ajax-запрос и может даже мышкой поводить. :)
Кроме того, есть скрипты для браузеров (вроде обезьянки для файрфокса) и для ОС (AutoIt, к примеру). Да, часть парсеров на такой проверке отвалится... Однако, если "ну очень надо будет" - разобраться с логикой ajax-запроса (в любом случае, код доступен) и curl-ом отправить можно и из консольки/скрипта...
melkozaur, вообще, кучу флэш-сайтов видел на DLE.
Сказал бы, что для связки (категория+статья+пагинация и даже + тэги) WP и джумлы более чем достаточно, но, видимо "более" не нужно :)
Таксономия Друпала также со всем этим справится... но, опять же, с "простотой" прокол
А как она включается? и где? И вообще, смысл строчек вышеприведённого конфига точно понятен?
SQL_CALC_FOUND_ROWS не всегда даёт ощутимый выигрыш, а чаще наоборот (см комментарии к статье по ссылке).
pupseg, что за движок-то (можно в личку, если инфа "неДляВсех"). И судя по
Если тормоза в поиске (и не получается решить администрированием) - имеет смысл вынести на сфинкс, как уже упоминали.. По остальной оптимизации - на мой взгляд, правильнее идти "от нагрузки", т.к. анализ (насколько глубокий?) всего кода - это долго/дорого.
Оно вообще (для СУБД) так называется.. и делается обычно на уровне администрирования БД
p.s. Переписать движок на 5.4, попутно оптимизируя (в уме держим аптайм) - задача кхм-кхм.. специфичная.
