[clockwork-agency]

Jaime,

We’ve gotten things working locally and updated (didn’t have WooCommerce turned on; grabbed updates directly from https://theeventscalendar.com/my-account/downloads/.

The duplicate buttons and fields are gone and things seem to be working as expected. Thanks so much!

[clockwork-agency]

Hey Sky,

In setting up another staging site I had neglected to turn WooCommerce back on. Sorry about the hassle — working as expected without issue.

[clockwork-agency]

Hey Jaime,

When we tried to update in production the site went down and we’re not able to test the multi-site stuff locally (see https://theeventscalendar.com/support/forums/topic/local-development-using-multi-site-license/). Very leery to try updating in production.

Thanks

[clockwork-agency]

It’s worth noting that for the client’s site at http://www.client.org we’ve also tried client.test and http://www.client.test locally as per the docs.

[clockwork-agency]

TL;DR: the way options are handled in rewrites changed in a very subtle way that’s leading to default values being used instead of custom values.

Quick Fix
Note: only change core files if you know what you’re doing! If you’re unsure about these changes, please wait until Modern Tribe releases an official fix.

Edit wp-content/plugins/the-events-calendar/src/Tribe/Rewrites.php and change line 259 from this:

'archive' => array( 'events', $tec->rewriteSlug ),

to this:

'archive' => (array) Tribe__Settings_Manager::get_option( 'eventsSlug', 'events' ),

(The forums are escaping things so you will want to replace “>” above with an actual greater-than symbol.)

That’s it! That’ll at least fix the archive page. There may be further, similar changes required if you’re using custom single item slugs and other settings.

What’s going on?

The data structures for settings in the get_bases() method in the rewrites file have changed. Previously the bases were single-item arrays with custom values overriding the defaults. Now these bases are multi-item arrays with the defaults first and the custom values second. When the bases are passed through array_map() the default values remain as the first items in the bases arrays and are thus used instead of the custom values.

Using the 4.6.8 get_option calls drops the multi-item settings and only sets a single value.

Comparing the $bases data from 4.6.8 to 4.6.10 you can get a sense of what might be going on. In this example we’ve set “events-list” as our custom archive value:

/* 4.6.8 */ $bases['archive'] = array('events-list');

/* 4.6.10 */ $bases['archive'] = array('events', 'events-list');

I’m not super familiar with The Events Calendar code-wise so I’m not sure how to provide a proper fix. Either the bases/options definitions need to be a single-item array like before or the array adjustments (map, et al.) need to override default settings with custom settings.

[clockwork-agency]

TL;DR: the way options are handled in rewrites changed in a very subtle way that’s leading to default values being used instead of custom values.

Quick Fix
Note: only change core files if you know what you’re doing! If you’re unsure about these changes, please wait until Modern Tribe releases an official fix.

Edit wp-content/plugins/the-events-calendar/src/Tribe/Rewrites.php and change line 259 from this:

'archive' => array( 'events', $tec->rewriteSlug ),

to this:

'archive' => (array) Tribe__Settings_Manager::get_option( 'eventsSlug', 'events' ),

(The forums are escaping things so you will want to replace “>” above with an actual greater-than symbol.)

That’s it! That’ll at least fix the archive page. There may be further, similar changes required if you’re using custom single item slugs and other settings.

What’s going on?

The data structures for settings in the get_bases() method in the rewrites file have changed. Previously the bases were single-item arrays with custom values overriding the defaults. Now these bases are multi-item arrays with the defaults first and the custom values second. When the bases are passed through array_map() the default values remain as the first items in the bases arrays and are thus used instead of the custom values.

Using the 4.6.8 get_option calls drops the multi-item settings and only sets a single value.

Comparing the $bases data from 4.6.8 to 4.6.10 you can get a sense of what might be going on. In this example we’ve set “events-list” as our custom archive value:

/* 4.6.8 */ $bases['archive'] = array('events-list');

/* 4.6.10 */ $bases['archive'] = array('events', 'events-list');

I’m not super familiar with The Events Calendar code-wise so I’m not sure how to provide a proper fix. Either the bases/options definitions need to be a single-item array like before or the array adjustments (map, et al.) need to override default settings with custom settings.

• This reply was modified 6 years, 3 months ago by clockwork-agency. Reason: Code formatting
• This reply was modified 6 years, 3 months ago by clockwork-agency. Reason: further code formatting information
• This reply was modified 6 years, 3 months ago by clockwork-agency. Reason: FORMATTING AGAIN FFS
• This reply was modified 6 years, 3 months ago by Leah.

[clockwork-agency]

Same issue here. It doesn’t matter what we set the slug URL to, it hijacks “/events”.

If we change the slug to “/events-calendar-blah-blah-blah” the events calendar will be visible at “/events” and “/events-calendar-blah-blah-blah”.

Looking at the release notes for The Events Calendar 4.6.10 and 4.6.9, there were changes made in/around code for URL slugs to support WPML and API output.

Going to diff the versions locally to see what changed as we’ve got angry clients. Once we’ve got a working patch we’ll provide it here should anyone else want to monkey-patch their events calendar instance until a proper release is available.

[Author]

Posts