[George]

Hey Jeremy,

We’ve heard a handful of similar reports recently, but all of the sources have been for different reasons so we’re not quite certain of there being a bug or not that is causing this.

On your site, would you be able to run through our full set of troubleshooting steps outlined here? → https://theeventscalendar.com/knowledgebase/testing-for-conflicts/

That’s the best place to start here, in my opinion. Let us know if you’re able to do those steps and, if so, what you find.

Thank you!
George

[George]

Hey Sean,

Thanks for boiling down your question to its essence, which seems to be as follows:

Would allowing the author to change the data of a Saved Organizer or Venue from the Submit an Event form cause any issues? Specifically, when submitting a new event or updating an existing event, if a saved Organizer/Venue’s data is changed on the Submit an Event form, would it be properly updated in the database?

If the developer you hire implements this functionality correctly, there should not be a problem here. Basically, if the Organizer and Venue are updated via something like AJAX, the developer can make the other links on the page (like “Submit Event”, etc.) un-clickable while the AJAX runs.

This way, you can ensure that the data is saved first before other actions like saving the event can be performed on the page.

Doing stuff like this is quite standard when make AJAX or just general front-end submission/editing features. Once the Venue and/or Organizer data is saved properly, then updating event(s) related to it will not affect that data unless there is code that explicitly modifies it – there isn’t, by default, so it would have be consciously added by the developer or yourself. That doesn’t sound like your plan 🙂 So as long as the AJAX front-end editing saves the stuff correctly, and perhaps has good features that prevent other links from being clickable on the page while it runs, you should be good to go.

I hope that helps!

Cheers,
George

[George]

Thanks for the update, and for the flexibility in the meantime while we continue to improve things. Stay tuned to the next few releases! 🙂

Cheers,
George

[George]

Hey Fridolin,

Thank you so much for reporting this to us. I’m very sorry to relay the news that this is indeed a bug.

We missed this bug until now, and your report has brought it to our attention and we will work actively on a fix for it. I’m sorry to admit that this leaves little options for actually fixing it on your site for now, the only thing I could think of would be to manually create another widget area where you’re using the shortcode currently, and then just drag another version of the Widget there for now.

If you’re not sure about creating widget areas in WordPress, the following Codex article should bring you up to speed quite thoroughly → http://codex.wordpress.org/Widgetizing_Themes

Thank you!
George

[George]

Hey Johan,

I’m sorry for the delay in response, but it’s been hard trying to come up with something to say here – there is unfortunately a bit of an impassable barrier here because fundamentally WMPL and The Events Calendar do not work together.

We are working hard to improve this and hopefully in the coming months will have better compatibility included in our plugins, but it may simply not be useable here.

If you’ve purchased The Events Calendar recently enough, we can issue you a refund. It seems like your original purchases were years ago, but we could at least refund your license renewals.

I’m really sorry to disappoint Johan. It pains us that our code doesn’t work well with WPML and we’re working very hard to fix that as soon as possible, one of our developers Gustavo is focused pretty centrally on it.

Thank you,
George

[George]

Hey Magnus,

I’m sorry to disappoint, but that is not possible without a level of code customization that is a bit beyond the scope of support we can provide here.

If you’re curious about where to even start with this, in The Events Calendar core plugin there are several Widget-related classes in the /src folder. If you start there you may be able to piece together how the calendar jumps to the current date, and modify this accordingly.

Please let me know if there are any other things I can help with, I’m sorry to disappoint on that front with the widget but changing it “for real” is quite tricky (however: see below! 🙂)

Thanks,
George

---

P.S. A “Hack” for Faking this Feature

So, up above I mentioned that “genuinely” getting the calendar widget to actually load on the desired month (if other than the current one) is a bit complex. However, there is one solution I came up with that sort-of “fakes” this effect. It works by using JavaScript to “fake” click the “Next Month” link, so that to the user it would seem like the page just loaded on that month.

You can try this out (as an idea – it may not work well enough for your needs 🙁 ) by pasting code like the following into your theme’s functions.php file:

add_action( 'wp_footer', 'example_fake_widget_click', 100 );

function example_fake_widget_click() {
    if ( ! wp_script_is( 'jquery', 'enqueued' ) ) {
        wp_enqueue_script( 'jquery' );
    }
?>
    <script>
    jQuery(document).ready(function($) {
        if ( $( '.tribe-mini-calendar-nav' ).length ) {
            $( '.tribe-mini-calendar-nav-link.next-month' ).trigger( 'click' );
        }
    });
    </script>
<?php
}

That’ll push the calendar one month ahead on page load. Need it to go two months ahead? Just add more calls of .trigger( ‘click’ ) – for example, to make it go three months ahead:

$( '.tribe-mini-calendar-nav-link.next-month' ).trigger( 'click' ).trigger( 'click' ).trigger( 'click' );

A bit of a hack, and not very pretty…but just an idea. Might help!

Cheers,
George

[George]

Hey Sean,

Thanks for clarifying that, sorry I misunderstood you at first!

Those “spinners” are a generic “input type”, the UI of which is dictated by your browser.

What browser are you in when you don’t see these spinners?

If possible, take a screenshot of what you see in your default browser. Then, view the same page in other browsers and compare the results.

Let us know what you find! 🙂

— George

[George]

Hey @popyoga,

While it may not be literally the next release, and we don’t have a specific date we can promise for when it will come out, we indeed have better ticketing support for recurring events in the pipeline and are working on it pretty hard, along with a few other general improvements to our ticketing framework.

I apologize for the lack of specific dates but would hate to promise something and then let you down if we have to push the date back again or something.

Let us know if you have any other questions here or comments, concerns, etc.

Thanks!
George

[George]

Thanks for the udpate! Can you run through the steps I outlined in the above reply? Let us know if you do, and what you find!

Thank you,
George

[George]

Hey Jim!

As a CSS neophyte, will that negatively affect any other pages?

No, only pages where the #tribe-events-pg-template ID is present, which is only on pages generated by The Events Calendar.

As for your other comments, thanks for the update and I’m glad the SEO thing is cleared up a bit.

Since both items have been addressed here, I’ll close up this particular thread to keep things organized – but if you have any other questions/issues/concerns, open a new thread here on the forums any time! 🙂

Cheers,
George

[George]

Glad to hear it Sean, thanks for the update!

Cheers,
George

[George]

Cool, thanks for the update. Has it mostly resolved your issues here? If so, I’ll close up the ticket, but feel free to post here or start a new thread if you any further questions/concerns/etc.

Thanks!
George

[George]

Hey @melzar,

To start answering your questions backwards: yes, we can remove links you’ve placed here to hide them search results 🙂

As for the other issues:

The recurrence time spans you’ve set up (3 months in the past / 12 in the future) could be at play here, and it’s potentially worth trying to shorten that time frame if you’re able to do so on your site.

As for the soft 404s, if the no-404s plugin is not working then trying your “404 to 301” plugin might indeed help. Worth a try!

[George]

Hello,

Thanks for confirming that.

When I got to the /events/community/add page on your site, I’m still met with this requirement to log in: https://cloudup.com/csqEAiOYXVy

Why is that? What settings and/or plugins on your site do you have configured to require logins there?

I would recommend running through our complete set of troubleshooting steps outlined here → https://theeventscalendar.com/knowledgebase/testing-for-conflicts/.

Do each step there, and after each plugin deactivation do two things:
1. Go to Settings > Permalinks in your admin area, and just click “Save Changes” without actually making any changes. This may seem like an odd thing to do but is a little “trick” within WordPress to get the permalinks across your site to refresh, which might help here.

2. Then go to http://innergy4every1.com/events/community/add and see if anything is improved.

So, do each step in that “Testing for Conflicts” article, while also doing steps 1 and 2 above after each plugin deactivation in that process.

This should help with further troubleshooting. Let us know what you find!

Thanks,
George

[George]

Hey Cindy,

The “Cost of Event” field cannot be used for anything other than the numeric cost of the event.

The best case I can think of for “Type” of event is to use Event Categories. These will be filterable in the Filter Bar.

If you use categories, you should then be able to filter by multiple categories.

I hope this information helps – apologies if what I wrote here led you to believe that the Event Cost field could be used for anything other than numeric price values!

— George

[Author]

Posts