0

So, I posted this issue last week regarding duplicating headers. I have fixed this issue I do believe but now it's kicking back a new error that I can't seem to solve. I fixed my last issue by stripping out the headers being added a second time inside the PHP of the form submit function and only allowing them to exist in the htaccess.

The only header that exists in the form submit PHP is the setting of the Content-Type to be application/json.

When I submit my form, the submitting message pops up fine. Then when the form submits/fails it does not pass back the message contained within the amp-mustache template tags.

    <div submitting>
      <template type="amp-mustache">
        Form submitting... Thank you for waiting.
      </template>
    </div>

    <div submit-success>
      <template type="amp-mustache">
        Thanks, your message has been sent successfully.
      </template>
    </div>

    <div submit-error>
      <template type="amp-mustache">
        Unfortunately your message could not be sent. Please try again later.
      </template>
    </div>

After a bit of looking around it seems to indicate that my Content-Type is not set to application/json on my PHP that submits the form but when I check the Network tab in Chrome all appears well as far as the headers are concerned.

Response Headers for PHP (xhr-contact-test.php) that submits the form:

access-control-allow-credentials: true
access-control-allow-headers: Content-Type, Content-Length, Accept-Encoding, X-CSRF-Token
access-control-allow-methods: POST, GET, OPTIONS
access-control-allow-source-origin: https://www.craigattachments.com
access-control-expose-headers: AMP-Access-Control-Allow-Source-Origin
amp-access-control-allow-source-origin: https://www.craigattachments.com
cache-control: max-age=604800
cf-railgun: 4d68972973 0.01 0.656948 0030 cc99
cf-ray: 4de04cf54e22ccfe-EWR
content-encoding: br
content-security-policy: default-src * data: blob:; img-src * 'self' data: https: https://static.craigmanufacturing.com; script-src 'self' 'unsafe-inline' 'unsafe-eval' blob: https://cdn.ampproject.org/v0.js https://cdn.ampproject.org/v0/ https://cdn.ampproject.org/viewer/ https://cdn.ampproject.org/v/ https://cdn.ampproject.org/rtv/ https://static.craigmanufacturing.com *.google.com https://maps.googleapis.com/maps/api/js/ https://maps.googleapis.com/maps/api/place/js/ https://cdn.polyfill.io https://cdnjs.cloudflare.com/ajax/; object-src 'self' https://www.craigattachments.com/pdf/; media-src 'self' https://www.craigattachments.com/pdf/; plugin-types application/pdf; style-src 'self' 'unsafe-inline' https://static.craigmanufacturing.com https://cdn.ampproject.org/rtv/ https://fonts.googleapis.com/; base-uri 'self';
content-type: application/json
date: Tue, 28 May 2019 12:41:04 GMT
expect-ct: max-age=604800, report-uri="https://report-uri.cloudflare.com/cdn-cgi/beacon/expect-ct"
expires: Tue, 04 Jun 2019 12:41:03 GMT
feature-policy: microphone 'none'; payment 'none'; geolocation *; sync-xhr 'self' https://www.craigattachments.com
referrer-policy: same-origin
server: cloudflare
status: 200
strict-transport-security: max-age=31536000
vary: User-Agent
x-content-type-options: nosniff
x-frame-options: SAMEORIGIN
x-xss-protection: 1; mode=block

The error it's passing back is below and points to line 1073 on the amp-form.js which is the function that sets the i-amphtml-rendered attribute on the appropriate amp-mustache template tag. Looking into that is what lead me to thinking the content-type is what was causing the issue but that now appears to be set correctly and the error persists.

Uncaught (in promise) TypeError: b.setAttribute is not a function

I have opened up my testing contact form at this link: https://www.craigattachments.com/contact-us-test/.

Any thoughts on where I should go next? I have tried a few things such as testing for the existence of certain headers, setting the Content-Type inside my htaccess and setting my headers only in the PHP.


Solution for anyone else that gets hung up on this... If you echo out your email as an array such as echo json_encode(array($email)); this error occurs. Taking the array out of the equation seems to fix it for me anyway - echo json_encode($email);


Update 2019/06/12: Huge thanks to Aaron. This issue has been given some better error handling parameters should anyone run up against this in the future: https://github.com/ampproject/amphtml/pull/22576

Craig Scott
  • 892
  • 4
  • 14

1 Answers1

1

I took a quick look and it looks like the returned object from the renderTemplate method is an array as opposed to an element.

enter image description here

https://github.com/ampproject/amphtml/blob/master/extensions/amp-form/0.1/amp-form.js#L1121

Possible there is a bug in the code. Inspecting the divs, it looks they are all the same success message as well. Is it possible to reproduce this is a much simpler form demo, with just just the bare minimum to reproduce. e.g. just the form Thanks

Aaron L.
  • 151
  • 4
  • Here's the stripped down version: https://www.craigattachments.com/test-form.php. Sorry it took me so long, was away on lunch. – Craig Scott May 28 '19 at 16:19
  • 1
    thanks Craig, I can reproduce with your JSON post data set and it looks to be a bug, I'll file an issue and will look into fixing it. Will update with more details later today. Thanks – Aaron L. May 29 '19 at 12:08
  • Filed an issue https://github.com/ampproject/amphtml/issues/22570. It looks you unintentionally hit a code path that should never work with amp-form. Is there a reason why you return a JSON array with your post end point? https://www.craigattachments.com/xhr-contact-test.php Changing that will fix the issue...though obviously we will fix it on our end. Thanks for the demo. – Aaron L. May 29 '19 at 19:04
  • Honestly, not entirely sure why we return it through a JSON array. I wasn't involved in the base set-up of the form, just helped make it send and am now working on sweeping back through the website to fix some things. I'm playing about 3 extra roles this week at work, but I'll go digging next week and see if I can come up with a better answer. Thanks for filing the issue, I subscribed to it to keep up to date on its progress. – Craig Scott May 29 '19 at 19:16
  • So, I legit have no clue why it was being passed back as a JSON array. I removed the array and all is good now. `echo json_encode(array($email_subject, $email_address, $html_email, $email_name))` became `echo json_encode($html_email)` and my error messages appear to be functioning normally. – Craig Scott Jun 04 '19 at 19:28
  • Sounds good. Yea I am not sure where we stand as far as whether we should allow that but I am going to go ahead and make the code change to assert that the submit-[state] template is an actual element that can be rendered so that at least there is an error message that is useful if that isn't the case. Thanks Craig – Aaron L. Jun 05 '19 at 20:17
  • Yeah, a useful error message would be great. I'll leave the test form up until I see the issue you posted has been closed. Thanks for your help, Aaron! – Craig Scott Jun 07 '19 at 11:42