[UTILIZED FOR 1.0.8] new .htaccess gives proper 404s

[gram]

The direct links above now work.
Personal message area works.
I tried to post, it did not work.
The links to forums/boards still throw errors.
http://www.open-sef.org/component/optio ... /board,8.0
http://www.open-sef.org/component/optio ... /board,9.0
etc., etc.
Sent PM to Marko via OpenSEF forum.
Marko had the audacity to require sleep.


Maybe the solution will be to use OpenSEF, your htaccess, and Marko's advanced SEF file for SMF.
We'll get there.

The thing we are really going to struggle with is the inconsistent naming for the SMF SEF urls.  There isn't really anything there I can grab onto with Apache's (VERY) limited regex.  I wonder how tough it would be to get SMF to rethink their conventions for sef?  Or, we could certainly look into Marko's solution too.  Does it provide more normal url endings like .htm, .html, .php, or just /?

Most of the URLs I have seen for SMF would work with this new filter if they ended with '/' like a directory entry would.  The exceptions are those that contain #, which would most likely need to come after the last '/'.

This filter looks for '/' at the end of the string first.  Those types of URL's will match first, followed closely by .htm,.html, and .php.  The remainder are wildcard (or negative wildcard) centered and will require more overhead time to match.

I am going play with it some more and see what I can come up with.  Probably need to stop by the forum and copy a few URLs.

Steve

[Goosemoose]

Why not get the url information from the smf database rather than the existing url? It would be easy to grab the thread title, and board title from the db.

[gram]

The problem is that we are not in PHP, or MySQL.  This Rewriting processing is pure Apache and precedes the instantiation of the other two.

GRAM

[gram]

Still some issues on the open-sef.org site SMF forum.
The direct links above now work.
Personal message area works.
I tried to post, it did not work.
The links to forums/boards still throw errors.
http://www.open-sef.org/component/optio ... /board,8.0
http://www.open-sef.org/component/optio ... /board,9.0
etc., etc.
Sent PM to Marko via OpenSEF forum.
Marko had the audacity to require sleep.


Maybe the solution will be to use OpenSEF, your htaccess, and Marko's advanced SEF file for SMF.
We'll get there.

Now I need to try your new code above . . . probably late tomorrow. (fading now)

I believe I have the solution.  It required one additional RewriteCond to solve.  Since most folks won't need it, I commented it out and made it optional in both sections of the .htaccess file in the first post of this thread.  Please look it over, and try it out.  In my testing it forced rewrites for any nonexistant files or directories that started with '/component/option,com', so all the non working SMF urls posted in this thread now work with it. 

I also changed the original RewriteCond that had been modified trying to capture the SMF URL.  It didn't make sense to leave it in when this new condition solved the problem.

Marko, GooseMoose, Ken,
Please test again and advise if this is solving the SMF problems.  Revisions are all in the original post.

Thanks,

GRAM

[Predator]

Works better now we will still test it on our site. So if new issues are visible we'll let you know.

[gram]

Thanks Marko!

GRAM

[WebJIVE]

I'll give it a go as well.  Quick question, is there an apache directive when a 404 occurs to have apache use the 404.php in the templates directory so that a nice message is displayed?  I could add it to this mod.  I'm going to test this with wrapped/integrated SMF and wrapped/integrated Coppermine.

Thanks

[EDIT] I'm going to play around with the apache ErrorDocument 404 directive.

[gram]

Think the Apache ErrorDocument directive is the better way to go.  If we add that type of directive into the Rewrite section we will increase the overhead with the new rules and or conditions.  Since Apache already has a rule for this type of situation, would be better to use their existing capabilities (will run faster).

Let me know how it turns out BoardJIVE.

Thanks,

GRAM

[WebJIVE]

Think the Apache ErrorDocument directive is the better way to go.  If we add that type of directive into the Rewrite section we will increase the overhead with the new rules and or conditions.  Since Apache already has a rule for this type of situation, would be better to use their existing capabilities (will run faster).

Let me know how it turns out BoardJIVE.

Thanks,

GRAM

The new mods work great on my site (integrated wrapped SMF and CM) now and the ErrorDocument directive worked like a champ.  I have better performance and a nice error message ;-).  BTW, for those following this thread, I restored the J! 404.php and created a custom 404.html instead so that I'm not even hitting the PHP interpreter. 

All I added to grams work is:  ErrorDocument 404 /templates/404.html  (which is my nice little 404 message .html)

Regards,
Eric

[gram]

Thanks Eric!

I really appreciate the follow up report.

It makes a nice performance difference doesn't it 

GRAM

[WebJIVE]

That it does.  I was surprised at how much of a difference it made.  Just imagine what J! 1.1 and something like this will do because of the way J! 1.1 is being re-architected.

[Goosemoose]

Hi Gram,
The updated .htaccess works with SMF now but my xtdratings/fascile forms component still gets a 404 error. See http://www.goosemoose.com/content/view/94/65/ for an example. Getting closer!

[gram]

I took a few moments and tested against the url for that frame.  I created a directory structure to match, and a matching filename.  It worked with the existing ruleset and returned that file (did not rewrite).

This might be a couple of things, and forgive me if I am taking you down a route you have already gone down.

1. check this directory/filename to ensure they actually exist, this is from your HTML code for URL you posted, and is the URL it points the iframe to:
http://www.goosemoose.com/components/co ... .frame.php

Above you refer to 'fascileforms', but this url points to '/com_facileforms'.  If the directory is correct, check to be sure the filename it goes to 'facileforms.frame.php', actually exists.

2. If the filename/directory checks out, post the contents of your .htaccess file's relevant rewrite section.  Lets check your settings and make sure they are correct for your site.

3.  What does 'facileforms.frame.php' do?  Could this error be caused by a request within that file that is failing?

Good to hear all else is working.  This is resolvable, just need to find the root of the error.

GRAM

[gram]

Another follow up GooseMoose,

I tried to access the filename/directory your frame points to, it was successful.  I got a blank page, and a status 200 from the server.  No 404 page, just blank.  That means this file exists. 

Clearly without params, it does nothing.  As soon as I add the params back in, I get your 404 error page, with a 404 error response.

I think you need to investigate what that file is doing to find the problem.

[Goosemoose]

Hi Gram,
Thanks for looking at it. I had a typo above, it is facileforms like you said.

1. check this directory/filename to ensure they actually exist, this is from your HTML code for URL you posted, and is the URL it points the iframe to:
http://www.goosemoose.com/components/co ... .frame.php

This does exist. In fact if you try to browse to http://www.goosemoose.com/components/co ... .frame.php you will get a blank page with the browser title Facile Forms Frame. This might suggest that htaccess is at least rewritting that page not to get a 404.

2. If the filename/directory checks out, post the contents of your .htaccess file's relevant rewrite section.  Lets check your settings and make sure they are correct for your site.

########## Begin Standard SEF Section
## ALL (RewriteCond) lines in this section are only required if you actually
## have directories named 'content' or 'component' on your server
#
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteCond %{REQUEST_URI} ^(/component/option,com) [NC,OR] ##optional - see notes##
RewriteCond %{REQUEST_URI} (/|\.htm|\.php|\.html|\?.*|/[^.]*)$  [NC]
RewriteRule ^(content/|component/) index.php
#
########## End Standard SEF Section

3.  What does 'facileforms.frame.php' do?  Could this error be caused by a request within that file that is failing?

I'm not sure what all the facileforms files do. I did notice something interesting though. xtdratings is a plugin for facileforms. The following URL's DO work: (these are in the backend so you won't be able to access them, but they might point to the pattern).

http://www.goosemoose.com/administrator ... figuration
http://www.goosemoose.com/administrator ... managerecs
http://www.goosemoose.com/administrator ... anagemenus

These are in the backed but don't work (return joomla 404 page). They are for the addon
http://www.goosemoose.com/administrator ... ff_frame=1
http://www.goosemoose.com/administrator ... ff_frame=1

If I take off the &ff_frame=1 then both work! They worked fine in Joomla 1.0.6 though so I don't know why the change would cause the last part to throw a 404 error. I haven't figured out how to get the pages on the frontend to work though:
http://www.goosemoose.com/components/co ... &Itemid=65

Let me know if you have any ideas.

[gram]

Your .htaccess settings are right on.  Just wanted to be sure you had all the options included for your section.

We would need to find out what 'facileforms.frame.php' is doing.

I don't know much about facileforms, but would be happy to look at that file if you want to pm it to me.

[Goosemoose]

Sent.

[kenmcd]

Note: FacileForms does not work with OpenSEF either.
The issue may be bigger than just this htaccess file.

[Goosemoose]

I can get Facile Forms to work in the backend, and xtdratings in the backed if I remove the code I showed above. Nothing fixes the frontend though. Gram, I've attched facileforms with xtdratings here as I can't do it via pm.

This all worked before I upgraded to 1.0.7 so it could be something else that broke it.

[gram]

The file you posted only has one xml file in it.  Is this the right one?

If not, can you send me a copy via email, at the address I put in the PM?

GRAM

[Goosemoose]

Darn, that was an older version then that was installed after installing facile forms. Guess I'll have to wait until the site comes backup as I don't have the other version on my computer.

[Goosemoose]

Site's backup. File is here: http://www.joomlaratings.com/component/ ... 4/lang,en/

It's the second file on the page if you go directly there.

[WebJIVE]

Has this been tested on localhost?  I used it on my production site just fine.  Today, I decided to try it on my dev machine with no luck.  Any suggestions?

Thanks,
Eric

[EDIT] Never mind for now.. This seems to be a problem with my local machine.  :-(

[focalguy]

Charles,

Try mixing this file with your original .htaccess file.  For example, your server may be having a problem with the -indexes statement or the section.

I would suggest starting with the section and commenting it out, then try the deleting the -indexes command.

BTW...  Just making sure, but you had SEF working, and you were previously using the standard Joomla .htaccess file?

GRAM

Mine is working after I commented out the Options -Indexes FollowSymLinks line.
What does that line do? and am I missing something with it commented out?

[gram]

Mine is working after I commented out the Options -Indexes FollowSymLinks line.
What does that line do? and am I missing something with it commented out?

Probably not, your ISP may have set those directives in a way that does not allow overides.

If it is working, and your SEF'd urls don't give 404 errors, you should be fine.  The important part of that line is the FollowSymLinks which is required for operation of mod_rewite.

If its working, you should be ok.

GRAM

[focalguy]

Thanks Gram, and thanks for all the work with the htaccess in general!

One more question which is really how I found this thread in the first place - I want http://www.mydomain.com to redirect to http://www.mydomain.com/cms/ but when I've used the redirect command it also redirects all my subdomains such as myname.mydomain.com which I don't want.

I found a suggestion of using modRewrite instead so I just copied this from what you had:

Code: Select all

RewriteCond %{REQUEST_URI} (/|\.htm|\.php|\.html|/[^.]*)$  [NC]
RewriteRule (.*) /cms/
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d

and it seems to work. It does take a little while before the site loads and if specifying folders that do not exist after http://www.mydomain.com it also gets redirected instead of a 404. Should I just remove all of the first line but (/) and maybe remove the other two lines?

To be clear, I want http://www.mydomain.com to take them to http://www.mydomain.com/cms/ but if they type http://www.mydomain.com/file or http://www.mydomain.com/folderdoesn't exist to show the 404. I'm sure it's pretty simple but I would be grateful if you have the time to show me.

[gram]

FocalGuy:

I haven't tried to do what you are doing, so let me comment on your settings and tell what I would pursue (sorry).

The RewriteCond's that follow your rewrite rule have no effect.  If you want them to apply to the rewrite rule, they need to come before it.

I think trying to get all of this into a singular set of rewrite rules and conditions would be a real headache.

You might want to set up a couple of sets of conditions and or rules.

For example, if you want everything in your '/gallery/' directory to go there and not be rewritten, set up a ruleset just for that.  Maybe:

RewriteRule ^gallery/ -  [L]

It would have to come before the ruleset for your Joomla.  This should (i haven't tested it) do a couple of things, keep the request_filename the same as it was recieved ( '-' means don't rewrite), then not process anymore rulesets (the [L]  means last ruleset for this match).

The problem is going to be mixing it up with a broader ruleset like (.*).  This means the rule applies to everything.

mod_rewrite builds a table of rewrite rules and conditions that is indexed by the pattern you set in the RewriteRule.  RewriteRule (.*) means that RewriteRule applies to everything.

I think you could get away with it, if the RewriteRule I suggested above is put in before the (.*) rule.  But you will have to try it and see.  It also might give you a 500 server error.

You don't have to have any RewriteConds for a RewriteRule to work.  But sometimes you can't get all the conditions into a simple RewriteRule.

You might get away with this:

Code: Select all

RewriteRule ^images/(.*)  - [NC,L]
RewriteRule ^forum/(.*) - [NC,L]

RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule (.*) /cms/%1 

Then put the normal .htaccess for SEF in the root of cms if you are using SEF.

Anything in square brackets following a RewriteRule or RewriteCond is command flag, and in the case of multiple, they are seperated by ',' (commas).  NC means case insensitive, L means this is the last rule if the pattern matches.  The %1 in the last Rewrite rule tells it to use whatever matched the (.*) .

RewriteCond's can match against Apache variables (like REQUEST_URI), RewriteRules match against the singular Apache variable REQUEST_FILENAME, which unfortunately can change if a rule before the one it is currently in has matched already.

I would suggest you take a little time and read up on how this works.  The documentation can be a little frustrating, as it doesn't cover all supported or unsuported aspects of the regex engine apache uses, and does not tell you what server directives set in the http.conf can cause you to get 500 server errors, but at least it is a guide to how to use this mod_rewrite.

Documentation is here:
http://httpd.apache.org/docs/1.3/mod/mod_rewrite.html

Feel free to ask questions if you think I can help, but by the time you get it all working, I may be asking you questions (about rewriting a root to a directory).

GRAM

[focalguy]

Wow, thanks a lot for that info Gram! I did take a brief look at the documentation for htaccess a couple of months ago when I first tried Redirect, but it just confused me so I gave up. However, with the knowledge you have shared (like what the [] (.*) %1  do) I will definitely take another shot.

I must have cut and pasted in the wrong order in my previous post because the way my code currently reads is

Code: Select all

RewriteCond %{REQUEST_URI} (/|\.htm|\.php|\.html|/[^.]*)$  [NC]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule (.*) /cms/

I'll play around with it and see what I come up with. Thanks a lot for the enormous push in the right direction. Especially since it's not really following the topic exactly....(oops)

[tyler]

just for anyone who is tracking successes, this is working much better for me with no conflicts whatsover.  Using apache for 404 processing seems much more efficient as I'm seeing.  And I'm running 404SEF BTW (on a heavily hack version of Joomla V1.0.2.

Many thanks once again Gram for following through to make this happen for all of us

-Tyler

[Goosemoose]

I dont' know if this helps at all, but just in case.

The reason xtdratings & facileforms stopped working is because of these lines in sef.php, once commented out everything started working again. Any ideas on why?

Code: Select all

// if ($juri != "" && !eregi( "index.php", $_SERVER['REQUEST_URI'] ) && !eregi( "index2.php", $_SERVER['REQUEST_URI'] ) && !eregi( "/?", $_SERVER['REQUEST_URI'] ) ) {
 header( 'HTTP/1.0 404 Not Found' );
 require_once( $mosConfig_absolute_path . '/templates/404.php' );
 exit( 404 );
}