[SOLVED] How to get .htaccess to redirect but not then rewrite a URI

[cife]

I'm running a site, www.cife.org.uk using CMSMS v1.4.1. I'm revising the site and want to change a number of page titles (for better SEO). To keep any existing page rank I want to make sure that anyone using the old page URI gets sent automatically to the new page. To do this I'm adding 301 redirects to the site's .htaccess file.

If the old URI (as specified in page links, address bar etc) has a .html extension (eg http://www.cife.org.uk/retakes.html), a redirect works fine, provided that I put a short file called retakes.html in the site's root directory.

redirect 301 /retakes.html  http://www.cife.org.uk/FAQs-about-A-level-retakes works just fine.

My problem is that what I really want to redirect are requests for site files without an extension. For example, Google give a link to this page as 'www.cife.org.uk/retakes/. Putting redirect 301 /retakes/  http://www.cife.org.uk/FAQs-about-A-level-retakes into my .htaccess file produces a URI of http://www.cife.org.uk/FAQs-about-A-lev ... e=retakes/

I can see what's happening (or what I think's happening): the rewrite code in the .htaccess file which CMSMS sets up is looking at the input address of '/retakes/', deciding it isn't a directory or a file and rewriting my output URI by adding ?page=retakes to it.

But, I'm not expert enough to see how I can solve this problem!

The rewrite code in my .htaccess file (which comes at the end, after all 301 redirect lines) reads

Code: Select all

#Options -Indexes
#ServerSignature Off
#Options +FollowSymLinks
#
<IfModule mod_rewrite.c>
RewriteEngine on
#
#Sub-dir e.g: /cmsms/
RewriteBase /

#
# added by ISVirtual to sort out standard domain canonicalisation issue
# alex.poole@isvirtual.co.uk
# 28th May 2010
#
RewriteCond %{HTTP_HOST} ^cife.org.uk [NC]
RewriteRule ^(.*)$ http://www.cife.org.uk/$1 [R=301,L]

#
# 301 Redirect all requests that don't contain a dot or trailing slash to
# include a trailing slash
RewriteCond %{REQUEST_URI} !/$
RewriteCond %{REQUEST_URI} !\.
RewriteRule ^(.*) %{REQUEST_URI}/ [R=301,L]
# Rewrites urls in the form of /parent/child/
# but only rewrites if the requested URL is not a file or directory
#
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^(.+)$ index.php?page=$1 [QSA]
</IfModule>

Many thanks for reading this and for any advice you can give me!

[tyman00]

I'm running a site, www.cife.org.uk using CMSMS v1.4.1.

I am not much of a htaccess expert, so I can't help much. But this question might be better off handled in other web development forums as it is not specific to CMSMS.

Also, Please upgrade ASAP. We tend to not support that old of versions. As described here: http://forum.cmsmadesimple.org/index.ph ... 336.0.html

If not for feature sake, do it for security sake. A lot of nice security features and changes have been added in the last 2 years.

[kermit]

try using mod_rewrite's rewriterule instead... e.g.

# redirects for obsolete urls
RewriteRule ^services/$ /our-super-duper-keyword-stuffed-annoyingly-long-url-for-our-services-page/ [NC,L,R=301]
RewriteRule ^services\.html$ /our-super-duper-keyword-stuffed-annoyingly-long-url-for-our-services-page/ [NC,L,R=301]

[cife]

Thanks for the comments. I tried your suggestion kermit, and with a bit of trial and error about where to put the rewrite statement relative to the exisitng ones, got a solution. It only worked if I kept the redirects in too - wierd!

Upgrading is a must I know, but it's so easy to put off when all's going well and you read posts of upgrading going wrong! Of course it's only when things go wrong that people post for help - you don't hear from the many more whose upgrade goes smoothly.

I take the point about ReWrite being something not strictly to do with the workings of CMSMS, and also that if one doesn't have the necessary expertise to use regex properly one should either acquire it or pay for an expert to do it, but there's one aspect of this which, if one of you tech wizards can find time, would help people like me. That's to add something to CMSMS documentation  which describes what the 'typical' .htaccess file which CMSMS installs on set-up actually does to incoming URL requests, and how to adapt this if one changes a page's name for SEO or any other purpose.

[tyman00]

Glad you got it from Kermit's suggestion!

You are very correct, for every 1 post on the forum with upgrade issues there are possibly dozens of other upgrades that went smoothly. Sometimes the upgrade issues can even be user error and not CMSMS error. But the sooner people try the sooner we can work out the kinks and bugs for everyone.

As stated earlier, I am no regex or htaccess guru. I struggle through my own setups so I can understand how documenting the example in the docs folder (cmsms doesn't install an .htaccess file as far as I know) would be of a benefit. Maybe I can have someone help with that for future releases.

We can try to incorporate some info on what to change, but it really will be difficult to do as what one person wants to do will not be the same as the next person or the next person. The best solution is to document what is there and leave it to the ones that want to make the changes to read documentation or seek help from pros instead of putting in information that may be very misleading to someone who has a different purpose in mind than what is explained.

Edit: Have you had a chance to look at the htaccess.txt file in the /docs folder. Not sure how much more it could really be explained. Seems fairly straight forward to me:  http://viewsvn.cmsmadesimple.org/filede ... access.txt

[kermit]

Thanks for the comments. I tried your suggestion kermit, and with a bit of trial and error about where to put the rewrite statement relative to the exisitng ones, got a solution. It only worked if I kept the redirects in too - wierd!

shouldn't need those.

i put rewriterule-based page redirects for specific pages/urls immediately before the main cmsms rewrite rule.. i.e. right above these:

RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^(.+)$ index.php?page=$1 [QSA]

[cife]

Got this in the relevant part of config.php (NB this is from a 1.4.1 installation, in need of update.

Code: Select all

#------------------
#Usability Settings
#------------------

#Allow smarty {php} tags?  These could be dangerous if you don't trust your users.
$config['use_smarty_php_tags'] = false;

#Automatically assign alias based on page title?
$config['auto_alias_content'] = true;

#------------
#URL Settings
#------------

#Show mod_rewrite URLs in the menu? You must enable 'use_hierarchy' for this to work for modules
$config['assume_mod_rewrite'] = true;

#Extension to use if you're using mod_rewrite for pretty URLs.
$config['page_extension'] = '.html';

#If you don't use mod_rewrite, then would you like to use the built-in
#pretty url mechanism?  This will not work with IIS and the {metadata} tag
#should be in all of your templates before enabling.
$config['internal_pretty_urls'] = false;

#If you're using the internal pretty url mechanism or mod_rewrite, would you like to
#show urls in their hierarchy?  (ex. http://www.mysite.com/parent/parent/childpage)
$config['use_hierarchy'] = true;

#If using none of the above options, what should we be using for the query string
#variable?  (ex. http://www.mysite.com/index.php?page=somecontent)
$config['query_var'] = 'page';

[cife]

Just to follow up on the need to update from 1.4.1 to 1.8.1. I ducked out of trying it myself and got replytomk3 to do it for me. Glad I did: most went fine but the old installation relied heavily on a template which used a lot of IF statements to create a variety of page layouts. Those entailed repeated {content} calls, which threw up error messages about duplicate content and which prevented the edit screens from showing most of the content. Oh, and TinyMCE refused to show either.  But Michael solved the lot: divided the one big template up into several separate layout specific ones which didn't involve the repeated IFs, and fixed the TinyMCE problem (not sure how he did that). So I now have a fully functional up-to-date installation. Michael you're a star! 

[replytomk3]

Hello

What's the remaining 5%, just to be clear??

[cife]

My lack of understanding what rewriteRule does. I now know a little bit more and so 100% sorted. Thanks to all for help.