Forum Replies Created
-
Posts
-
Been a while waiting for a reply so I’ve decided to go ahead an roll my own:
https://gist.github.com/gyrus/9eb174ecf37f0b67e3ac685b3b03d6a9
What I’ve done is to just grab the metadata, and to update it directly, rather than grab the events and try to update using the tribe_update_event() function – which didn’t seem to be working for some reason. (It’s split into two functions so I can manage things easier if I need to run this in batches.)
It’s very hard to thoroughly test this, so I’m still looking for confirmation from you. Part of the reason I’ve asked here rather than just diving in with my own solution is that you know the plugin so much better than I do. My faith in that panning out to getting the right solution from you has been badly shaken due to none of the solutions you’ve posted actually working properly. However, that doesn’t make me any wiser about the plugin, so I’m still wary.
One test I did do is to check the format of an event’s recurrence meta after running my conversion script, then check it again after I’ve manually pressed ‘Update’ on that event’s edit screen. Here’s the meta after the script ran:
Array ( [rules] => Array ( [0] => Array ( [type] => Every Week [end-type] => On [end] => 2016-05-25 [end-count] => 1 [custom-type] => Daily [custom-interval] => [custom-type-text] => [occurrence-count-text] => events [custom-month-number] => First [custom-month-day] => 1 [custom-year-month-number] => 1 [custom-year-month-day] => 1 [recurrence-description] => every Wednesday in term-time. [EventStartDate] => 2016-04-13 16:00:00 [EventEndDate] => 2016-04-13 18:30:00 ) ) [exclusions] => Array ( ) [description] => every Wednesday in term-time. )And here it is after a manual update:
Array ( [rules] => Array ( [0] => Array ( [type] => Every Week [end-type] => On [end] => 2016-05-25 [end-count] => 1 [EventStartDate] => 2016-04-13 16:00:00 [EventEndDate] => 2016-04-13 18:30:00 ) ) [exclusions] => Array ( ) [description] => every Wednesday in term-time. )Is all those custom-* keys from the rules being dropped OK? I’ll go an find an event with more complex rules. Here’s the meta after the conversion script:
Array ( [rules] => Array ( [0] => Array ( [type] => Custom [end-type] => On [end] => 2016-08-20 [end-count] => 1 [custom-type] => Daily [custom-interval] => 1 [custom-type-text] => Day(s) [occurrence-count-text] => events [custom-month-number] => First [custom-month-day] => 1 [custom-year-month-number] => 1 [custom-year-month-day] => 1 [recurrence-description] => . [EventStartDate] => 2016-08-20 10:00:00 [EventEndDate] => 2016-08-20 12:30:00 ) ) [exclusions] => Array ( ) [description] => . )(I think the full stop as the description is being used by the client to suppress the auto-generated event description.) And again after a manual update:
Array ( [rules] => Array ( [0] => Array ( [type] => Custom [end-type] => On [end] => 2016-08-20 [end-count] => 1 [custom] => Array ( [type] => Daily [interval] => 1 [start-time] => Array ( [hour] => 08 [minute] => 00 ) [duration] => Array ( [days] => [hours] => [minutes] => ) ) [EventStartDate] => 2016-08-20 10:00:00 [EventEndDate] => 2016-08-20 12:30:00 ) ) [exclusions] => Array ( ) [description] => . )As you can see the custom-* keys in the rules seem to have changed. Would this affect anything? I can’t really go ahead without knowing for sure.
To be clear, I’ve been through the tedious process of updating sequentially to every version of the plugin between the one we currently have on production and the most recent release, and the data didn’t get converted. I’m at a loss trying to imagine how you managed this whole process without a clear data conversion strategy. Could you check with whoever developed this particular feature? I’ve wasted a lot of time on this issue already and I really need to get a water-tight solution soon.
Hi there,
Yes, things have become a little confusing! Glad to know I’m not alone though.
First, some clarification. From what you’re saying, it sounds like the latest version of the plugin is designed to work with recurrence data in either the old or new format – but data will get converted to the new format organically, as events are updated in WP. Is that right? So the old data format is more ‘deprecated’ than obsolete?
Past that, there’s a bug in the recent versions of the plugin that means, although generally they work with the old data format while it’s waiting to get organically converted, it isn’t picking up the old recurrence description? Obviously I’ll add a workaround if necessary. I’m just wondering why it’s necessary – if this is a bug in handling the old data, shouldn’t it be fixed, or something should be provided to convert the old data?
Anyway, on to your workaround. One change that’s needed is the initial empty() test needs to go. As far as I can see the latest plugin creates a description automatically if there’s nothing there, so it’s never empty by the time it reaches this filter – so the above code would never have a chance to grab the legacy description.
With that empty out the way, this works in terms of front-end output. However, when I go to the admin edit screen for the event, the description field is of course blank. And when I update, the blank field overwrites the legacy description.
So this workaround would work OK to begin with, but it would organically erase all the description data over time!
Is there a way to also filter the value populating in the admin, so it’s saved properly when updated? Or are we looking at another approach here?
To be clear, I could probably solve this eventually all by myself. It would just take time, and I’m really busy. Since we’re paying customers and your engineers know the plugin inside-out, I thought it could save time if we asked you for a bit of help here. Not sure if this is going to pan out! 😉 But we may be close to a solution. Please let me know about the issue with the admin description population. I can see the field in the PRO file /src/admin-views/event-recurrence.php, but it’s not clear where the array $recurrence is being populated.
I’m afraid we’re stuck with the exact same issue. To be very clear about what’s going on, I’m dumping the new
$dataarray that’s being constructed, and then dumping the new meta value (fetched usingget_post_meta(), after callingtribe_update_event( $event_id, $data ). I’m then exiting straight away, so this is just a test on the first event recurrence being updated in the loop.Here’s the dump of
$data(I can confirm that this, as far as it goes, accurately reflects the old data):Array ( [recurrence] => Array ( [rules] => Array ( [0] => Array ( [type] => Custom [end-type] => Never [end] => 2015-10-01 [end-count] => 1 [custom-type] => Weekly [custom-interval] => 1 [custom-type-text] => Week(s) on: [occurrence-count-text] => events [custom-month-number] => First [custom-month-day] => 1 [custom-year-month-number] => 1 [custom-year-month-day] => 1 [recurrence-description] => Weekly [EventStartDate] => 2015-09-14 15:30:00 [EventEndDate] => 2015-09-14 17:30:00 [custom-week-day] => Array ( [0] => 1 [1] => 2 [2] => 4 [3] => 5 ) [excluded-dates] => Array ( [0] => 2016-01-15 16:30:00 [1] => 2016-01-18 16:30:00 [2] => 2016-01-19 16:30:00 [3] => 2016-01-21 16:30:00 [4] => 2016-01-22 16:30:00 [5] => 2016-01-25 16:30:00 [6] => 2016-01-26 16:30:00 [7] => 2016-01-28 16:30:00 [8] => 2016-01-29 16:30:00 [9] => 2016-02-01 16:30:00 [10] => 2016-02-02 16:30:00 [11] => 2016-02-04 16:30:00 [12] => 2016-02-05 16:30:00 [13] => 2016-02-08 16:30:00 [14] => 2016-02-09 16:30:00 [15] => 2016-02-11 16:30:00 [16] => 2016-02-12 16:30:00 [17] => 2016-02-15 16:30:00 [18] => 2016-02-16 16:30:00 [19] => 2016-02-18 16:30:00 [20] => 2016-02-19 16:30:00 [21] => 2016-02-22 16:30:00 [22] => 2016-02-23 16:30:00 [23] => 2016-02-25 16:30:00 [24] => 2016-02-26 16:30:00 [25] => 2016-02-29 16:30:00 [26] => 2016-03-01 16:30:00 [27] => 2016-03-03 16:30:00 [28] => 2016-03-04 16:30:00 [29] => 2016-03-07 16:30:00 [30] => 2016-03-08 16:30:00 [31] => 2016-03-10 16:30:00 [32] => 2016-03-11 16:30:00 ) ) ) [exclusions] => Array ( ) [description] => Weekly ) )Then here’s the new meta value for
_EventRecurrence, fetched aftertribe_update_event()is called and passed the new data:Array ( [rules] => Array ( ) [exclusions] => Array ( ) [description] => Weekly )So presumably there’s something wrong with data format being passed to
tribe_update_event()? It doesn’t seem to be anything to do with exclusions – none of the new data comes through.My questions was, if you look at the data I posted above (https://theeventscalendar.com/support/forums/topic/updating-to/#post-1099976) you’ll see that as well as ‘exclusions’, there’s also a load of ‘excluded-dates’. I’m not sure how (or if) these need mapping to the new data structure, as I don’t see any equivalent (see second code snippet above, https://theeventscalendar.com/support/forums/topic/updating-to/#post-1099998).
I’m not quite sure about the exclusions here. I wondered about this kind of modification to your script:
$data = [ 'recurrence' => [ 'rules' => [ $recurrence ], 'exclusions' => [ $recurrence['exclusions'] ], 'description' => $recurrence['recurrence-description'] ] ];But I’ve just created a new event with exclusions to look at the data format and it looks like this:
Array ( [rules] => Array ( [0] => Array ( [type] => Every Week [end-type] => On [end] => 2016-06-30 [end-count] => [EventStartDate] => 2016-04-24 08:00:00 [EventEndDate] => 2016-04-24 17:00:00 ) ) [exclusions] => Array ( [0] => Array ( [custom] => Array ( [type] => Date [date] => Array ( [date] => 2016-05-29 ) [interval] => 1 [start-time] => Array ( [hour] => 08 [minute] => 00 ) [duration] => Array ( [days] => [hours] => [minutes] => ) ) [EventStartDate] => 2016-04-24 08:00:00 [EventEndDate] => 2016-04-24 17:00:00 ) ) [description] => it's weird )Looking back at the data I’m trying to convert (above), I’m not sure where those ‘excluded dates’ have gone?
Unfortunately this doesn’t seem to work. I’m running it on single events to test.
An event with this meta:
Array ( [type] => Every Week [end-type] => On [end] => 2016-05-21 [end-count] => 1 [custom-type] => Daily [custom-interval] => [custom-type-text] => [occurrence-count-text] => events [custom-month-number] => First [custom-month-day] => 1 [custom-year-month-number] => 1 [custom-year-month-day] => 1 [recurrence-description] => every Saturday in term-time. [EventStartDate] => 2016-04-16 11:00:00 [EventEndDate] => 2016-04-16 13:00:00 )Seemed to get successfully converted to this:
Array ( [recurrence] => Array ( [rules] => Array ( [0] => Array ( [type] => Every Week [end-type] => On [end] => 2016-05-21 [end-count] => 1 [custom-type] => Daily [custom-interval] => [custom-type-text] => [occurrence-count-text] => events [custom-month-number] => First [custom-month-day] => 1 [custom-year-month-number] => 1 [custom-year-month-day] => 1 [recurrence-description] => every Saturday in term-time. [EventStartDate] => 2016-04-16 11:00:00 [EventEndDate] => 2016-04-16 13:00:00 ) ) [description] => every Saturday in term-time. ) )However, there was an event with this meta:
Array ( [type] => Custom [end-type] => Never [end] => 2015-10-01 [end-count] => 1 [custom-type] => Weekly [custom-interval] => 1 [custom-type-text] => Week(s) on: [occurrence-count-text] => events [custom-month-number] => First [custom-month-day] => 1 [custom-year-month-number] => 1 [custom-year-month-day] => 1 [recurrence-description] => Weekly [EventStartDate] => 2015-09-14 15:30:00 [EventEndDate] => 2015-09-14 17:30:00 [custom-week-day] => Array ( [0] => 1 [1] => 2 [2] => 4 [3] => 5 ) [excluded-dates] => Array ( [0] => 2016-01-15 16:30:00 [1] => 2016-01-18 16:30:00 [2] => 2016-01-19 16:30:00 [3] => 2016-01-21 16:30:00 [4] => 2016-01-22 16:30:00 [5] => 2016-01-25 16:30:00 [6] => 2016-01-26 16:30:00 [7] => 2016-01-28 16:30:00 [8] => 2016-01-29 16:30:00 [9] => 2016-02-01 16:30:00 [10] => 2016-02-02 16:30:00 [11] => 2016-02-04 16:30:00 [12] => 2016-02-05 16:30:00 [13] => 2016-02-08 16:30:00 [14] => 2016-02-09 16:30:00 [15] => 2016-02-11 16:30:00 [16] => 2016-02-12 16:30:00 [17] => 2016-02-15 16:30:00 [18] => 2016-02-16 16:30:00 [19] => 2016-02-18 16:30:00 [20] => 2016-02-19 16:30:00 [21] => 2016-02-22 16:30:00 [22] => 2016-02-23 16:30:00 [23] => 2016-02-25 16:30:00 [24] => 2016-02-26 16:30:00 [25] => 2016-02-29 16:30:00 [26] => 2016-03-01 16:30:00 ) [exclusions] => Array ( [0] => Array ( [type] => Custom [custom] => Array ( [type] => Date [date] => Array ( [date] => 2016-03-03 16:30:00 ) ) ) [1] => Array ( [type] => Custom [custom] => Array ( [type] => Date [date] => Array ( [date] => 2016-03-04 16:30:00 ) ) ) [2] => Array ( [type] => Custom [custom] => Array ( [type] => Date [date] => Array ( [date] => 2016-03-07 16:30:00 ) ) ) ) )After the conversion, I dumped the new _EventRecurrence meta and got this:
Array ( [rules] => Array ( ) [exclusions] => Array ( ) [description] => Weekly )I’m trying to follow the logic, but I guess the issue is in the format of the data that’s passed to tribe_update_event() ? Let me know if you spot anything obvious from your end.
Oh wow, I just wanted word on what needs keeping and what doesn’t, and you went and wrote the script! Thanks. I’ll get testing and let you know if there’s any issues.
I’m keen to get started on the conversion script here, I’m just a bit wary of the changes above. Could one of your engineers confirm the conversion that happened? Can all those ‘custom-*’ key/values, plus the ‘occurrence-count-text’ one, which aren’t in the new format, simply be dropped?
I just tried manually changing ‘recurrence-description’ to ‘recurrence’ in an event’s _EventRecurrence field (I properly updated the serialized key length as well). Going back to the event’s edit screen, the field wasn’t being populated, and on updating, the recurrence data got converted but again, the description is lost.
Looking at the old and new format for _EventRecurrence, I’m not sure I know exactly what’s going on. Here’s the old format:
Array ( [type] => Every Week [end-type] => On [end] => 2016-05-27 [end-count] => 1 [custom-type] => Daily [custom-interval] => [custom-type-text] => [occurrence-count-text] => events [custom-month-number] => First [custom-month-day] => 1 [custom-year-month-number] => 1 [custom-year-month-day] => 1 [recurrence-description] => every Friday in term-time. [EventStartDate] => 2016-04-15 16:00:00 [EventEndDate] => 2016-04-15 18:30:00 )When I update the event (with latest plugins installed), it becomes this:
Array ( [rules] => Array ( [0] => Array ( [type] => Every Week [end-type] => On [end] => 2016-05-27 [end-count] => 1 [EventStartDate] => 2016-04-15 16:00:00 [EventEndDate] => 2016-04-15 18:30:00 ) ) [exclusions] => Array ( ) [description] => )As you can see, as well as the description value being lost, a number of key/values are lost completely. I’m not sure if this data is simply irrelevant now, or if it should be being factored in some other way in the new system.
Ideally, it’d be good if you could point me to some code or documentation about these changes. Surely such a radical change in your data schema would have been documented, and would have involved some conversion code which would indicate exactly what’s going on?
I guess my last resort would be to write scripts which:
- Store the recurrence description in a separate, temporary meta field
- Programmatically updated every event (not sure if this is possible? would the new format be constructed from the edit screen’s form inputs rather than converted directly?)
- Added the recurrence description back into the new format
But again, I’m not sure about all that data that’s being dropped. Any ideas?
Sure, I can develop an update script. I just didn’t want to reinvent the wheel with a limited budget, and I assumed this issue must have been addressed along the way by your code. If there’s literally nothing you can point me to that already handles this, I’ll crack on with a custom script.
It looks like Relevanssi don’t have any experience of integrating with EC (https://wordpress.org/support/topic/drawing-on-relevanssi-text-search-for-modern-tribe-events-calendar-search?replies=3).
If you don’t have any pointers regarding leveraging Relevanssi’s features for the EC search, do you have any regarding trying to achieve my requirements without other plugins? I need to:
- Make the text search match categories, so a text search for ‘dance’ should match events which are categorised as ‘dance’, but don’t necessarily have ‘dance’ in the body text (obviously this is in addition to matching those with ‘dance’ in the body).
- I’d like multi-word text searches to match ANY of the words, not the exact phrase.
I think both features are common to plugins which extend WP’s rudimentary search functionality. Is there any way to extend EC’s search in these ways?
OK, so I downloaded every single release of all three plugins greater than the versions currently running on live (detailed above), up to the very latest. I updated them all, in synch, one step up at a time. After each step up I:
- Refreshed the plugins page to check the versions, and let any update scripts be run.
- Refreshed the edit screen of a certain recurring event to see what things looked like in the admin.
- Looked at the _EventRecurrence value directly in the database.
Fun! Not 😉
What I noticed was:
- At 3.12, the ‘Recurrence description’ field on the event edit screen vanished, but the ‘recurrence-description’ key and value inside the serialised _EventRecurrence value for the event remained.
- At 3.12.5, the ‘Recurrence description’ field returned to the edit screen, but not populated with the value in the database. Looking at the data, the ‘recurrence-description’ key and value remained.
- Nothing else changed with respect to the recurrence description all the way up to the latest versions.
- I tried entering something in the new (empty) field on the edit screen, updated the event, and when I looked in the data, the serialised array was in the new format, with ‘description’ instead of ‘recurrence-description’, with the old value gone.
I’m finding it hard to believe you actually wiped all that recurrence description data from everyone’s installations – or left it to people to manually re-populate before they saved individual events in admin?
On the other hand, nothing seemed to be in place on any of the updates to convert the old array format to the new one. It’s just left to when you save an event next – and the old value for the recurrence description is simply lost.
Please let me know how you think we can best approach this update process without losing data. Again, I realise having left things not updated for a while isn’t normal (it was out of our hands!). But having done the updating sequentially, it looks like this may have been an omission in the process which updating as each new release came out wouldn’t have helped with.
Ah, the version was in the question title but it got cut out. I’m updating from 3.11.2 (main plugin), 3.11.1 (PRO), 3.11 (Filter Bar). I’ll try progressively updating. Let me know if you think of anything else.
Hi there,
No, the priority makes no difference. I’ve never had issues with priorities like 999999, but anyway, setting my hook to 99 doesn’t change anything.
After a while of step-by-step debug dumping, I think I’ve tracked the issue down to the Pro plugin’s Main.php, the function setup_hide_recurrence_in_query() around line 1170. If I comment out these lines my AJAX query is OK:
// if the admin option is set to hide recurrences, or the user option is set if ( $this->should_hide_recurrence( $query ) ) { $query->query_vars['tribeHideRecurrence'] = 1; }should_hide_recurrence() brings us to the admin setting. I’ve unchecked that and the AJAX request with a date set is returning recurrences as expected. D’oh!
Well, that seems stupid and simple, but I’m not sure. setup_hide_recurrence_in_query() is hooked to tribe_events_pre_get_posts with default priority (10). So why does my code, hooked at 99 or 9999, not override the default admin setting?
I left the admin setting checked, to hide recurrences, because that’s exactly what we want as default. However, now I’ve set the admin setting to default to show recurrences, our default list view has them hidden. I guess in this case, my override is working – it just wasn’t working the other way round, on AJAX requests.
Our team is now testing things as they are. If everything seems to work, I’ll probably leave it at that. Even though there does seem to be something amiss in terms of the logic, if the outcome is OK, I don’t have the time to dig deeper to solve a mystery that isn’t apparently affecting things aversely. Let me know if this sheds light on what’s amiss for you, and thanks for your help so far.
Hi there,
Thanks for the extra information. However, no joy!
I’ve switched the tribe_events_pre_get_posts hook for pre_get_posts. Here’s the hooked code in question:
add_action( 'pre_get_posts', 'yh_tribe_events_pre_get_posts', 9999 ); function yh_tribe_events_pre_get_posts( $query ) { // Is this an events query on the front end? if ( PILAU_FRONT_OR_AJAX && tribe_is_event_query() ) { //echo 'yh_tribe_events_pre_get_posts() - START: <pre>'; print_r( $query ); echo '</pre>'; exit; if ( YH_EVENTS_SHOWING_RECURRENCES ) { // Show recurrences $query->set( 'tribeHideRecurrence', false ); } else { // Hide recurrences $query->set( 'tribeHideRecurrence', true ); } // Include child categories if filtering by category if ( ! empty( $query->query_vars['tax_query'][0] ) ) { $query->query_vars['tax_query'][0]['include_children'] = true; } // Never return past events if ( $query->get( 'tribe_is_past' ) ) { $query->set( 'post__in', array( 0 ) ); } //echo 'yh_tribe_events_pre_get_posts() - END: <pre>'; print_r( $query ); echo '</pre>'; exit; } }A few notes of explanation:
- PILAU_FRONT_OR_AJAX is set to ( ! is_admin() || ( defined( ‘DOING_AJAX’ ) && DOING_AJAX ) ) – self-explanatory
- YH_EVENTS_SHOWING_RECURRENCES is set to ( ! empty( $_REQUEST[‘tribe-bar-date’] ) ) – we only show recurrences if a specific date has been picked by the user
You can see the commented-out bits where I’ve been returning debug data (and I’ve been adding a console.log() line to the TEC JS to see it via AJAX).
All my tests show that the latter print_r( $query ) shows the tribeHideRecurrence query var to be set correctly for any particular request. Only, when a date is picked, the AJAX request doesn’t include recurrences. Then, when you refresh the page with the query vars that have been added, the non-AJAX request returns the events with recurrences, as expected.
I really thought the pre_get_posts thing you mentioned would solve this, it sounded like the obvious diagnosis if tribe_events_pre_get_posts isn’t hooked for AJAX requests.
The priority on my hook, 9999, is what I had it at before. I wondered if by “51 or greater” you meant between 0-50 (since WP hooks get processed earlier the lower the number). However, it doesn’t seem to matter what the priority is, I’ve tried it all the way down to 0.
Any other ideas? We’re not in a big rush here, but we need to solve this over the next week and it’s eating up more and more of our time.
