[Barry]

Hi Vivianne,

Thanks for getting in touch.

The topic you linked to is approximately 3 years old and related to a much earlier version of one of our ticketing plugins, so I’m not too surprised it didn’t work 😉

To achieve what you want you will definitely need to do some custom coding – and it is going to mean customizing the output not only of our plugin(s) but of WooCommerce, too, so for some elements of this work you may need to refer to their documentation or connect with their support team.

Before we go any further, though, I notice that you appear to have two valid license keys at present but neither relate to Event Tickets Plus (nor to our legacy WooTickets plugin). Did you purchase a support key for one of those plugins under a different account? Would it be possible for you to login using that account instead?

Thanks!

[Barry]

Excellent, glad you got something working (and thanks for sharing the final solution – I’m sure other WP Super Cache users may find this useful) 🙂

[Barry]

Hmm, well, one other thought is switching away from the wp_enqueue_scripts action and instead using:

tribe_pre_get_template_part_pro/widgets/mini-calendar-widget

In the normal run of things, this will fire after the calendar widget has enqueued its own scripts so may be a better choice.

Unfortunately, for custom development/integration tasks like this one, we are unable to provide in-depth support and we’ll really need to bow out and leave this one to you (but please don’t forget that you can post a feature request, if you haven’t already done so, requesting that this sort of capability be officially baked in to the plugin) 🙂

[Barry]

Thanks for sharing your solution, great to hear you’ve got something working there 🙂

I don’t believe we do trigger any events once the widget is set up, and would assume setting a timeout as you have done works because our own scripts aren’t ready to listen out for click events prior to document.ready (since your code is also waiting until that point, it’s probably an order of operations issue we’re looking at here).

Enqueuing your script in the footer as you suggested is definitely an option or, if you prefer not to do that, it may simply be that bumping the priority on your wp_enqueue_scripts callback to something like 100 will do the trick.

[Barry]

Hi @psasser,

Great question!

In WP Super Cache’s FAQ page there is an explanation of how to keep specific parts of pages (such as widgets and other things that we don’t want to be ‘frozen in time’) dynamic:

See: “How do I make certain parts of the page stay dynamic?”

Additionally, it’s also worth bearing in mind that most of our widgets feature ajax-driven pagination. A clever customization could make use of this to refresh the widget content as soon as the page is rendered, keeping the information nice and fresh.

Both approaches involve a little custom development/integration work and I’m afraid we can’t assist with the fine detail of that, but this does seem like something other users might be interested in and so it could definitely be worthwhile posting a feature request on our UserVoice page for improved out-of-the-box integration with WP Super Cache.

I hope that helps 🙂

[Barry]

Hi Angela,

Thanks for the extra detail.

My assumption may be wrong but going by what I have read Events Calendar js should load in the footer which it isn’t.

Again, I’d emphasize that it is perfectly correct and expected for some number of scripts enqueued by The Events Calendar and its associated plugins to do so in the head rather than the footer – this generally isn’t a cause for concern in of itself.

I too am finding that I might have to refresh many times before the calendar loads.

Well, it doesn’t seem to be the very snappiest of sites but the calendar views all work as expected when I visit. Could the need to refresh actually be more of a perception issue – in that it takes a few seconds longer than people are used to for pages to load, making them feel they ought to hit the refresh button?

If so, perhaps making adjustments to improve performance – such as adding caching systems or even upgrading to a more powerful hosting package might be part of the answer?

I also don’t see the JS errors you cited – can you detail how I’d replicate these (do they show up on a particular view or after you perform a certain type of action)?

[Barry]

Hi Angela,

Thanks for getting in touch!

Some amount of JS will indeed be loaded from within the head element and that’s to be expected. What I’m not too clear on are the specific problems you are facing.

Can you describe what you mean when you say the calendar isn’t loading consistently and is this something I would be able to see on the (test?) site you linked to where you are running only a default theme?

Thanks!

[Barry]

Great – hopefully we can close in on the issue!

[Barry]

Thanks!

Unfortunately, though definitely worth a try, I suspect those are false positives: the Google Map errors in particular have no bearing on this (they’re a known problem) and the isotope layout issue does not seem to trigger the same problem for me when I test the site with the latest version of Firefox.

So, again, this seems rather specific to you, the computers you are using or the network they are on: can you follow up on my questions about the environment you are trying to access these sites from?

• Do you have access to machines running something other than Windows 7? Do you see the same issue then?
• Does the same thing crop up if you switch to Google Chrome on the same machines, if that’s something which is available to you?
• Are you behind any kind of firewall or do you have any security software running that might impact?

Again, we are unable to replicate and I’d expect far, far more reports if there was a general problem impacting Firefox users in this way.

[Barry]

Awesome, I’m glad to hear that worked – and thank you for sharing this solution – we’ve got lots of Avada users out there and this will probably be very useful for them, too 🙂

[Barry]

That’s really odd.

I should highlight before we go much further that it would be very hard for us to support all browsers on all operating systems. In this case, we’re talking about Windows 7, for which mainstream support has ended, as well as IE9, which has not been supported by its vendor at all for quite some time.

The fact that you see the same problem when running a very recent build of Firefox, though, is concerning – but it’s such a popular browser I would anticipate many more users reporting this issue if it was a widespread problem.

That to say, it sounds like this set of issues is specific to either Windows 7 or else that’s incidental and there is some other factor at work. Is there anything else I would need to know about the environment in which you are using these machines? For instance, are these machines running behind a corporate firewall or do they have any additional security measures in place a ‘normal’ PC might not have, or anything of that order?

Is there something specific we can run (Debug?) that would tell you more?

There is 🙂

Let’s focus on Firefox for the moment. Please navigate to photo view on our WP Shindig test site and open the browser dev tools (normally: Ctrl + Shift + I). Do you see any errors being reported in the console tab?

Leave the dev tools/console open and refresh the page: any other errors?

[Barry]

Happy to help 🙂

I’ll go ahead and close this topic – but of course should anything else crop up please don’t hesitate to create a new one and one of the team will be only too happy to help.

[Barry]

Hi Deborah,

Unfortunately I am still unable to replicate. I see you noted down use of Firefox 45.0 – are you seeing the issue with that browser also? Also, if you open your browser console in any browser where you see this problem, do you notice any errors?

Thanks!

[Barry]

Hi Alison,

I appreciate your standpoint but I’m afraid I disagree with your assessment of this as a bug.

If the importer locates what it believes is the same event (ie, it has already been imported) then it does not create a new event, rather it updates the existing one. The criteria for determining what counts as the same event has essentially remained unchanged: it is one where title, start and end dates are the same – and this has been the case since CSV imports rolled out in our 3.2 release.

So, if you import from the following CSV data:

title, startdate, starttime, enddate, endtime, category
Test Event, 2016-04-20, 1000, 2016-04-20, 1500, blue

You will end up with a an event called Test Event categorized in the blue category. If you subsequently import the following CSV (where the only change is the category):

title, startdate, starttime, enddate, endtime, category
Test Event, 2016-04-20, 1000, 2016-04-20, 1500, red

Then you won’t end up with a second event of the same name, instead the existing Test Event will be updated and re-categorized under the red category.

Again, this hasn’t changed since version 3.2 and if you experienced something different prior to December 2015 that was itself either an unintentional bug or, as Josh suggested, it may simply be that the source data had subtle differences in terms of the titles and dates which meant they weren’t seen as the same event.

I’m sorry, but unless we’ve misunderstood you this isn’t something we will be treating as a bug: it’s the intended behaviour. We’re open to changing it or adding enhancements to help achieve what you are aiming for, but doing so will mean we need to introduce a new setting or at least a new filter hook (so that we can ensure users who understandably expect the intended historic behaviour as detailed above are not taken by surprise).

Perhaps, as a workaround, you could incorporate the category into the event title in the following form (where blue would of course be the category):

My Event Title [blue]

With a small customization you could remove any bracketed category text from the titles prior to displaying them: that way, you would have unique events ‘per calendar’.

I hope that clarifies things and also gives you some avenues to explore in the near term.

[Barry]

Hi Alison,

Thanks for your patience so far and our apologies for the delayed responses: as Geoff noted, Josh has been unavailable recently – that combined with unusually high volumes of support requests have unfortunately meant we weren’t quite as responsive here as we normally are.

Also I noticed on our account that it still states our license is still expiring in a week. I was told it would be extended for another month?

I’m unsure why this didn’t take effect – but have now extended it for a further month 🙂

I would like to be clear though that we can’t guarantee this feature will be implemented within that timeframe, nor can we keep extending your license indefinitely (and I’m sure you don’t expect us to – but I felt it best to clarify this simply to ensure your expectations are not set incorrectly). It’s also worth bearing in mind that CSV import is a core feature that ships with our free plugin, The Events Calendar, and so is not directly related to Events Calendar PRO itself.

For our perspective this is a proposed feature request rather than a bug and given there doesn’t seem to be a lot of demand for it across the community it’s not our very highest priority: we’ll evaluate it and make a decision on taking it forward in due course, but I’d hate to leave you with a promise of a fast turnaround when that isn’t really something you should count on in this specific instance.

Thanks once again for your patience and if you have any follow-up questions about this please let me know and I’ll do my best to get you an answer – of course, for any other unrelated issues that crop up please do post a fresh support topic 🙂

[Author]

Posts