Назад | Перейти на главную страницу

как удалить расширение .php с помощью htaccess на хостинге godaddy linux

Как удалить .php расширение с использованием .htaccess файл. Я пробовал много примеров безуспешно. Регулярно появляется внутренняя ошибка сервера. Я использую хостинг Godaddy Linux.

Это последний код, который я использую.

<IfModule mod_rewrite.c> 
     Options All -Indexes 
     Options +FollowSymLinks -MultiViews 
     RewriteEngine On 
     RewriteBase /

     # Unless directory, remove trailing slash 
     RewriteCond %{REQUEST_FILENAME} !-d 
     RewriteRule ^([^/]+)/$ http://a.sprybirds.com/$1 [R=301,L] 

     # Redirect external .php requests to extensionless url 
     RewriteCond %{THE_REQUEST} ^(.+)\.php([#?][^\ ]*)?\ HTTP/ 
     RewriteRule ^(.+)\.php$ http://a.sprybirds.com/$1 [R=301,L] 

     # Resolve .php file for extensionless php urls 
     RewriteRule ^([^/.]+)$ $1.php [L]
</IfModule>

Сайт припаркован на субдомене http://subdomain.example.com и последовательность папок такая же, как web-root/sub_folder/site_folder/.

У вас есть файл .htaccess в ./public_html/? Если да, то что внутри? Принцип работы .htaccess заключается в предоставлении директории, ближайшей к фактическому корневому каталогу, наивысшим приоритетом.

Например:

/home/username/public_html/.htaccess

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

/home/username/public_html/sub_directory/.htaccess

Если ты первичный .htaccess файл устанавливает правила в одну сторону, а подкаталог устанавливает их в другом, возможно, вы столкнетесь с проблемами (т.е. с ошибкой).

Если вы настроены в своем фактическом корневом веб-каталоге, следующие строки могут вызывать некоторые проблемы, поскольку cPanel позволяет администраторам сервера устанавливать эти параметры по умолчанию из WHM. Если они уже установлены (в частности, -Indexes), вы, скорее всего, увидите ошибку.

Options All -Indexes
Options +FollowSymLinks -MultiViews

Заметка: The -Indexes Директива обычно устанавливается по умолчанию еще до того, как клиенты помещаются на сервер (или это должно быть, если нет особой причины не делать этого), к вашему сведению. Это скорее рекомендация по безопасности для предотвращения просмотра каталогов, поскольку не каждый клиент узнает об этом, если нет index.[ext] файл в каждом каталоге, их каталоги широко открыты для просмотра любым желающим.

Если их удаление устраняет ошибку, значит, вы нашли проблему :). Если удаление этих строк не помогает, нам нужно начать с проб и ошибок.

Вернитесь к началу и посмотрите каталоги, расположенные над каталогом, с которым у вас возникли проблемы. Проверьте файлы .htaccess и убедитесь, что у вас установлен флажок «отображать или показывать скрытые файлы» или установлен на «да» в программе S / FTP, которую вы используете, поскольку они не всегда видны по умолчанию.

Отсюда лучше всего будет создать резервную копию каждого файла .htaccess и повторно добавить их один за другим, пока вы не столкнетесь с другой ошибкой. Таким образом, вы можете отметить, какой файл при загрузке вызвала ошибку, и мы сможем проверить это.

Обновление # 01

Поскольку виновником ошибки, скорее всего, действительно был -Indexes, вы можете добавить следующее обратно в .htaccess файл:

Options +FollowSymLinks -MultiViews

Если это не решает ошибку 404, попробуйте следующее:

Options +FollowSymLinks -MultiViews
RewriteEngine On
RewriteBase /

# Adds Trailing Slash to the URI as long as it's not for a
# file.
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_URI} !(\.[a-zA-Z0-9]{1,5}|/|#(.*))$
RewriteRule ^(.*)$ http://subdomain.example.com/$1/ [R=301,L]

# Checks to make sure the request is a directory.
# Checks to see if the request matches a file with a .php ext.
# If all is well, push the request through to the matching file.
RewriteCond %{REQUEST_FILENAME} !-d
RewriteCond %{REQUEST_FILENAME}\.php -f
RewriteRule ^([^\.]+)/$ http://subdomain.example.com/$1.php

В вопросе отсутствуют примеры URL-адресов, что действительно важно для диагностики таких проблем, однако ...

# Resolve .php file for extensionless php urls 
RewriteRule ^([^/.]+)$ $1.php [L]

Это соответствует только URL-адресам с сегментами одного пути, т.е. URL-адреса, которые фактически находятся в корне документа, например. /foo. Он не будет соответствовать URL-адресам с несколькими сегментами пути, т.е. URL-адреса, которые фактически находятся в подкаталогах, например. /foo/bar - что объясняет, почему вы получаете ошибку 404 для «файлов php внутри подпапки».

Вам нужно убрать косую черту в RewriteRule шаблон, чтобы соответствовать любой глубине URL:

RewriteRule ^([^.]+)$ $1.php [L]

Включая косую черту в класс отрицательных символов, вы сопоставляете только те URL, которые не содержат косой черты. т.е. Только URL-адреса в корне документа.

(Нет необходимости обратная косая черта экранировать буквальную точку при использовании внутри класса символов.)