The Events Calendar/PRO/Add-ons 3.9: things to be aware of

If you’ve seen our release notes for the 3.9 updates, you’ll know that a fair number of changes were made in this latest round of updates to Modern Tribe’s The Events Calendar plugin suite. But we also wanted to put this post out — as we’ve been doing the past few releases — to showcase the specific high-level items site administrators will want to consider before applying the updates. (You naturally will also want to review the release notes post.)

Though there are fewer items to touch on this time than we’ve had in the past, the list below is still worth reviewing.

1. A number of files have changed in The Events Calendar, Events Calendar PRO, Eventbrite Tickets and Community Events. Specifically, the changes were across the board in PRO and limited to a few files in the other plugins:

• The Events Calendar: the-events-calendar/views/month/mobile.php and the-events-calendar/views/modules/map.php
• The Events Calendar PRO: All view files due to code changes made to achieve compliance with WP standards
• Eventbrite Tickets: events-eventbrite/views/eventbrite/hooks/ticket-form.php
• Community Events: events-community/views/community/modules/captcha.php

2. We ported the [tribe_mini_calendar] widget over from Barry’s Event Rocket add-on.  This adds a calendar widget, which can be embedded in a post by using the aforementioned shortcode. You can also try specifying categories and tags, ie [tribe_mini_calendar category=”parties”] or [tribe_mini_calendar tag=”black-swan-event”]. Plus, you should be able to mix and match multiple taxonomy term slugs and IDs: [tribe_mini_calendar tag=”black-swan-event,20,60″ categories=”twist,samba,491,groove”]. As the above example suggests you should also be able to use tag and tags interchangeably (same for category and categories). A title attribute can also be passed as can any of the standard widget arguments:

• before_widget
• after_widget
• before_title
• after_title

3. The advanced list widget that ships with PRO now appears in a manner consistent with the list that displays below the calendar widget. We’d seen some complaints about the fact that these views were not consistent, and as a result closed the gap this release. If you have overrides or customizations in place for the widget…you should check out how they’ll behave and be prepared to make slight modifications to conform with the new structure. Keep in mind that the widget which ships with the core The Events Calendar remains totally unchanged this release; the change here only impacts PRO.

4. The last dates of the previous month and the first dates of the following month now show in Month view (like a real calendar). Now we ought to at least see the dates of each day from the previous/next month: they should also be slight opaque to differentiate them from current month days. If a day from the previous/next month is included and contains events, those events should be listed. On mobile view, days from the previous/subsequent month should be populated and clicking on them should result in events for that day being listed – just as with days from the current month. This change also means there will no longer be “dead space” on Month view.

5. Ticket checkins can now be filtered by purchaser name, not just order ID/authentication code. This is pretty self-explanatory, but is going to have impacts on those running a tickets framework add-on who host events that require checkins at the door…it should make your lives easier! You can filter by order ID, security code and ticket ID as previously was possible.

6. Ticket prices now properly integrate with Filter Bar. While the “cost” filter in Filter Bar previously wouldn’t pick up ticket costs, it now should integrate with them smoothly. If you’d previously disabled the cost filter due to this limitation…now might be the time to bring it back.

7. reCAPTCHA has been added to Community Events. Last but certainly not least! This should go a long way in helping combat Community-driven spam submissions. There are new settings fields for reCAPTCHA API keys which you will need to populate. (If you leave the recaptcha api key settings blank, the front-end form should not show the recaptcha field, and it should not be required for successful validation.) From there, anonymous submissions from the community form should show the recaptcha form. Leave it blank, or put in invalid values, and the submission will be rejected. Fill it in appropriately, and the submission should be accepted (assuming everything else validates, of course). Authenticated users should not see the reCAPTCHA form.  You should be able to disable captchas entirely (including hiding the settings from the admin) by adding this to your theme or an mu-plugin: add_filter( ‘tribe_community_events_captcha_plugin’, ‘__return_null’ ); And it should do the trick.

8. tribe_get_custom_field has been deprecated, so you should use TribeEventsCustomMeta::get_custom_field_by_label() or work with existing function tribe_get_custom_fields() instead. Here’s a snippet we put together for a user that should help get you where you want to be with this. We deprecated a few other functions, too. Specifically, the following have been deprecated as of 3.9, in an effort to remove duplicate functionality and reduce code bloat:

• tribe_the_custom_fields()
• tribe_get_custom_field()
• tribe_custom_field()
• tribe_get_related_events()
• tribe_related_events()

—

There you have it: the highlights of this release that site administrators will hopefully find value in. If any of the information above is unclear or if you have further questions, drop us a line on the forum and we’ll do our best to help out. Cheers!