Ulrich Christensen
Forum Replies Created
-
I’ve found the culprit, which is an aptly-named plugin called “Post Type Switcher”. That plugin is meant as an easy way to change the post type of the post you’re editing, but seeing as it reads the post type to use from its own variable in the $_POST superglobal, it forces the associated posts Venue and Organizer to have their parent’s (TribeEvent) post type. Ironically enough that plugin was super-helpful in fixing problem posts.
That plugin really does, what it is supposed to (albeit too well), so it is not a problem to fix on that end.Going forward to avoid similar problems I think you should either explicitly set the post type after the call to wp_update_post in TribeEventAPI::updateVenue (and TribeEventAPI::updateOrganizer) :
set_post_type($venueId, TribeEvents::VENUE_POST_TYPE);
or use a call which doesn’t call action hooks to update these associated posts, when called from an TribeEvent post.Alternatively, would it not be possible to store the meta-data with the TribeEvent post (by making VenueId and OrganizerId point to the TribeEvent post’s postId)? It would of course involve using the meta-data field for Venue name and Organizer name instead of their respective post_title.
This would get around the problem with the wrongly deleted associated posts.The whole Venue and Organizer entries showing up as events caused me quite a headache, since the person posting the events accidentally removed all the Venue and Organizer entries, because they looked like errors.
This, of course, results in the name of the Venue and the name of the Organizer to not show up, but all the other data shows up fine, because it is in the “postmeta” table.
It would be nice, if the Venue and Organizer posts would be re-created, if they are missing.
The errors occurred before I made any modifications.
It looped infinitely when I tried to publish an event, and both Venue and Organizer entries showed up in the list of events.I added the lines to remove and reinsert the “save_post” action “addEventMeta” to solve the infinite looping inside the method addEventMeta around the call to TribeEventsAPI::saveEventMeta.
I’ve solved my problem with a possibly ugly hack in both TribeEventsAPI::updateVenue and TribeEvents::updateOrganizer. I simply do a query with $wpdb to update the post-type after the call to wp_update_post to ensure that the post-type is correct.
Example:
public static function updateVenue($venueId, $data) { wp_update_post( array('post_title' => $data['Venue'], 'ID'=>$venueId) ); TribeEventsAPI::saveVenueMeta($venueId, $data); global $wpdb; $sql = "UPDATE $wpdb->posts SET post_type = '".TribeEvents::VENUE_POST_TYPE."' WHERE ID = '".$venueId."'"; $wpdb->query($sql); }I have no idea as to what is the cause of the wrong post type.