Celebrator Creator

Project Reflection

I learned a ton with this project. When I started working on this program, my title hadn't even been changed to "Web Developer" yet. I was still technically a graphic designer. Because I've fiddled around with programming since I was a kid, I was able to really easily transition to a technical role, and I'm grateful to have had the opportunity to do that at my job, instead of something I would have to work on outside of my normal work hours.

I learned how to build my own PHP programs from scratch, how to work in several distros of Linux; I learned all about the cloud, I brought a ton of our service sites in from being managed by third-party vendors, and even transitioned our entire infrastructure to AWS.

This project is a big reason why this site's not super robust; it was the thing that kept me occupied the longest, and gave me more tools to use than I ever knew I needed. Now I can do some pretty gnarly acrobatics with a text editor, even without external tools like ChatGPT or Copilot.

Here's how it all started

The company was constantly growing, which means the locations and employees on the company's website would, too. The problem was that my company's website used a page building plugin for a long time (*cough cough* Elementor). Unless you were a wizard whose specialization was web-o-mancy, that plugin would not play nice with dynamically populated data. Because of my project load at the time and the nature of that plugin, it could take me anywhere from a few minutes to even up to a week to get accurate data put up in all the right places. It was like using crayons to paint the Mona Lisa, while the Mona Lisa was on fire.

We needed to be able to manage locations and employees at the drop of a hat. Right off the bat, there aren't many (if any) plugins that can do this - at least not for free (or cheap), and not from what I could find. Fine, we'll have to make our own.

There needed to be an admin management area that authenticated users could easily access to make updates, so I wouldn't even have to touch the site anymore, and I could focus on other projects. There also needed to be a client-facing component that would be pretty to look at and easy to navigate, so people could find who they need to.

If an employee quits and decides to throw a molotov cocktail through the window, the company might not want to wait for a week for me to take their headshot off the site. The system needs to be able to reflect changes in seconds.

The system needed to be able to automatically handle all of the updates sitewide; that means that if someone changes their name, you'll only have to change it in one place, not three, or four, or twelve. So I also needed my own template system.

What I thought I should do

I needed to build it all myself, so I started by getting my toolset together. I put together a few different classes: a few for the core engine and component management, a couple for managing locations, and a couple for managing employees. I also created a template system that would build a scalable foundation for displaying data and adding new features. These classes were the backbone for running CRUD operations on the database, and for displaying the data on the front-end.

I built a couple of admin panels that allowed the user to add, edit, and delete locations and employees. The forms used AJAX to send and retrieve data from the database, and the data was displayed in a table that could be sorted and filtered. The admin panels were built using the WP Admin template system, so they were super easy to add to and modify. The client-facing component was built using the new template system, which worked in tandem with WP's post system to display the data. If there's already a loop for displaying posts, why not use it?

I needed to make sure that the system was quick, pretty, and easy to use, so I used AJAX to send and retrieve data from the database. The WP Admin template system made building the admin panels a breeze, and I used the WP Post system to help display the data on the front-end in both single and archived views. After sprinkling some CSS on it and doing some kickflips with JavaScript, I ended up with a pretty spiffy system that was easy to use and quick on its feet.

What I did

After testing and a tech demo, the users who would interact with the system regularly were able to see it in action, and they were blown away by the results. The system was able to manage locations and employees at the touch of a button, and reduced the time it took to update the website from hours, days, or weeks, to just a few seconds.

The system is overall pretty good. The client-side JavaScript made it pretty snappy, the templating structure made it easy to get the right info in the right places, and the utility classes made CRUD operations downright delightful. It works, it's easy to use, and it's pretty to look at - on the front-end and the back.

The new system had the added bonus of giving each location its own page, which was wildly different to how the old system worked. The old system had a single page for all locations, and the user would have to scroll through the list to find the location they were looking for. The new system was much more user-friendly, and it was a big hit with the users. The locations were categorized by state, whether they were appointment-only, and whether they were a franchise location, and team members were searchable by name.

What happened after

It was definitely a slow burn, but eventually it was successful. It provided the company the ability to measure culture engagement and convert those metrics into actionable items; it gave people something to look forward to at work, outside of just daily tasks; it helped me grow exponentially as a developer. While there is still room for improvement, there is now a super solid foundation for the company to build upon.

What I learned

The system was built using a lot of custom code, and it added a decently-sized repository to our codebase. This project helped me really focus on making sure our production servers were up-to-date with our codebase, and that there was no more spaghetti code thrown together somewhere.

I ended up learning how to use a lot of built-in APIs from WordPress than I had originally planned. I used the WP Admin API to build the admin panels, and I used the WP Post API to standardize and display the data on the front-end. I also used the WP Template Hierarchy to display the data in single and archive views. I was able to use a lot of existing code to build the system, which saved me a lot of time and effort.

Few things are more frustrating than having to write the same CSS over and over again. Although it was unfortunately toward the tail end of finishing this project, I did finally discover how to start using Bootstrap for styling.