recurrence description lost in update

[Nico]

Hey Mike,

Thanks for clarifying, here’s a pattern sample of what the plugin expects:


$pattern_example = [
'rules' => [
/*...already covered... */
],

'exclusions' => [
[ /* Start of first exclusion date rule */
'custom' => [
'type' => 'Date',
'date' => [
'date' => '2016-07-01'
],
'interval' => 1,
'start-time' => [
'hour' => '12',
'minute' => '30',
'meridian' => 'pm'
],
'duration' => [
'days' => null,
'hours' => null,
'minutes' => null
]
],
'EventStartDate' => '2016-07-01 12:30:00',
'EventEndDate' => '2016-07-01 14:30:00'
], /* End of first exclusion date rule */

/* ... more exclusions as required ... */
]
];


The excluded-dates part is not required anymore in the new data structure…

Best,
Nico

[Steve]

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 $data array that’s being constructed, and then dumping the new meta value (fetched using get_post_meta(), after calling tribe_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 after tribe_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.

[Nico]

Hey Mike,

We’re sorry if things got a little confusing, we were trying to provide a pointer/basic framework that you could iterate on (and thought that’s what you wanted) but it feels like you’re going to require more assistance than that:

• The basic problem of not having an automated way to handle this migration is definitely our bad and we apologize, though actually few customers have been troubled by this.
• Organically, over time, as events are updated or are replaced by new events, the old data ought to work its way out of the system … until then it seems the key problem you are faced with is the lack of recurrence text.
• How about setting up a filter using the tribe_get_recurrence_text hook?

For that last point, the basic form (I’m writing this without testing, though) would be:

add_filter( 'tribe_get_recurrence_text', 'legacy_recurrence_text_support' );

function legacy_recurrence_text_support( $text ) {
// If we have something to display, return it
if ( ! empty( $text ) ) return $text;

// Else try to find any 'legacy' recurrence description
$rec_data = get_post_meta( get_the_ID(), '_EventRecurrence', true );

if ( ! empty( $rec_data['recurrence-description'] ) )
return $rec_data['recurrence-description'];

return $text;
}


Maybe this approach works better for you?

Please let me know about it,
Best,
Nico

[Steve]

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.

[Steve]

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.

[Steve]

Hiya, is there anyone around to address this?

[Nico]

Hey Mike,

Sorry for the delay in my reply, as you posted several times the thread kept going to the bottom of my queue so I’m noticing it now.

I’ll share this with a dev and let you know about it later.

Best,
Nico

[Nico]

Mike,

Well I’ve reviewed this with Barry (the developer who is helping me on this thread), and your solution looks right! Of course to be sure there’s some testing to be done, which we actually can do for you if you provide a database dump, and give us some time (probably a week or so).

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?

You are right on this, but honestly this is the only case where the migration of this data became critical. Actually logging this as a bug would take more time to fix than helping you here!

Please let us know if you want us to make some tests to your script, and take a deeper look into the issue. As stated this will take a bit longer as I would need to create an internal ticket for a developer to do this (I’m not so technically versed to do so)!

Best,
Nico

[Steve]

This reply is private.

[Nico]

This reply is private.

[Steve]

Any update on this?

[Nico]

Hey Mike,

Not much for now, the developer who has this ticket assigned was working to get the maintenance release 4.1.3 out which finally happened yesterday. He gave me a heads up yesterday that this is still under his radar but he couldn’t allocate time to work on it.

Thanks for the patience,
Nico

[Nico]

Mike,

Thanks for the patience while someone from the dev team analyzed the code and the data migration.

So, after picking some randoms threads the conclusion was that the recurrence description was successfully migrated for all case, but on some cases (like event #3129 “Hackney South Youth Forum”) we did notice that – for us – the recurrence pattern didn’t show as expected in the event editor or the frontend following the migration. Can you check on that event to see if we are getting the same result?

Best,
Nico

[Steve]

The recurrence description for event 3129 seems to show up in the editor OK. However, could you refresh my memory? It’s been a long time since I was looking at this and you (rightly) deleted my post where I uploaded the data for you. Did I give you ‘unconverted’ data for you to try out, or did I give you the data after my attempted conversion for you to inspect?

[Nico]

Thanks for following up Mike!

You sent a database dump via email, that’s the data we used.

Best,
Nico

[Author]

Posts