Author Archive

Event Espresso and WordPress 5.0

As many of our customers know, Event Espresso is a plugin for WordPress which means we are very dependent on what happens in the WordPress ecosystem. For the last two years, WordPress has been developing a new page/post editor code-named “Gutenberg” and it’s slated to be released December 6, 2018, with the release of WordPress 5.0.

WordPress Gutenberg

Here at Event Espresso, we’re really excited for the new page/post editor coming to WordPress and we’ve been investing time over the last year in preparing our plugin for the changes. In this article, I want to share with you what you can expect with Event Espresso when you upgrade your site to WordPress 5.0, and also give you a little bit of a preview into what we’re working on for the coming months.

(more…)

Tags:
Posted in WordPress | No Comments »

Important Upcoming Changes to Dates and Times in Event Espresso

This post is important news for any Event Espresso 4 user who has their WordPress website using a UTC offset for its timezone setting instead of a timezone string (e.g. city/region). If you have your website set to use a timezone string (e.g. a city/region) then you will not be affected by anything in this post. Check Your Date and Time Settings! – Log in to your WordPress website and navigate to: Settings > General > Timezone
WordPress Time Zone Settings Events

Are you a developer? You may be interested in our developer blog post that goes into more technical details: Upcoming Changes to the Datetime System

An update is coming that will fix some bugs we discovered related to users who set their WordPress Timezone to a Manual Offset from UTC. We wanted to give some heads up on this update because it could impact the dates and times on your Event Espresso powered website. Here’s a rough outline of this post for those of you who want to skim to the parts that impact you:

  1. Backstory – Outlines some basics around the Manual Offset from UTC setting for your website timezone and why it generally is a bad idea to have your site set to an offset as opposed to a city/region.
  2. Problems – The issues we discovered and fixed.
  3. What this means for you – How the fixes will affect some websites.
  4. Recommendations – What we recommend to prepare for this change and deal with any potential impact you may experience on your website.

(more…)

Posted in News, Development, EE4 | No Comments »

Developers Corner: Datetime System improvements coming with (tentatively) EE 4.8

Hey folks, there are some significant improvements coming to the EE4 date and time system with Event Espresso 4.

Note, these improvements will impact any custom code and/or third party add-ons that utilize the Event Espresso Datetime system.  So developers will want to take note of them and prepare your code for these changes as soon as possible.

Summary of Changes

As we improve systems in Event Espresso 4, our goal is to make them simple, clear, and as flexible as possible; these datetime improvements do just that. Here’s a summary of these improvements, but please see the Important Changes to EE_Datetime System coming to EE article on the Developer Portal for complete details:

1. Dates continue to be saved in the database in mysql format (Y-m-d H:i:s) and UTC+0.  Nothing changes there.

2. Dates live within the models and model objects as PHP DateTime objects.

3. Any unixtimestamps coming into the EE Date Time system are considered to be a true unixtimestamp (time()) and not a timestamp with the calculated offset that current_time('timestamp') provides.

4. Formats are now required for when instantiating EE_Base_Class objects with date time strings that are not a unixtimestamp.

5. New helpers are available for setting up strings for date related queries.

6. New EE_Base_Class helper for displaying localized date.

7. Extensive unit test coverage

When will these improvements be released?

Right now all the changes are found in the FET-3456-promotions-spco branch of Event Espresso 4.  This branch is currently available on our Pre-release Channel (prc) (sign up via your account page) for those who wish to try it out.  We strongly encourage developers to checkout the branch via github and make sure any of your custom code and/or custom add-ons work with the new improvements.

For existing Event Espresso 4 users, we have already updated all our core add-ons that are impacted by these improvements so they work both with the current datetime system and the new datetime system.  So you should see no impact when we release this on the stable channel.

Have any questions or feedback? You can leave a comment below, post in the forums, or even create an issue in Github.

Posted in News, Development, EE4, Developers | No Comments »

Messages System:
Your Tool for Getting the Word Out

email-monitoring

One of the most powerful features added to Event Espresso 4 is the new messages system. In this post, we’re going to give you an overview of what this new system is, some of the terms you’ll come across when working with it, and tell you why we think Messages is so powerful.


What is “Messages”?

The messages system is the engine that powers all the notifications that go out from EE when triggered by different things happening on your Event Espresso powered website. By different things I mean things like:

  • when person registers for an event
  • when a payment is made
  • when a registration is cancelled
  • etc.

When one of these things happens (we call them triggers[1]) then the messages system kicks in to prepare and send out notifications about what happened. At this point there are a number of components in the messages system that play a role in assembling and sending a message. Let’s take a look at what those components are:

Message Types

messagetype_messenger_contextMessage Types describe the kind of message that is being sent and describe what the content of the message will be about. In Event Espresso there are currently (as of the time of writing this document) 8 different message types. Three for payment related messages (payment received, payment reminder, payment declined), and five registration related messages (registration approved, not approved registration, registration pending, registration declined, registration cancelled). Message types are attached to triggers[1]

Messengers

Messengers describe the vehicle that delivers the messages. The most common delivery vehicle pretty much all of us are familiar with is email! This is why email is the first and currently only messenger used by the messages system however it is important to note (and I’ll expand on this later) that it is not intended to stay that way.

Contexts

A context describes who or what receives the message. You won’t see the word context much in the UI for messages because the labels for contexts are dynamic and are defined by message types (but can also be overridden by messengers). When defined by the system, they will take on a label that more accurately describes the intent. For instance with all the current message types in the system there are up to three contexts available (which are labelled recipients in the ui): event admin, primary registrant, and registrant. The purpose of the context is to empower you to be more granular in the messages you send out.

As an example, for the Registration Approved message type, the event admin may receive summary details of the registration that was approved, whereas the primary registrant will receive information pertaining to the whole group registered, and the registrant just receives details on their specific registration for the event.[2]

Keep in mind that the number of contexts available per message type and messenger combination is variable depending on how they’ve been designed by us (or the third-party plugin for the messages system). For instance, we didn’t include the registrant context with any of the payment message types because its really only the primary registrant (the one who completed the registration) who is concerned with paying for the tickets.

Message Templates

Message_template_editorMessage Templates are the blueprint for what the message will look like when its assembled. This is a very powerful component to the messages system because it allows for more granular control of the “looks” of outgoing messages.

The important thing to remember about message templates, is that there is a message template for each messenger, message type, and context combination. So for example, there is a template for the email messenger, registration approved message type, and Event Admin recipient (context).

Each message template will have fields that are defined by the messenger primarily but also supplemented by the message type if there are any additional fields required by the message type. For instance, all email templates will have to, from, subject and main content fields.

Note
You will see other fields like [event_list], [attendee_list] etc in the message templates. These are special fields related to messages shortcodes which I’ll be getting to in a later section.

When you activate Event Espresso, the message system comes with default global templates out of the box that will help you get started right away with your events without having to do any editing. However you are able to edit any of these templates.

Difference between Global and Event specific templates
One more powerful feature with the new messages system is that by default, global templates will apply to every trigger happening with an event. So that means, for example, when a registration is approved (the trigger), all the global templates using the Registration Approved message type get sent. However, the messages system also allows Event Authors to create a custom template for that message type to be used only for that event. If this is done, then when the Registration Approved message type is triggered the message template for that event is used instead of the global message template. This allows you to differentiate different automatic messages for different events.

Message Shortcodes

Message_shortcodesMessage shortcodes are special snippets of text that allow for precisely controlling how dynamic content will display in the message template. If you are familiar with how WordPress shortcodes work then using these shortcodes should be fairly straightforward. Shortcodes such as [EVENT_NAME], [REGISTRANT_FNAME], [EVENT_AUTHOR_FORMATTED_EMAIL] all provide an easy way to indicate where dynamic content will be inserted when messages are sent.

There are also special shortcodes that we call list-type shortcodes. These are shortcodes such as [ATTENDEE_LIST], [EVENT_LIST], and [QUESTION_LIST][3]. These shortcodes are special because when you use it, you are indicating that this is where you want a list of items to be displayed in your template. When the message generator[4] gets to this shortcode, it will signal it to look for a corresponding field in the template to know how to parse each item in the list. So when you see a field in a message template that is labelled with [event_list] then you know that when the [EVENT_LIST] shortcode is parsed, the generator will look in the [event_list] field to know how to parse each event item. Super powerful!


What’s Next?

We intentionally built the messages system so it would act more like a framework for being able to rapidly add different kinds of messengers and message types for Event Espresso. We also hope that third party developers will also find this to be a useful tool for adding their own messengers and message types into the system. Want some examples?

  • What about a Facebook messenger for posting notifications to a Facebook page?
  • What about a Twitter messenger for posting notifications to your event twitter account?
  • Or maybe a messenger to connect data from different triggers[1] with your favorite accounting app via their API?
  • Or maybe a messenger to connect Event Espresso with Zapier or If This Then That.

Here’s some message types we are working on for future iterations of EE4[5]:

  • a newsletter message type that will allow you to send batch emails to all registrations or contacts (or subsets meeting certain criteria)
  • an automated event notification message type that let’s contacts know when you’ve posted a new event.
  • automated payment reminder message type that works similarly to the current payment-reminder message type except that this new one will allow you to set a schedule for sending messages to people who haven’t paid for their ticket yet.

There are all kinds of ideas we’ve heard from customers about notifications and how they should work and we’re excited because we now have a solid framework to build out some of those ideas (and for others to build their ideas). Have you tried the messages system in EE4 yet? What do you like/dislike about it? We’d love your feedback!


  1. Triggers simply refer to the places where a message might be “triggered” to be sent. Examples are: when a payment is made, when a registration is approved, when a registration is cancelled. Notice the word when, that is indicative that triggers are very much event based.  ?
  2. Note, we may eventually add registrant contexts for payment message types if it becomes possible for registrants in a group registration to pay for their own registration.  ?
  3. This shortcode is only found with Event Espresso 4 Regular (not decaf version).  ?
  4. This is slang for the code that handles putting messages together using the templates and the data from the trigger point.  ?
  5. Please do not take this as a promise that this will be completed soon. All we mean by this statement is that it is something planned, but there is no current ETA on delivery.  ?

Posted in Home Page | No Comments »

Do NOT follow this link or you will be banned from the site!