aaronsnow
Forum Replies Created
-
Hi- sorry for the lag. Yeah, the adverse behavior is that the twice-serialized values can’t be read by any other plugins that are expecting once-serialized values — which is what happened to me with ACF: I’d make some selections, click Update, and then when their control read the values back out of the field, it didn’t see anything it recognized, so the control wouldn’t re-populate.
Aside from plugin conflicts, the values can’t be queried, either — at least not in the usual way.
Anyway, thanks for the fix. It’ll save me the trouble of re-applying it with each upgrade. ??
Thanks, Marcus. The fix above makes this moot, but FWIW it looks like the serialization happens in function save_events(), same file, line 1681:
$event['event_attributes'] = serialize($event['event_attributes']);
Events Manager folks– any chance the following fix (or equivalent) could make it into your next rev?
I’m pretty sure I’ve found the conflict between EM and ACF. In EM’s classes/em-event.php, at line 625-640 (in ver. 5.1.8.5), all post_meta fields get updated — even if you’ve disabled event attributes in Settings. That’s the part that’s causing the conflict: EM is serializing the field, and ACF serializing it too, not imagining any other plugin would modify its fields.
So here’s the fix: at line 629, I changed
}elseif($key == 'event_attributes'){
to
}elseif($key == 'event_attributes' && get_option('dbem_attributes_enabled')){
This way, if you choose not to enable EM’s attributes feature, then EM doesn’t assume all available post_meta to be attributes, and won’t do anything to them (e.g., unwanted serialization). This fix doesn’t let you use both EM’s attributes feature and other plugins’ custom fields, but that seems like a reasonable trade-off.
Maybe for next ver release?
Thank you …
FWIW, I have custom attributes turned off in EM, because of the “deprecated attributes” issue. I’m trying to use ACF instead (because the UI is so much more flexible/palatable to our client).
Hi,
I had a similar problem, and ended up writing a function based on get_posts_sharing_custom_field_value(), but for repeatable fields. it actually turned out to be pretty straightforward. Since they’re stored in the post meta as comma-separated, quoted values, the SQL is a little less performant, but for me it’s well worth the tradeoff.
I’ve pasted the code below FWIW. I also added an option to filter by post_type, as I’m often looking only for one type of post when I use this.
// based on CCTM's get_posts_sharing_custom_field_value(), // but returns the posts that match anywhere in a repeatable field // (stored in the db as comma-separated, double-quoted strings) // - also added a param for filtering by post_type, since it's so common function get_posts_containing_custom_field_value($fieldname, $value, $post_type = '') { global $wpdb; $query = "SELECT DISTINCT {$wpdb->posts}.ID FROM {$wpdb->posts} JOIN {$wpdb->postmeta} ON {$wpdb->posts}.ID = {$wpdb->postmeta}.post_id WHERE {$wpdb->posts}.post_status = 'publish' AND {$wpdb->postmeta}.meta_key = %s AND {$wpdb->postmeta}.meta_value LIKE %s "; if ($post_type) $query .= " AND {$wpdb->posts}.post_type = %s "; $query_prepped = $wpdb->prepare( $query, $fieldname, '%"' . $value . '"%', $post_type ); $results = $wpdb->get_results( $query_prepped, OBJECT ); $completes = array(); foreach ( $results as $p ) { $completes[] = get_post_complete($p->ID); } return $completes; }
So helpful. Worked perfectly for me too. Thanks!