Pipes not working

It’s working.

But it does not work for me.
I create a form like

[select your-recipient "CEO|[email protected]"
                    "Sales|[email protected]"
                    "Support|[email protected]"]

But getting

<select name=”your-recipient” class=”wpcf7-form-control wpcf7-select” aria-invalid=”false”>
<option value=”CEO”>CEO</option>
<option value=”Sales”>Sales</option>
<option value=”Support”>Support</option>
</select>

I use WP 4.3.1 and CF7 4.3

What may be the cause of such behaviour?

Getting the same results as zisen with WP 4.3.1 and CF7 4.3.

From looking at the source it seems like pipes are parsed fine but then only used at checkbox and quiz but not at select.

If anybody has a working select with pipes, could you please post your exakt WP and CF7 version? Thanks.

I have the same problem!

you can try to modify from the line 147 of plugins/contact-form-7/includes/shortcodes.php
—–
if ( WPCF7_USE_PIPE ) {
$pipes = new WPCF7_Pipes( $scanned_tag[‘raw_values’] );
$scanned_tag[‘values’] = $pipes->collect_befores();
$scanned_tag[‘pipes’] = $pipes;
$scanned_tag[‘labels’] = $pipes->collect_afters();
} else {
$scanned_tag[‘values’] = $scanned_tag[‘raw_values’];
}

//$scanned_tag[‘labels’] = $scanned_tag[‘values’];
——

Takayuki Miyoshi this is not a good answer for a developer!!!!

@grig12 —?THANK YOU! That works! I thought I was going crazy.

I was about to hard code the fields per the author’s suggestion on another thread that this was not possible. Hate to modify plugin code, so I humbly request that this change makes its way into the official code. ??

Not sure why it doesn’t unless the data is meant to be hidden from the DOM?

This way it works, thank you !

@takayuki Miyoshi : definitely NOT a good answer

I would add that the order specified in the plugin documentation (label | value) is the opposite of the one actually used by the WPCF7_Pipes class:
values -> before
labels -> after

I’m using WP v.4.3.3

I would ask too this fix to be added in the next versions of this nonetheless very useful plugin.

It’s a bit of a short answer, but actually @takayukister is right. It is working.

The front-end code will indeed display with the value and HTML having the same value, but in you email messages or databases, [your-recipient] will render the value after the pipe.

So the correct value is used in the back end. I agree this is a bit strange but it kind of makes sense if you think about it. For one, it hides the e-mail addresses from the front-end, making sure bots can’t get their hands on the email addresses.

In most cases however, I think it would make a lot of sense to display the value after the pipe as the actual value of the drop down list. Since modifying the plugin code is bad practice, here’s a code snippet that you can add to your functions.php file:

add_filter('wpcf7_form_tag','bdwm_form_tag',10,1);

function bdwm_form_tag($scanned_tag) {
	$pipes = new WPCF7_Pipes( $scanned_tag['raw_values'] );
	$scanned_tag['values'] = $pipes->collect_afters();
	return $scanned_tag;
}

Thank you — your response reminded me to go look at the site where I implemented this, and the plugin had been updated and broke the form — must not have been in use lately as the client hasn’t said anything yet. ??

I just updated CF7 again and instead of editing the code used the functions.php snippet above, and it works perfectly again.

I understand the explanation you gave, but in my particular case I’m using jQuery to add the values after the pipe from two dropdown each time the user changes either, and updating a total value field below — so even though it may pass the correct values on the back end, I needed to be able to grab the values in the DOM within jQuery, which wasn’t possible (AFAIK) without this alteration. So, THANKS!

The front-end code will indeed display with the value and HTML having the same value, but in you email messages or databases, [your-recipient] will render the value after the pipe.

This is a feature not a bug. The vast majority of users of the plugin intend it to work this way.
Since @jules-colle has provided the code snippet that helps those who don’t, I suggest that this be marked as Resolved.

I’m fine with that, if my and others’ use case is the minority then it should not be the default behavior. I’m happy there’s a solution not involving hacking the plugin, so my only suggestion would be that this makes it into any relevant documentation so it’s more easily found by people looking for a fix.

I’m still frustrated we can’t search a particular plugin’s support forum, so I’d like to see this get added to Takayuki’s website docs. ??

I agree – @takayukister should add this to documentation.

This worked like a charm! Thank’s so much @jules-colle