Welcome to WebmasterWorld Guest from 220.127.116.11
Forum Moderators: open
Is there any way to make web forms using FrontPage without using FP SE..? Coz my web server no longer support FP extensions, and i need my forms to work, so if anyone knows how to make web forms using FP without using the FP SE then pls tell me how :(
And i want my web forms to deliver it results to my email ID and also when someone click submit it should go to my custom designed confirmation page.
This is how it use to work when FP SE was there on my sever and since MS has stopped FP SE on linux based severs, lot of web servers no longer support FP SE
Pls tell me how to do this on FP and without using the FP SE
And isn't there anyway to make the form using FP it self and get the results to your email ID without any complex procedures. for an example using the same features on FP to set the mail option and page redirect options to my own custom confirmation page when someone click the submit button?
<form action="sendform.asp" (or sendform.php)....>
Since .asp and .php have different types of "includes" for the custom results form, that is why you would have to make that page manually. Make sense?
If you check W3C Tutorials [w3schools.com], there are some on form processing which may help. There are also some programs that will write the results page and processing script in various price ranges.
Bad news. Not only do you have to insure your Page settings ( Tools - Site Settings - Default Page Encoding ) shows Unicode UTF 8 - etc.
but we've also found - any existing pages with the dreaded < span en-us > will have to be manually removed from the HTML.
It seems that if FrontPage sees the encoding between, in, or near :-) any Paragraph or Table, etc. it will follow in kind and continue to add Span Language between anything you do.
In our 'crazy-making' search for a 'fix' - we discoverd that on the same page - some areas would add the code and another area would not.
It just didn't make sense! - until we looked closely at the HTML in the associated vicinities. Where any < span en-us > codes in any form were present already - FP would continue to add more with any changes made. No pre-existing < span en-us > in the work paragraph, table, background setting, etc. - FP would not add the dreaded Span Language.
This holds true regardless of the afformentioned setting checks and MS Office Updates.
Not sure how Expression Web handles this issue - at present. After a few months of using it - we decided the general 'frustration' factor with Expression Web just wasn't worth any new Bells & Whistles it might have. At least not for our current needs.
Back to manually removing thousands of those insane Span Language tags. Argggg!
Hope that helps! :)