##################################################### # READ THIS COMPLETELY IF YOU CHOOSE TO USE THIS FILE # # The line just below this section: 'Options +FollowSymLinks' may cause problems # with some server configurations. It is required for use of mod_rewrite, but may already # be set by your server administrator in a way that dissallows changing it in # your .htaccess file. If using it causes your server to error out, comment it out (add # to # beginning of line), reload your site in your browser and test your sef url's. If they work, # it has been set by your server administrator and you do not need it set here. # #####################################################

## Can be commented out if causes errors, see notes above. Options +FollowSymLinks

Senior Member

First you need to get a much newer copy of the basic Joomla htaccess file. Yours is very old and contains several flaws.

Having obtained a new file, you'll then need to customise it with your various changes. However, you need to do it slightly differently.

The rules in your current file are in the wrong order. The new htaccess file available for Joomla gives hints as to where additional rules should go. Follow those directions closely.

The first section should contain rules that block access. The next section should be RewriteRules configured as redirects, with the non-www/www rule as the last one. The final section should be RewriteRules configured as internal rewrites.

The use of RewriteRule to perform this task may be appropriate if there are other RewriteRule directives in the same scope. This is because, when there are Redirect and RewriteRule directives in the same scope, the RewriteRule directives will run first, regardless of the order of appearance in the configuration file.

running these rules in the wrong order may cause: - exposure of mod_rewrite-rewritten urls in a subsequent mod_alias Redirect (likely what caused your /smartoptimizer/ redirect) - multiple redirects to reach the canonical url

RewriteRule ^(.*\.(js|css))$ smartoptimizer/?$1

are you trying to pass the file name in a query string to the default directory index document for the /smartoptimizer/ directory?

Senior Member from US

#2 Get rid of any envelopes in the form <IfModule...> Not the contents! Just the envelope itself, opening and closing. Either you have the mod or you don't.

#3 As noted above, any rules using mod_alias (Redirect by that name) must be changed to use mod_rewrite (RewriteRule with [R=301] flag). If there are many of them it can be done globally in any text editor that does Regular Expressions. I only saw one or two, so you can change them manually.

#4 Functionally it doesn't matter how you arrange your htaccess. Each module will execute separately, in an order determined by the server. But for your own sanity, group each module together. Put any one-off directives such as Options or ErrorDocument at the top of the htaccess where you can easily find them.

And now

#5 Get all your RewriteRules in the right order. In general this means:

(a) group rules in order of severity. First any access-control rules ([F] flag); then any deleted pages ([G] flag); then the redirects ([R=301,L] flag); finally the simple rewrites ([L] flag only). There are exceptions, but that's the default ordering.

(b) within each of these categories, list rules from most specific to most general. Like this:

and then for whole directories RewriteRule ^directory/(.*) http://www.example.com/$1

Your last redirect will ordinarily be domain-name canonicalization (see any of several thousand earlier threads in Apache subforum), and your second-to-last will ordinarily be the "index.html" redirect (again, see earlier threads).

You are using a CMS that involves rewriting everything to index.php, so there will be some extra rules involving requests for index.php vs. requests for other pages.

Your generic htaccess probably has a number of conditions involving -f or -d. You can get rid of most of these by constraining the rule to requests for pages, for example (^|\.html|\.php|/)$ It is very unlikely that your CMS involves itself in rewriting requests for non-page files.

Any rule that involves bad parameters will have a preceding condition that looks something like this

RewriteCond %{QUERY_STRING} (^|&)options=blahblah

where "blahblah" means any values that the "options" parameter is not allowed to have. Details will depend on exactly what the parameters are called and what their potential values are. Admittedly this is easier to do in hand-rolled php where the page itself looks at the values and decides what action to take (404, 301 or 200). But it can be done in htaccess too.

I may have overlapped phranque's post a little. But at least I kept my RewriteCond from winking.