htaccess AddType question
 

I want to add this to my htaccess:

AddType application/x-httpd-php .htm .html

to be able to use php includes without changing my page extensions. I already have this in there:

AddType text/html .shtml
AddHandler server-parsed .shtml .html

at the top, before all of my rewrite stuff.

so can I have both in there or is there something I can add to what's already there?

thanks for any help!
:)

With Apache1, you cannot run a page with SSI and PHP parsing at the same time.

With Apache2, you can, but, it isn't recommended. Apache2 would be something like:

maybe..... not all servers will allow you to mix them.

well that simplifies things :D

as I want to use the php, I'll just take out the SSI altogether then.

thanks :)

Ewwwwwww.

echo @stripslashes( @join( @file( "http://www.somedomain.com/cgi-bin/someperl.cgi" ),"" ));

As for running htm pages as php, maybe in one directory it would be OK, but not sitewide. You dont really want HTM being parsed as PHP if you can help it. It will cause a performance hit.

ok you two, get a room :D

well I'm not up on all this techy stuff lol. If you tell me how to do something I'll understand it, but I probably won't know why it works :)

I have one directory with about 125 or so pages that I'd be needing the php on. Any new pages in that directory I would just do as php I guess.

I was thinking about just switching them to php anyway if I can do a global redirect or something since they're all in the same directory? I really don't want to have to redirect 125 pages separately, it sounds a bit messy.

for now I'm going to parse 'em, if you guys have a good solution my ears are open :)

realizing of course that if maxclients is set to 512, and you have 257 surfers hitting a page that is calling that url from your local server, you're going to get a connection refused on the 257th surfer's request. Since php doesn't support keepalives, do that more than once on a page and you've got 1+ a connection for each of the file requests, reducing the number of surfers that you can serve on your site.

And that doesn't really solve the problem. If a file is being included, sure, that will work, though,

is a bit friendlier, and, honors the timeout timer built into php. file, if I recall, does not honor the default_socket_timeout. Neither does include/include_once or require/require_once.

If it is a local file, you're better off doing:

But, how do you handle normal SSI?

Without converting that code to php, you would have to add the output filter for INCLUDES. SSI is used for more than including other files including adding the query string to urls, displaying the current date, etc.

In the end, SSI wasn't used, so, it's a moot point. :)

personally, I would leave them as .htm or .html files and just parse them. No supported evidence behind it, but, a gut feeling that google prefers .html files over .php

If you wanted to redirect files, you could do it with mod_rewrite.

If you want to silently serve the .php as .html (and for some reason didn't want to parse .html)

If you wanted to 301 redirect the old content to the new page

Personally, I would just turn on php parsing for .html files in that directory and not worry about it.

thank you |blowkiss| that's exactly what I want to do because it seems to be the easiest way.

So if you wanted a "page.php" to display as "page.html" to perhaps take advantage of Google's hypothetical preference, this would work?

Interesting thread...wish I understood more of this stuff...

IF google prefers .html over .php, yes, that would allow it. There are other factors to keep in mind -- moving existing, indexed content will surely cause an upheaval. Link trades pointed at those .php files will of course get redirects to the .html version which may lose some incoming link influence. You certainly wouldn't want to serve the same page as .php and .html or google may see it as duplicate content and toss one into supplemental (hopefully not the page you're trying to push). I wouldn't really recommend changing existing content, but, for new content I tend to prefer .html. I can see some of the reasoning behind it, but, that is just a tiny factor that I feel has a tiny influence on things.

php parsing itself has a detrimental side effect of setting the last-modified-time of the document to the current time. Technically that is true since the page was composed right then, but, that means that your documents never age and therefore might affect another metric that google looks at. Do you trust a page that is always updated more than a page that is a steady, archival version of an article?

Some of the history behind the different file extensions is a little odd. Ages ago, CPUs weren't as powerful, the php module built into apache wasn't a great performer. You had SSI which allowed you to put things like dates and do simple includes into documents - simplifying menus/navigation.

So, to preserve 'hardware', .html was for a document that needed no parsing, .shtml was used for documents with SSI. .php and .phtml was used for documents that needed php parsing. Because the default server config for .html usually didn't include php parsing, most developers just used .php because it was guaranteed to be parsed.

I could be completely wrong.

If the html pages running as php are just getting a few hits, its no big deal unless you are running a really slow computer. On the other hand, if the html being parsed as php is a gallery listed on the hun, it will probably turn your server into jelly.

My guess is you will be alright, especially if CD34 says so.