Various issues with netlify forms

Support
1

Original issue (see others further down): Data-netlify & (data-)netlify-honeypot NOT removed during deploy

In benomatis-stage (site now removed), a gatsby site, form attributes data-netlify and (data-)netlify-honeypot are not removed, despite relevant documentation stating the contrary:

In the resulting HTML that’s deployed, the data-netlify="true" or netlify attribute is gone, and the hidden form-name input’s value matches the name attribute of <form>…

Source: Forms setup | Netlify Docs

When Netlify parses the static HTML during post-processing, the build system automatically strips the netlify-honeypot attribute from the <form> tag…

Source: Spam filters | Netlify Docs

2

@benomatis Is Gatsby actually creating a static version of the form that can be parsed by the Netlify build process?

If the form is only being injected into the page at runtime by Gatsby operating as a SPA (Single Page Application), then the form won’t be getting seen/processed.

See:

You could verify by doing a local build and then searching your output files to see if the form exists as plain html.

3

Yes, it does exist, but I’m wondering, would netlify form submissions work if the form wasn’t present? Because, as indicated, submissions work just fine, it’s just that the said attibutes are still there when I inspect the HTML elements on the resulting page.

4

@benomatis Netlify forms works primarily off of having detected a static form during the build process.

Netlify modify the static files that they detect during the build, so if they encounter a .html with a <form> with the appropriate attribute, it gets rewritten to remove the attributes as indicated in the documentation.

Meanwhile Gatsby may rendering a dynamic version of “the same form” at runtime and still inserting those attributes on the form, Netlify won’t be detecting/removing those, because they’re coming from JavaScript, (which Netlify didn’t look through), and are happening at runtime.

5

Do you mean if it’s gatsby, it won’t be removed? It’s a simple component with a form inside with the appropriate settings that ultimately make it work when deployed. Or would the attribute removal only work on fully static HTML files that do not involve site generators at all? If so, that should probably be corrected in the doc.

6

@benomatis I’m not too sure what you’re asking, in terms of, where you believe the distinction is between static and dynamic.

The “static file” that Netlify parses could be a plain text file (having used no generator) or it could be generated by anything, so long as it exists in plain HTML in the Deploy directory after the build so that it can be parsed.

All I’m indicating is that if Gatsby (or anything else) has also stored a representation of the form that it “creates at runtime from JavaScript”, then Netlify won’t have modified that JavaScript in a way where it “generates a different form”.

I’m not aware of your specific form, so it’s possible there’s a bit of a miscommunication here, I’m just trying to explain how Netlify’s system is predicated on processing a static file and has little to do with runtime functionality.

7

Well, I think it’s super confusing, but apparently your work differently, so let me pull in the other issues I have with forms:

  1. Netlify-honeypot or data-netlify-honeypot?:
    The blog post on setting up forms in React appears to indicate 2 variants for the honeypot attribute, and I’m not sure which one is the correct one.

    netlify-honeypot or data-netlify-honeypot?

  2. Netlify form 404 with netlify dev (gatsby site):
    I successfully added a form, but when trying to use it in local development (netlify dev ), submitting the form just hits 404, though the console log for success does show. Is this supposed to happen like this? Is this the most I can get out of local testing? So if I get the parts executed in the .then part of the fetch sending the form, I should be good?

  3. Netlify forms notification subject provided in HTML form ignored:
    The subject line I provided in a hidden input, as instructed in the doc, is ignored when setting up notifications, even though during the notification setup it does indicate the form already has a subject line. I tried recreating the notification entry, or even selecting it to only kick in for the specific form, but nothing changed it. Interestingly if I did set it in the UI, the subject was respected, despite the fact the UI message stated it would be overriden by the value in the HTML form.

8

For the original topic (let’s call it No 1, for clarity’s sake), below is my form - is there any reason why netlify would not remove said attributes? I have no special webpack setup, nothing fancy, I simply push to the repo, and netlify does it’s magic, normally.

import React, { useState } from "react"
import { useForm } from "react-hook-form"

const ContactForm = () => {
  // ...

  return (
    <div className="form-wrapper">
      <form
        name="contact"
        method="post"
        data-netlify={true}
        data-netlify-honeypot="real-name"
        // ...
      >
        <input type="hidden" name="form-name" value="contact" />

        <input
          type="hidden"
          name="subject"
          value="New %{formName} form message from %{siteName}"
        />

        <div style={{ display: "none" }}>
          <input name="real-name" />
        </div>

        <input placeholder="email" name="email" />

        <textarea rows={3} placeholder="message" name="message" />

        <input type="submit" value="Send" />
      </form>
    </div>
  )
}

export default ContactForm
9

#2 - A Netlify staff member would be able to confirm, but I know from experience that the blog articles aren’t maintained in the same way the documentation is. So you should preference the documentation.

#3 - This is the support guide everyone gets pointed to when they encounter this (and generally all form issues).

#4 - I don’t actually work with Gatsby or Netlify Forms, so can’t say for certain, you could take a look at this thread which mentions the same issue. If that doesn’t help (or searching for other similar threads) I’d imagine Netlify support will be able to point you in the right direction.

10

Yes, there is.

That’s a reactive form, declared in JavaScript.

Netlify will never process that file.

The “static HTML output” of that file (if Gatsby is making static HTML output of that file), is what would be processed and have its attributes modified at build time.

When Gatsby then renders your page at runtime, it may be using a compiled JavaScript version of your form component/page to do so reactively, it’s not necessarily actually navigating to a compiled HTML version of your page.

1 Like
11

  1. The same blog post mentions both variants of the attribute in 2 different places, so I guess data-netlify-honeypot must have been a typo made in the article as the doc has netlify-honeypot.

  2. That guide has no info on local testing specifically, as the form is all ok when deployed, I only get 404 while testing locally using netlify dev.

  3. Yes, that thread is exactly the same, but it has no solution, the OP didn’t reply to the question from support. For me the subject is Form submission from contact form: (seems to be the default to me, I have never set this anywhere) if I omit the relevant field in the UI and despite the fact I do have the relevant hidden field present in the HTML form.

12

#2 - I’d work under that assumption, just use netlify-honeypot - if still concerned you could easily do a plain HTML file test to confirm that it sees and removes netlify-honeypot

#3 - I see no mention of netlify dev in the forms documentation, and no mention of forms in the netlify dev documentation, my assumption would be that you cannot test forms with netlify dev and that seems to be confirmed by this post

#4 - You probably have already, but when submitting the form you could look at the request in your network tab and confirm what values are being submitted.

1 Like
13

  1. All ok now, I decided slimming down the form tag, as I realized I didn’t need a whole lot of the things, as I kind of mixed the normal HTML form implementation with the JavaScript / AJAX one, and with the latter one you really only need to send stuff through the post request, so those attributes won’t be needed to be added to the actual form tag.

  2. Yeah, I just tested it and the correct attribute appears to be netlify-honeypot indeed. Again, sending this through as part of the object inside the post request’s body appears to do the trick.

  3. It’s been introduced a couple of months later that statement has been made: Add support for form submissions by RaeesBhatti · Pull Request #780 · netlify/cli · GitHub. The post request still gives me 404 locally, but otherwise everything else works fine, ie. I can inspect the request payload in devtools, and everything is happening as desired as part of the success (.then()) callback of the post request.

  4. You were right, I just realized I forgot to send the subject through with the fetch post request. Thanks a lot again!

14

Excellent, great work @benomatis

With #3 I was thinking more in terms of netlify dev doing the parsing and processing side of form handling (what happens during a build process), not so much the catching/routing of the form submission.

15

on 3, not sure what it’s supposed to and not supposed to do, tbh, would be great to actually receive clarification on that from someone…

by the way, I slimmed stuff down so much that I started to receive 404 on the deployed site as well, and no messages were delivered. Back to the drawing board…

16

Ok, I figured it out: I moved the contact form into a popup, and apparently that would not work because the form is not present at build time, I guess. So I’ll have to find a way around that…

I think the issue in “Page Not Found” when submitting form must be the same (the code there shows references to a ‘modal’).

If anyone from the netlify team sees this, I’d really like to get an answer on point 3, what is actually supposed to be possible in netlify dev with forms? Because it’s supposed to be supported, but I don’t see what exactly and how.

17

@benomatis I’m not sure what Gatsby does automatically, I don’t use Gatsby, but you can ensure that a form is detected by…

  • Having a plain HTML form in your index.html page but just visually hidden
  • Having a plain HTML form in a HTML file in your Deploy directory that you never link to anywhere
18

Yes, the problem seems to be the popup, as unfortunately its contents aren’t present, not even hidden, they’re simply not there in the DOM at all, which is why the form was not parsed by netlify.

To netlify support folks: point 3 still open: would be great to see forms in netlify dev being documented somewhere, because it does seem to be supported, but unsure to what extent.

19

(trying to consolidate the many topics I have opened on this, let me reply here):

From Netlify form 404 with netlify dev (gatsby site) - #7 by hrishikesh

That’s unfortunately not true: I have seen the form being submitted in the console, but it actually not being collecting form data when pushed to the live site. I have had to create a separate staging site and test it by constantly pushing to it until I got it right. Simply in dev there is no way to properly test form submission, unless there is something I’m not seeing or looking at that I should.

20

The production environment often differs form the dev environment. If Netlify CLI was able to log the form submission, that would mean that in your local setup, the form works fine. But when you run your build process, something is changed in a way that the form doesn’t work anymore.

While it’s not an actively used feature (testing forms locally), I think I have seen the log myself a few times. But based on this code: cli/src/lib/functions/form-submissions-handler.mjs at cb613a1927b38760f3dd5f084b52889434302c48 · netlify/cli (github.com) and this PR: fix: don’t run form submission logic on paths matching function by Skn0tt · Pull Request #6048 · netlify/cli (github.com), I think we try to parse a POST request as a form submission.