[Nico]

Hola Óscar,

Gracias por la respuesta y disculpa la demora en la mia!

En cualquier caso si recomendáis agregar la función en cualquier otro fichero, por favor, házmelo saber.

Definitivamente no es lo correcto agregar codigo en los archivos core de WordPress ya que al actualizar la version del mismo estos cambios van a ser descartados. Lo que viste en el codex es la ubicacion de la funcion que permite ‘añadir’ los filtros. En este caso solamente utilizamos un filtro existente, y el codigo enviado deberia ir en el archivo functions del theme o theme hijo en caso de esta usando uno.

Sobre el tema logueo, sigo pensando que es un bug. Siempre he tenido el logueo deshabilitado(y lo sigo teniendo), pero el plugin está generando un fichero en la carpeta temporal aunque después no esté añadiendo ninguna información (todos los ficheros tienen 0 bytes, están vacíos, puedes verlo en la captura que te adjunto).

Esto es interesante voy a compartirlo con el equipo de desarrollo para conocer su opinion al respecto. Posiblemente sea un bug!

Me alegra saber que por el momento eso no te esta trayendo problemas, pero dejame consultarlo para entender si es un bug o solamente la forma en que funciona! Ni bien tenga alguna respuesta de parte de desarrollo te hago un update.

Saludos,
Nico

[Nico]

Hola Fernando, como estas?

Gracias por ponerte en contacto con nosotros nuevamente!

Primero que nada dejame decirte que el problema que estas experimentando esta directamente relacionado con el theme que estas usando. Por defecto el formulario para la compra de entradas no se abre en pop-up, tampoco los campos adicionales x asistente. Dicho esto, creo que lo mejor es que te pongas en contacto con los desarrolladores del theme para ver si ellos pueden darte alguna solución al problema.

Lamentablemente no hay mucho que podamos hacer en esta caso desde nuestro lado 🙁

Saludos,
Nico

[Nico]

Stoked to hear Jonathan! Thank YOU for pointing this out 🙂

I’ll go ahead and close out this thread, but if you need help with anything else please don’t hesitate to create a new one and we will be happy to assist you.

Best,
Nico

[Nico]

Hi there Simon,

Thanks for getting in touch with us, and sorry to hear about this issue!

I’ve inspected the source code of the site and it looks like you’ve copied/pasted the scripts from our demo site wpshinding. Not sure why you did this but it’s not a good idea.

Can you please try to switch to a default theme like Tweenty Seventeen (or any other WordPress theme) and check on this? My guess is that your theme is lacking the wp_footer(); and/or wp_head(); calls. Can you check on this?

Please let me know about it,
Best,
Nico

[Nico]

Hey,

I could confirm what I stated in my reply yesterday with the team. SO basically it’s not possible to import an event cost via ICS.

Please let me know if there’s anything else I can help you with,
Best,
Nico

[Nico]

Hi there @natiotech,

Thanks for getting in touch with us!

As far as I’m aware the iCal format spec does not define a field for event cost. So I don’t think this is possible, hence not a feature of the importer. Anyway let me touch base with the team on this, just to be sure I’m not missing something!

I’ll be back when I have a confirmation on this,
Best,
Nico

[Nico]

Hi there Jonathan,

Thanks so much for reaching out to report this issue!

I just confirmed the code in the KB article is not working correctly as you state. You can use this updated code instead, which seem to work fine:


add_action( 'init', 'move_eb_ticket_form' );

function move_eb_ticket_form() {
$display_tickets = array( tribe( 'eventbrite.main' ), 'print_ticket_form' );
remove_action( 'tribe_events_single_event_after_the_meta', $display_tickets, 9 );
add_action( 'tribe_events_single_event_before_the_meta', $display_tickets );
}


I’ll update the code in the Knowledgebase article as well! Once more thanks for the heads-up 🙂

Please let me know if it works for you,
Best,
Nico

[Nico]

Hi there Robyn,

Thanks for getting in touch with us and welcome to our support forums 🙂

First thing I’d recommend is to update the plugins to the latest version. Once that’s done, Can you please follow the steps described in our Testing for conflicts guide? This way we can see if this is a problem in our plugin or a conflict with the theme or other installed plugins.

Please let me know about the testing results,
Best,
Nico

[Nico]

Hi there @papertower,

Thanks for getting in touch with us to report this! Let’s see what’s going on here.

Although your point is super valid, I couldn’t reproduce this in my local test site. I know this has been an issue in past versions of the plugins but after some iterations this was solved at the time.

It would be great if you could share your system information with me so I can which versions of the plugins you are using.

Please let me know about it,
Best,
Nico

[Nico]

Hi there Chelsea,

Thanks for following up and really sorry for the delay in our reply 🙁 Cliff assigned this thread to me as he thought I could help you better, and it was out of my radar until I noticed it today. I’ve already review your request and I’ll try to help out as best as I can 🙂

First of all, what you are experiencing in the site is normal. If the timezone is changed, all event start and end date/times will be ‘converted to the new timezone’. Unfortunatelly we don’t have an automated way of changing all events timezones without affecting the event date/time. Hunter suggests a SQL query in this reply to change just that information.

I think that getting the events in your site to the correct timezone and time settings will be the best. In that case you can rely on default behaviour of the iCal feed generator. But there’s also a filter to alter each event information before the iCal feed is printed. This gives you an opportunity to hijack the information there. The snippet below (paste it in your theme’s (or child theme’s) functions.php file) will force a timezone for events without converting it’s date or time:

https://gist.github.com/niconerd/cbbb0e4a5b1494955fa9f61cc58f9a9a

Please let me know if this works for you,
Best,
Nico

[Nico]

Thanks for clarifying Adage!

If you want to change the zoom of all embed maps, you can do so from ‘WP-Admin > Settings > General > Google Maps default zoom level’. But if you just want to target single venue pages, you can use the following snippet (paste it in your theme’s (or child theme’s) functions.php file):

https://gist.github.com/niconerd/b747a80afb2b33c5fa6d7deede65b1f8

For the scroll wheel, it’s not so easy to do it for embed maps. You can find some suggestions here → http://stackoverflow.com/questions/21992498/disable-mouse-scroll-wheel-zoom-on-embedded-google-maps

Please let me know if this helps,
Best,
Nico

[Nico]

This reply is private.

[Nico]

Thanks for following up Riza!

I’ve re-checked and that’s how week view displays events by default. Just to check we are on the same page this is how I’m seeing it:

I guess week view is not the best display for those events (all week empty except for weekends), but again it’s how week view displays events by default.

Please let me know if you are seeing differently from your side,
Best,
Nico

[Nico]

Thanks for following up Herman!

That means that I need to manually post all the events again from the one now to the Pro version? Or will the Pro version use the data from the old one.

It will use the existing data, no need to re-enter anything manually 🙂

You cna find more details on how to install and activate Events Calendar PRO here → New User Primer: The Events Calendar and Events Calendar PRO

Please let me know if there’s anything else I can help you with,
Best,
Nico

[Nico]

Thanks for confirming Ivan! Glad to be of service 🙂

I’ll go ahead and close out this thread, but if you need help with anything else please don’t hesitate to create a new one and we will be happy to assist you.

Best,
Nico

[Author]

Posts