I am building a blog-ish site using CI. I am using the HMVC plugin. The module that I am working in is "/journal".
The individual articles are accessed at /journal/article/ID/SLUG. This works fine, but I would like to shorten the URI to /journal/ID/SLUG using mod_rewrite.
Here are my rules:
RewriteEngine On
RewriteBase /
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^journal/([0-9]+)(.*)$ index.php?/journal/article/$1$2 [L,NC]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^(.*)$ index.php?/$1
For testing I am using /journal/2.
I know that the rules is matching. If, for instance, I change the redirect to http://google.com, I will indeed get redirected to Google. However, when using the rule as written it seems to be ignored and I get a 404 no matter what I put in.
Am I making some obvious (or arcane) error?
Edit: I figured this out shortly after posting the question. My rules are indeed correct but I need to change the following line in config/config.php:
$config['uri_protocol'] = 'AUTO';
to
$config['uri_protocol'] = 'PATH_INFO';
I won't claim to know exactly what that change does or why it fixes the issue. Perhaps someone can follow up with an explanation.
The $config['uri_protocol'] tells CI which $_SERVER superglobal to use to determine your apps URI. The 'PATH_INFO' option uses $_SERVER['PATH_INFO'] which is the URL request (without host portion), see php manual.
The 'AUTO' option is a CI thing to make suitable for different environments without config tweaks.
Personally, I have written a few PHP SEF controllers, I find it better to do all the processing with the PHP controller(s) scripts.
htaccess and rewrites can be tricky, harder to debug and one typo can kill the whole site (ouch). I am sure there are small performance gains, but one would need some pretty heavy demands. You are heading to your index.php controller anyway. I find happier code when it is all in one place ;-)
good luck with it...and hopefully I provided some insight to your issue.
Related
I can't get the following RewriteRule to work.
I have a PHP SQL query to display a web page. It requires a RewriteRule rule which I'm trying to achieve in a .htaccess file.
Here is the full URL at the moment.
www.example.com/category/sub-cat/page.php?art_url=a-page-of-mine
I can't get it to do
www.example.com/category/sub-cat/a-page-of-mine
My Code below:
Options +MultiViews
RewriteEngine On
RewriteCond %{REQUEST_FILENAME} !-d
RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule ^([^\.]+)$ $1.php [NC,L]
ErrorDocument 404 /error-404.php
#error 404
RewriteRule ^error/?$ error-404.php [NC,L]
RewriteRule ^category/sub-cat/(0-9a-zA-Z]+) category/sub-cat/page.php?art_url=$1 [NC,L]
Can someone help me out?
AS I said in the comments
Missing a few things here (0-9a-zA-Z]+) like [- as in ([-0-9a-zA-Z]+)
This is going to bite you too...
RewriteRule ^([^\.]+)$ $1.php [NC,L]
Match everything that doesn't have a dot and add .php to it with the [L] last flag. I would bet it will never pass that one in the first place.
Generally you want the more specific rules first, followed by the more generic ones last.
Also if I recall correctly the NC i no case, so you can get rid of the A-Z and just do [-a-z0-9]+
A better way
I try to avoid query string rewrites and rely on the URI method of rewriting common in MVC frameworks
example.com/index.php/category/sub-cat/a-page-of-mine
And then use a router and HTACCESS to only remove the index.php it's much simpler that way.
I have a pretty bare bones router on my GitHub page that shows how to route URL's like that.
https://github.com/ArtisticPhoenix/MISC/tree/master/Router
One big issue with messing with the query string is you can lose the ability to use $_GET the way it's designed to be used for things like search forms etc. So it's better to route not rewrite. Also the MVC way gives you a single entry point for all requests to go through which can make it easier to manage things like Constants, and Autoloaders....
Oh well, this is broken of course:
(0-9a-zA-Z]+)
The charclass lacks the opening [ and doesn't contain/match a literal - as well.
Right. To get this working I needed to add QSA as in [QSA,NC,L]. After how many weeks!!??
I recently installed MediaWiki 1.23.9 on a HostGator-hosted server (Apache-based I believe). I got it all configured and got pretty URLs up and running, got action URls also rewriting properly and everything was nice. I noticed, however, that anchor links, specifically the auto-generated section headers, aren't quite so pretty. They undergo "dot encoding" for some reason I'm not 100% sure on.
This results in /w/MyPage#Section_1_(Stuff_Here) becoming /w/MyPage#Section_1_.28Stuff_Here.29.
With parentheses being valid URI characters (and in fact, if used in a page title, they are properly not encoded in the URI), I don't understand why this is happening, nor how to stop it. I looked through all manner of bug reports and even tried glancing through the MediaWiki source. I found the function that performs the encoding, but as far as I can tell parentheses shouldn't be getting encoded.
My question is: Is there a way to prevent MediaWiki from encoding parentheses in section header anchors? Failing that, can I mask this behavior using .htaccess rules? For reference, my current .htaccess file is below, though I would very much prefer turning it off rather than masking it.
RewriteEngine On
RewriteCond %{DOCUMENT_ROOT}%{REQUEST_URI} !-f
RewriteCond %{DOCUMENT_ROOT}%{REQUEST_URI} !-d
RewriteRule ^(.*)$ %{DOCUMENT_ROOT}/w/index.php [L]
RewriteCond %{DOCUMENT_ROOT}%{REQUEST_URI} !-f
RewriteCond %{DOCUMENT_ROOT}%{REQUEST_URI} !-d
RewriteRule ^/?w/images/thumb/[0-9a-f]/[0-9a-f][0-9a-f]/([^/]+)/([0-9]+)px-.*$ %{DOCUMENT_ROOT}/w/thumb.php?f=$1&width=$2 [L,QSA,B]
RewriteCond %{DOCUMENT_ROOT}%{REQUEST_URI} !-f
RewriteCond %{DOCUMENT_ROOT}%{REQUEST_URI} !-d
RewriteRule ^/?w/images/thumb/archive/[0-9a-f]/[0-9a-f][0-9a-f]/([^/]+)/([0-9]+)px-.*$ %{DOCUMENT_ROOT}/w/thumb.php?f=$1&width=$2&archived=1 [L,QSA,B]
Note: This answer to a different question provides a quick explanation of what the "dot encoding" process is, though not how to exclude parentheses from it.
MediaWiki encodes section ids to honor HTML4 restrictions. This is a relic of the past as MediaWiki uses HTML5 these days, which removed those restrictions. You can set $wgExperimentalHtmlIds to true to make MediaWiki follow HTML5 rules (where only whitespace needs to be converted).
This is called "experimental" because at the time (the setting was introduced in 2010) browser support for HTML5 was somewhat unreliable. Today that's probably fine but no one actually tested that so use it at your own risk.
I'm configuring Expression Engine on Windows using IIS and have ISAPI v3 Rewrite installed.
It's partly working. The main site and subpages work but needs to be modified because some web page assets are stored in similarly named directories.
The recommended Rewrite provided by Ellislabs is this and I've modified it a little to work with our Win 2012 IIS 8 server:
RewriteEngine On
RewriteBase /
# Removes index.php from ExpressionEngine URLs
RewriteCond %{THE_REQUEST} ^GET.*index\.php [NC]
RewriteCond %{REQUEST_URI} !/system/.* [NC]
RewriteRule (.*?)index\.php/*(.*) abc/$1$2 [R=301,NE,L]
# Directs all EE web requests through the site index file
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^(.*)$ abc/index.php?/$1 [L]
For example, the URL http://oursite.example.com/abc works.
Subpages are mostly working and I suspect this applies to any page really but I'm noticing it on subpages. It removes index.php and mostly loads, such as http://oursite.example.com/abc/subdept/page/
However our developer has some assets kept in a server directory named /uploads/abc/ so if a page refers to this directory, it fails to load those assets because it contains the same name, "abc".
Thus, what is the best way to handle this?
I'm guessing I can either tell it to ignore "uploads/cls" or correct the current Rewrite so that it only looks at the first "abc". I'd like for the solution to cover most similar issues that would arise so I don't have to keep modifying it. We have 12 sites and I'll have to apply the solution to each one.
Everything I've tried hasn't worked.
Also, I thought !-f and !-d would tell it to ignore it if the file or directory existed and that doesn't seem to be working as I'd expect here because these images in /uploads/abc/ do exists.
Thanks!
--
Additionally just trying to get it to work at all, I tried adding a htaccess file with "RewriteEngine Off" in the /uploads/abc/ directory and that failed to fix it.
I also tried to add this after each comment and it fails to fix it:
RewriteCond %{REQUEST_URI} !^/excluded-folder/.*$
Seeing how both of the above attempts fail to fix it, I'm wondering if there could be something else going on. Any ideas?
My rewrite was fine. The problem turned out to be code within an Expression Engine template that the in house developer created. They updated the code and the images are loading fine now.
I'm still a bit fuzzy on the working of .htaccess, and I've looked around but I can't find anything to help this specific issue.
EDIT: I realize there are other questions that seem like they cover this issue, but I checked some and they didn't seem to offer any help I could understand, and I didn't want to hijack them with my own issues.
This is what I have:
Options +FollowSymLinks
#RewriteBase /
RewriteEngine on
RewriteRule /mp3/(.*) http://old.domain.com/mp3/$1 [R=301,L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^([^/]*)$ /index.php?p=$1 [L]
As you can see from the last line, the string typed after the server name is actually a URL parameter and depending on that parameter, different content is pulled from the database and that page is displayed on the site.
The problem I'm having is that the client has a content page called "podcast", so they would go to site.com/podcast which should quietly redirect to site.com/index.php?=podcast and load the content for that page. Unfortunately, the client also has a real site.com/podcast/ folder on their server. Because of this, the rewrite is ignored and the browser attempts to load that folder. It either shows a file listing or a forbidden error if I disable the listing.
After some research (I'm still new to htaccess), I learned that the two lines prior disable the rewrite if the path points to an actual file or folder. Unfortunately, commenting out the one with !-d doesn't seem to have any effect, and commenting out both gives me a server error.
Admittedly, part of the problem here was lack of foresight. URL rewrites should have been planned before everything else was put together, but it wasn't until the site was basically completed that I was notified that the client wants "Friendly URLs" that don't include the ?p= part. Regardless, perhaps there is a way to fix this.
Is there some .htaccess trickery I can use that will force the rewrite even if the URL entered points to a folder (not a specific file) that actually exists? As stated before, removing the !-d doesn't seem to help, although I'm not sure why. Perhaps I misunderstand its purpose.
Thank you for any help, and please be lenient with me if I overlooked something obvious. This is an issue presenting itself on the client's live site right now so I feel a little rushed in solving it. Thanks again.
OH YEAH, and the solution can't be specific to /podcast. The way the client's site is set up, when they want to create a new subpage for the site, a new name is saved for that content based on their title for the page and it is possible (unlikely, but still possible) that another page can be created with a name that matches an existing folder on the server.
Here is a note from mod_rewrite documentation:
By default, mod_rewrite will ignore URLs that map to a directory on
disk but lack a trailing slash, in the expectation that the mod_dir
module will issue the client with a redirect to the canonical URL with
a trailing slash.
This explains why mod_rewrite ignores the URL /podcast. I would suggest that you rename physical directories so that do do not (accidentally) match article names.
Another option would be to disable the DirectorySlash setting. This will prevent Apache from redirecting /podcast to /podcast/.
DirectorySlash Off
RewriteEngine On
RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule ^([^/]*)$ /index.php?p=$1 [L]
Be warned that disabling this setting has side effects. Read through the documentation first.
Change the following line of code:
RewriteRule ^([^/]*)$ /index.php?p=$1 [L]
to
RewriteRule ^(podcast([^?]*)) index.php?p=$1 [L,NC]
My .htacces begins with
RewriteEngine on
RewriteBase /
(I tried it also without RewriteBase...)
I tried all of the following rewriting rules to rewrite the URL
index.php?page=news
to
/blog
RewriteRule ^/?([-A-Za-z0-9]+)/([-A-Za-z0-9]+)/blog$
index.php?page=$1 [L]
RewriteRule ^([^/]*)/blog$ /sites/blog/index.php?page=$1 [L]
RewriteRule ([a-zA-z]+)/([a-zA-z]+)/blog$ index.php?page=$1 [L]
Nothing works - no error. Mod_rewrite is installed and working. I restarted Apache and MySQL everytime I changed something in my .htaccess.
I also want to change my URLs which looks like this... index.php?page=single_news&category=release&id=9&headline=Beastie%20Boys%20III
...into: blog/release/9-Beastie-Boys-III
I am lost. Hope you can help me.
First of all, upload your .htaccess and other files (whole project) to some working, ready hosting server. And check, if your rewriting works OK there. This will let you know, if this is problem with .htaccess or XAMPP itself. I had many strange problems with using .htaccess locally, under XAMPP, that were magically gone, after files were uploaded to Internet hosting.
For example, I don't have working autorization using .htaccess locally, because right after I provide correct login and password I see exactly the same error message as you mentioned. As for me, I'm more than sure that this problem is purely related to incorrect interpretation of .htaccess done by XAMPP (as everything works like a charm on production server), not by some mistakes in .htaccess contents.
I wasted (too) many hours on finding solution and left it. For right now, if I'm developing locally, I rename ".htaccess" to "htaccess", so it is ignored by XAMPP (Apache on-board of it) and re-enable it only when deploing files to production server. This approach maybe isn't to professional, but it saved me a lot of time and stress! :]
On the other hand, if your hosting also fail with the same symptoms, then you'll know, that this is not XAMPP releated problem and you have something wrong with your syntax.
Take a look here for a similar problem reported on StackOverflow.com, where (as I think) the cause is the same as in your issue.
Here's the solution to change links from http://www.domain.tld/index.php?page=blog to http://www.domain.tld/blog is:
RewriteEngine On
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^\w+$ index.php?page=$0 [L]
RewriteCond %{THE_REQUEST} index\.php
RewriteCond %{QUERY_STRING} ^page=(\w+)$
RewriteRule ^index\.php$ /%1? [R=301,L]
and for links like: http://www.domain.tld/index.php?page=single_news&id=1&headline=This%20Is%20A%Headline
the solution is:
RewriteRule ^blog/(\d+)-([\w-]+)$ index.php?page=single_news&id=$1&headline=$2
After using this code, links looks like this: http://www.domain.tld/blog/2-this-is-a-headline
For your first question, try this:
RewriteEngine on
RewriteRule ^/blog$ /index.php?page=news