Events Calendar Pro Slug URL rename not working

[elecevan]

Hey, we use our Portfolio to create pages for special events. It uses the Slug & url “Events.” When I added the Events Calendar to our site, I changed the Events Calendar slug from the default “Events” to “Calendars” and the url slug to “calendar.” It worked great until the most recent Update to Events Calendar. The slugs & url’s are just how I set them, but /events go’s to our Calendar instead of our Portfolio page. I re-saved the settings for the slugs & url, and still, the page directs to the Calendar.

Home

[elecevan]

Had to deactivate our Modern Tribe Plugins to get our Portfolio summary page, /events/, back. Bummer.

[Victor]

Hi Greg!

I’m sorry you are having that issue. Let me help you with it.

Have you tried flushing your site’s permalinks structure and see if any changes? You can do so by going to wp-admin > Settings > Permalinks  and click “Save Changes”.

Please let me know if that works for you?

Thanks,
Victor

[nickfetner]

This issue also is happening to me. I tried flushing permalinks and cache. My specific issue is trying to use the ‘events’ slug for a different page. It seems Events Calendar forces the ‘events’ slug to the calendar page.

I was able to temporarily fix by going back to version 4.6.9 for the-events calendar and 4.4.21 for events calendar pro. Hoping there is an update to fix this soon.

[elecevan]

Just flushed the permalinks structure and no go. Still not following my custom slug.

[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.

[elecevan]

Thanks Nick. Flushing the permalinks did not help. I downloaded older versions and installed them. It’s working the way it should. Peace, Greg

[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.

[nickfetner]

Thanks Clockwork. Appreciate the details. Hopefully this will help push an official update quicker.

[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.

[Victor]

Hi Folks!

Thanks for chiming in here and following up with this issue.

I can confirm this is a bug on our latest version of The Events Calendar, which we are already investigating.

For the time being, the workaround is to downgrade to our previous version 4.6.9 > https://theeventscalendar.com/knowledgebase/downgrading-plugin-past-version/

We apologise for the inconvenience. We will keep you posted as soon as we have an update on this.

Best,
Victor

[Victor]

Hi There!

Just wanted to share with you that a new release for The Events Calendar is out, including a fix for this issue 🙂

Find out more about this release → https://theeventscalendar.com/the-events-calendar-4-6-10-1/

We really appreciate your cooperation and patience while we worked on this.

Please update the plugin and let us know if the fix works for your site.

Best,
Victor

[Support Droid]

Hey there! This thread has been pretty quiet for the last three weeks, so we’re going to go ahead and close it to avoid confusion with other topics. If you’re still looking for help with this, please do open a new thread, reference this one and we’d be more than happy to continue the conversation over there.

Thanks so much!
The Events Calendar Support Team

[Author]

Posts