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