Comunidad en Slack para WordPress Colombia

Desde que tuvimos el primer WordCamp en Colombia, en noviembre de 2016, la comunidad WordPress en Medellín y otras ciudades del país ha tomado fuerza y está más unida que nunca.

Hace poco, se creo un grupo en Slack donde todos podremos compartir, discutir, organizar y planear todo lo relacionado WordPress en este país. Los invito a seguir estas instrucciones para hacer parte de esta comunidad:

Crear una cuenta en

Si ya tiene un usuario para participar en los foros de, o un usuario para acceder al Slack de WordPress, puede saltarse este paso, pues ese es el nombre de usuario que deberá usar para ingresar a WordPress Colombia.

  1. Visite
  2. Elija un nombre de usuario e ingrese su correo electrónico.
  3. Revise su buzón de correo electrónico. El sistema le enviará un mensaje con un enlace que deberá utilizar para generar la contraseña de la nueva cuenta. Es posible que el mensaje tarde algunos minutos en aparecer en la bandeja de entrada.

Crear un cuenta en WordPress Colombia

  1. Visite
  2. Ingrese el nombre de usuario de su cuenta en
  3. Elija el dominio al que está asociada su cuenta. Intente primero eligiendo como dominio; funcionará para la mayoría de usuarios.
  4. Revise su buzón de correo electrónico. Slack le enviará un mensaje con un enlace para continuar el proceso de registro.
  5. Haga click en el enlace. Luego elija un nombre de usuario (el mismo que eligió en, si es posible) y una contraseña.
  6. Finalmente, acepte los términos y condiciones. Bienvenido, ya es parte de esta nueva comunidad!

Getting Eventbrite API WordPress plugin to work on systems with 32-bit builds of PHP

Last week I had to use the Eventbrite API plugin to show upcoming events on a client’s website. The plugin does all the work out of the box; if you are happy with the default appearance, there is no need to write a single line of code to get it working. You just need to connect your Eventbrite account and create a page that uses the template that the plugin provides. It just works… as long as you are using a 64-bit build of PHP.

If you are using a 32-bit build of PHP, there are some features that don’t work:

  1. the_permalink()  and get_the_permalink()  return a broken URL.
  2. Pages for single events show none of the event’s information.
  3. The ticket form widget shows an error saying the event is not publicly available.

The three problems above have the same cause: the ID of Eventbrite’s events cannot be represented as 32-bit integers, but that’s exactly the data type that WordPress uses to store the ID of posts. Since Eventbrite API is designed to make events available as if they were instances of custom post types, WordPress applies the same sanitization procedures that it applies to posts found in the website’s database. However, every time WordPress converts the event’s ID from a string (as returned by the API) to an integer, the ID property ends up having a value of 2147483647 , which is the maximum value for a 32-bit signed integer.

The original event’s ID is lost in the sanitization process, causing every function that uses that value to return incorrect results.

In order to overcome the problems described above and knowing that it was all caused because the ID being used was not the event’s ID, I used several WordPress and Eventbrite API filters to insert the correct value in key places.

Depending on your needs, you may have additional issues, but I expect all of them to be caused by the same error: the event ID being used is not really the event’s ID. Hopefully the code below my inspire you to create similar workarounds to get your implementation working.

the_permalink()  and get_the_permalink()  return a broken URL

Eventbrite API uses the post_link  filter to provide a custom permalink. However, their functions uses the ID property of the post object, which we already know no longer holds the value we want.

I copied their function, edited the code to use a different property (event_id ) and created my own handler for the post_link  filter:

function wvega_850_filter_event_permalink( $url ) { // eg.
    if ( function_exists( 'eventbrite_is_event' ) && eventbrite_is_event() ) {
        $url = sprintf( '%1$s/%2$s/%3$s-%4$s/',
            esc_url( home_url() ),                             // protocol://domain
            sanitize_title( get_queried_object()->post_name ), // page-with-eventbrite-template
            sanitize_title( get_post()->post_title ),          // event-title
            get_post()->event_id                               // event ID

    return $url;
add_filter( 'post_link', 'wvega_850_filter_event_permalink', 11 );

The event_id  property is a string that holds the value the ID property had before WordPress converted it to int. I created a handler for the_post action that grabs the original value and stores it in that property:

function wvega_850_eventbrite_workaround( $post ) {
    if ( ! is_a( $post, 'Eventbrite_Event' ) ) {

    if ( ! is_integer( $post->ID ) ) {
        $post->event_id = $post->ID;
add_action( 'the_post', 'wvega_850_eventbrite_workaround' );

Having the event’s ID stored as the event_id  property of the post object is what makes all my other workarounds possible.

Pages for single events show none of the event’s information

UPDATE (2015-09-13): The single event page will show information about the same event, no matter which event is being requested in the URL. This is an issue also caused by the real ID of the event not being available. Unfortunately, I don’t have a way to fix this using existing hooks. I’m currently trying to get a new hook added to the plugin so that I can create another workaround for this problem.

UPDATE (2015-09-14): The hook was accepted by Eventbrite API’s developers and will be included in the next release. I included a new function below (wvega_850_eventbrite_transient_name ) that uses that filter to make sure the information shown in single event pages always corresponds to the event being requested.

The single page for Eventbrite events uses a sub-class of WP_Query to retrieve the information of the event being shown. The page captures the event’s ID from the URL (the custom permalink generated in the previous step), moves the value into a query var using Rewrite rules and, finally, passes the value as the p  parameter of the query.

However, WordPress also converts that value to an integer. When the Eventbrite API plugin makes a request to retrieve the event’s information, the ID of the event is no longer available causing the request to return an empty object.

The code below uses the http_api_curl  action to capture all requests sent to and replace the incorrect ID with the value we stored in event_id .

function wvega_850_http_api_curl( $handle, $r, $url ) {
    if ( false === strpos( $url, '' ) || false === strpos( $url, '2147483647' ) ) {

    $eventbrite_id = get_query_var( 'eventbrite_id' );

    if ( empty( $eventbrite_id ) ) {

    $new_url = str_replace( '2147483647', $eventbrite_id, $url );
    curl_setopt( $handle, CURLOPT_URL, $new_url);
add_action( 'http_api_curl', 'wvega_850_http_api_curl', 10, 3 );

Please note that the code above will work only if the HTTP requests are being made using cURL. If a different transport is used, the http_api_curl action won’t be fired.

Next, we need to filter the name of the transient Eventbrite API uses to cache query results. Otherwise our single event pages will start showing the same information, no matter what event was requested.

function wvega_850_eventbrite_transient_name( $transient_name, $endpoint, $params ) {
    if ( $endpoint == 'event_details' ) {
        $params['p'] = get_query_var( 'eventbrite_id' );
        $transient_name = 'eventbrite_' . md5( $endpoint . implode( $params ) );

    return $transient_name;
add_filter( 'eventbrite_transient_name', 'wvega_850_eventbrite_transient_name', 10, 3 );

The problem with the default implementation is that the value stored in $params[‘p’]  is always 2147483647 . The code above replaces that value with the real event ID and then creates the transient name using the same expression used in the original function.

The eventbrite_transient_name  filter does not exists in Eventbrite API 1.0.8 or below, but it will be available in future versions. If version 1.0.8 is still the latest  version when you are reading this post, then you need to update the get_transient_name()  method in Eventbrite Manager class, replacing the following code:

protected function get_transient_name( $endpoint, $params ) {
    // Results in 62 characters for the timeout option name (maximum is 64).
    return 'eventbrite_' . md5( $endpoint . implode( $params ) );

with this one:

protected function get_transient_name( $endpoint, $params ) {
    // Results in 62 characters for the timeout option name (maximum is 64).
    $transient_name = 'eventbrite_' . md5( $endpoint . implode( $params ) );
    return apply_filters( 'eventbrite_transient_name', $transient_name, $endpoint, $params );

In this case is ok to edit a plugin’s code. The changes we are introducing are exactly the same ones that will be available in the next release.

If you ever need to change how a plugin works, please consider sending a patch to the author first. That way others benefit from your modifications and you don’t need to keep applying your modifications every time a new version of the affected plugin is released.

The ticket form widget shows an error saying the event is not publicly available

The problem here is similar to the one above. The widget generated by the Eventbrite API plugin points to the wrong URL because it uses the an incorrect value for the event’s ID.

Luckily, the plugin has a filter that we can use to modify the code used to generate the widget before is sent to the browser. I created a handler for the eventbrite_ticket_form_widget filter and used a simple regular expression to find the incorrect value and replace it with the one stored in event_id .

function wvega_850_eventbrite_ticket_form_widget( $form_widget ) {
    $event_id = get_post()->event_id;

    if ( empty( $event_id ) ) {
        return $form_widget;

    return preg_replace( '/eid=d+/', 'eid=' . urlencode( $event_id ), $form_widget );
add_filter( 'eventbrite_ticket_form_widget', 'wvega_850_eventbrite_ticket_form_widget' );


Many other functions that use the ID property of the current post object are probably broken as well; I just didn’t need those to be working in this case. The above are just workarounds and a are far from a real solution.

If you really want to solve all those problems, the solution is to start using a 64-bit version of PHP, but if you can’t do that and you still want to use the Eventbrite API plugin to bring Eventbrite events to your WordPress website, I hope the code above helps you.