Почему мой код .htaccess не работает идеально для красивых URL - PullRequest
Новая
       55

Почему мой код .htaccess не работает идеально для красивых URL

0 голосов
/ 27 января 2019

Я использую следующий код .htaccess для создания симпатичного URL. 

# code to make pretty URLS | we're using this code to achieve /category/slug
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^(.+)/([\w-]+)/([\w-]+)$ app/post.php?&category=$2&slug=$3 [L,QSA]
RewriteRule ^(.+)/([\w-]+)$ app/post.php?category=$2 [L]

Когда я print_r($_GET) я получаю следующий вывод

Мой параметр URL - http://www.exanple.com/usage-tips

Array ( [category] => usage-tips)

но в этой категории так много постов, поэтому мне также придется добавить страницу № из paginator.

Так что теперь мой параметр URL равен http://www.exanple.com/usage-tips/2

Array ( [category] => productivity [slug] => 2 )

print_r($_GET) показывает новый параметр с slug я хочу, чтобы этот параметр был page, потому что на основе этого я извлеку переменную и соответственно установлю paginator. Я не понимаю, как этого добиться.

Кроме того, есть еще одна проблема. Предположим, у меня есть 29 сообщений и на каждой странице я ограничил 6 сообщений.

В настоящее время я использую этот параметр URL www.example.com/?page=2, потому что, если я использую этот www.example.com/2, он будет рассматривать переменную 2 в категории

Может кто-нибудь помочь мне с логикой, где я ошибаюсь?

1 Ответ

0 голосов
/ 27 января 2019

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

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

Однако есть обходные пути. Вы можете изменить шаблон URL, используемый для этой нумерации страниц, на что-то вроде http://www.example.com/usage-tips/page/2, тогда легко сопоставить этот шаблон: 

RewriteEngine on

# http://www.example.com/usage-tips/page/2
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^/?(.+)/page/([\d]+)$ app/post.php?&category=$1&page=$2 [END,QSA]

# http://www.exanple.com/usage-tips/some-usage-tip
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^/?([\w-]+)/([\w-]+)$ app/post.php?category=$1&slug=$2 [END,QSA]

# http://www.exanple.com/usage-tips
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^/?([\w-]+)$ app/post.php?category=$1 [END,QSA]

Или, может быть, вы могли бы определить, что любой второй заданный аргумент, который содержит чисто числовое значение, должен рассматриваться как номер страницы, тогда как все остальное считается слагом: 

RewriteEngine on

# http://www.example.com/usage-tips/2
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^/?(.+)/([\d]+)$ app/post.php?&category=$1&page=$2 [END,QSA]

# http://www.exanple.com/usage-tips/some-usage-tip
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^/?([\w-]+)/([\w-]+)$ app/post.php?category=$1&slug=$2 [END,QSA]

# http://www.exanple.com/usage-tips
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^/?([\w-]+)$ app/post.php?category=$1 [END,QSA]

Эти измененные наборы правил также будут работать в конфигурации хоста http-серверов или внутри файла динамической конфигурации (файл ".htaccess").

Общее замечание по этому поводу: вам всегда следует размещать такие правила в конфигурации хоста http-серверов, а не использовать файлы динамической конфигурации (".htaccess"). Эти динамические конфигурационные файлы добавляют сложность, часто являются причиной неожиданного поведения, их трудно отладить, и они действительно замедляют работу http-сервера. Они предоставляются только в качестве последнего варианта для ситуаций, когда у вас нет доступа к реальной конфигурации хоста http-серверов (читай: действительно дешевые поставщики услуг) или для приложений, настаивающих на написании своих собственных правил (что является очевидным кошмаром безопасности).

...