Looking at the release notes for CiviCRM 4.7.11 there was a security issue that was fixed to do with these external snippets: https://civicrm.org/advisory/civi-sa-2016-17-manage-csrf-overrides-for-external-profile-forms
The release notes state, though, that existing installations should not have been affected by the update.
I would recommend that you look ...
I found this deep in the recesses of Jira: Standalone Form HTML for Profiles has relative URL. So it was fixed back in 3.0 but must have reverted at some point. As best I can follow, Resources.php builds this via addScriptFile, which calls addScriptUrl, which calls getUrl, which creates the URL by running through the extension manager (CRM/Extension/system....
It's not 100% but you can identify submissions that are local origin by referer in the web logs.
Additionally, any POST that is not from an external form will have a preceding GET for the same form path, while a POST that is a profile submission from remote origin will not. Good opportunity to practice a little awk 😀
This is available under Misc (Undelete, PDFs, Limits, Logging, Captcha, etc.) (CiviCRM >> Administer >> System Settings >> Misc (Undelete, PDFs, Limits, Logging, Captcha, etc.))
Note: Try clearing CiviCRM cache if you still unable to see it under
we found that if we changed the references from "src="/sites/all/modules/civicrm [...] to a complete url, it would work. An alternative solution seems to be to strip out all references to civicrm and just implement it using a form field.
Take a look at CRM_UF_Page_Group::profile().
You want to do that except instead of passing gid (the profile id) through the url you'd make it a function parameter, and then what you want is the value of the $profile variable.
I wonder if it's the recaptcha on the form action page?
My guess is that posting to that page without the recaptcha data (which is what your form does) is going to cause the server to be annoyed, and perhaps there's some kind of code ...