FrontPage and the .htaccess file

A site owner installing a package of mine seems to have a problem that I can't address yet, because I know absolutely zip about FrontPage. I urgently need advice and help.

The problem is that when he adds a few mod_rewrite lines to his .htaccess file, FrontPage bellyaches that it can't work with his site. The added lines are exactly these:

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
# ----------------------------------------------------------------------------------------------
RewriteRule ^books-plain/([A-Z0-9]+)\.html$ /FREEBIE/free1.php?&asin=$1 [L]
RewriteRule ^books-reviewed/([A-Z0-9]+)\.html$ /FREEBIE/free2.php?&asin=$1 [L]
# ----------------------------------------------------------------------------------------------
</IfModule>
#​

(They accomplish their intended purpose perfectly.) There are no other rewrite-related lines in his .htaccess file.

Can anyone tell me what is going on? (And what to do: surely there are people using FrontPage who have mod-rewrite lines??)

 

I've never been able to modify any files outside of FP without causing problems.

Check that the file permissions and ownership haven't been changed. FP needs to be able to read/write the file. I'm not sure the exact perm. needed, tho.

 

OK, I've paid some dues and gotten some perspective on this problem. It was not too difficult: the web is flooded with people claiming that they are tearing their hair out over the matter. So far as I can tell, FrontPage is the usual M$ mass of butchery and how-not-to examples from Programming 101; but the thing that really, really flames up is this:

M$ has, on its server software, no such thing as an .htaccess file, nor anything much like one in functionality. But, in designing FP, they use for what amounts to simple .cfg files (of which I gather it strews many and many hither and yon on its poor users' web sites) files named--gee, can you guess?--yes, .htaccess. Why, what a likely name for a .cfg file!

Moreover, since FP treats those files as its private property, anyone attempting to use one for what, on a Linux-based server, is its real, and often critically important, uses ends up with FP whining that it can't work on that site any more. (That should be a clue: Oh, you can't? Sorry, guess I'll have to ditch you.) So FP effectively cripples, seriously, the utility of any Linux-based server on whose files it is used. Sheer coincidence, of course.

(There's other and equally bad stuff, but I am focussing on one particular problem.)

The web is also full of answers to those hair-threatened users that you just have to shrug and bear it. But in a few cases, the answer was less knee-jerk. It seems, and I emphasize the tentative nature of that remark, that if one puts non-FP stuff into one's .htaccess file in front of (or atop, if you prefer that view) the FP lines, the two types, FP and non-FP, will work and play well together. Some say yes, some say no.

(There appear to be other solutions, too, but there are questions about their possibly weakening security.)

Does anyone have any experience of this matter?

 

This situation would only occur for FrontPage users who either use FP to publish or who use FP extensions.

FP users who upload pages via FTP and do not use FP extensions have full use of their htacess file.

 

Thank you. I have seen a few notes along those lines, but less succinct.

As I know very, very little about FP--and that is a lot more than I care to--let me ask what a user who, clearly, has been and is using FP extensions and/or FP to publish would need to do to convert to using ftp upload (which one web source said "is the usual method anyways"). What I need to be able to do is explain succinctly but clearly and exactly, in a docfile, what FP users currently in that position need to do to switch over--and have it be persuasive enough that they don't think I am asking them to turn their world upside down just to suit my package. Is there some clear, simple set of exact directions, a URL, at which I could point such folk? (Or at least a hazy one I could rewrite?)

(I reckon that anyone who knows the potential power of .htaccess on an Apache server would have no problem, but it is just those who do not that I reckon I need to address.)

Sidebar question to all: I never have made, and do not contemplate ever making, web pages save by manually typing in a text editor. Am I some sort of primitive barbarian? I mean, they are all 100% XHTML, and neatly indented, and all that good stuff. . . .

 

(bolding of text placed by me)

With all due respect, if you are serious about helping FP users implement your program, I would seriously consider remembering that you are working out a mutually beneficial business partnership with them. It is generally not a great idea to start by sounding as if you're slamming the editor they choose to use. Many financially successful web designers use FP as a tool to design websites.

Fp users have a choice of using FP publishing or any FTP program, but they can't use both. If they choose to use an FTP program, they simply need to request that their host disable FP extensions. This would require that the particular user not be using any coding that require extensions. (There are very few, beyond publishing)

This is a choice YOU have made. The key to successful websites is not in which tool the designers choose to use (or not use).

Just my 2 cents... nothing more... nothing less...

 

Just so. The rub is that it seems, from hours of reading nothing but FP-related pages, that FP really is a M$ bomb tossed into the *nix world. I indeed would like to work co-operatively with web-site operators who use FP, and I cannot, and do not, expect them to switch to Dreamweaver or some such just because they see the name in my info docs.

But I do need to find a way to make the package work on such sites. If you haven't seen it in the other forums here, the essence of the thing relies on Apache servers' ability to use mod_rewrite to make php-script calls all look like static pages. And Rewrites are--no doubt by careful, deliberate design--the thing that will not work in .htaccess if FP is being used in "publish to server" mode.

So, as far as I can see right now, what I need to do is to gently persuade potential users reading the docfile that the advantages to them of having a fully usable .htaccess file (they will all be Apache users--the package won't work on anything without mod_rewrite and it checks their server software) outweigh whatever nuisance (mostly, I imagine, changing a habit) it is to switch from using "publish to server" to using "publish to file" then ftp-uploading. I guess also that emphasizing the risks of "hot/live" editing wouldn't hurt..

But ideas along those lines are what I am seeking.

 

Now I understand what you are looking for!

The ability to access the htaccess file opens a whole new world to these users! In addition to being able to use programs such as yours, a few of the most important benefits they will receive is the ability to design custom 404 pages for their sites, create 301 re-directs, and of course the use of mod rewrites for additional dynamic pages they may have. Of course one of the biggest benefits to these users is never again having to choose a host based on having FP extensions available.

I think perhaps people are basically creatures of habit. Sincere advice on the multitude of avenues opened up to them by moving away from the need for FP extensions, should help guide them in that direction. You may want to consider encouraging them to speak with other FP users who do NOT use FP extensions.

 

Thank you, Cricket, that is good advice.

I have, however, come across something that might be a clean, simple answer that gives the best of both worlds. The problem is that my "expertise" is only what one can learn in a few hours of surfing, so I need help.

Can anyone definitively and assuredly either verify or falsify the following:

A user whose web site is hosted as a virtual domain by an ISP can request that the ISP place in the user's "Virtual Host" configuration file the statement--

AccessFileName .syscfg​

--and that when that is done (and there should be no reason to deny the request) the Apache server will not look for .htaccess files in that user's directories but will instead look for files named .syscfg (or any arbitrary name the user might have dreamt up for the request) and treat them just as it normally would files named .htaccess

Or, on a dedicated server, that statement could be put in the server config file to the same effect.​

If that were so, then the user could let M$ fiddle its private .htaccess files till the cows come home (do not try this yourself, professional cows on closed meadow), while using .syscfg (or whatever) files to do all the joyous and wonderful things that .htaccess normally does.

Help here, please? Urgently needed . . . .

 

This is a sort of (bump) on the previous post.

I have spent many, many long and very tedious hours on the web researching this, and have come to the conclusion that it is like the secrets of the pyramids: those who say don't know, and those who know don't say.

I strongly suspect (but could use confirmation even of this) that there is no problem getting an ISP to implement AccessFileName .whatever, so I think that whether I have a bright idea or am at a dead end will depend on whether the fiends who designed FrontPage were smart enough to actually read from Apache what the access-file name is, or whether with classic Redmond laziness they just hard-coded .htaccess.

Pleeeze, pretty please with sugar on it, does anyone know those things?

 

I am curious... Were you ever able to resolve this issue?

 

Sadly, no. In the package docfiles, it explains that if a user is using FrontPage and is using it in the "publish-to-server" mode, they need to, when engaging in a FP session:

1. download their "normal" root .htaccess file and save it;

2. upload a previously saved FP version;

3. do their FP work;

4. download and save the new FP .htaccess file; and,

5. upload-restore the "normal" .htaccess file.

There is at least one user doing things that way now, and he seems to feel it no big deal.

I still think, though, that there has to be a better way, but I can't find enough information on Apache server configuration. (Well, I guess it's all out there, but I can't find a digest that touches on this and haven't had several straight days to comb through what is out there.)

 

I am not at all a techie type, so I may be way off base here. I wonder if this article answers some of the reasons why this issue has been such a challenge. Perhaps the section under the heading Warning gives a hint to a possible solution?

http://www.freewebmasterhelp.com/tutorials/htaccess/

 

Sadly, no. In the package docfiles, it explains that if a user is using FrontPage and is using it in the "publish-to-server" mode, they need to, when engaging in a FP session:

1. download their "normal" root .htaccess file and save it;
========

This is a good idea when messing with the fp htaccess.

=========
I still think, though, that there has to be a better way, but I can't find enough information on Apache server configuration. (Well, I guess it's all out there, but I can't find a digest that touches on this and haven't had several straight days to comb through what is out there.)
===========

Where are you putting the rewrite stuff? FP htaccess can be messed with, but with care, and only certain things. Make sure you have a back up.

Anytime you want to add anything to a fp .htaccess file; it should be below all of the stuff that fp adds - skip a line and then add your stuff.. I have tested/fixed things in this manner and I know it works. I have not, however tested for your particular situation, way back when I started in hosting; it was all over the hosts website -that if you used fp you couldn't mess with the .htaccess, but that was then.

Let me run a test and see what happens.

 

I did test; and frontpage did not work with the example you provided:

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
# ----------------------------------------------------------------------------------------------
RewriteRule ^books-plain/([A-Z0-9]+)\.html$ /FREEBIE/free1.php?&asin=$1 [L]
RewriteRule ^books-reviewed/([A-Z0-9]+)\.html$ /FREEBIE/free2.php?&asin=$1 [L]
# ----------------------------------------------------------------------------------------------
</IfModule>
#

However, it did work with the 301 redirect example you provided elsewhere in this forum. I didn't look at my logs, so this is a guess; but I suspect when logging on to FP; it's trying to go to the /FREEBIE/ directory; or the directory I added in. Have you tried this without the <IfModule mod_rewrite.c> statement added?

 

I think we can all agree that FP occasionally leaves a lot to be desired when it comes to generating clean and efficient HTML. But let's leave that alone for the moment and talk about FP and the .htaccess file, because I've been reading a variety of incorrect things from people who have admitted that they don't even really know the program at all. There is a simply INCREDIBLE amount of misinformation going on here.

First of all... let's make something quite clear. The .htaccess files created by FrontPage are absolutely 100% standard and contain NOTHING that a standard Apache server wouldn't recognize. They are most certainly NOT some sort of ".CFG" or ".CNF" files in disguise.

FrontPage DOES use a variety of ".CNF" files and certain other files to maintain it's own configuration data, but this is separate from anything in the .htaccess file, and these files only affect FrontPage and its extensions, not the rest of the web server.

Furthermore, FP does NOT create .htaccess files all throughout your website. It's perfectly predictable where they DO get created. There is one created in the website's root directory, and one in certain of the various "private" directories that FP uses to store information about the website, like the "_vti_pvt" folder. Plus, if you use FP's built-in feature for managing a password protected directory, it will create one there too.

The main real issue regarding the .htaccess file and FP is that the FrontPage extensions don't always do a great job of parsing the file. They can get confused if they find unexpected commands BEFORE the commands they're looking for. When this happens, it can break FP's "Publish To Web" feature, but it doesn't really impact anything else.

There are CERTAIN commands you can place at the TOP of the file, like "ErrorDocument", but many commands will confuse the FP extensions if they come before the "AuthName", "AuthUserFile" and "AuthGroupFile" commands. These are the commands that are used to control access to the website for uploading within FP, which is why the "Publish to Web" feature breaks.

Specifically, this applies to the .htaccess file in the website's root directory. Also, note that this is strictly not a problem with the actual FrontPage application itself. It's actually a problem with the FRONTPAGE SERVER EXTENSIONS.

The FP extensions can also get confused if you upload an .htaccess file from a Windows-based machine using BINARY mode FTP because the EOF characters will probably be Windows CR+LF instead of the LF-only format normally used by Unix/Linux.

It's a good idea to back up the original .htaccess file in the website's root directory before you edit it or upload a new version, but this is something that ANYBODY should probably do, not just FP users.



Mike

 

Author: Michiel van der Blonk (204.212.120.---)
Date: 19-01-05 12:56

I have a solution that worked for me. Without this solution I could not even enter my FrontPage web anymore. FrontPage kept saying: "there is no web defined blabla, should I create a web blabla"

In the root folder of your frontpage web you will find the folders named

_vti_bin/
_vti_adm
_vti_auth

in each .htaccess file you find in these folders add the following line:

Options +FollowSymlinks

That solved my problem
-----------------------------------------------------------

I found this on the FREEBSD Diary, and can confirm that it works perfectly for me. I had to share.

Jay

 

Since this thread is active again, I just want to point out that the "Freebie" package no longer uses the .htaccess file, and so has no potential clashes with FrontPage.

 

jreher's above solution does in fact work, but one directory has a slightly different name when using FrontPage 2003, and jreher does not note (overtly) that the latter 2 directories are nested within the first.

Specifically, in the root folder of your FrontPage web you will find the folder named:

_vti_bin

And within that folder you will find two more folders:

_vti_adm
_vti_aut

And in each of these three folders you will find a .htaccess file. Into each of those .htaccess files, after all the FrontPage lines of code, you will insert a blank line, followed by this line:

Options +FollowSymlinks

Then add another blank line after it for good measure, and close the file.

Now it will work.

-------------------------
Cheers to All, the HostingDude
http://www.hostingdude.com

 

Not sure what you mean, owl.

This was never a problem under version 3.0 of Mr. Rat's script, with or without the Pokemon mod-rewrite.

And it's not even a problem under version 4.0 of Mr. Rat's script unless you are using mod-rewrite in which case it's a problem.

It becomes a problem because Pokemon's mod-rewrite requires a substantial mod to the root .htaccess and that does mess up FrontPage 2003.

And this (above) is then the solution.

I've found this from running it Mr. Rat 4.x with Pokemon's Mod-Rewrite on quite a number of websites.

Hope this solution helps.