[Andres Fernandez]

Hello Tribe,

Trying to accomplish the exact same thing as Nick… it would be tremendously helpful if you guys would consider adding the “limit” parameter to the “calendar view” [tribe_events] shortcode, to override the limit set in the plug-in’s main settings.

The reason this would be helpful is that for Events Calendar Pro users (like Nick and myself), having the ability to display a “rich” view on any given page (other than the main events page) while being able to control the number of events displayed, would be more interesting than being restricted to rendering the list widget via shortcode (the list view widget is great for a sidebar, but not nearly as great to display events in a section of a full-width page).

I highly encourage you to consider this improvement to an upcoming update of the plug-in, it’ll make it that much more powerful.

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

[Author]

Posts