This is a submission for the GitHub Finish-Up-A-Thon Challenge
From 17 Checkboxes to a Security Score: Finishing WP Secured with GitHub Copilot
There is a special category of projects that every developer has.
Not the failed experiments.
Not the half-written ideas.
Not the repositories that never worked.
I'm talking about the projects that almost made it.
The ones that solved a real problem.
The ones that had users.
The ones that worked.
But somehow never felt finished.
For me, that project was WP Secured.
A WordPress security hardening plugin that already had 17 security protections built into it.
The plugin wasn't broken.
It wasn't abandoned because of bugs.
It wasn't abandoned because the idea failed.
It was abandoned because I couldn't quite figure out what it wanted to become.
That changed during the GitHub Finish-Up-A-Thon.
What started as a plugin with 17 checkboxes became a security platform with scoring, risk analysis, dashboards, security insights, and one-click hardening.
More importantly, it finally became the product I originally imagined.
And GitHub Copilot helped me get there.
What I Built
WP Secured is a WordPress security hardening plugin designed to help website owners reduce their attack surface by disabling unnecessary WordPress features and applying security best practices.
The original version already included 17 security protections:
- Disable XML-RPC
- Hide WordPress Version
- Disable Trackbacks
- Disable Self-Pinging
- Disable RSS Feeds
- Disable PHP Execution
- Disable Login Hints
- Disable Login by Email
- Disable File Editor
- Disable Directory Browsing
- Disable Comments
- Disable Comment URLs
- Disable Application Passwords
- Disable REST API
- Disable Admin Bar
- Login Security
- File Protection
From a functionality perspective, the plugin worked.
Users could install it.
Open the settings page.
Check boxes.
Save settings.
And their site became more secure.
Simple.
Effective.
Finished... at least technically.
The problem was that it didn't feel finished.
WordPress security is one of those areas where users often don't know whether they are protected or not.
You can disable ten features and still wonder:
Is my website actually secure?
You can enable every setting and still have no idea how much risk you've reduced.
The plugin answered the question:
"What protections can I enable?"
But it never answered:
"How secure is my website right now?"
That missing piece bothered me for a long time.
Because security isn't just about configuration.
It's about visibility.
It's about understanding.
It's about confidence.
And WP Secured wasn't providing any of those things.
So when the GitHub Finish-Up-A-Thon challenged developers to revisit and complete unfinished projects, I immediately knew which repository I was opening.
Original WP Secured Settings Page Showing 17 Checkboxes.
The original experience looked exactly like what many WordPress security plugins look like:
A list of options.
A collection of settings.
A wall of checkboxes.
Functional?
Absolutely.
Helpful?
Yes.
Inspiring?
Not really.
There was no feedback loop.
No indication of progress.
No guidance.
No overall picture of site security.
Just settings.
And that became the problem I wanted to solve.
Demo
GitHub Repository: Before Finished Up
mrteesurez
/
wp-secured
A WordPress security hardening plugin.
wp-secured
A WordPress security hardening plugin.
Live Demo: Before Finished Up
GitHub Repository: After Finished Up
Finish WP Secured with Security Scoring Dashboard and One-Click Hardening
#1
This pull request completes a major phase of development for WP Secured, a WordPress security hardening plugin that was previously functional but unfinished.
The original plugin provided 17 security hardening features through a simple settings page where users could enable or disable protections using checkboxes. While effective, it lacked visibility, guidance, and an overall security assessment experience.
This update transforms WP Secured from a collection of security toggles into a security hardening platform.
- Added weighted security scoring system
- Introduced risk classifications
- Calculates overall site security posture
- Provides protection coverage metrics
- Added modern security dashboard
- Displays security score and status
- Highlights active protections
- Provides actionable security insights
- Added quick hardening workflow
- Allows users to apply recommended protections faster
- Simplifies the onboarding experience
- Introduced a more modular structure
- Added core scoring and dashboard components
- Improved maintainability for future enhancements
WP Secured currently includes hardening modules for:
- Disable XML-RPC
- Hide WordPress Version
- Disable Trackbacks
- Disable Self-Pinging
- Disable RSS Feeds
- Disable PHP Execution
- Disable Login Hints
- Disable Login by Email
- Disable File Editor
- Disable Directory Browsing
- Disable Comments
- Disable Comment URLs
- Disable Application Passwords
- Disable REST API
- Disable Admin Bar
- Login Security
- File Protection
- Basic settings page
- 17 independent checkboxes
- No security score
- No dashboard
- No security guidance
- Security score
- Risk classification
- Security dashboard
- Protection coverage metrics
- One-click hardening
- Improved user experience
This work was completed as part of the GitHub Finish-Up-A-Thon Challenge.
The goal was not to create a new project, but to return to an existing one, finish unfinished work, and transform it into something more complete and useful.
WP Secured was already functional, but this update finally delivers the visibility, usability, and guidance that were originally envisioned for the project.
Live Demo: After Finished Up
The Comeback Story
The Project I Never Finished
Most unfinished projects fail because they're bad ideas.
WP Secured wasn't one of those projects.
That's what made it harder to ignore.
The plugin actually worked.
The security features were already implemented.
The architecture was relatively stable.
Users could install it and immediately improve their site's security.
In many ways, it was already more complete than dozens of repositories sitting in my GitHub account.
And yet, every time I looked at it, something felt incomplete.
The best way I can describe it is this:
WP Secured solved security.
It didn't solve the user experience of security.
Those are very different things.
A developer can look at 17 security settings and understand their value.
A website owner often can't.
The plugin expected users to know:
- What XML-RPC is
- Why REST API exposure matters
- Why login hints can be dangerous
- Why file editor access increases risk
- Why application passwords should be disabled
That's a lot of assumptions.
The more I thought about it, the more I realized the plugin was built from a developer's perspective rather than a user's perspective.
Developers think:
Enable security features.
Users think:
Is my site safe?
The plugin answered the first question.
It never answered the second.
Then life happened.
Client work.
Deadlines.
New projects.
Other priorities.
Like many side projects, WP Secured slowly moved down the list.
Weeks became months.
Months became longer than I care to admit.
The repository sat there.
Working.
Usable.
And unfinished.
Old GitHub Repository State
Every now and then I would open the project.
Review the code.
Think about improvements.
Close it again.
Not because I didn't care about it.
Because I wasn't sure what the next step should be.
Ironically, the challenge wasn't technical.
The challenge was product design.
The plugin didn't need more security features.
It needed a better way to communicate security.
And for a long time, I couldn't quite figure out how.
Until one simple idea changed everything.
The Problem With 17 Checkboxes
Let's imagine two users.
User A
Installs WP Secured.
Enables:
- XML-RPC Protection
- Login Security
- File Protection
Leaves everything else disabled.
User B
Installs WP Secured.
Enables:
- 15 out of 17 protections
Both users save their settings.
Both users see the same interface.
Both users receive no feedback.
From the plugin's perspective, they're simply configurations.
But from a security perspective, they're completely different.
User B is significantly more protected.
User A still has multiple attack surfaces exposed.
Yet the plugin treated both situations exactly the same.
That became the fundamental flaw.
There was no measurement.
No context.
No indication of risk.
No prioritization.
No guidance.
No visibility.
Imagine a fitness app that only provided workout buttons.
No progress tracking.
No calories.
No goals.
No statistics.
That was WP Secured.
Users could make changes.
But they couldn't understand the impact of those changes.
The plugin gave them controls.
It didn't give them visibility.
And visibility is often what motivates action.
Without visibility, hardening becomes guesswork.
Without visibility, users don't know what to do next.
Without visibility, security becomes a checklist exercise rather than a measurable outcome.
I realized the plugin didn't need more options.
It needed a way to tell a story about security.
A story users could understand instantly.
That realization became the turning point.
The Idea That Changed Everything
The breakthrough happened when I stopped thinking about settings.
And started thinking about scores.
Almost every successful platform today uses some form of scoring or progress visualization:
- Credit scores
- SEO scores
- Performance scores
- Accessibility scores
- Health scores
Why?
Because humans understand progress.
Humans understand percentages.
Humans understand risk levels.
A score transforms complexity into clarity.
And suddenly the question wasn't:
Which settings are enabled?
The question became:
What is this website's security score?
Everything clicked.
Instead of presenting 17 independent features, I could present a security posture.
Instead of showing settings, I could show progress.
Instead of expecting users to understand WordPress internals, I could translate security into something visual and actionable.
The concept quickly evolved into three core metrics:
- Security Percentage
- Risk Classification
- Protection Coverage
Then I added risk levels:
- High Risk
- Medium Risk
- Secure
- Hardened
Immediately the plugin felt different.
A user could open the dashboard and understand their security status in seconds.
No security expertise required.
No documentation required.
No guessing required.
The plugin finally had a language users could understand.
And once that idea existed, everything else started falling into place.
The dashboard.
The scoring engine.
The security insights.
The one-click hardening experience.
For the first time since I created the project, I wasn't just improving a plugin.
I was completing a vision.
And that's when GitHub Copilot became an important part of the journey.
Building the Scoring Engine
Once the idea of a Security Score clicked, the next challenge was implementation.
Turning 17 independent security toggles into a single measurable system is not trivial.
Because now the question changed:
How do you quantify WordPress security in a meaningful, explainable way?
I didn’t want a random number generator.
I didn’t want a vanity score.
I wanted something that reflected real-world risk reduction.
So I designed a weighted scoring model.
The Scoring Model
Each security feature was categorized into risk tiers:
Critical Protections
These directly reduce high-impact attack surfaces:
- XML-RPC
- REST API
- PHP Execution
- File Editor
- Login Security
- File Protection
High Protections
Important but not immediately catastrophic:
- Application Passwords
- Directory Browsing
- Login Hints
- Login Email
- Version Disclosure
Medium Protections
Reduce information leakage and minor vectors:
- Comments
- Comment URL
- RSS Feeds
- Trackbacks
- Self-Pinging
Low Protections
Quality-of-life / minor hardening:
- Admin Bar
Weighted Scoring Logic
Each category contributes differently to the final score:
- Critical = 10 points each
- High = 7 points each
- Medium = 4 points each
- Low = 2 points each
The final score is normalized into a percentage.
This creates a meaningful interpretation:
- 0–40% → High Risk
- 41–65% → Medium Risk
- 66–85% → Secure
- 86–100% → Hardened
Suddenly, security became readable.
Not technical.
Not abstract.
Readable.
Code Sample: Security Score Calculation Logic
function calculate_security_score($settings) {
$score = 0;
$max_score = 0;
$weights = [
'critical' => 10,
'high' => 7,
'medium' => 4,
'low' => 2,
];
$features = [
'xmlrpc' => 'critical',
'rest_api' => 'critical',
'php_execution' => 'critical',
'file_editor' => 'critical',
'login_security' => 'critical',
'file_protection' => 'critical',
'app_passwords' => 'high',
'directory_browsing' => 'high',
'login_hints' => 'high',
'login_email' => 'high',
'version_hide' => 'high',
'comments' => 'medium',
'comment_url' => 'medium',
'rss_feeds' => 'medium',
'trackbacks' => 'medium',
'self_pinging' => 'medium',
'admin_bar' => 'low',
];
foreach ($features as $feature => $level) {
$max_score += $weights[$level];
if (!empty($settings[$feature]) && $settings[$feature] === true) {
$score += $weights[$level];
}
}
return round(($score / $max_score) * 100);
}
Why This Model Works
The key design decision was not treating all security features equally.
Because in real WordPress attacks:
- Disabling REST API is far more impactful than hiding the admin bar
- File execution protection is more critical than comment restrictions
- Login hardening matters more than RSS feed disabling
The scoring system reflects that reality.
Not perfectly.
But meaningfully.
Designing a Better Experience
Once the scoring engine existed, everything shifted from “settings page” thinking to “product experience” thinking.
The plugin was no longer a checklist.
It became a dashboard.
The Dashboard Redesign
Instead of listing checkboxes, the new dashboard shows:
- Security Score (big visual indicator)
- Risk Level (color-coded badge)
- Protection Coverage (progress visualization)
- Quick Actions (recommended fixes)
- Security Insights (explanations)
This transformed the plugin from:
configuration tool
into:
decision support system
The New Dashboard Redesign
One-Click Hardening
One of the biggest usability improvements was introducing:
One-Click Hardening
Instead of forcing users to understand each setting, the plugin can now:
- analyze current configuration
- identify missing protections
- apply recommended hardening automatically
This is critical because most users don’t want 17 decisions.
They want a safe default state.
New Dashboard: Protected feature section
Before vs After Experience
| Before | After |
|---|---|
| Settings page | Security dashboard |
| 17 checkboxes | Security score |
| No context | Risk classification |
| Manual configuration | One-click hardening |
| No guidance | Actionable insights |
The difference is not visual.
It is conceptual.
My Experience with GitHub Copilot
GitHub Copilot didn’t “build the plugin”.
It didn’t magically solve architecture problems.
But it accelerated the thinking process.
Architecture Discussion
Prompt used:
"Analyze my WP Secured plugin structure.
I already have:
- main plugin file
- admin settings page with checkboxes
- includes/ folder with ~17 security hardening features
I want to refactor this into a modular security plugin ready fo WordPress installation.
Design a clean architecture with:
- Core loader system
- Module-based structure
- Central registry for all security features
- Separation between:
- Hardening modules
- UI modules
- Scoring system
- Reporting system"
Copilot helped identify separation between:
- scoring system
- dashboard layer
- security modules
But I still made the final decisions.
So, I gave it exact folder structure to use:
Using this exact folder structure:
wp-secured/
├── wp-secured.php
│
├── includes/
│ ├── core/
│ │ ├── class-loader.php
│ │ ├── class-scoring.php
│ │ ├── class-dashboard.php
│ │ ├── class-hardening.php
│ │
│ ├── modules/
│ │ ├── xmlrpc.php
│ │ ├── rest-api.php
│ │ ├── login-security.php
│ │ ├── file-protection.php
│ │ └── comments.php
│ │
│ └── helpers/
│ └── utils.php
│
├── admin/
│ └── admin-page.php
│
├── assets/└── readme.txt"
Scoring System Design
Prompt used:
"Create a Security Scoring Engine for my WordPress plugin WP Secured.
It should calculate a score from 0 to 100 based on enabled hardening features.
Design rules like:
Security Hardening Score Rules
Critical Protection (10 points each)
- XML-RPC disabled = +10
- REST API disabled/restricted = +10
- PHP execution in uploads disabled = +10
- File editor disabled = +10
- Login Security enabled = +10
- File Protection enabled = +10 ."
Copilot suggested a flat scoring approach initially.
I refined it into risk-tier weighting.
Dashboard Design Ideas
Prompt used:
"Design a modern WordPress admin dashboard UI for WP Secured.
It should display:
- Security Score card (large, centered)
- Risk breakdown (Critical / High / Medium / Low)
- Protected Features summary (enabled hardening list)
- Quick Actions section:
- "Secure My Site" button
- "Run Security Scan"
- "Generate Report"
UI requirements:
- Clean card-based layout
- Modern SaaS-style design
- WordPress admin compatible
- Responsive layout
- Use CSS grid or flexbox
Then, Improve the dashboard by adding:
- Animated security score counter (0 → final score)
- Color-coded risk indicators (red/yellow/green)
- Tooltips explaining each security metric
- "Before vs After Security Score" comparison widget"
The output helped structure UI components like:
- score widget
- risk badge
- insights panel
But again, implementation required iteration.
Refactoring Session
What Copilot helped with:
- boilerplate cleanup
- function modularization
- repetitive code reduction
What I rejected:
- overly generic abstractions
- unnecessary complexity
- over-engineered patterns
Because in real systems:
simplicity is a feature
Not everything needs abstraction.
Human judgment still mattered.
Copilot accelerated iteration.
It did not replace it.
GitHub Copilot Refactoring Journey Walkthrough
This part of the project became more structured once the direction was clear.
The workflow evolved into:
- modular refactoring instead of full rewrites
The most important change was psychological:
I stopped treating this as a “side project”.
And started treating it as a “finished product in progress”.
Lessons Learned
A few key lessons emerged from this entire process:
- Finishing matters more than starting
- Small UX changes can outweigh new features
- Visibility is more valuable than control
- Developers often overestimate user understanding
- A score can be more powerful than a setting
But the biggest lesson was this:
A working project is not the same as a finished product.
And WP Secured finally crossed that gap.
Final Thoughts
When I first built WP Secured, I thought I was building a WordPress security plugin.
But looking back now, I realize something else:
I was actually building an attempt at clarity.
Security was never the hard part.
WordPress already gives you enough hooks, enough control, enough flexibility to harden a site.
The hard part was:
Helping users understand what all of it meant.
That’s what the 17 checkboxes represented.
Not a technical limitation.
A communication gap.
And for a long time, I treated that gap as “good enough.”
Until this challenge forced me to reopen it.
What changed wasn’t the codebase.
It was the perspective.
Instead of asking:
“What security features should I add next?”
I started asking:
“What does a user actually understand when they open this plugin?”
That question changed everything.
Because suddenly:
- Features were not enough
- Settings were not enough
- Even functionality was not enough
What mattered was interpretation.
And interpretation requires structure.
That’s where the security score came in.
Now WP Secured is no longer just a list of toggles.
It is:
- A security scoring system
- A risk visualization tool
- A guided hardening assistant
- A decision support layer for WordPress security
And more importantly:
It finally tells users what their choices mean.
The Real Achievement
It would be easy to say:
“I added a dashboard and a scoring system.”
But that misses the point entirely.
The real achievement was not technical.
It was finishing something I had stopped believing I would ever return to.
This project sat unfinished not because it failed…
but because I didn’t yet know how to complete it.
GitHub Copilot helped accelerate implementation.
But the real driver was the decision to revisit something unfinished and ask:
“What would it take to make this feel complete?”
What WP Secured Is Now
WP Secured is no longer a collection of features.
It is now a system with:
- A measurable security posture
- A visual representation of risk
- A guided improvement path
- A simplified decision layer over complex WordPress internals
It transforms security from:
“configure this correctly”
into:
“understand where you stand, and improve from there”
Why This Matters
Most developers underestimate how important visibility is.
We assume:
- users understand settings
- users understand consequences
- users understand tradeoffs
But they don’t.
Not because they’re not capable.
But because the system never explains itself.
WP Secured now tries to bridge that gap.
And that gap is where most security tools fail.
Final Reflection
There is something deeply satisfying about finishing an abandoned project.
Not because the code changes dramatically.
But because the intent finally matches the implementation.
WP Secured was never truly broken.
It was just incomplete in meaning.
The GitHub Finish-Up-A-Thon didn’t just push me to ship features.
It pushed me to rethink what “finished” actually means.
And GitHub Copilot didn’t replace the work.
It helped me move faster through the thinking process required to complete it.
In the end, the most important outcome wasn’t a new feature set.
It was closure.
Final Message
If there is one thing I will take away from this experience, it is this:
The hardest projects to finish are not the ones that fail.
They are the ones that almost work perfectly… but still feel incomplete.
WP Secured was one of those projects.
And now, finally, it isn’t.
GitHub Copilot Journey Complete
This wasn’t just a plugin update.
It was a return.
A rebuild.
And a completion of something I had left behind for too long.
Thank You
To the GitHub Finish-Up-A-Thon for the push to revisit old work.
To GitHub Copilot for accelerating the implementation process.
And to every unfinished project sitting quietly in a repository somewhere:
Maybe it’s not broken.
Maybe it’s just waiting to be finished.
Top comments (0)