0
votes

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

1

1 Answers

1
votes

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