Skip to content
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

Closed
jeherve opened this issue Jan 22, 2014 · 24 comments
Closed

Contact form: cannot insert a form using do_shortcode #102

jeherve opened this issue Jan 22, 2014 · 24 comments
Labels
[Closed] Won't Fix wontfix. This issue will not be addressed. [Feature] Contact Form [Pri] Low [Type] Bug When a feature is broken and / or not performing as intended

Comments

@jeherve
Copy link
Member

jeherve commented Jan 22, 2014

Steps to reproduce:

  1. 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] " ); ?>
  1. Load a page using this template file: the contact form is displayed.
  2. Fill in the form, and submit it
  3. The form is not submitted properly.

Reported in this trac ticket:
https://plugins.trac.wordpress.org/ticket/1762

@jtwiest
Copy link

jtwiest commented Jan 25, 2014

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

@blobaugh
Copy link
Contributor

blobaugh commented Feb 3, 2014

@jeherve do you have time to test this?

@jeherve
Copy link
Member Author

jeherve commented Feb 3, 2014

@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!

@blobaugh
Copy link
Contributor

blobaugh commented Feb 3, 2014

Whoops. You should not be checking your messages then!

@aaronbazinet
Copy link

Yep, I'm still having this issue. Contact form appears on page, but message doesn't send.

@blobaugh blobaugh modified the milestones: 3.2, 3.3 Aug 27, 2014
@georgestephanis
Copy link
Member

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.

@georgestephanis georgestephanis modified the milestones: vFuture, 3.3 Oct 9, 2014
@jpswade
Copy link

jpswade commented Oct 10, 2014

This issue still appears in Version 3.1.1...

@georgestephanis
Copy link
Member

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.

@jpswade
Copy link

jpswade commented Oct 10, 2014

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?

@georgestephanis
Copy link
Member

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.

@jpswade
Copy link

jpswade commented Oct 10, 2014

I understand.

I guess the solution for the time being is to use a widget instead...

@clarklab
Copy link

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.

@lstude
Copy link

lstude commented May 22, 2015

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:

  1. Update user's email address to wherever you want form to send: update-user
  2. Change the author on whatever page is linked to your broken form to the updated user (in our case, it was Home - Front Page change author
  3. Form now submits to proper address

@RobertShippey
Copy link

@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?

iandunn pushed a commit to WordPress/wordcamp.org that referenced this issue Nov 15, 2018
…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
svn2github pushed a commit to svn2github/wordcamp-plugins that referenced this issue Nov 16, 2018
…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
vedanshujain pushed a commit to WordPress/wordcamp.org that referenced this issue Nov 29, 2018
…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
vedanshujain pushed a commit to WordPress/wordcamp.org that referenced this issue Nov 29, 2018
…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
vedanshujain pushed a commit to WordPress/wordcamp.org that referenced this issue Dec 6, 2018
…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
vedanshujain pushed a commit to WordPress/wordcamp.org that referenced this issue Dec 6, 2018
…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
@stale
Copy link

stale bot commented Dec 25, 2018

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 stale bot added the [Status] Stale label Dec 25, 2018
@htdat
Copy link
Member

htdat commented Oct 24, 2019

Still the issue. Just tested with 7.9-alpha.

@stale
Copy link

stale bot commented Apr 23, 2020

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 stale bot added the [Status] Stale label Apr 23, 2020
@kraftbj kraftbj removed this from the Not Currently Planned milestone Jan 26, 2021
@stale stale bot removed the [Status] Stale label Jan 26, 2021
jeherve pushed a commit that referenced this issue Jun 18, 2021
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.
@github-actions
Copy link
Contributor

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.

@simison
Copy link
Member

simison commented Jan 2, 2025

@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.

@jeherve
Copy link
Member Author

jeherve commented Jan 6, 2025

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.

@jeherve jeherve closed this as completed Jan 6, 2025
@jeherve jeherve added the [Closed] Won't Fix wontfix. This issue will not be addressed. label Jan 6, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
[Closed] Won't Fix wontfix. This issue will not be addressed. [Feature] Contact Form [Pri] Low [Type] Bug When a feature is broken and / or not performing as intended
Projects
None yet
Development

No branches or pull requests