Open jeherve opened 10 years ago
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?
@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. Thanks!
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 do_shortcode
function seems to make the form ignore the to
parameter. Anyone else found any other ways to fix this?
Also i've found that if shortcode is created in page editor - then everything is OK: feedback items created, email sent. BUT if I use same shortcode in php file - form saves, everything is ok, except sending notification to email :-\
<?php
echo do_shortcode("[contact-form to='alex@*****.com' subject='teehljjkhfksdjhkl'][contact-field label='Name' type='name' required='1'/][contact-field label='Email' type='email' required='1'/][contact-field label='Website' type='url'/][contact-field label='Comment' type='textarea' required='1'/][/contact-form]");
?>
@Forket that seems to be a different issue, and I wasn't able to reproduce.
Could you check your server's email logs to make sure the email wasn't blocked when you sent it out.
Could you also try to use a plugin like Postman to send all emails through a different email provider, and see if it helps?
Thanks!
Also reported here: #2678300-t
The issue is still there. Jetpack 6.3-beta
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.
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.
Steps to reproduce:
Reported in this trac ticket: https://plugins.trac.wordpress.org/ticket/1762