-
Notifications
You must be signed in to change notification settings - Fork 808
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Contact form: cannot insert a form using do_shortcode #102
Comments
Form only processes when it is coming from a widget or when the shortcode is in the comment. |
@jeherve do you have time to test this? |
I'm afk until next week so I wouldn't mind if you could check for me. |
Whoops. You should not be checking your messages then! |
Yep, I'm still having this issue. Contact form appears on page, but message doesn't send. |
I wonder if the best way to resolve this may be an option or custom post type or something that we store forms in by a hash of the complete shortcode. It could lead to some legacy cruft for previous versions of a shortcode, but it would ensure that we could always look up on the back-end and see what the contact form looked like. |
This issue still appears in Version 3.1.1... |
It's not a bug, it's an enhancement. The form contents is fished back by scanning the queried post of the page it was submitted to. Without any way of knowing what the form looked like, there's no way to accept the submission. We're considering an alternate data store, but currently it's just not feasible. |
I'm not sure I fully understand why it needs to know what the form looked like in order to store and send the message? |
Because how else would it know what fields to expect? Keep in mind that it does support adding of multiple fields, and we can't trust user input, as they could spoof new fields. Especially as the data gets stored in the database, and not merely emailed out. |
I understand. I guess the solution for the time being is to use a widget instead... |
For me, the form actually sends just fine, it's just sending to the wrong address. Using do_shortcode somehow makes it ignore the "to" parameter. The thing that has me really puzzled is how my address keeps getting the submissions. We've changed the page author, the admin contact, my user account email: I simply have no idea how it's getting my email. |
As an update to @clarklab's previous comment -- we were able to use the following workaround to get our footer form to send to the proper address: |
@lstude I think your workaround might help me here, but my contact form is on the single template for a custom post type, so do you think I would have to change the author of every item of my custom post type to make the form work across all instances of it? I've found the same as @clarklab, the |
…ne created in template. There's a Grunion bug that prevents using arbitrary do_shortcode() calls: Automattic/jetpack#102 git-svn-id: https://meta.svn.wordpress.org/sites/trunk/wordcamp.org@386 74240141-8908-4e6f-9713-ba540dce6ec7
…ne created in template. There's a Grunion bug that prevents using arbitrary do_shortcode() calls: Automattic/jetpack#102 git-svn-id: https://meta.svn.wordpress.org/sites/trunk/wordcamp.org/public_html/wp-content/plugins@386 74240141-8908-4e6f-9713-ba540dce6ec7
…ne created in template. There's a Grunion bug that prevents using arbitrary do_shortcode() calls: Automattic/jetpack#102 git-svn-id: https://meta.svn.wordpress.org/sites/trunk/wordcamp.org@386 74240141-8908-4e6f-9713-ba540dce6ec7 git-svn-id: https://github.com/WordPress/wordcamp.org.git@53 a64dc54a-4538-25e2-d9ce-ce57b7db7bff
…ne created in template. There's a Grunion bug that prevents using arbitrary do_shortcode() calls: Automattic/jetpack#102 git-svn-id: http://meta.svn.wordpress.org/sites/trunk/wordcamp.org@386 74240141-8908-4e6f-9713-ba540dce6ec7
…ne created in template. There's a Grunion bug that prevents using arbitrary do_shortcode() calls: Automattic/jetpack#102 git-svn-id: https://meta.svn.wordpress.org/sites/trunk/wordcamp.org@386 74240141-8908-4e6f-9713-ba540dce6ec7
…ne created in template. There's a Grunion bug that prevents using arbitrary do_shortcode() calls: Automattic/jetpack#102 git-svn-id: https://meta.svn.wordpress.org/sites/trunk/wordcamp.org@386 74240141-8908-4e6f-9713-ba540dce6ec7
This issue has been marked as stale. This happened because:
No further action is needed. But it's worth checking if this ticket has clear reproduction steps and it is still reproducible. Feel free to close this issue if you think it's not valid anymore — if you do, please add a brief explanation. |
Still the issue. Just tested with 7.9-alpha. |
This issue has been marked as stale. This happened because:
No further action is needed. But it's worth checking if this ticket has clear reproduction steps and it is still reproducible. Feel free to close this issue if you think it's not valid anymore — if you do, please add a brief explanation. |
The action names that we're hooking to a callback are wrong, they've changed and we haven't updated it. I've added the new ones and left the old ones for backward compability.
This issue has been marked as stale. This happened because:
No further action is needed. But it's worth checking if this ticket has clear reproduction steps and it is still reproducible. Feel free to close this issue if you think it's not valid anymore — if you do, please add a brief explanation. |
Drawn by @davewhitley. Closes #102.
@jeherve I think we can close this issue at this point, as a wont-fix? One can use |
Yes, I think it's a lot less relevant in a world of block-based widgets and the Form block being available to insert in templates in block-based themes. |
Steps to reproduce:
Reported in this trac ticket:
https://plugins.trac.wordpress.org/ticket/1762
The text was updated successfully, but these errors were encountered: