php.htaccessfriendly-urlpretty-urls

Why is my .htaccess code not working perfectly for pretty URL


I am using the following .htaccess code to make pretty 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]

When i print_r($_GET) i get the below output

My URL parameter is http://www.exanple.com/usage-tips

Array ( [category] => usage-tips)

but there are so many posts under this category so I'll also have to add page no from paginator.

So now My URL parameter is http://www.exanple.com/usage-tips/2

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

The print_r($_GET) shows a new parameter with slug i want that parameter to be page because based on this I'll extract the variable and set the paginator accordingly. I'm not getting how to achieve it.

Also, there's one more issue. Suppose I have 29 posts and on every page, I have limited 6 posts.

I am currently using this URL parameter www.example.com/?page=2 because if I use this www.example.com/2 then it will consider the variable 2 into the category

Can someone help me here with logic, where am i going wrong?


Solution

  • Your issue is that there is no information given whether that second argument is meant as a page number or as a slug. Without information there is no way to tell, nothing your can directly do about by implementing rewriting rules.

    Also you appear to have a one-off issue with the capture count, but that might be the result of some simplification of your example posted here, so I will fix it for the specific example here but not make more comments about that. You will need to adapt the given solution for your (probably different) situation in real life.

    There are workarounds, though. You could change the URL pattern used for that pagination to something like http://www.example.com/usage-tips/page/2, then it is easy to match that pattern:

    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]
    

    Or, maybe you could define that any second argument given that holds a pure numeric value is to be considered a page number whilst everything else is considered a slug:

    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]
    

    These modified rule sets will work likewise in the http servers host configuration or inside a dynamic configuration file (".htaccess" file).

    A general remark about this: you should always prefer to place such rules in the http servers host configuration instead of using dynamic configuration files (".htaccess"). Those dynamic configuration files add complexity, are often a cause of unexpected behavior, hard to debug and they really slow down the http server. They are only provided as a last option for situations where you do not have access to the real http servers host configuration (read: really cheap service providers) or for applications insisting on writing their own rules (which is an obvious security nightmare).