This is a submission for the GitHub Finish-Up-A-Thon Challenge
What I Built
Every open-source conference needs a home on the web. An open-source community runs an existing ticketing platform handles event ticketing. But there was a gap: it was doing too much. It was managing ticketing and trying to be a full event website at the same time. That's not a great separation of concerns.
The idea was straightforward: build a dedicated WordPress Event Management Plugin that handles the public-facing side of events — the landing pages, speaker grids, session listings, schedules, and code of conduct pages — while the ticketing platform stays focused on what it does best.
A community contributor started this plugin. They got the foundation in place, but the code was procedural, hardcoded in places, and not following WordPress coding standards. It was a solid proof of concept, but not something you'd ship to a production site.
This challenge gave me the push to finally finish it.
Demo
Animated GIF or short screen recording of the plugin in action — switching between event pages in WordPress admin
Live repository: https://github.com/fossasia/WPFAevent
Plugin pages completed so far:
| Template | Status |
|---|---|
events-template.php |
✅ Complete |
past-events-template.php |
✅ Complete |
speakers-template.php |
✅ Complete |
code-of-conduct-template.php |
✅ Complete |
landing-template.php |
✅ Finished during this challenge |
schedule-template.php |
🔄 In progress |
The Landing Page — Before
The Landing Page — After
After — the finished landing template with header navigation, featured sections
The Comeback Story
Where It Started
The original prototype gave us a working skeleton. You could register the plugin, activate it, and assign pages to templates. That was genuinely useful groundwork. But when you looked under the hood:
- Template files were full of hardcoded values — event names, speaker names, and section titles were written directly into PHP strings
- Logic was scattered across procedural scripts with no class structure
- There was no consistent use of WordPress hooks (
add_action,add_filter), sanitization helpers (sanitize_text_field,esc_html), or nonce verification - The landing template existed as a file but rendered almost nothing dynamically
It wasn't broken — it just wasn't finished, and it wasn't ready for anyone to actually use on a real site.
Side-by-side of old procedural code vs. new OOP class structure in VS Code
The Refactor
The first big task was structural. I rewrote the plugin to follow WordPress Coding Standards and proper Object-Oriented PHP:
- Each template is now handled by its own PHP class
- WordPress hooks are registered cleanly in a central bootstrap file
- All output is properly escaped using
esc_html(),esc_url(), andwp_kses_post() - Data is pulled via custom post types and post meta — no hardcoded values anywhere
The three earlier templates (events, speakers, code of conduct) had already been refactored before this challenge. The landing template was the next one on the list — and the most complex.
Finishing the Landing Template
The landing page is the hub for an individual event. When a visitor navigates to a specific event, this is what they see first. It needed to:
- Display a header with navigation links — Schedule, Speakers, Register — that are relevant to that specific event
- Pull in featured content sections dynamically based on event metadata
- Render a Speakers grid showing featured speakers for the event, sourced from the custom post type relationships — no hardcoded names or photos
- Stay modular — each section is its own component so future contributors can add or swap sections without touching the core template
WordPress admin — assigning the landing-template.php to a page via the Page Attributes dropdown
Frontend output of the landing page showing the header nav, featured sections
My Experience with GitHub Copilot
I'll be honest — I was skeptical at first. I've used AI autocomplete tools before and found them useful for boilerplate but frustrating for anything that required understanding a project's specific conventions.
GitHub Copilot surprised me.
Where It Helped Most
WordPress-specific patterns. The WordPress API has a lot of functions you need to remember — the right sanitization function for the right context, the correct way to register a custom post type, how to structure a WP_Query call with the right arguments. Copilot was genuinely good at filling these in accurately, and it mostly respected the OOP structure I had already established when suggesting completions.
Copilot suggestion in VS Code — showing it autocompleting a register_post_type() call with correct arguments
Repetitive structure. The speakers grid component follows a pattern: query posts, loop through results, output HTML with escaped values. Once I wrote the first version, Copilot helped me apply the same pattern to featured sections quickly, and it kept the escaping consistent — which matters a lot in WordPress.
Docblock comments. Writing PHPDoc comments for every method is tedious but important for an open-source plugin that other contributors will maintain. Copilot generated accurate docblocks based on the method signatures and logic, saving real time.
Copilot generating a PHPDoc comment for a class method in the landing template file
Where I Steered It
Copilot sometimes suggested patterns that were technically valid PHP but not the WordPress way. For example, it would occasionally reach for plain mysqli or PDO for data queries rather than WP_Query or get_post_meta(). I learned to prompt it with more context — mentioning WordPress hooks or the class it was working inside — and that helped a lot.
It also couldn't know our plugin's specific data model (how speakers relate to events, how featured sections are stored in post meta) without me giving it context. Once I pasted in the relevant schema or pointed it at an existing similar method, the suggestions got much more useful.
The workflow that worked best: write the method signature and a comment describing intent → let Copilot fill in the body → review and adjust. It's a genuine collaboration, not a vending machine.
What's Next
The landing template is done, but the plugin isn't finished. Sessions and schedule templates are next. The goal is to have a complete, standards-compliant plugin that any community member can drop into a WordPress site and use for their event.
If you're interested in contributing, the repo is open. Issues are tagged and the architecture is documented.
Tooling Disclosure
AI tools used in this project:
- GitHub Copilot — used for code generation, autocompletion, and docblock writing throughout the plugin development, as described in the "My Experience with GitHub Copilot" section above
- Claude Code — used to assist with drafting and structuring this article
Both tools were used as assistants, not as authors. All architectural decisions, code review, and final judgement calls were made by the human contributor.
Top comments (0)