Chapter 1. Building the Operational Layer
The public Rides Collective experience was supported by a separate internal platform built for the operational work behind the event. It gave the team one private workspace for handling media submissions, monitoring voting, reviewing engagement, and following participant activity without placing restricted workflows inside the public-facing product.
Chapter 2. The Operational Challenge
Without a dedicated operational layer, event photos, voting records, visitor responses, requests, and participant information would remain spread across public flows and manual handling. The response was to organize those responsibilities inside a centralized admin platform while keeping MySQL data, Supabase participant information, and media storage separated according to their roles.
Chapter 3. Media Intake and Moderation
Event media could enter the platform through file upload or a camera-based submission flow. The application validated the uploaded file, corrected image orientation when needed, and generated original, medium, and thumbnail variants so each asset could be used appropriately across the internal and public experiences.
The Photo Log provided the moderation layer after upload. Operators could search records, review asset completeness, edit display information, replace images, control public visibility, and remove invalid entries. Only active media was made available to the public gallery and voting experience.
Chapter 4. Voting Operations
Voting operations were divided between record-level review and aggregated results. The Votes Log supported searching, checking, and correcting individual records when operational intervention was required, while Vote Results summarized totals, unique participation, and ranked entries across the available voting categories.
Chapter 5. Engagement and Participant Insights
Post-event feedback and music requests were brought into internal review interfaces instead of remaining isolated on the public side. This allowed the team to review visitor impressions, understand recurring requests, and manage follow-up actions from a consistent operational workspace.
User Activity provided an operational view of platform interactions, while Users Log connected participant, attendance, and related event status information from Supabase. Together, these views helped the team review engagement patterns without mixing participant administration into the public interface.
Chapter 6. Technical Foundation
The platform was implemented as a PHP 8 application with a custom route dispatcher, reusable Tabler-based interface components, vanilla JavaScript, and PDO-based MySQL access. MySQL handled operational records, Supabase supplied participant-related information through a server-side adapter, and generated image variants were stored separately as media assets. The admin workflow also included session-based access, session regeneration after login, CSRF validation for state-changing actions, prepared database statements, login rate limiting, and MIME-aware upload checks.
Chapter 7. Application Flow and Operational Impact
The completed workflow moved from authenticated access and dashboard monitoring into media management, voting oversight, engagement review, participant monitoring, and post-event close-out. This separation gave the public product and internal operation clearer responsibilities, while making event activity and follow-up information easier for the team to review in one place.
