Убрать окончание /index.php

Здравствуйте! Столкнулся с такой проблемой на сайте с Joomla после его доменного имени сразу везде идет строка /index.php как её убрать? А то очень не удобно смотрятся ссылки и главную страницу гугл скушал вместе с таким окончанием. Заранее спасибо.

Попробуйте добавить в конфигурацию Апач (если Ваш сайт работает под Апач) команды:

Options +Indexes             # Если режим Indexes не включен ранее

DirectoryIndex index.php

Извиняюсь за тупой вопрос, но где это добавлять? Гдето-то в DirectAdmin?

Создайте файл .htaccess и впишите туда

Создайте файл .htaccess и в нем напишите:

DirectoryIndex /index.php

Файл положите в корень сайта

Всеравно бестолку...

Человек о чпу говорит похоже...

Ну да.

Цитата ("CoolHeart"):

Всеравно бестолку...

Вы как именно это проверяли?

В .htaccess:

RewriteEngine On

RewriteRule ^index.php$		/        

Ну, и потом ссылки везде исправить.
И настроить Джумлу, чтобы она без index.php ссылки генерировала (если это возможно)

Цитата ("sukebe"):

В .htaccess:

RewriteRule ^index.php$		/        

"" - и клиенты с медленным каналом ждут в два раза дольше пока страница загрузится. А еще входящий трафик удваиваем и хитов в два раза больше становится. А потом, когда посетителей станет побольше, будем жаловаться, что сайт "лежит" или "сайт ддосят". Но если нас это не смущает, то решение, безусловно, хорошее. Можно даже RedirectMatch использовать - оно и работать побыстрее будет. Не забудьте только, что вместо "/" после "^index.php$" надо писать полный URI сайта: http://ваш.дом.ен/ иначе "не сработает".

Цитата ("Demiurh"):

Demiurh

Немного ошибся тогда. Вобщем все норм работает, спасибо.

В джумле в настройках "Сайт"-"Общие настройки"-"Установки Search Engine Optimization" везде установить "да" и перейменовать файл htaccess.txt в .htaccess

Цитата ("Illarion_SA"):

Цитата ("sukebe"):

В .htaccess:

RewriteRule ^index.php$		/        

"" - и клиенты с медленным каналом ждут в два раза дольше пока страница загрузится. А еще входящий трафик удваиваем и хитов в два раза больше становится.

С чего бы это?

Цитата:

А потом, когда посетителей станет побольше, будем жаловаться, что сайт "лежит" или "сайт ддосят". Но если нас это не смущает, то решение, безусловно, хорошее.

????
Цитата:

Можно даже RedirectMatch использовать - оно и работать побыстрее будет.

С RedirectMatch, к сожалению, не получится.
Через RedirectMatch, имхо, не получится - получится бесконечный цикл, т.к. для веб-сервера это будет выглядеть так:
/index.php -> -> / -> -> /index.php -> -> / -> -> ...


Цитата:

Не забудьте только, что вместо "/" после "^index.php$" надо писать полный URI сайта: http://ваш.дом.ен/ иначе "не сработает".

Это актуально только для RedirectMatch, который в данном случае, как я написал выше, работать не будет.

Цитата:

В джумле в настройках "Сайт"-"Общие настройки"-"Установки Search Engine Optimization" везде установить "да" и перейменовать файл htaccess.txt в .htaccess

да!

Цитата ("sukebe"):

Цитата ("Illarion_SA"):

"" - и клиенты с медленным каналом ждут в два раза дольше пока страница загрузится. А еще входящий трафик удваиваем и хитов в два раза больше становится.

С чего бы это?

Это просто. Модификатор "R" заставляет mod_rewrite выдать браузеру клиента ответ перенаправляющий браузер на другой URI. Давайте вспомним как это работает: когда сервер выдает ответ-перенаправление, браузеру клиента возвращается обычный набор заголовков с заголовком перенаправления и текст что-то вроде "302 moved temporarily http://новое.uri" (не помню текст ответа дословно, за точность ручаться не могу). Получивши такой ответ, браузер клиента формирует новый запрос с адресом http://новое.uri и посылает его на сервер (сервер может быть или тем же или другим). Получив этот запрос, сервер обрабатывает его обычным образом. Очевидно, что при использовании редиректов, браузер клиента должен вместо одного открыть два соединения (если не используется pipelining), разместить два запроса и дождаться два ответа (пользователи с медленным каналом замечают это сразу же), сервер, также, должен принять два запроса вместо одного (длина одного запроса 200-400 байт) и конечно, сервер должен обработать эти два запроса, т.е. запустить обработчик, прочитать любимый в народе .htaccess, сформировать заголовки ответа, сформировать запись в логе и т.д.

Цитата ("sukebe"):

Цитата:

А потом, когда посетителей станет побольше, будем жаловаться, что сайт "лежит" или "сайт ддосят". Но если нас это не смущает, то решение, безусловно, хорошее.

????

Это просто. Предположим, обработка одного редиректа занимает 50 мсек. - разумеется, это немного. Теперь, представим себе, что популярность нашего сайта достигла 1 миллиона хитов в сутки, в этом случае на обработку редиректов уйдет 50000 сек. или 13.9 часов - из 24-х часов имеющихся в одних сутках, т.е. для того, чтобы обслужить 1 миллион запросов/сутки уже придется ставить два сервера вместо одного. Возможно, 50 мсек на один редирект это слишком много, но не будем забывать, что когда сервер обрабатывает один редирект, обработка остальных запросов немного замедляется, что в свою очередь замедляет обработку очередного редиректа. Когда количество запросов в единицу времени превышает некоторый критический уровень, процесс замедления принимает лавинообразный характер и сервер коллапсирует. При коллапсе сервера, количество входящих запросов падает (пользователи уходят на другие сайты), через некоторое время сервер "оживает". Коллапс сервера развивается за несколько секунд, неопытный администратор обычно говорит, что сервер "почему-то лег" или "это атака DDoS", начинаются звонки провайдерам, пишутся письма, открываются проекты на этом сайте и т.д.

Цитата ("sukebe"):

Цитата:

Можно даже RedirectMatch использовать - оно и работать побыстрее будет.

С RedirectMatch, к сожалению, не получится.
Через RedirectMatch, имхо, не получится - получится бесконечный цикл, т.к. для веб-сервера это будет выглядеть так:
/index.php -> -> / -> -> /index.php -> -> / -> -> ...

Да, Вы правы - зациклится, если DirectoryIndex установлен как /index.php. Если в качестве DirectoryIndex прописан другой файл, то работать будет.

Цитата ("sukebe"):

Цитата:

Не забудьте только, что вместо "/" после "^index.php$" надо писать полный URI сайта: http://ваш.дом.ен/ иначе "не сработает".

Это актуально только для RedirectMatch, который в данном случае, как я написал выше, работать не будет.

RedirectMatch обрабатывается Апачем и браузером точно также как и модификатор "R" в RewriteRule (см. выше механизм обработки редиректов), требование чтобы в параметре редиректа, будь то "R" или директива Redirect, использовался полный URI связано с тем, что ответ-редирект обрабатывается браузером независимо от предыдущего запроса (так, как будто новый адрес был напечатан в строке URL браузера) и обычные правила умолчаний здесь не действуют. В дополнение, процитирую руководство Апач, описание модификатора "R" директивы RewriteRule:
Цитата:

'redirect|R ' (force redirect)
Prefix Substitution with http://thishost/ (which makes the new URL a URI) to force a external redirection. If no code is given a HTTP response of 302 (MOVED TEMPORARILY) is used. If you want to use other response codes in the range 300-400 just specify them as a number or use one of the following symbolic names: temp (default), permanent, seeother. Use it for rules which should canonicalize the URL and give it back to the client, e.g., translate ``/~'' into ``/u/'' or always append a slash to /u/user, etc.

Note: When you use this flag, make sure that the substitution field is a valid URL! If not, you are redirecting to an invalid location! And remember that this flag itself only prefixes the URL with http://thishost/, rewriting continues. Usually you also want to stop and do the redirection immediately. To stop the rewriting you also have to provide the 'L' flag.

Цитата ("Illarion_SA"):

Цитата ("sukebe"):

Цитата ("Illarion_SA"):

"" - и клиенты с медленным каналом ждут в два раза дольше пока страница загрузится. А еще входящий трафик удваиваем и хитов в два раза больше становится.

С чего бы это?

Это просто. Модификатор "R" заставляет mod_rewrite выдать браузеру клиента ответ перенаправляющий браузер на другой URI. Давайте вспомним как это работает: когда сервер выдает ответ-перенаправление, браузеру клиента возвращается обычный набор заголовков с заголовком перенаправления и текст что-то вроде "302 moved temporarily http://новое.uri" (не помню текст ответа дословно, за точность ручаться не могу). Получивши такой ответ, браузер клиента формирует новый запрос с адресом http://новое.uri и посылает его на сервер (сервер может быть или тем же или другим). Получив этот запрос, сервер обрабатывает его обычным образом. Очевидно, что при использовании редиректов, браузер клиента должен вместо одного открыть два соединения (если не используется pipelining), разместить два запроса и дождаться два ответа (пользователи с медленным каналом замечают это сразу же), сервер, также, должен принять два запроса вместо одного (длина одного запроса 200-400 байт) и конечно, сервер должен обработать эти два запроса, т.е. запустить обработчик, прочитать любимый в народе .htaccess, сформировать заголовки ответа, сформировать запись в логе и т.д.

Это все верно. Но утверждение об увеличении в 2 раза времени загрузки страниц и входящего трафика не верно.
Увеличивается в 2 раза время с момента запроса страницы до начала работы скрипта, а это - ерунда по сравнению с временем передачи сгенерированной страницы и даже со временем, за которое ее сгенерирует скрипт.
Входящий трафик тоже увеличится далеко не в 2 раза - я почти уверен, что на каждый запрос страницы (index.php) приходится несколько запросов к сопутствующим файлам - css/js/картинки/флэш.

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

Цитата ("Illarion_SA"):

Цитата ("sukebe"):

Цитата:

А потом, когда посетителей станет побольше, будем жаловаться, что сайт "лежит" или "сайт ддосят". Но если нас это не смущает, то решение, безусловно, хорошее.

????

Это просто. Предположим, обработка одного редиректа занимает 50 мсек. - разумеется, это немного. Теперь, представим себе, что популярность нашего сайта достигла 1 миллиона хитов в сутки...

Дальше можно было не читать (но я прочитал).
Какой сайт на Джумле, да еще и работающий на одном сервере, выдержит миллион хитов в сутки?

Пусть мы имеем миллион хитов в сутки. Предположим, что сервер обрабатывает запрос и генерирует страницу за 100 мсек (для нестатического некешированного контента это, имхо, шоколадно). Пользуясь Вашим расчетом, получаем, что в сутки сервер будет работать над генерацией страниц примерно 28 часов.

Цитата ("Illarion_SA"):

RedirectMatch обрабатывается Апачем и браузером точно также как и модификатор "R" в RewriteRule (см. выше механизм обработки редиректов), требование чтобы в параметре редиректа, будь то "R" или директива Redirect, использовался полный URI связано с тем, что ответ-редирект обрабатывается браузером независимо от предыдущего запроса (так, как будто новый адрес был напечатан в строке URL браузера) и обычные правила умолчаний здесь не действуют.

Это не так. При использовании мод_рерайта, независимо от наличия модификатора "R", указывать полный адрес необязательно.

Цитата ("Illarion_SA"):

В дополнение, процитирую руководство Апач, описание модификатора "R" директивы RewriteRule:
Цитата:

And remember that this flag itself only prefixes the URL with http://thishost/, rewriting continues

Вот ключевой момент в цитате из документации.
Соответственно, к моему варианту .htaccess надо только L добавить. А не хост/протокол/порт, как Вы предлагаете. За нас это сделает сам сервер (благодаря директиве R).