If you can provide any sort of callstack trace for the error, that’d be awesome. Based on what we have above, it’s an issue with wp_check_invalid_utf8()
function wp_check_invalid_utf8( $string, $strip = false ) {
$string = (string) $string;
...
}
The callstack, if available, would give me a list of function/code calls that I could trace my way through effectively and see where the WP_Post object is ending up being passed at, instead of a string value.
Thanks for any and all help you can provide for this one.
This problem didn’t exist in staging, so I can’t really help. I don’t know to to reproduce the error without breaking our lead funnel again. In a panic, I had to substitute a different plugin in place of yours. The form worked when were in staging last week, so my path to reproduce would be to set up the site on another domain with an SSL certificate and learn how to use a callstack tracing plugin. My motivation there is low since I found another plugin.
Understandable and fair point.
I’ll definitely keep my eyes open regarding the issue overall. I haven’t experienced it myself in testing/development.
To help possibly spur details that could help. Are both sites running the same version of WordPress and almost the same setup for plugins/theme? I know WP_Post came in around version 4.4.0
They are exactly the same WP software and database running on WP Engine because it is the very same instance of WordPress. The form started erroring after we launched the production domain with https and stopped using whatever.wpengine.com. We used the interconnectit.com search and replace tool to change all URLs in the database from the staging to production URLs.
We’re keeping an eye on this one, but for the meantime we’re going to mark the thread resolved and as a known potential issue needing addressed.
