.htaccess (yet another post)
Permalink 3 users found helpful
There are many posts with htaccess problems. I added pretty urls and yes got the file not found error. Thanks to Nglyabonga in a forum post I got the answer that worked for me.
I just want to add another perspective and give a .htaccess write-up I did during troubleshooting. The perspective is that some comments talked about changing a core (/concrete) file. Never a good idea! But there is always the "you gotta do what you gotta do" rule.
Fortunately I added a line to site.php as suggested by Nglyabonga. The line is: define('SERVER_PATH_VARIABLE', 'REDIRECT_URL'); That line worked for my Host Provider. But I want to share my research too. This is what I learned trying to understand the pretty urls code. Sorry if it is a bit long winded but it may be helpful to others that face .htaccess problems!
OK here is the Concrete5 pretty URL code. I'm not a .htaccess expert but I did research this on the internet and this is what I found.
# -- concrete5 urls start --
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /c5/
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^(.*)$ index.php/$1 [L]
</IfModule>
# -- concrete5 urls end –
Lets just break this down:
These lines are required to use the rewrite engine. The first line is not provided by concrete5 code but in some cases may be required. Your Host Provider may block the use of “Options +FollowSymlinks” but if the rewrite rule doesn't appear to work it is worth a try. Here is the downside - you get a server 500 error if your Host Provider has blocked the use of that line of code.
Options +FollowSymlinks
RewriteEngine On
RewriteBase /c5/ will be specific to your install. If you installed to the root of your server the line would look like RewriteBase /
note: I left a period off the end of that sentence because the line would not have a period in .htaccess.
These lines are tricky:
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
To begin with the RewriteCond is a condition for the following RewriteRule (there can be many conditions).
Next the %{REQUEST_FILENAME} is a server variable which is pretty obvious what the variable means.
Then comes the tricky part. The !-f and the !-d. The -f means filename and the -d means directory name and the ! means negative assertion. I searched around the internet to find this answer:
RewriteCond %{REQUEST_FILENAME} !-d
If the request is for a real directory (one that exists on the server), index.php isn't served.
RewriteCond %{REQUEST_FILENAME} !-f
If the request is for a file that exists already on the server, index.php isn't served.
Finally there is the Rewrite Rule that can be thought of as an equation. Rule$ New-Rule. If that is confusing just ignore it because it is just my way of looking at the structure of the line -
RewriteRule ^(.*)$ index.php/$1 [L]
The ^(.*)$ is very specific. It is Perl Regular Expression or PCRE which you can read about online. The upper carrot ^ means the beginning of the string. Be careful because [^] has a different meaning in PCRE. Inside the brackets it is like a ! or negative sign. Just remember that here it means the beginning of the string because there are no brackets. The ( ) just contain the string and yes the dot or period is significant. It means “any character except newline”. The * means “all the characters in the string” so it essentially says whatever length of the string. And the $ ends the string. You need a space before the next part of the equation:
index.php/$1
That replaces the string with index.php/$1
The $1 is the variable for the %{REQUEST_FILENAME}
And the very last [L] means last rule so it ends the rules. Another common flag is [NC] which means ignore case. You can combine flags so [L, NC] would be a valid set of flags.
Here is a good link to look at for more neat tricks: http://corz.org/serv/tricks/htaccess2.php...
I hope this helps some of you that struggle with these problems. Apparently, each Host Provider presents different capabilities for .htaccess. That's a bummer. So if all else fails ask your host provider for advice too!!!!
I just want to add another perspective and give a .htaccess write-up I did during troubleshooting. The perspective is that some comments talked about changing a core (/concrete) file. Never a good idea! But there is always the "you gotta do what you gotta do" rule.
Fortunately I added a line to site.php as suggested by Nglyabonga. The line is: define('SERVER_PATH_VARIABLE', 'REDIRECT_URL'); That line worked for my Host Provider. But I want to share my research too. This is what I learned trying to understand the pretty urls code. Sorry if it is a bit long winded but it may be helpful to others that face .htaccess problems!
OK here is the Concrete5 pretty URL code. I'm not a .htaccess expert but I did research this on the internet and this is what I found.
# -- concrete5 urls start --
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /c5/
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^(.*)$ index.php/$1 [L]
</IfModule>
# -- concrete5 urls end –
Lets just break this down:
These lines are required to use the rewrite engine. The first line is not provided by concrete5 code but in some cases may be required. Your Host Provider may block the use of “Options +FollowSymlinks” but if the rewrite rule doesn't appear to work it is worth a try. Here is the downside - you get a server 500 error if your Host Provider has blocked the use of that line of code.
Options +FollowSymlinks
RewriteEngine On
RewriteBase /c5/ will be specific to your install. If you installed to the root of your server the line would look like RewriteBase /
note: I left a period off the end of that sentence because the line would not have a period in .htaccess.
These lines are tricky:
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
To begin with the RewriteCond is a condition for the following RewriteRule (there can be many conditions).
Next the %{REQUEST_FILENAME} is a server variable which is pretty obvious what the variable means.
Then comes the tricky part. The !-f and the !-d. The -f means filename and the -d means directory name and the ! means negative assertion. I searched around the internet to find this answer:
RewriteCond %{REQUEST_FILENAME} !-d
If the request is for a real directory (one that exists on the server), index.php isn't served.
RewriteCond %{REQUEST_FILENAME} !-f
If the request is for a file that exists already on the server, index.php isn't served.
Finally there is the Rewrite Rule that can be thought of as an equation. Rule$ New-Rule. If that is confusing just ignore it because it is just my way of looking at the structure of the line -
RewriteRule ^(.*)$ index.php/$1 [L]
The ^(.*)$ is very specific. It is Perl Regular Expression or PCRE which you can read about online. The upper carrot ^ means the beginning of the string. Be careful because [^] has a different meaning in PCRE. Inside the brackets it is like a ! or negative sign. Just remember that here it means the beginning of the string because there are no brackets. The ( ) just contain the string and yes the dot or period is significant. It means “any character except newline”. The * means “all the characters in the string” so it essentially says whatever length of the string. And the $ ends the string. You need a space before the next part of the equation:
index.php/$1
That replaces the string with index.php/$1
The $1 is the variable for the %{REQUEST_FILENAME}
And the very last [L] means last rule so it ends the rules. Another common flag is [NC] which means ignore case. You can combine flags so [L, NC] would be a valid set of flags.
Here is a good link to look at for more neat tricks: http://corz.org/serv/tricks/htaccess2.php...
I hope this helps some of you that struggle with these problems. Apparently, each Host Provider presents different capabilities for .htaccess. That's a bummer. So if all else fails ask your host provider for advice too!!!!
Wow, this is a really great explanation. Thanks for sharing!
Thanks for the info :)
I was also curious, instead of having this in .htaccess, I should be able to simply place it at the end of my Virtual Hosts file (on Linux). For instance I have a website called MyAwesomeWebsite.com (not really, but as an example), so I could append the code to the file /etc/apache2/site-available/MyAwesomeWebsite? That is of course after using the a2dissite command and then a2ensite when done
I was also curious, instead of having this in .htaccess, I should be able to simply place it at the end of my Virtual Hosts file (on Linux). For instance I have a website called MyAwesomeWebsite.com (not really, but as an example), so I could append the code to the file /etc/apache2/site-available/MyAwesomeWebsite? That is of course after using the a2dissite command and then a2ensite when done
I am re-writing this reply because my comments about web hosting were inappropriate (sorry).
When you select pretty urls Concrete5 creates a .htaccess file. My understanding is that .htaccess can be added to any directory for special configuration settings. For example allow or deny settings are often used to make directories either public or private. You may want to protect proprietary code with deny all settings.
Enabling pretty urls caused me problems (and others too) so understanding each line of code was important to me. As it turns out my problem was solved by adding a line to site.php instead. Other Forum posts said modifying the Concrete5 .htaccess code was their solution. It varies per web host. I am not qualified to discuss httpd.conf or Apache2 configuration. Perhaps a new discussion would be better for that topic.
When you select pretty urls Concrete5 creates a .htaccess file. My understanding is that .htaccess can be added to any directory for special configuration settings. For example allow or deny settings are often used to make directories either public or private. You may want to protect proprietary code with deny all settings.
Enabling pretty urls caused me problems (and others too) so understanding each line of code was important to me. As it turns out my problem was solved by adding a line to site.php instead. Other Forum posts said modifying the Concrete5 .htaccess code was their solution. It varies per web host. I am not qualified to discuss httpd.conf or Apache2 configuration. Perhaps a new discussion would be better for that topic.
