schmeee

Hi Adam. Let me describe my workflow in detail, as I think we miiiiight be missing each other in our respective understanding of a) your instructions, and/or b) my bugfix steps. Here’s my pre-launch situation:

Two daughter sites on one multisite network:
– site A (live): https://lemanslakeland.com (connected to sitekit)
– site B (staging): https://lemansrebuild.mighty-little-websites.com (not yet connected to sitekit)

Upon launch, I changed site A URL to https://lemanslakelandold.mighty-little-websites.com (but forgot to reset Site Kit before doing so), and changed site B URL to https://lemanslakeland.com. Got sitekit connex error, Googled to refresh my understanding of the usual fix, and then:

– reverted to previous respective site URLs for sites A and B,
– then reset site kit on site A (which had the live production lemanslakeland.com URL when I did)
– then RE-reverted both site URLs to post-relaunch status
– same error when trying to connect site kit on the now-live new version of their site.

Hope this clarifies my situation and attempted mitigations. I THINK I did the proper usual thing as detailed in your setup guide, but lmk if I’ve misstepped in some way. Thanks,

:Benjamin

Resolved, with help from my hosting tech support team. FYI (in case this comes up for other users), I had toggled (per my usual practice) a Yoast Advanced setting, to strip unregistered querystring pairs, that was interfering with EE’s regular functioning. Unchecking that obscure lil’ box cleared the whole problem right up. Thanks again for eliminating some possibilities in advance that helped me and my support guys focus on likelier culprits. :Benjamin

Hi Tony, thanks for your speedy response. I ran through your list of things to check, and have some additional details that might help us diagnose and resolve this issue. First off, the standard EE checkout page you referenced is indeed the page specified in our ‘Critical Pages’ screen. When I visit that URL (that is, https://newwavesingers.org/registration-checkout/) directly, without initiating a ticket first, in either a logged-in or unlogged-in state, I see a regular page and headline, but the shortcode isn’t pulling in any additional data so the page is empty otherwise (if that’s not normal).

When I’m logged in, and I start a ticket purchase, I get sent to a VERY different URI:
https://newwavesingers.org/registration-checkout/?uts=1762880906#checkout. That page delivers the totally expected, totally correct ticket purchaser next step experience: Steps / event+ticket deets / attendee details intake form / ‘Proceed to Finalize Registration’ button.

A few additional details that might help further with diagnosis / resolution:

• I tried adding a 301 redirect, from /registration-checkout/page/ to https://newwavesingers.org/registration-checkout/, passing all query parameters as-is. This did land a not-logged-in ticket purchase attempt on the right page (no more added /page/#checkout at the end of the URI, no more ‘Oops… 404’ message) but did not seem to properly pass the querystring value in a way EE could use. Try for yourself, starting your purchase attempt from this URL if it’s helpful:
  https://newwavesingers.org/events/click-here-for-tickets-to-the-sunday-12-7-25-400pm-performance-of-sounds-of-the-season/
• The old version of this website we brought over during migration ran a MUCH older version of EE, which I updated during migration and tested, in a general way, but had no live event at the time to test ticketing functionality. This is our first attempt to provide EE event ticketing after the rebuild.
• I used WP’s default export/import tool, rather than a migration plugin, because the old site was a standalone WordPress build but the new incarnation is a daughter site on a multisite network.
• I’m not certain if the old site used a different permalink structure than my rebuild. Could that impact this issue somehow? Should I try setting permalinks to ‘Plain’ instead of ‘Post name’?

Anyway, appreciate your thoughts and guidance on where to go from here.

Can I ask (nicely!) for a little help getting my code to work? It’s erring, and I’ve pinned the problem down to my ask for $instance->get_posted_data( 'second-opinion-buyer-name' ) — there is definitely a user-entered field for second-opinion-buyer-name in the form. Is get_posted_data() unavailable within wpcf7_mail_html_header? Any documentation you have w/r/t wpcf7_mail_html_header and/or get_posted_data() would be useful. Thanks in advance for your expert assistance! :Benjamin

function mzh_addmetas_mail_html_header ( $doctype_html_html_xmlns_http_www_w3_org_1999_xhtml_head_title_esc_html_this_get_subject_true_title_head_body, $instance ) { 
	// make filter magic happen here... 
	// assemble new metas...
	$addmetas = '
	<meta name="lead_information_version" content="1.0" />
        <meta name="lead_source" content="https://myziphome.com" />
        <meta name="lead_type" content="buyer" />
	<meta name="lead_name" content="' . $instance->get_posted_data( 'second-opinion-buyer-name' ) . '" />';
		$doctype_html_html_xmlns_http_www_w3_org_1999_xhtml_head_title_esc_html_this_get_subject_true_title_head_body = '<!doctype html> 
		<html xmlns="http://www.w3.org/1999/xhtml"> 
		<head> 
		<title>' . esc_html( $instance->get( 'subject', true ) ) . '</title> 
		' . $addmetas . 
		'
		</head> 
		<body> 
		';
	return $doctype_html_html_xmlns_http_www_w3_org_1999_xhtml_head_title_esc_html_this_get_subject_true_title_head_body; 
}

// add the filter 
add_filter( 'wpcf7_mail_html_header', 'mzh_addmetas_mail_html_header', 10, 2 );

• This reply was modified 3 years, 11 months ago by schmeee.

I figured it out – sort of. Seems like the other-plugin shortcode invocation ( [8b_home_value] ) messes with regular flow in some way. Once I stripped out its duplications, and pushed its containing group to the end of the form so that no other conditional groups appear after it, my problems resolved.

I’m guessing it created no problems on your online tester because the shortcode wasn’t actually firing anything – it just passed through as literal ‘[8b_home_value]’.

Anyway, thanks for your timely responses. File this away as one more troubleshooting node: “Does your form have an outside [shortcode] embedded? Might cause unexpected behaviors!”