Enable search engines friendly URLs ?

[Jezella]

I have just purchased the licence for Esvon Classifieds and find that the instructions are not so good so need help apart from automation from the Esvon so called help centre.

I am trying to enable search engine friendly url's which is supposed to be possible from the program admin pages.

Basically on one of the Esvon admin pages I ought to be able to check a check box and then Enable search engines friendly URLs ? This is the theory. However next to the check box is the following statement.

You need Apache module "mod_rewrite" installed for this. If mod_rewrite is installed and you want this option to work please copy ".htaccess" file from "/docs/" dir into script dir (where index.php resides) .

Having read this I entered my HM control page, went to Apache handlers and then entered "htm" into the ext. section and "mod_rewrite" in the handler section and then clicked Add button. Next I entered "html" int the ext. section and again "mod_rewrite" in the handler section and clicked the add button.

Following this I went back into my (Esvon) software program and checked the check box to enable search engine friendly URL's. Hay presto, problems.

It seems that htaccess file is doing something as the url's are improved for the search engine. However, before any alteration on my part my url's would be similar to this http://www.sell-the-car.co.uk/index.php?page=out&id=14 where thing worked fine thought not a very friendly url.

After my alterations my url would appear as follows http://www.sell-the-car.co.uk/page-12.html maybe a more friendly url but resulting in a HTTP 404 page not found error message. I've looked for page-12.html but can't fine it anywhere.

May I refer to the above again

.....please copy ".htaccess" file from "/docs/" dir into script dir (where index.php resides)

I suspect that I am making an error here. In the "/docs/" dir of my PC no htaccess exists but on my HM server it does.

Please try to help me here as I'm lost.

Ashley Jezella

[Andy Z]

On the server, take the .htaccess file from /docs/ and move/copy it to where the index.php for the script is. Remove the Apache handlers you added in cPanel.
The .htaccess most likely includes the mod_rewrite instruction your script uses to create the search-engine friendly URLs. (There is no need for the Apache handlers).

Try now.

[Jezella]

Andy thanks but this still does not work. I think that what might be of importance is that I have frontpage extensions installed.

Basically, I think that I'm confussed as to what I am trying to achieve or how the software is supposed to work.

The index.php file is here www.sell-the-car.co.uk/index.php I presume that the htaccess file is here www.sell-the-car.co.uk/.htaccess but on the server.

May I include the this again from an above post.

"You need Apache module "mod_rewrite" installed for this. If mod_rewrite is installed and you want this option to work please copy ".htaccess" file from "/docs/" dir into script dir (where index.php resides) ."

It seems to me that .htaccess was never in /docs/ but here www.sell-the-car.co.uk/.htaccess Also, I have no script dir.

Sorry for being stupid.

Ashley Jezella

[Jezella]

This is a copy of my .htaccess file


IndexIgnore .htaccess */.??* *~ *# */HEADER* */README* */_vti*

<Limit GET POST>
order deny,allow
deny from all
allow from all
</Limit>
<Limit PUT DELETE>
order deny,allow
deny from all
</Limit>
AuthName www.sell-the-car.co.uk
AuthUserFile /home/ashley/public_html/_vti_pvt/service.pwd
AuthGroupFile /home/ashley/public_html/_vti_pvt/service.grp
AddHandler mod_rewrite htm
AddHandler mod_rewrite html

[Jezella]

Andy I've got it. I did not have the full instruction in my htaccess file.

For other with a similar problem, my file should have looked as follows and not the above.

IndexIgnore .htaccess */.??* *~ *# */HEADER* */README* */_vti*

<Limit GET POST>
order deny,allow
deny from all
allow from all
</Limit>
<Limit PUT DELETE>
order deny,allow
deny from all
</Limit>
AuthName www.sell-the-car.co.uk
AuthUserFile /home/ashley/public_html/_vti_pvt/service.pwd
AuthGroupFile /home/ashley/public_html/_vti_pvt/service.grp
AddHandler mod_rewrite htm
AddHandler mod_rewrite html




# Search engine friendly URLs config file for Esvon Classifieds
# You need Apache module "mod_rewrite" installed

Options +FollowSymLinks

RewriteEngine On
RewriteRule ^page-([^\.]+)\.html$ index.php?page=out&id=$1
RewriteRule ^category-([^\.]+)\.html$ index.php?page=browse&cat=$1
RewriteRule ^browse-([^-]+)-([^\.]+)\.html$ index.php?page=search&s_res=AND&cid=$1&off=$2


Many thanks Andy

[Andy Z]

A side note: If I recall correctly (hmm...) and things haven't changed (might be), but custom .htaccess and FP extensions do not mix. FP will complain, whine, do wierd and terrible things, etc. if you bother/overwrite its special .htaccess files.

I suggest opening a ticket with HM (www.hmhelpdesk.com) and ask to be sure.

[Jezella]

Andy yes some strange things happened. This is my htaccess now.

# -FrontPage-

IndexIgnore .htaccess */.??* *~ *# */HEADER* */README* */_vti*

<Limit GET POST>
order deny,allow
deny from all
allow from all
</Limit>
<Limit PUT DELETE>
order deny,allow
deny from all
</Limit>
AuthName www.sell-the-car.co.uk
AuthUserFile /home/ashley/public_html/_vti_pvt/service.pwd
AuthGroupFile /home/ashley/public_html/_vti_pvt/service.grp
AddHandler mod_rewrite htm
AddHandler mod_rewrite html





# Search engine friendly URLs config file for Esvon Classifieds
# You need Apache module "mod_rewrite" installed

Options +FollowSymLinks

RewriteEngine On
RewriteRule ^page-([^\.]+)\.html$ index.php?page=out&id=$1
RewriteRule ^category-([^\.]+)\.html$ index.php?page=browse&cat=$1
RewriteRule ^browse-([^-]+)-([^\.]+)\.html$ index.php?page=search&s_res=AND&cid=$1&off=$2


OK the top page. FP ext. works fine but as soon as this lower section of code is added I'm unable to connect my local PC FP program to HM servers.

Will contact HM support about this.

Ashley Jezella

[Jezella]

I need the following to work with FP



# Search engine friendly URLs config file for Esvon Classifieds
# You need Apache module "mod_rewrite" installed

Options +FollowSymLinks

RewriteEngine On
RewriteRule ^page-([^\.]+)\.html$ index.php?page=out&id=$1
RewriteRule ^category-([^\.]+)\.html$ index.php?page=browse&cat=$1
RewriteRule ^browse-([^-]+)-([^\.]+)\.html$ index.php?page=search&s_res=AND&cid=$1&off=$2

[Jezella]

I've copied this from another forum and hope that nobody minds. It should be on interest to others with problems to do with FrontPage and .htaccess

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. . . .



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)



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.



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.


Jezella