Events not publishing/Page not found

Hi Barry,

I’ll keep that in mind in the future. It turns out I likely am having the same problem, the permalinks fix wasn’t working because of a caching issue. Once I fixed that the permalinks solution did work, it just isn’t practical.

Thanks.

@barry,
I do have this issue corrected. By doing the permalink switch I mentioned above, it is working properly. Thanks!

I have still the same problem and it looks that’s something wrong with Event Calendar not my page. :/

https://tri.be/support/forums/topic/after-upgrade-single-event-view-stopped-working/#post-88857

had this problem and the permalink fix didn’t work for me. The new update fixed it tho. updated to 3.4.1! yay!

ooooh spoke to soon,now its back to not working again

so i found what caused mine to fail, incompatibility with a plugin called “project status”. Even after getting rid of this plugin, i had to deactivate the event calendar , then reactivate it to get it to work right again!

@aaron,
Glad you got it to work as we’ll!

I have the same problem. In one situation I got a 404, in other – cyclical redirect on page with single event. It depends of permalink structure (and I don’t want to change it!). But in any case there is right way to see event page: call it https://www.yoursite.com/?tribe_events=event_name. Problem wasn’t decided for a long time, and I desided to simply find a part of code where link to single post is generated and change it according to this sample.

For month view it is in /the-events-calendar/views/month/single-event.php line 27 (ver.3.4.1). Here’s link string made with function tribe_event_link. For widget – it’s made with tribe_get_event_link.

Both functions we can find in /the-events-calendar/public/template-tags/link.php and what’s more – tribe_event_link only calls tribe_get_event_link. So, isn’t it a decision to change this function?

And, at last, here’s my simple variant of this function:

function tribe_get_event_link() {
		$lnk = get_permalink($event);
		$lnk = explode("/", $lnk);
		return $lnk[0] . "/" . $lnk[1] . "/" . $lnk[2] . "/?tribe_events=" . $lnk[4];
	}

Well, maybe you’ll decide that it’s reverse ingeneering, but what we can do – this variant works!

We don’t recommend changing core code, certainly, but you’re welcome to if you want and understand the consequences. I’m not sure that particular fix will be useful in every case for all users, though.

That apart I want you to know we are unlikely to monitor this thread going forward and recommend posting individual threads if you need further help – thanks for the updates, though, particularly the info about “Project Status”. There certainly seems to be a broad correlation between plugins that modify WP’s rewrite rules and this 404 issue for single events.

Of course, it’s not a decision, cause if version of plugin will be renewed, all changes will be lost. But if I whant my calendar do working now – not a days-weeks-… later – it’s only one way: modify code. Of course, those who don’t understand basical php will not do it, but if someone do – this is one of the possible ways to try, I think.

Btw, cyclical redirect in this plugin is an old problem (don’t remember for shure, maybe some monthes). I tried to analyse mechanism of redirects in it, but from version to version it becomes more and more difficult. Add this to redirects in .htaccess, wordpress core, some other plugins in your installation – so where is the broblem? Noone can tell you, it’s only your combination of different factors. And if you don’t want to change your links structure or kill some plugins you need – will author change the code only for you? Will he find universal algoritm for everyone? And general question: when? For me it’s critically, of course not for everybody.

Hi!

We definitely appreciate your viewpoint and I want you to know we do work hard to be good citizens of the WordPress world – and that ethos extends to our code, which we want to play as nicely with other plugins (and themes) as is practical.

That said, can we write code that is guaranteed to work universally in all installations and side-by-side with every other plugin? The reality is we cannot.

As you highlight, a single installation of WordPress can be a complex beast with many layers and addons – I am sure you appreciate then the challenges in supporting many thousands of installations with sometimes wildly different configurations in terms of plugins, themes, versions and differing hosting environments.

Thanks for sharing your solution though, hopefully it will indeed be useful for others here.