Meet the Minds Behind Florida DrupalCamp 2025: Conversations with the Speakers

As part of The Drop Times’ coverage of Florida DrupalCamp 2025, we reached out to several prospective speakers to gain insight into their sessions, key takeaways, and what excites them most about the event. In this segment of our coverage, we feature four distinguished speakers: Christian Burk, Steve Wirt, Aubrey Sambor, and Josh Fabean.

This year's camp, which will take place from February 21 to 23 at Florida Technical College in Orlando, promises to be a hub for Drupal professionals, enthusiasts, and newcomers alike. The event will offer a dynamic mix of insightful sessions, hands-on training, and networking opportunities.

Attendees can expect a diverse learning experience spanning topics such as design, theming, usability, development, performance, and project management. The camp kicks off on Friday with expert-led workshops, providing an immersive introduction to key Drupal technologies. As excitement builds, let’s hear from our featured speakers about what they have in store for this highly anticipated event.

Let's have a look at The Drop Times's brief interview with some of the event speakers.

Christian Burk

Session: Sum of a Batch!!!

TDT [1]: Large-scale batch operations can be daunting, especially on high-traffic sites. What are some of the biggest challenges developers face when making mass content changes, and how does your approach help overcome them?

Christian Burk: Because large-scale changes across large sites take time, it is not impossible for a script to time out midway through its run. Because the module uses the State API to keep track of which item it is on, a disruption in the script is recoverable. When you have to run a script that did not complete, it will start where it left off. The module's user interface also lets someone with the proper permissions see what script has been run and the status of each run, including whether it was completed or not and which was the last processed item.

On a high-traffic site, the timing of the script run can be a challenge. It may need to be run off-hours to minimize any disruption to the user. Because the module supports cron and uses a more natural language approach to define it, a script could be scheduled to run on a certain day at a certain time when the site is not as busy, such as 'on the 4^th of July after 21:00.'

Lastly, on a large site, it can be very difficult to tell what has happened by reviewing the recent logs, as the maximum number of entries is usually too small to really review. Plus, when a script logs to the watchdog, then the script messages are mixed up with all of the other messages, making them difficult to find. This module creates a batch log entity with a message for each item processed. These logs can persist until they are intentionally deleted, which means that not only will the logs not be lost in the sands of time but they can also be viewable by users without the permissions to view watchdog or to run the script itself.

TDT [2]: Your session highlights a contribution from the Department of Veterans Affairs and CMS. How does this module improve the way organizations handle large content updates, and what makes it a game-changer for Drupal developers?

Christian Burk: On large projects, like those for the federal government, the work can span several years. Over that time, the teams can evolve or turn over completely, meaning that the approach to content changes can similarly evolve or be completely different. This could mean that from one developer to the next, the way that such changes get made could differ dramatically. Essentially, it means reinventing the wheel to an extent every time.

You May Like

Blog

Launching TheDropTimes with Drupal and Thunder Distribution

Blog

Launching TheDropTimes with Drupal and Thunder Distribution

This module provides a framework and a collection of functions so that, as happened on one change to the Veterans Affairs site, we could have three developers each working on updating different content but using a common base class that was an extension of a class provided by the module. As a result, the bulk of the work could be done by one person on the base class and the other two could work on their own with minimal conflicts and maximal efficiency.

Steve Wirt

Session: Sum of a Batch!!!

TDT [3]: Handling massive content updates can be tricky—performance issues, logging, and failures can cause major headaches. What inspired the development of this batch processing approach, and how does it make large-scale updates more manageable?

Steve Wirt: The Codit: Batch Operations module was inspired by the number of complex choices that have to be made when doing massive content updates.  Re-inventing them every time was mentally painful and fraught with the potential to forget something crucial.  So this module handles a lot of the pain points with astonishing flexibility but with all the security of a repeatable, well-tested process.  Logging, though, is the ultimate confidence builder because you can easily tell what happened, and if something went badly, it provides tools to recover smoothly.

TDT [4]: For Drupal developers working on enterprise-level sites, what key takeaways from your session will help them execute batch operations more smoothly and with greater confidence?

Steve Wirt: 

• Flexibility:  There have been many times when I have planned a large content operation that was originally intended to run in an update hook, but after scripting it all, I realized it needed to be run some other way. Whether it needs to be run by cron, update hook, deploy hook, or manually,  the implementation is the same.  You can write the process first and then decide how you want it to run.
• Resiliency: Unexpected error shut the operation down? No problem, it picks up where it left off.
• Simplicity: instead of thinking about all the supporting tasks like logging and error handling, you can stay focused on the content operations.

Aubrey Sambor

Session: What a front of the front end developer brings to your team

TDT [5]: Your session aims to show that front of the front end developers are a crucial part of any team. What’s one surprising or overlooked way these developers contribute to better, more accessible, and user-friendly websites?

Aubrey Sambor: I’d say a front of the front end developer’s expertise with semantic HTML is vastly overlooked! Using the right HTML element in the right place helps with accessibility and long-term site maintainability.

Also, accessibility matters more to a project than some people think, and a front of the front end developer has the right skill set to ensure accessibility standards are met on any website they build.

Finally, a front of the front end developer’s CSS writing skills can be vastly overlooked, but being able to write performant styles using newer CSS techniques can speed up development time, minimize file sizes, and make your site more efficient.

TDT [6]: What challenges do these developers face in proving their value, and how can they effectively advocate for their role within a team?

Aubrey Sambor: A challenge that front of the front end developers faces is the assumption that their role isn’t important if they’re focusing on HTML and CSS. Javascript is important too, of course, but having a strong foundation in HTML structure and writing performant CSS holds just as much weight as the ability to write cutting-edge Javascript.

One thing that the front of the front-end developers can do to advocate for a role in their team is to be a part of the project from the very start. Working with stakeholders, designers, and other developers as part of the discovery process, then collaborating with design to ensure the designs are feasible, helps make a front of the front-end developer’s presence known on a project.

TDT [7]: What do you hope the audience will take away from your session about the role of a front of the front end developer in today’s web development landscape?

Aubrey Sambor: I hope that the audience sees how valuable a front-of-the-front-end developer can be to their team! By thinking of accessibility first and foremost, knowing which HTML elements make the most sense when building a site, and implementing the latest and greatest in CSS techniques, a front of the front end developer adds so much to your project.

Josh Fabean 

Session: Self-Hosting at Home: Taking Back Control and Building Your Skills

TDT [8]: Self-hosting can seem intimidating to those used to the convenience of big tech services. What are some of the biggest misconceptions about self-hosting, and how does your session help make it more approachable?

Josh Fabean: Not sure if it's a misconception or not, but you don't have to go from 100% reliance on Google to 0% in a day or even ever. If you can get your dependence on big tech down to 50% you'll be in a much better position than most people. It also is a slow process and you can do as much or as little as you want as fast as you want. It's also very easy to start using services again if you decide it's not for you. 

I will help make it more approachable by breaking down the individual pieces needed to get a service running on your own hardware. I will provide a git repo (still WIP, hoping to have more services and readmes in there before the session) that anyone can take and get something spun up themselves. I will also tell you about many communities, whether on Discord or random websites, where you can ask for help.

TDT [9]: Beyond privacy and data ownership, self-hosting is a great way to build technical skills. What are some of the most valuable skills attendees can expect to gain by exploring self-hosting, and how might these skills benefit them professionally?

Josh Fabean: The skills required to run things yourself are the same skills that are required to deploy Drupal websites to production. Whether that's currently handled by a DevOps engineer, a network admin, or whoever is in your situation, the skills you learn hosting things yourself can be used to be more useful in any of those jobs. There are plenty of stories of people who were not in tech, who started self-hosting things, who then got high-paying DevOps jobs and were able to use the local infrastructure they built out as their resume.