Can I safely add hand-coded html to a FP webpage?

Will including my correct html form script break FP?

[Wizcrafts]

I have been approached regarding adding my guestbook code and Perl script to a FrontPage web. The existing form codes I received are not working and horribly bloated by FP and full of "webbots." The prospective client wants to have a form for people lacking an email client, so they can choose from a selection of 13 recipients, to have a textarea for comments, then submit the form and have it email the output to the selected recipient. This is exactly what my guestbook/comments form does, but it is written by hand in standards compliant HTML.

My HTML is all hand-coded in NoteTab Pro, to HTML 4.01 Strict or Loose standards and this form POSTS to a renamed Perl script, in the cgi-bin, which is secured against formmail phishers, CHMODed to 711, and which allows for numeric email aliases to be used in the html form to hide the recipients addresses from email harvesters.

I do not have or use FrontPage. How can I safely go about including my standards compliant form codes into the existing FP webpage without breaking the webbots and server extensions? Can I ftp the Perl script to his server and chmod it as needed, and have it work with the modified form page? Or, must these operations all be done from within FrontPage, by editing the source, then uploaded by FP http?

TIA from a non-FP webmaster

[bill]

Sounds possible.

It would probably be best to get the HTML into the client's template via FP if they use any extensions on the page. They can set the FP options not to alter any HTML and you should be safe with later versions of the product. Uploading of the page should be done through FP so as not to mess up their server extensions. Accessing the server to upload scripts and CHMOD things will depend on the server, but I've done it on an Apache server with FP extensions without any corruption of the extensions.

[jim_w]

I believe that if they are running FrontPage97, they cannot turn off the webbots thingy. A lot of people I find never upgraded to Office higher than 97, so they have FP97 on their machines still.

Just FYI

[Wizcrafts]

Thanks for the answers guys.

I believe they are using FP 97. The code I was sent says FrontPage version 4. If that is FrontPage 97 does that mean that they cannot use any code I might send as is?

I have never seen such code bloat as this one page exhibited! A simple contact form, with Name, and Comments fields, a header and sidebar occupies 17 KB in FP. My advanced guestbook script, typed in NoteTab Pro, with a long list of recipient options, hidden fields for data and multiple input fields is just over 8.5 kb.

[pageoneresults]

I have never seen such code bloat as this one page exhibited! A simple contact form, with Name, and Comments fields, a header and sidebar occupies 17 KB in FP

What you are probably seeing is FP's confirmation scripts. If the client has validation set for the form fields, those webbots are controlling all of the validation aspects of the form. It could be the number of characters allowed, a minimum number of characters, maybe the field only allows integers, etc.

I wouldn't really classify it as bloat. If you take an external validation script and configure it so that it performs the same functions as the FP validation bots, I believe you may end up with similar file sizes after all is said and done with.

[jimbeetle]

Version 4 is FP 2000.

Not sure if this will help in your situation but you might have them paste your code into the page using the FP Insert > Advanced > HTML Markup command. This adds tags that tell FP not to mess with this code.

[Wizcrafts]

What you are probably seeing is FP's confirmation scripts.

Here is a snippet of code showing only the actual Form HTML. I don't know if it has any calls to a validator, but I can't see anything like that anywhere in the entire webpage.

<form onSubmit="" method="POST" action="--WEBBOT-SELF--">
<!--webbot bot="SaveResults" startspan s-label-fields="TRUE"
s-builtin-fields="Date Time REMOTE_NAME REMOTE_USER HTTP_USER_AGENT"
s-form-fields S-Email-Format="TEXT/PRE"
S-Email-Address="[e-mail]" --><strong>[FrontPage Save Results Component]</strong><!--webbot
bot="SaveResults" endspan -->

Here is the code FP produced to create the input and comments fields, not including dozens of lines for the inoperable radio buttons for recipients:

     <p class="mstheme" style="word-spacing: 0; text-indent: 0; line-height: 100%; margin: 0" align="left"> </p>
     <p class="mstheme" style="word-spacing: 0; text-indent: 0; line-height: 100%; margin: 0" align="center">Enter your comments in the space provided below:</p>
         </center>
     <dl>
     <dd>
      <p class="mstheme" style="word-spacing: 0; text-indent: 0; line-height: 100%; margin: 0" align="left"><textarea name="Comments" rows="5" cols="32"></textarea>
      </dd>
     </dl>
     <p class="mstheme" style="word-spacing: 0; text-indent: 0; line-height: 100%; margin: 0" align="center">Tell us how to get in touch with you:</p>
     <dl>
      <dd>
      <table cellspacing="0" width="273" cellpadding="0">
       <tr>
       <td align="left" width="46">
        <p class="mstheme" align="left"><font color="#FFFFFF">Name</font></td>
        <td width="230">
        <p class="mstheme" align="left">
        <input maxLength="256" size="28" name="Username"></td>
        </tr>
        <tr>
        <td align="left" width="46">
         <p class="mstheme" align="left"><font color="#FFFFFF">E-mail </font></td>
         <td width="230">
         <p class="mstheme" align="left">
         <input maxLength="256" size="28" name="UserEmail"></td>
         </tr>
         <tr>
         <td align="left" width="46">
          <p class="mstheme" align="left"><font color="#FFFFFF">Tel</font></td>
          <td width="230">
          <p class="mstheme" align="left">
          <input maxLength="256" size="28" name="UserTel"></td>
          </tr>
          <tr>
          <td align="left" width="46">
           <p class="mstheme" align="left"><font color="#FFFFFF">FAX</font></td>
           <td width="230">
           <p class="mstheme" align="left">
           <input maxLength="256" size="28" name="UserFAX"></td>
           </tr>
          </table>
          </dd>
         </dl>
   <center>
          <p class="mstheme" align="center">
          <input type="checkbox" value="ContactRequested" name="ContactRequested">
          Please contact me as soon as possible regarding this matter.
          <p class="mstheme"><input type="submit" value="Submit Comments">
          <input type="reset" value="Clear Form"></p>
         </form>
         </center>

[Wizcrafts]

Version 4 is FP 2000.
Not sure if this will help in your situation but you might have them paste your code into the page using the FP Insert > Advanced > HTML Markup command. This adds tags that tell FP not to mess with this code.

Thanks JimBeetle, that does help.

[Wizcrafts]

Here is a sample of what I call bloat. There are several dozen of these lines of styled paragraphs, all repeating the same style attributes instead of creating a class in the HEAD and using class="".

<p style="word-spacing: 0; text-indent: 0; line-height: 100%; margin: 0"> </p>

[jimbeetle]

FP doesn't usually apply these by itself. Looks to me like somebody initially styled a paragraph and then that was carried throughout the document.

You might suggest to your client that they clean up the formatting restyle attributes in an external CSS.

[pageoneresults]

Actually your client is using FP's inline styling tools. This is part of the WYSIWYG environment and yes, it can create code bloat if not used correctly. In this instance, it is being used correctly as inline styles need to be applied to any element needing style.

External css (as jimbeetle points out) is definitely the way to go for your client if they have repeating inline styles all over the place.

P.S. Just saw the code you posted above. It appears that your client is using a Microsoft Theme which will create all sorts of code bloat that not even external css will help with. They will need to break away from the theme and reformat using FP includes if you want to eliminate the bloat from the theme.

[Wizcrafts]

I always create stylesheets for any websites I create, but I had nothing to do with creating this one, and may not be involved any further with it. I was simply pointing out the bloat that FP has created, with the choices the original user has made.

I frequently run HTML Tidy on imported webpages like this, and have it set to create css rules to replace font tags, empty paragraphs, center, etc. HTML Tidy embeds into NoteTab Pro, plus various HTML and CSS validators and spelling checkers. Once I find a common theme across multiple pages I move the css to external scripts, and ditto for javascript.

I have never used a WYSIWYG editor.

Thanks again for the suggestions regarding my interaction with FrontPage 4.

[jim_w]

Can't he just put every thing between a couple of webbots and treat it as unvalided HTML?

[bill]

Can't he just put every thing between a couple of webbots and treat it as unvalided HTML?

If they do that then you have to remember to do all of your styling inline. Those webbot HTML/Code inserts only work between the

<body>

tags.

...oh and it's not unvalided HTML, it's just marked so that FP won't alter any code entered between those tags made by the WYSIWYG. It's a way to preserve the original code/script that's been around since the earliest days of FP.

[jim_w]

>unvalided HTML

Your right, I stand corrected. I should have said markedup HTML.

[davegerard]

Up until FP2000, FrontPage had a tendancy to hose up code with it's auto-formatting feature. You'd leave a delimiter out and rather than having the page simply error out, it would practically rewrite the whole page moving your code to where FP thought it should go. I never could figure out how to disable that feature, if in fact there was even a way. Anyway that went away with FP2000. If you're using FP97 or FP98, I would almost recommend NOT inserting your code from FrontPage at all. If you do, make a backup first.