jetpack
jetpack copied to clipboard
Automattic
Contact form: cannot insert a form using do_shortcode
Steps to reproduce:
- Edit one of your theme's template files and add a Contact form with the do_shortcode function:
<?php echo do_shortcode( "[contact-form][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] " ); ?>
- Load a page using this template file: the contact form is displayed.
- Fill in the form, and submit it
- The form is not submitted properly.
Reported in this trac ticket: https://plugins.trac.wordpress.org/ticket/1762
Form only processes when it is coming from a widget or when the shortcode is in the comment.
https://github.com/Automattic/jetpack/blob/master/modules/contact-form/grunion-contact-form.php#L146-172
@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!
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.
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:
- Update user's email address to wherever you want form to send:
- Change the author on whatever page is linked to your broken form to the updated user (in our case, it was Home - Front Page
- Form now submits to 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!
This issue has been marked as stale. This happened because:
- It has been inactive in the past 6 months.
- It hasn’t been labeled `[Pri] Blocker`, `[Pri] High`.
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.
![stale[bot] avatar](https://avatars.githubusercontent.com/in/1724?v=4 "Published by a pub.dev verified publisher"){kind=small}
This issue has been marked as stale. This happened because:
- It has been inactive in the past 6 months.
- It hasn’t been labeled `[Pri] Blocker`, `[Pri] High`.
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:
- It has been inactive in the past 6 months.
- It hasn’t been labeled `[Pri] Blocker`, `[Pri] High`, etc.
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.
![github-actions[bot] avatar](https://avatars.githubusercontent.com/in/15368?v=4 "Published by a pub.dev verified publisher"){kind=small}
@jeherve I think we can close this issue at this point, as a wont-fix? One can use do_blocks() and modern block markup if there's a need to do something like this programmatically.
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.