Multiple Front End Forms

Can you provide a pastebin.com paste of all the code you’re using for this?

I realize you link to the blog post, but it’s best to use the code from the current state of your own attempt.

Curious if I can find something with it or see anything off.

Thanks Michael.

I put both files in a Gist

Note, this is being done through a mu-plugin. main.php basically loads the other CPT files. This can be refactored at a later date if need be (also loads other CPT, but paper does come first and works, the other CPT save but ignores the CPT and post_status.)

Also, I’m not married to this being done with a shortcode, but the example allowed me to quickly prototype out the front end work. I’m currently calling the shortcodes in a page template with do_shortcode anyway.

Thanks again for a fresh set of eyeballs.

Unrelated, but would perhaps help with ease and assurance would be using the cmb2_init hook, which you can use once CMB2 is loaded, to do what you need.

function my_function_name() {
	require_once WP_CONTENT_DIR . '/plugins/CMB2/init.php';
	require_once WP_CONTENT_DIR . '/plugins/CMB2-Pipes/cmb2-pipes.php';
}
add_action( 'cmb2_init', 'my_function_name' );

I also changed the __DIR__ to one of the WP constants.

Can you point me to where you got CMB2-Pipes from? Is it https://github.com/lucatume/CMB2-Pipes ?

Yes, that’s the plugin. I use that for front end editing of items to map the CMB2 title field t o the post title. So it isn’t being used in the shortcode post creation.

I’ll look at cmb2_init. My current method is an artifact of refactoring old code that was using a different method to create the CPT forms and slowly switching over.

Note I’m using 2 instances currently of each form. One for editing and works on the backend, one for front end creation. They might be able to be combined at some point, but I wanted to keep both for now.

Just re-read your thoughts on that function. I’m not using this in plugins, I’m using it as part of my own mu-plugin. But I’m sure I could modify the paths. I don’t think that relates to my issue currently though.

No, all of my last reply was mostly in regards to getting my local setup set up so I can start tinkering and see what I can come up with, outside of just reading the code.

Finally got things not fatal erroring on my localhost.

I am finding this line curious:

'post_type' => reset( $post_types ), // Only use first object_type in array

It’s possible that the $post_types variable is not resetting in cases of multiple instances of the shortcode being used on the same page, if that’s what’s going on like I’m interpreting. Is that the case here?

Could you provide the shortcodes you’re using for the place you’re trying to add everything to?

We’re making progress here, I feel it.

The shortcodes are only being used one per page template.

<?php echo do_shortcode( '[chapel_new_paper]' ); ?> and <?php echo do_shortcode( '[chapel_new_client]' ); ?> respectively.

That line was also one that I was curious about, as well as

unset( $post_data['post_type'] );
unset( $post_data['post_status'] );

in the _new_post_form_submission functions.

I really do appreciate your help in this. I combed through this code for several days before reaching out.

I’m starting to wonder if it has to do with the $post_types = $cmb->prop( 'object_types' );

I don’t have a for sure answer as to why, but I have managed to track down the fact that the hidden attributes aren’t being submitted as part of the $_POST data for the Clients submission, at least when I have both on the same page and have the clients shortcode last.

Because of that, it’s defaulting to the post post type and draft status, which is what WP uses with wp_insert_post() when none are provided.

My hunch is that since both callbacks get called, and $_POST is set and ready in both, perhaps it gets to the unset( $_POST['atts'] ) point for the first shortcode. Due to persistence in the globals, by the time it reaches the 2nd callback, that atts key is gone and our problem presents itself.

Out of curiosity, since both shortcodes rely on hitting submit and the $_POST global, do both work just fine when on their own dedicated pages? Is there definite need to have both on the same page?

No, they are not on the same page currently nor will they need to be.

A couple of things I found, the $atts was being set to the form ID not the shortcode. See Line 461 I think that should be chapel_new_client not new_client_metabox

However, changing that didn’t alter the outcome.

Also, when submitting a new client form, I’m not getting the success message of “New client created.” Paper however does.

Again, can’t thank you enough for your time and help on this.

Ignore the part about not showing “New client created.” I’ve sorta turned myself inside out at this point.

According to the codex, the part at line 461 would be this:

$shortcode
    (string) (optional) Shortcode name to be used by the shortcode_atts_{$shortcode} filter. If this is present, it makes a "shortcode_atts_$shortcode" filter available for other code to filter the attributes. It should always be included for maximum compatibility, however it is an optional variable.
    Default: None

A bit later I’ll go back in with just the client shortcode and see if I’m still getting the same results and do more step debugging.

If you have a suggestion for submitting the from without using shortcode, I’m all ears. As I mentioned, that’s not imperative to my goal. Though I understand if you want to find a solution to original example I linked to.

After doing a var_dump of $_Post, I can confirm $_POST['atts'] are being clobbered and not passing into client CPT form.

Edit

OK, I commented out this line (as well as the aforementioned unsets) and voila, the client form worked.

I’ve not encountered any issues *yet* with that commented out, reading between the lines, unsetting those values was for adding the image attachment?