[Barry]

Hi Daniel,

I’m sorry you’ve had such a disruptive experience.

I’ve noticed that when they’re not working they all say that the ea.theeventscalendar.com server is not responding. Could I be getting rate limited by your server since I’m making a lot of requests from the same IP address?

That is a great hypothesis: with around 500 sites running from the same multisite network/the same IP address, this is a real possibility.

While we look at options here, I wonder if I could ask you to dig out some data for us to look at (and if you are uncomfortable doing this/are unsure how, let me know and I’ll be happy to try and build a way to make it easier to obtain this – but if you have access to phpMyAdmin or a similar tool it ought to be pretty straightforward):

• Your network will typically contain a lot of different sets of tables, one set per site
• The usual form is for the tables relating to different sites to be distinguished by numbered prefixes such as wp_1_*, wp_2_*, etc
• Would you be able to query within the options table for a number of different sites on your network and share the content of the cron option with us?
• A sample of two or three sites that are running Event Aggregator would be great

An example query (again, the wp_1_* prefix is likely to be different in your case for each of your sub-sites) to give you a better idea would look like:

SELECT option_value FROM wp_1_options WHERE option_name = ‘cron’;

Thank you!

[Barry]

Seems fine to me – are you mixing and matching WooCommerce tickets with RSVPs perhaps?

Either way, I’m sorry to say we’re pretty much at the end of what we can do to help you here: as noted at the start, the degree of support we can offer for custom dev tasks tends to be limited so all I can hope is that the above at least gives you a starting point and you can take things forward under your own steam and iron out any further problems from there.

Remember that, if you need more help than we can provide here (with custom development in particular) there are plenty of folks who can help:

http://theeventscalendar.com/find-a-customizer

Good luck with the project 🙂

[Barry]

Hi Danna,

I’m not sure that our plugins generate that piece of text. Can you provide me with a URL so I can see live example? It would make it easier to determine the source 🙂

Thanks!

[Barry]

Hi Gary,

That’s a really great question.

All of our plugins are sufficiently flexible that you can generally bend them to meet pretty much any reasonable use case – but I have to be clear this isn’t something that either Event Tickets or Event Tickets Plus were built for and so it would certainly require a degree of creativity and possible some custom dev work to get the sort of end result you are looking for.

That to say, if you need a plugin that offers this out-of-the-box, we probably aren’t going to be the right choice, sadly.

If you are or have access to a dev who can implement custom solutions on top of plugins like ours, though, you could certainly come up with a natty way of facilitating this 🙂

I hope that helps but do let me know if I can answer any other questions you might have.

[Barry]

Fantastic, glad you’re on track 🙂

[Barry]

Excellent!

[Barry]

Thanks for the information, Antonio. If you visit the “history” tab, do imports mostly show as having succeeded or failed (can you share a screenshot of that, too)?

---

Gracias por la información, Antonio. Si visita la ficha “historial”, las importaciones muestran mayormente como haber tenido éxito o no (¿puede compartir una captura de pantalla de eso también)?

[Barry]

This reply is private.

[Barry]

Your other post has been deleted 🙂

Re the problem at hand, let’s switch from obtaining $ticket[‘order_id’] to grabbing $ticket[‘order_id_display’] instead. That certainly seems to work for me, for both the regular ticket email and for the PDFs, too.

[Barry]

Hi John,

Depending on the number of events to be generated they may not all be created instantly, though it sounds like perhaps something else happened here – an unusual ‘blip’ so to speak.

Do let me know if it occurs again, though, and we’ll be happy to explore it some more 🙂

[Barry]

Hi David,

It’s not something I can reproduce – whether I’m creating or updating a recurring event initially or am creating/updating a matching translation, both the post and post parent IDs are integers rather than strings and so I don’t see this error.

I’d love to have a better handle on why this is happening for you and I wonder if another plugin (or even code from your theme) could be interfering in some way.

theeventscalendar.com/knowledgebase/testing-for-conflicts

If you are positioned to do this, either on your current site or a staging/test site, can you deactivate everything except the minimum required WPML plugins (let’s say WPML Multilingual CMS, WPML String Translation and WPML Translation Management) along with the minimum number of plugins on our side required to work with recurring events (The Events Calendar and Events Calendar PRO) and a regular default theme such as Twenty Seventeen.

Can you still replicate under those conditions? I wonder also if you observe any difference between new and existing events and if there is a specific operation you are doing that triggers this (is there for instance a difference between updating or creating a series of events in the default language vs one of the other languages you are working with)?

Thanks!

[Barry]

Hi Amy,

I’m really sorry you were kept waiting so long – but would love to help if I can. Some code like this should help:

function reregister_tribe_events_shortcode( $atts ) {
	$shortcode = new Tribe__Events__Pro__Shortcodes__Tribe_Events( $atts );
	return $shortcode->output();
}

add_action( 'init', 'reregister_tribe_events_shortcode', 100 );

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

The problem it solves is that – by design – the [tribe_events] shortcode will only render once per page. Behind the scenes, though, we find that a lot of page builders effectively trigger the display of shortcodes and other things more than once (though the output is only used once), which can cause problems.

I wanted to flag that because this code will also let you use [tribe_events] multiple times on the same page, however it is not designed for that and doing so may cause problems (in other words, use this solution with care!).

[Barry]

Hi Antonio,

I’m sorry to hear you’ve experienced difficulties with this. Before we continue, I would love to clarify a few things:

• Where are you seeing the errors and can you provide a screenshot?
• Are you primarily importing from facebook.com, or from a different source?
• Approximately how many imports have you scheduled?

Thanks!

---

Hola Antonio,

Lamento oír que ha tenido dificultades con esto. Antes de continuar, me encantaría aclarar algunas cosas:

• ¿Dónde está viendo los errores y puede proporcionar una captura de pantalla?
• ¿está importando principalmente desde Facebook.com, o desde una fuente diferente?
• aproximadamente ¿cuántas importaciones ha programado?

Gracias!

[Barry]

Hi Adam,

Thanks for contacting us.

The language used in the setting might be a little confusing, but I think all you need to do here to get the pattern you are after is switch “the next day” to “the same day”.

This isn’t talking about the same or next day relative to the initial event, rather it is relative to each additional instance that is generated.

I hope that helps!

[Barry]

Hi @cbzen,

It’s certainly possible – as a further customization – but remains something that we do not support “out of the box”: some amount of custom dev work would be required to make this happen.

You’re more than welcome to propose this, though, as a future feature of the plugin:

Our UserVoice page: add feature requests here!

Other users can then up-vote it, giving us a great idea of how much demand there might be (or, if you can find a suitable existing request, you can in turn up-vote that).

[Author]

Posts