[Barry]

I’m sorry to hear that, Tom, but if you’d rather move on I’m sure we can accommodate your request.

[Barry]

Hi Tiffany,

Once you’ve imported an event you can edit then set the Leave this event associated with Eventbrite option to No — that will break the connection between them.

There’s some information about how this and other facets of how Eventbrite Tickets over in our knowledgebase:

theeventscalendar.com/knowledgebase/creating-tickets-and-publishing-to-eventbrite

Does that help at all?

[Barry]

Hi there, Dean.

what the downside to running the code with and without the caching is on a live environment.

A lot depends on how many events you have, if you already have a persistent caching layer in place and other factors relating to your hosting environment … so it’s hard for us to give you a definitive answer here.

What I’d suggest then is measuring the difference: look at how it behaves with caching, then do some further benchmarking without caching. Remember also that it’s not necessarily a choice between caching and no caching — for instance you could replace the following code from the snippet:

set_transient( 'all_geo_markers_store', $markers, DAY_IN_SECONDS );

With something like this, which will set it to expire a whole lot sooner:

set_transient( 'all_geo_markers_store', $markers, HOUR_IN_SECONDS );

With that sort of approach you could still benefit from transient-based caching but keep things reasonably fresh at the same time 🙂

[Barry]

Hi Andrew,

Thanks for contacting us.

Officially, we support the same stack as WordPress itself and – at this time – that does not include MS SQL.

I cannot replicate those same errors on a standard installation and, given your notes, that makes me think that perhaps the complicating factor is the translation layer provided by Project Nami rather than a bug within The Events Calendar (if you’ve got any thoughts to the contrary or can guide me in a way that would allow me to reproduce on a standard installation running on top of MySQL, though, definitely let me know).

We’re certainly not closed to the idea of improving compatibility, but at this time I’m not sure we see quite enough demand for this to invest in it ourselves.

There are a few ways forward from here:

• You could submit a request on our UserVoice page for Project Nami compatibility – as others can up-vote requests this is really helpful in terms of letting us gauge demand
• If you have specific ideas as to how we could change our code to make it compatible with Project Nami (bearing in mind, it would need to be something that is feasible for us as a MySQL-focused team to maintain) then we’d be open to discussing a pull request should you wish to submit one
• It looks like your purchase of an Events Calendar PRO license was very recent: if you need to make things work in the short term and cannot move to a MySQL-based stack, we’d certainly be happy to provide you with a refund should you wish to re-invest in a different solution that better meets your needs

We’d be sorry to lose you, but realistically I’m not sure how much we can do for you at this point. I hope the above at least provides you with some options you can take forward, though 🙂

[Barry]

This reply is private.

[Barry]

This reply is private.

[Barry]

This reply is private.

[Barry]

Hi Justin,

There are a couple of things you can try but I can’t guarantee the effects will be long-lasting (they might however provide you with some temporary relief, at least). First:

• Visit Events ‣ Settings ‣ Import and look inside the General Import Settings area
• Import limit type will be set to one of two types and that controls the next setting you will see which will either be a date range or numerical limit
• Whichever it is, try reducing it (ie, from 2 months to 1 month or from 200 to 100, etc)

Second (whether this is workable will depend on how much time you have and how many scheduled imports you have):

• Visit the Events ‣ Imports ‣ Scheduled Imports screen
• For each scheduled import, delete and recreate

In some cases, this clears things out and will restore normal operation. I realize it’s clunky and ideally it wouldn’t be recommended. Hopefully our next release will provide a more complete solution that doesn’t require this sort of step and I can only thank you for your patience in the interim.

[Barry]

Hi Israel!

Much as we’d like to, I’m afraid it is not possible for us to guarantee success when additional plugins such as third party WooCommerce extensions are used.

The best I can really suggest is picking the bundle plugin that best fits your needs and giving it a try … I’d like to think that if the other plugin also respects WordPress and WooCommerce best practices then everything would “just work”.

Of course, in practice things can be more complex than that and we don’t really have any direct experience with those other plugins to draw on here.

We’d love to hear how you get on, though 🙂

[Barry]

Glad you’re all sorted here, Jan.

I’ll go ahead and close the topic since you marked it as ‘resolved’ but of course please don’t hesitate to create new topics if we can help with anything else 🙂

[Barry]

Hi Gordon,

I understand it’s frustrating – and we want to help you.

It’s possible it was removed recently, but I’m not sure I can identify this bug on our known issues list. Here’s what I can tell you, though: the majority of our users aren’t experiencing the problem you have described and I’m unable to replicate it myself, either on a regular installation or within a multisite network. As I’m sure you can appreciate, that makes it difficult for us to assist you and it points to the existence of a conflict somewhere along the line.

How about this: let’s ignore the multisite angle for the time being. If you install a new WordPress site – it can be as simple as a sub-directory install such as example.com/test (most CPanel type hosting environments make setting this up pretty easy) – are you able to replicate the same thing using only our plugins?

Assuming for the moment you cannot, start adding the same plugins and the same theme that you have on your live site. Do you find one of those trigger the problem? If so, pause and let us know!

Approaching things this way may help to identify the component that is triggering the conflict and it will avoid any disruption on your live site 🙂

Are you able to give that a shot?

[Barry]

Sorry to hear it didn’t work for you, Sylvia.

We are of course sorry for the delay in delivering a substantive fix on this one. As you’ll appreciate, it involves interaction by two major and fairly large components – The Events Calendar on one side, WPML on the other – and only one of those is entirely within our control.

Nonetheless, we realize this is important for you and many others and we’ll do our best to progress a fix as soon as we can.

[Barry]

This reply is private.

[Barry]

…and just for the benefit of other users reviewing this topic, I’d emphasize again the need to read the comments in the code. If you are running an English language site, for example, the above code will probably result in an error unless you swap out the reference to jp with en (and so on for other languages).

[Barry]

Hi Palmtree,

Perhaps this snippet will help you:

add_action( 'wp_footer', function() {
echo <<<HTML
<script type="text/javascript">
if (
'function' === typeof jQuery
&& 'function' === typeof jQuery.fn.bootstrapDatepicker
) {
// 1) In this example we're adjusting the jp (Japanese) property,
// to modify the English equivalent we'd access en instead.
//
// 2) The format in this example will result in the year then the
// full month, but all formats as described below are accepted:
// https://bootstrap-datepicker.readthedocs.io/en/latest/options.html#format
jQuery.fn.bootstrapDatepicker.dates.jp['titleFormat'] = 'yyyy MM';
}
</script>
HTML;
}, 1000 );

This could be added either to a custom plugin (preferred) or else to your theme’s functions.php file.

Please note that you will probably need to tweak it to get the format you desire, as per the comments in the code itself 🙂

[Author]

Posts