This tutorial is part of the Building Your Startup With PHP series on Envato Tuts+. In this series, I’m guiding you through launching a startup from concept to reality using my Meeting Planner app as a real-life example. Every step along the way, I’ll release the Meeting Planner code as open-source examples you can learn from. I’ll also address startup-related business issues as they arise.

In the prior episode, I described building the infrastructure for tracking changes to meetings so we would know how to share updates with participants. In this episode, I’ll cover monitoring the log and delivering email notifications of changes.

If you haven’t tried out Meeting Planner yet, go ahead and schedule your first meeting. As your colleagues and friends respond, you’ll see notifications in action. I do participate in the comment threads below, so please share your feedback. I’m especially interested if you want to suggest new features or topics for future tutorials.

As a reminder, all of the code for Meeting Planner is written in the Yii2 Framework for PHP. If you’d like to learn more about Yii2, check out our parallel series Programming With Yii2.

Monitoring Meeting Updates

With the MeetingLog from the prior episode, we’ll regularly monitor for when changes are a few minutes old and consolidate them into a single update to the other participant(s) or meeting organizer.

Our DaemonController process actionFrequent will check for Meetings with fresh updates every few minutes:

public function actionFrequent() {
// called every three to five minutes
// notify users about fresh changes
Meeting::findFresh();

Choosing the Right People to Notify

Meeting::findFresh() looks at the log for entries that are older than MeetingLog::TIMELAPSE, currently five minutes. When it finds them, it looks at each of the actors involved in making the changes, and it notifies them via Meeting::notify():

If the meeting organizer made the change, then the participant(s) need to be notified. If a participant made the change, then the organizer (and in the future other participants) need to be notified; multiple participant meetings will be implemented in later tutorials.

Creating a Text Summary of the Meeting Log

In Meeting Planner’s current user interface, a number of logged changes refer to identical items and cancel each other out. For example, if you click the switch for a place, it first goes to reject. You need to click it again to accept it. Both changes are logged.

I had to write extra code to create a concise, accurate textual summary of the log.

For example, here is the historical MeetingLog of actions. Notice the repetition of actions by Cloudster that cancel each other out on the same places and times:

Here’s the code that builds a textual string of what’s occurred. I’ll likely do polishing work in the future to clean up the clarity of the description. For example, the final version provides a proper grammatical list with the appropriate use of commas then ‘and’ for the last time.

In the future, there will be multiple participants whose actions overlap in time, so we’re grouping the history by actor_id.

Then, I’m tracking the $current_actor as we build the textualization so we only mention their name once, i.e. “Jeff did these actions. John did these actions,” not “Jeff did this, John did this, Jeff did this and John did this and John did this.”

Similarly, I’m tracking the mention of objects in $items_mentioned and ignoring the earlier events, only providing the latest, dominant action on a place or time, i.e. “Jeff accepted No Bones Beach Club” not “Jeff rejected No Bones Beach Club, Jeff accepted No Bones Beach Club.”

The code was intricate and fun to write. The resulting textualization (shown above) is fun to observe.

Delivering the Notification Email

In the Refining Email Templates tutorial, I described the switch to our new responsive Oxygen templates. This required an overhaul of the notify-html.php template and will require incremental polishing over time.

What’s Next?

I hope you’ve enjoyed the two-part notifications tutorials. I found building the log and creating a textual description of the history to be challenging and fun to develop. And it proved useful with debugging and summarizing meeting updates for the notifications. However, testing wasn’t easy as there were always timestamps and background tasks that needed to be manipulated to verify the code was working.

Please try out the notifications functionality by scheduling your first meeting. You should receive regular notifications as your invitees respond. Also, I’d appreciate it if you share your experience below in the comments, and I’m always interested in your suggestions. You can also reach me on Twitter @reifman directly.