We’ve spent the better part of the last year strategizing, planning, and building a makeover. In the coming months, we’ll be introducing new calendar views for The Events Calendar and The Events Calendar PRO. But what did it take to actually pull off the development work?
We snagged a couple of the developers from our team who worked on the project to talk about their experience rebuilding the calendar views. Our hope is that this is not only an interesting look behind the scenes, but helpful for other front and back-end developers who are tasked with reworking a long-running legacy project that has a lot of moving pieces and many users who rely on it.
You’ll hear from Luca Tumedei, a back-end developer who has worked on The Events Calendar since 2014 and Paul Kim, a front-end developer who has taken an instrumental role in developing and maintaining the interface of our plugins.
First off, tell us a little bit about the project. How did it come up and what were your first thoughts?
Paul: Our current views were becoming outdated, at least from a visual and user experience perspective. We knew that we needed to update the look and feel of the calendar to stay competitive as the ecosystem evolved. Since the project was so design-focused, I assumed it would mostly be focused on the front end, but turns out that wasn’t the case. There was a lot of work to be done on the back end to update The Events Calendar codebase while making the data much simpler. To be honest, I initially felt a bit overwhelmed with the task, but working with the team that we have made me excited for the challenge.
Luca: Our calendar views have taken us pretty far for ten years, but as we moved away from a PHP 5.2 compatibility requirement, we started to notice that the structure of our code became overly layered and distributed a fair amount of complexity. In other words, the development history started to be a source of overhead — or technical debt — more than a rock to build our house on. We decided to rework the views in a way that leverages the unified architecture that comes from using modern and performant PHP code. I was excited. And a bit scared, to be honest. Mostly excited, though.
The Events Calendar has been around a long time. What did you do to ensure backwards compatibility, especially for developers who rely on customized versions of the calendar view templates?
Luca: We took three steps and started way before any “new and shiny” thing was available.
First, behind the scenes, we unified the way the existing calendar views fetches information from the database; this change fell under the umbrella of the “repository” release and refactoring, Once we had that architecture in place and a way to store and grab data, we started working on the new view system itself.
Second, we didn’t remove any of the existing views. That means the new views and the existing ones will co-exist peacefully and users (or developers) will be able to use one or the other with no issue.
Finally, we spent a lot of time migrating a number of approaches from the existing calendar views to the new ones (e.g our templating system that supports custom overrides). We could not keep 100% compatibility, but we have made it so that the new views will leverage the default WordPress loop and a new, powerful, event-dedicated post object.
This is a significant overhaul of the calendar design. How was working hand-inhand with the design team?
Paul: We are very lucky to have such amazing designers on our team, and working with them on this project was a treat. Having dedicated designers is quite a new thing for our products team and they worked hard to create a universal design system using a combination of Sketch for creating the mockups and InVision for prototypes. This became the backbone that everything else was built upon. Once the design system was set up in code, creating and styling the views became a much more streamlined process. Rather than having multiple implementation of, say, a button, we were able to reuse the same code and maintain consistency.
Luca: Mockups, lots of them! From a back-end perspective, some designs (e.g. the “stack” at the top of Month and Week Views) required new and challenging solutions. So, design was instrumental in helping define the scope of what we ended up building so we could focus on the best technical implementation.
What was the hardest technical challenge you came across? Did you learn anything new from it?
Paul: I think the hardest technical challenge, aside from some of the amazing functionality we’ve built into the new views, was planning and executing a structure for the CSS. We wanted a consistent, flexible and component-driven system in order to balance developer happiness in how we approach the code with standards, and to make it pleasant for users to customize the styles to complement their sites.
There are hundreds of thousands of users who use The Events Calendar and the range of their skills in development varies vastly. To be able to consider the full range and still provide a technically sound solution was difficult, but fun. Learning to plan, structure, and code for all levels of developers was a new challenge for me, but also an important lesson I took away from building for a large user audience.
Luca: The hardest thing for me was unifying the way calendar views access data. Events are events, right? Right. Yet each view consumes the data for those events in different and specific ways that makes it difficult to streamline the code and data as much as possible. This led to a lot of code fragmentation and maintenance issues, but project allowed us to plan our code in a way that avoids those issues and creates better solutions to the same problems while leveraging more reusable code. The biggest takeaway for me: think API first.
Finally, is there anything you’re particularly proud of now that you’re able to look back on your work?
Paul: To come from a place where we did not have a strong CSS standard to have a sound architecture and approach, I think this is a major win for the plugins and the products team.
Luca: We’ve reduced the footprint of the code for our views and, in the process, the code is more readable and testable. I need not say more.