PDA

View Full Version : FrontPage Extension Question / Request...



nhouse
06-12-2004, 07:02 AM
Hello Everyone,

I search regularly through the forum to see what improvements or suggested bug fixes there may be within DA, with it's regard to MS FrontPage. I REALLY enjoy DA and it's continued development and reliability... however... (yea you knew this was coming, right?)

Even though I am not totally bothered with the lack of some of the FP administrative features, a few of my clients are. Ok, all of you old timers here at the forum... have you found any way to combat these issues? Some of you may want clarification of these statements, so for you:

1. Yes, you can install / uninstall the FP extensions through the control panel, BUT it seems that the administrative side does not get copied to the proper place. Regardless, the administrative features do not work.. ie, user management, FP password protection, child web administration, etc. Granted, you can do basic publishing without many errors. Please see the attachment for an example of an administrative error.

2. Also, some of the web-bots seem to be malfunctioning. Example... you can create a contact form in the top level of the FP site... then try creating the same one in a sub-directory and it will not work properly and gives error messages.

3. These issues may not hinder the hard core hand coders or even myself with my mid-level skills... BUT they are pretty hard to deal with some of my clients who are continuing to ask why this doesn't work or that doesn't work.... and the fact that they cannot easily complete the same administrative tasks that they have been used to doing on other servers with the same LAMP environment that I have on my server... with the exception of the different control panel.

To finish this up, I will confess openly here that I'm not a server guru or even as well versed in RedHat as I ought to be... luckily I have others in my office that handle those things. But, I am directly involved with the end users whom use our web services and have to be accountable to them. THUS my lenghty message here with the hopes that someone will help resolve these issues.

I also know that John and his team are working hard to improve DA and add to it's functionality. So please do not get me wrong... I appreciate their product and their efforts. However after reading through other posts I understand that FP may not be as high on the priority list as other features but it is still important to a lot of people... so I wonder if the development team has ever considered outsourcing this problem to other folks who may be able to save us all a few gray hairs? (and I'm certainly not referring to me)

Thank you for taking the time to read over my ramblings and I appreciate your input.

Randy (CCSi tech)
Paying Customer and Fan of DA

nobaloney
06-12-2004, 07:12 PM
I'd bet the problem is none of us understand what FPX is supposed to do on our Linux systems; we just follow install instructions.

I've run servers running FPX under both the Cobalt RaQ and Plesk control panels, for at least four years, and frankly I have no idea what I should be looking for or seeing.

I've never had a client complain, but I presume that's because they only do basic publishing.

Does the company that ported FPX say these things should work?

Where is the specific documentation on these issues under Linux?

Jeff

nhouse
06-13-2004, 01:24 PM
Jeff...

I am also unsure of how the FP extensions are copied when you execute the "install frontpage extensions" script in the DA control panel. I am not sure if there is an installer does the work -or- if the script simply copies files from a directory somewhere in an attempt to replicate the process on demand.

I do know that on other boxes running Linux / Apache / MySql / PHP with control panels like Cpanel, the administrative features work. This is the thing that befuddles me... if it works on one box, it should on the other... unless the DA panel has a much different file architecture, but those things are way beyond me.

Input from anyone else... please?

nobaloney
06-14-2004, 10:35 AM
I agree nhouse.

Do you want me to give you a testing account on my testing server, so you can see if the problem is just with your box and if FPX works on my testbed system?

Jeff

digilexic
07-17-2004, 06:23 PM
I am having similar problems with FP...first of all being that forms will ONLY work when acessed via http://www.domainname.com, if someone comes into the site via http://domainname.com (without the www) and tried to fill out the form, they are greeted with a username/password popup.

I also do not have any of the web administration functions working.

Has anyone found out more about this in the past month?

nhouse
07-17-2004, 07:47 PM
Hi, unfortunately this must be way down in the priority list for the developers. I did figure out a way to make sure my forms work. BUT it is still important to me to be able to use the administrative functions that FP offers. I sure wish that John and crew would fix this situation. It would give me more of a reason to brag on DA to folks ;)

DirectAdmin Support
07-19-2004, 01:54 PM
Hello,

What's the "official" way to access the admin section? I believe I have seen it working on our build system, but that was after several hours of poking (can't say I remember what I did to get it to work). I'll take another look at it, but you can try installing the extensions again. I do know that I changed the install process for them a few months ago. (not the per-domain extension.. the whole program with customapache)

cd /usr/local/directadmin/data/customapache
./build update
./build frontpage_ext

Give that a try and let me know how the admin section is *supposed* to work and what it isn't currently doing :)

John

nhouse
07-20-2004, 04:37 AM
John...
Thank you so much for the reply. I will be quick to say that I am not an expert on the matter... but I will provide you with as much info as I can to try and get these issues worked through. FP can be a bother at times, even for me... but some of our clients really do need those functions to work for them. I will post more here later today.

skruf
07-20-2004, 05:16 AM
Hey,

This may or may not be relevent...

I compared the FP default Virtual container, from a RH 9 box w/FP, with the FP default Virtual container on a DA box and here's what the one on the RH 9 box had:

<VirtualHost _default_:8090>
DocumentRoot /usr/local/frontpage/version5.0/admin-exes
DirectoryIndex fpadmcgi.exe
MIMEMagicFile /dev/null
<Directory /usr/local/frontpage/version5.0/admin-exes/>
AddHandler cgi-script .exe
Options ExecCGI
AllowOverride All
</Directory>
</VirtualHost>

Also, in each of the Virtual containers that have FP installed these are in the container:

MIMEMagicFile /dev/null
<Directory /var/www/virtuals/domainname.com/public_html>
AllowOverride All
</Directory>

The only difference is the: MIMEMagicFile /dev/null and AllowOverride All.

I'm not sure if this helps but, it's a start!

David

nhouse
07-20-2004, 03:04 PM
John...
I am attaching three different screen shots to three separate replies so that you can see a bit more detail, I'll also try giving a short description about each one. I am using my own account as the test subject. Oh, I have removed and applied the extensions a couple of times. I have even deleted and recreated accounts just to test this out.

First screen shot is attached to this message. It shows how a client would typically access the FP admin feature. You access it directly from within the FP application... please see the attached image.

nhouse
07-20-2004, 03:09 PM
Second screen shot is what we get now when we try to bring up the admin area. You get the old "page cannot be found" error. In the image attached you can see where it tries to execute from.

Normally the EXE would generate a page in the end user's browser where they can create users, authors, etc. and set unique permissions for each. Also, and this is very important to some people, you use this tool to create FP "child webs."

nhouse
07-20-2004, 03:14 PM
Third screen shot is of the directory where the EXE should be... but isn't. I assume that when the FP extensions are applied, the executables should be copied to:

_vti_adm (and) _vti_aut

nhouse
07-20-2004, 03:27 PM
Sorry for the multiple posts... but I think you might like to see these screen caps.

Here is a screen cap from another account that I manage on a different server system. It shows what "should" be displayed in the client's browser.

John, if I can give you any more info at all to help with this, just let me know.

DirectAdmin Support
07-21-2004, 01:23 PM
Hello,

Alright, I've just tested it on our test system to the fpadmcgi.exe and I can confirm it *does* work *without* the file being there.

I'm pretty sure it's using the /usr/local/frontpage/version5.0/exes/_vti_bin/_vti_adm/fpadmcgi.exe file.. because I renamed it temporarily and it stopped working, then changed it back and it worked again. So it appears as though mod_frontpage handles the path for you.

Let me know if you have that file.. or if creating it (and path) works for you.

John

nhouse
07-21-2004, 07:48 PM
Hmmmmmmmmm...
John, thanks for the information. I can tell you as well that ours is not working. Let me look into the data that you listed and see if everything is the same on our server and I'll let you know what I find.

"If" we discover that it is a problem with our installation of DA, what would we do to correct it? Well, I guess you can address that after I investigate further. Thanks again for your assistance.

EDIT: DUH! I guess that is what you were telling me in the message above... sorry!

skruf
07-21-2004, 07:58 PM
Hey,

Well, I did some testing with one of our sites and it does work using:

http://www.domain.com/_vti_bin/_vti_adm/fpadmcgi.exe

That was from a browser and not within Frontpage.

But, shouldn't we be able to access it via:

http://www.domain.com:8090

as well... That doesn't work...

On the site we tested it on we did uninstall and reinstall the extensions before trying it. It wasn't working prior to that.

David

sonomalinks
07-25-2004, 08:29 PM
Yes, I am also having some similar problems. One is the form asking the user for a user name and password if they access the website without the www.

Also, when I publish through FrontPage I get "an error occurred accessing your Frontpage web files. Authors - if authoring...
"WebMasters - please see the server's system administrator.

nhouse
07-26-2004, 04:31 AM
Ok, folks... I have run the commands:

cd /usr/local/directadmin/data/customapache
./build update
./build frontpage_ext

I have also tried opening straight from a browser and I still can't access the administrative EXE's. Let me do a wee bit more investigation and I'll reply in a while. PLEASE continue following this thread... thanks!

sonomalinks
08-15-2004, 06:41 PM
Originally posted by nhouse
Hi, unfortunately this must be way down in the priority list for the developers. I did figure out a way to make sure my forms work. BUT it is still important to me to be able to use the administrative functions that FP offers. I sure wish that John and crew would fix this situation. It would give me more of a reason to brag on DA to folks ;)

Hello,
So what was your solution to the forms not working correctly when someone types in http://website.com instead of http://www.website.com

Do you have to edit the .htaccess file with some kind of redirect or is there a better fix?

Thanks,

Mark

rldev
08-16-2004, 12:34 PM
Hmm FP problems. Any word on correcting these issues? My clients have been using FP on a linux machine for many years with very little problems. They have full administrative access as well. This is very important to get right. You should be able to submit a form regardless if you accessed the site via www or not.

nobaloney
08-16-2004, 07:22 PM
Originally posted by rldev
You should be able to submit a form regardless if you accessed the site via www or not.
While I'm NOT a FrontPage expert, I believe the only way you can guarantee an FPX website will work the same way with and without the host extension (usually www) is by rewriting example.com to www.exmaple.com.

That's because FPX understand the website as www.example.com, and NOT as example.com.

Jeff

nhouse
08-17-2004, 06:33 AM
Gentlemen...

To be clear... my issues ARE that the administrative portion of FP isn't working properly. I can make the forms work fine now. What I had to do to achieve this was to go into the form properties on the "live" site and point (browse) to the resulting "form_results.htm" file. It sounds a little odd but that makes it work for me. Now, if I can get the other features to work... ;)

rldev
08-17-2004, 08:53 AM
Originally posted by jlasman
While I'm NOT a FrontPage expert, I believe the only way you can guarantee an FPX website will work the same way with and without the host extension (usually www) is by rewriting example.com to www.exmaple.com.

That's because FPX understand the website as www.example.com, and NOT as example.com.

Jeff

What do you mean by:

"rewriting example.com to www.exmaple.com."

?

nobaloney
08-17-2004, 10:16 AM
My apache books are buried somewhere and I don't have time to look for them right now.

You can look up "Rewrite" in apache documentation; it'll give you the information you need so that when someone types "example.com" into their browser, it'll be changed to www.example.com.

Jeff

rldev
08-17-2004, 11:11 AM
Ok I didn't know you were talking about mod_rewrite. I have Fp extensions installed on my current server(No DA). FP Admin works and no mod rewrite is needed for FP to function with or without "www". Is it possible that FP has a problem with the way DA configures the Vhost entries? I really haven't heard of this being a problem on the other major control panels, not that FP doesn't have a boatload of issues. I can even publish to FP via ip address.

nobaloney
08-18-2004, 10:35 AM
The only control panels I've ever used with FPX do an automatic rewrite; you type in example.com, and it gets rewritten by www.example.com.

My explanation was a paraphrase of stuff I've read elsewhere.

As I've written previously, I'm not an FPX expert, and I don't use it myself, so I guess I'm at the end of what I can help with, outside of a paid support request I can send on to my FPX expert.

Jeff

rldev
08-18-2004, 11:19 AM
Thanks Jeff. It might be worth paying for to have this looked into. I will see what I can dig up over the next week.

nobaloney
08-18-2004, 02:27 PM
Please don't consider my post as a solicitation. I think this is something we could pass on to DirectAdmin support and get a response from them.

Have you tried that?

Jeff

rldev
08-18-2004, 07:39 PM
I was not offended by anything you said. I didn't take it as a solicitation. I have passed it on to DA Support and their response was as if this is isolated. When I get things rolling a bit, I will see if I can work with them on this.

digilexic
08-18-2004, 09:12 PM
I have passed it on to DA Support and their response was as if this is isolated.

I can assure you this is NOT the case, as I have the same problem...

My temporary solution was to setup the site with 2 Index pages...one called index.html and one called index.htm

index.html is the one that pops up by default if you just type www.domain.com OR domain.com (minus the www) in your browser, so I set it to automatically forward them to http://WWW.domain.com/index.htm that way if they came in without the www, it is now there.

Since the frontpage forms ONLY work when the www is present on the domain, all my pages now have explicit URL's with the whole domain as part of the address instead of relative URL's that only list page and directory, in case someone comes in to a page from a search engine and its not corrected by the autoforward.

rldev
08-19-2004, 06:47 AM
Wow a lot of patch work. These types of issues can really hamper moving my fp clients to DA.

I will not assume, but this seems to be related to the DA implementation. Is there anyone who doesn't have a problem with this whole "www" alias thing?

nobaloney
08-19-2004, 10:06 AM
Originally posted by rldev
I was not offended by anything you said. I didn't take it as a solicitation.
Glad to hear it.

If you'd like I can temporarily give you a domain account on one of my systems and you can try an FPX site there, to determine if the problem is local to your machine or not.

Let me know by private email (address below in sig) if you'd like me to set up an account for you to test.

Jeff

sonomalinks
08-19-2004, 10:32 AM
It's definitely not an isolated case because I have the same FP forms problems. Also, I have seen other posts with the same problem. If people come in without the WWW they are welcomed with a pop-up that asks them for the user name and password.

I don't know much about the server end but it seems that there should be some kind of rewrite for the apache server or mod with DA so that all users using FrontPage don't have to make modifications.

Mark
Sonomalinks.com

sonomalinks
08-19-2004, 10:42 AM
It's definitely not an isolated case because I have the same FP forms problems. Also, I have seen other posts with the same problem. If people come in without the WWW they are welcomed with a pop-up that asks them for the user name and password.

I don't know much about the server end but it seems that there should be some kind of rewrite for the apache server or mod with DA so that all users using FrontPage don't have to make modifications.

Mark
Sonomalinks.com

rldev
08-26-2004, 05:05 PM
Well the good news is that John got my FPAdmin working well. DA is going to add a link in the FP portion of the cp to access the FP admin.

So really the only issue that will remain is the www alias problem. I have to say it is strange indeed. I have looked at a handful of non DA systems and I can not figure out what the problem is. Jeff you mentioned coming accross some data on the Net about this? I couldn't find anything. Maybe some links handy?

Folks, John is definitely working on this issue, he wants to get it corrected.

I suppose at the very least the FP extension setup could put a redirect in the .htaccess file. However, this is not a fix, but a patch.

rldev
08-26-2004, 05:07 PM
BTW,
Can anyone verify that the FPAmind does not work in the FireFox Browser. Every time you go to execute a command it just spits out a coded page.

nobaloney
08-26-2004, 08:57 PM
I'm sorry, I just don't have any further information on FPX. I'm willing to let you set up an account on one of my servers for testing purposes. Please let me know if you're interested.

Jeff

rldev
08-27-2004, 05:21 AM
Hello Jeff,
Thanks. I have a couple of accounts setup on different servers. This was something I was just trying to make others aware of and wanted to confirm.

DanB
11-09-2004, 05:12 PM
Hi guys,

I hate to open this up again, but I can't seem to get the
Frontpage Admin link to function.

When I click on it, it asks for the username and password,
after entering it I get "The page cannot be found" page.

[DA v1.23.0]


Thanks

Dan

nhouse
11-09-2004, 05:38 PM
Hi Dan... I have been having this same issue (as you described) for months. I have tried a couple of things that John suggested and it made NO difference. It is VERY frustrating... especially when you deal with a lot of clients who really need FP to work properly... I get tired of coming up with work arounds and giving excuses to my clients about why FP doesn't work properly on my server.

I have been quiet for several weeks now about this issue because I have more or less given up on it. I hope that at some point the DA team will resolve it though as I believe there will always be people who need FP. What really bugs me though is the fact that some people seem to have all of the functionality built into FP... and some of us do not.

DA 1.23.1

DanB
11-10-2004, 06:05 AM
Well, Front Page and I have never liked each other. This is the first customer that has requested it.

I'm not even sure if they can get by without having the admin link.




Dan