ivan-lev

RewriteEngine ON только один раз должен в файле быть.

Сразу после него следующие строчки редиректов вставить.

Если просто добавить строчку

RewriteEngine ON

ошибка будет?

RewriteEngine on
RewriteRule ^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, попутно оптимизируя (в уме держим аптайм) - задача кхм-кхм.. специфичная.