Workaround for 404 errors when switching to upcoming events (caused by WPML)

[Andres Fernandez]

I’ve been facing an issue reported by others in the Forums, namely the conflict between The Events Calendar and WPML, and I came up with a “workaround” using WP’s flush_rules function and a conditional with $_SERVER[‘REQUEST_URI’] on the 404 template, that essentially has my site “healing itself” when a 404 error is triggered when switching to upcoming events (“list view”).

Not sure if this is still an issue as these threads are closed (I’m using oldish versions of the EC plugin and WP for particular reasons). Please reply if more details on the “workaround” would be helpful to the community, I’d be happy to share them.

Thanks!!

[Josh]

Hello aplussideas,

Thanks for reaching out to us!

This is actually a great suggestion and something that we discussed internally as a potential solution to some of the 404 errors. We’ve currently passed on the option of adding this into our core plugin because of the potential for this to be taxing on servers for heavily trafficked sites.

If you would like, you can definitely add your solution here and it will be available for others to use as a reference in the future.

Thanks!

[Andres Fernandez]

Of course! Here’s what I did as a workaround to address my specific issue (upcoming events triggering a 404 error as a result of users switching languages on the site via WPML):

I updated the 404 template on my site to detect if the 404 error came from /events/upcoming/, and if it did, execute the flush_rules function. I also added a meta redirect after the flush_rules function to send the user back to the /events/upcoming/ page, which is now working OK after the flush_rules.

Here’s what my 404.php template looks like now (NOTE: obviously this is specific to my site’s theme, but the code I added “can” work for others); at the bottom of this response (after the code) I explain what each part does:
==============
<?php if ($_SERVER[‘REQUEST_URI’] === “/events/upcoming/”) { ?>
<?php $wp_rewrite->flush_rules(); ?>
<META http-equiv=”refresh” content=”3;URL=”<?php $_SERVER[‘REQUEST_URI’] ; ?>”>
<?php } ?>
<?php get_header(); ?>
<section id=”searchTemplate” class=”container internal boxes” >
<div class=”internalContainer”>

<div class=”info internalFullWidth” style=”width: 93% !important;” data-background=”<?php bloginfo(‘template_url’); ?>/images/bg3.jpg”>
<h1><?php _e(“Error 404 – Not Found”, “republicadominicana”); ?></h1>
<h2 style=”margin-top: 5px; margin-bottom: 5px; line-height: 26px;”><?php if ($_SERVER[‘REQUEST_URI’] === “/events/upcoming/”) {
_e(“This was a momentary error. You’ll be redirected to the Events page in 3 seconds.”, “republicadominicana”); } ?>
<?php if ($_SERVER[‘REQUEST_URI’] !== “/events/upcoming/”) { ?>
<?php echo $_SERVER[‘REQUEST_URI’]; _e(” was not found or may have been moved. <br />Perhaps a search might help!”, “republicadominicana”); ?></h2>
<h2 style=”color: #fff;”>
<div style=”margin-top: 30px; margin-bottom: 40px;”>
<form role=”search” method=”get” class=”search-form” action=”<?php echo home_url( ‘/’ ); ?>”>
<label>
<span class=”screen-reader-text”>Search for:</span>
<input type=”search” class=”search-field” placeholder=”Search …” value=”” name=”s” title=”Search for:” />
</label>
<input type=”submit” class=”search-submit” value=”Search” />
</form>
</div>
</h2>
<?php } ?>

</div>

</section>

<?php get_footer(); ?>
=============

The PHP code above get_header detects if the 404 error came specifically from /events/upcoming/ and if so, it first triggers the flush_rules function (which solves the problem) and then triggers the meta redirect back to the /events/upcoming/ page. If it didn’t come from /events/upcoming/ then it does the usual thing that a 404 error page does.

Further down in the code I use a conditional with $_SERVER[‘REQUEST_URI’] again, this time to show the user a message on the screen that informs them this was a “temporary error” and that they’ll be redirected back to the Events page in 3 seconds.

And further down I use the conditional again, but this time to show users something different if the 404 error was NOT triggered by /events/upcoming (in this case it’d be a normal 404 error, so I show them a standard “not found, try a search” message along with the typical WP search form).

I use pingdom to monitor the site, and I have a check specifically to alert me if the /events/upcoming/ page is down for more than 1 minute; since I implemented the workaround above, I’ve had ZERO alerts (before I was getting several alerts per day at ALL hours – given that the site is accessed from all over the world).

I stress the fact that the workaround above is specific to the issue I was having and is unlikely to resolve OTHER 404 errors other folks might be experiencing.

Separately, here’s an idea that may (or may not) make Tri.be Events work better with WPML in the future (and I apologize for how simplistic it may sound):

– What if the various views are implemented via shortcodes on actual WP pages, rather than the way they’re managed right now? Similar to how Woocommerce does it (when you install Woocommerce it gives you the option to create the pages the plugin needs – shop, cart, checkout, etc. – and basically puts the necessary shortcodes to render those views on those pages. Since they’re actual pages, they’re 100% “translatable” via WPML (with the added bonus that you can “enhance” those pages if you’re using a pge-builder, etc.)

Just a thought… again, I don’t know Tri.be Events in-depth to know if this is even feasible, but I do love the plug-in and it’d be awesome if it can work more seamlessly with WPML (both being the “gold standard” for their specific purposes, event management & translation).

[Josh]

Hello aplussideas,

Thanks so much for adding this information and hopefully this will help others in the future.

Having full compatibility with WPML is still on our radar. Your suggestion for shortcodes would help with some of the compatibility issues but would create new ones as well. There is a balance to be found that hasn’t quite been landed upon.

Thanks again for your input and contribution to the community! I’ll go ahead an close this ticket and allow it to be archived for anyone else searching for this issue.

Thanks!

[Author]

Posts