Custom Post Meta Not Saving on Recurring Events

[Cliff]

With all plugins deactivated except for TEC and ECP, and on the default theme, I can no longer save custom post meta using the meta boxes I built. These meta boxes work fine elsewhere (and have for years), and also work fine on *non-recurring* events.

Basically, the fields remain blank after saving. However, I can put them directly into Custom Fields and have it be fine—it seems to just be keeping my custom meta box from hooking into the save.

[Barry]

Hi Cliff,

Would you be able to share the relevant code (via Pastebin/Gist/similar)? We can’t guarantee being able to help out with custom dev work like this but we’d be happy to take a peek and see if anything jumps out 🙂

Thanks!

[Cliff]

Hey Barry,

I appreciate that, but it’s most definitely a bug with ECP, interfering with a very simple, common customization.

Here’s enough of the plugin to see what’s happening: https://gist.github.com/logoscreative/7daa90a4507eb53eab08

It works on top of the Meta Box plugin.

Again, I’ve been able to isolate this to recurring events only, with the default theme enabled and only the TEC and ECP plugins enabled, along with this meta box.

[Barry]

Hi Cliff,

Thanks for sharing that snippet – unfortunately it doesn’t really give me a sense of where your save handler comes in to play though (unless I’m missing something) and that is likely to be where the problem is.

I appreciate that, but it’s most definitely a bug with ECP, interfering with a very simple, common customization.

I’m not sure I agree. Here’s some sample code I knocked up that simply adds a meta box containing a text input (and of course handles saving it – excuse for the moment the lack of safety checks). I don’t really see a problem in terms of adding a meta box and saving the data:

add_action( 'add_meta_boxes', 'add_event_meta_box' );
add_action( 'save_post', 'custom_field_save_handler' );

function custom_field_save_handler() {
	if ( ! isset( $_POST['test_field'] ) ) return;
	update_post_meta( get_the_ID(), '_meta_box_custom_field', $_POST['test_field'] );
}

function add_event_meta_box() {
	add_meta_box(
		'test_meta_box',
		'Test Custom Meta Box',
		'render_test_meta_box',
		TribeEvents::POSTTYPE
	);
}

function render_test_meta_box() {
	$field = esc_attr( get_post_meta( get_the_ID(), '_meta_box_custom_field', true ) );
	print '<input type="text" name="test_field" value="' . $field . '" />';
}

I have to admit I’m not familiar with the Meta Box plugin but can only guess it deviates from this sort of pattern. That’s not to say this is the only way to do it, or that there isn’t a bug, just that I’m not convinced there is a problem other than one of integrating the two systems.

[Cliff]

This should give you an idea: http://plugins.svn.wordpress.org/meta-box/tags/4.3.8/inc/meta-box.php

I hear your skepticism, but this was working fine prior to the recent round of ECP updates, which obviously had a major bug with saving recurring events.

So, the code above was run and successfully saved post meta on a recurring event?

[Barry]

Hi Cliff,

Yes – as far as I can see the sample code I provided works as expected with recurring events (definitely feel free to try it out and confirm for yourself, though). Looking at the Meta Box plugin code though I can broadly see what’s happening here:

• As things are now, recurring events are made up of lots of different child posts – one for each event in the series – plus one parent post representing the entire series
• When you edit all events in a series and hit update the save_post action fires multiple times (once for each post)
• Each time this happens the RW_Meta_Box::save_post() method is called – which handles saving the meta data – but it is designed to run once only and so is unlikely to ever save the meta data in the case of the parent post (but it’s important that happens)

While I can definitely see the line of reasoning for the way RW_Meta_Box::save_post() behaves I don’t feel it represents a bug in our code. It’s just when it comes to dealing with recurring events you’re hitting up against a scenario the authors of that plugin didn’t anticipate.

I hope that sheds some more light on what’s happening – but I think we’ll need to leave it to you to figure out the best path forward from here if you need to keep using it as it is ultimately looking like an integration issue rather than a failing as such on our side.

Good luck 🙂

[Cliff]

Can you point me to when that changed in ECP, then, so I can understand it better?

[Barry]

Sure, so the primary change is that – previously – a recurring event consisted of one post but with additional pieces of meta data for every recurring instance (basically, additional _EventStartDate entries).

There were a number of limitations about this approach though and we have now switched to having a single parent post (for the initial event in the sequence) plus multiple child posts, one for each instance that follows it.

If you edit and update all events in a series that means – as things currently stand – each of those posts needs to be updated. The plugin you are leveraging to add your meta boxes though is intentionally limited to updating just one post (if you look at the first few lines of RW_Meta_Box::save_post() you can see what I mean) and that’s the choke point here, so to speak.

Does that help explain things at all?

[Cliff]

Yes it does. Thanks!

For the record, a change like that probably should have been shared. Many of us have done cool stuff that works with ECP, but that stuff starts breaking inexplicably when a major object structure changes like that. 🙂

[Barry]

Communication about major changes is definitely critical and if we let you down there we’re sorry.

I would note though that we did try to summarize changes in advance of the release going out in this blog post and if you listen to Reid’s talk on that page you’ll note he put some particular emphasis on the fact that the recurrence changes were fairly major. We also tried to make it clear we were happy for devs who had implemented customizations to reach out and test things in advance:

If you’ve done some customizations and want to grab a pre-release version of this release to test them out beforehand, let us know and we’ll try to work something out. Email pro @ tri.be for more info.

There’s always room for improvement though and if we could have done a better job here we’re definitely open to your feedback as ever 🙂

[Author]

Posts