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:

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:

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 .

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.

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:

with this one:

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 .


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.

jQuery TimePicker

jQuery TimePicker is a plugin to help users easily input time entries. It works by allowing the user to type times in a free format or selecting them from a dropdown menu.

The plugin will automatically convert all time entries to a format that can be changed passing the timeFormat option; the default value is hh:mm p which will give something like ’02:16 PM’. The following are a few examples of the supported “formats”:

  • 1234 will be converted to 12:34 AM
  • 1234 p will be converted to 12:34 PM
  • 456 will be converted to 04:56 AM
  • 1656 will be converted to 04:56 PM
  • 1:1 P will be converted to 01:10 PM
  • 1:9 A will be converted to 01:09 AM
  • 8:59 will be converted to 08:59 PM
  • 1:20:30 will be converted to 01:20:30 PM
  • 46 will be converted to 05:00 AM (4 hours plus 60 minutes)

There are other supported formats, all inspired by the behavior of a similar timepicker used in Google Calendar. To see more, check the options page.

How to Use

To use jQuery TimePicker you’ll need to include two files: jquery.timepicker.js and jquery.timepicker.css. Then you can use the following code to initialize the plugin:

[codesyntax lang=”javascript”]



  • timeFormat: this is the format of time string displayed in the input field and the menu items in the combobox. Available modifiers are: h, hh, H, HH, m, mm, s, ss, p.
  • minTime: a Date object. Only the time parts (getHours, getMinutes) of the object are important. Time entries before minTime won’t be displayed/allowed.
  • minHour: int. Ignored if minTime is set.
  • minMinutes: int. Ignored if minTime is set.
  • maxTime: a Date object. Time entries after maxTime won’t be displayed.
  • maxHour: int. Ignored if maxTime is set.
  • maxMinutes: int. Ignored if maxTime is set.
  • starTime: a Date object. The time of the first item in the combobox when the input field is empty. If the input field is not empty the first item will be the next allowed time entry.
  • startHour: int. Ignored if startTime is set.
  • startMinutes: int. Ignored if startTime is set.
  • interval: int. Time separation in minutes between each time entry.
  • dropdown: boolean. Whether the dropdown should be displayed or not.
  • scrollbar: boolean. Whether the scrollbars are shown or not.
  • change: a callback called when the value of the input field changes. A Date object with the selected time is passed to the callback.


The Plugin has been tested in Firefox 3.6, Google Chrome, Safari (Windows) and IE 7.
Bugs reports, comments and new features suggestions are welcome at GitHub, in Gitter, or through the contact page of this blog.


Latest version of jQuery TimePicker can be downloaded from GitHub.

Flot – Una librería gráfica para jQuery

Es sorprendente la cantidad de alternativas para crear gráficos en un sitio web. Cuando empecé a investigar sobre el tema no esperaba encontrar tanto, pero la verdad es que hay opciones para todos los gustos:

Luego de probar Google Chart API (la unica opción de la lista que no requiere JavaScript) y gRaphael decidí quedarme con Flot, una librearía gráfica para jQuery. Gráficos atractivos, sintaxis intuitiva (es como usar cualquier otro plugin de jQuery), soporte para eventos y la posibilidad de ser extendida a través de plugins, son varias de las características que hicieron de esta librería mi elección para crear gráficos para la web. Vea un ejemplo completo

Deshabilitar WP-SynHighlight en el contenido mostrado en los feeds

WP-SynHighlight es un plugin para WordPress que permite mostrar codigo fuente con sintaxis resaltada en el contenido de los posts. Este plugin hace uso de GeShi para resaltar el código y por tanto soporta todos los lenguajes soportados por GeShi.

Hoy estaba revisando como se ven los posts  en este blog cuando son leidos desde un  FeedReader como Google Reader o Liferea. El problema con resaltar el código con una solución del lado del servidor como WP-SynHighlight es que no importa como se acceda el contenido, WordPress siempre va a incluir en la respuesta una cantidad de elementos HTML con el mero objetivo de mejorar la presentación. Creo que cuando un usuario está leyendo el contenido a través de un FeedReader está mas interesado en la estructura y el contenido, no tanto su presentación, de otro modo iría directamente a la fuente. Así, enviar contenido con código fuente resaltado a quienes usan FeedReaders me parece innecesario porque a) sin las hojas de estilo utilizadas en el sitio fuente el contenido no aparece realmente resaltado y b) los elementos HTML que antes permitían resaltar el código ahora dificultan que el lector lo manipule: un simple copy-paste da como resultado código mal formado y numeros de línea entre las linea de código. Vea como evitarlo…