Category: WordPress Contribution

  • Celebrating My Training Contributor Badge

    Gold circular badge enclosing a graduation cap icon, followed by the text "Training Contributor."

    On June 6, 2025, during our weekly Training Team meeting, I was awarded the Training Contributor badge in recognition of my contributions to Learn.WordPress.org. This badge honors members who help create, review, or translate lessons, and I’m proud to be among the recipients.

    Highlights from the 3rd June 2025 Meeting

    In the meeting recap on Make WordPress Training, we covered:

    • Reviewing Q2 goals: we gathered feedback on our 2025 milestones as we wrapped up the second quarter.
    • Volunteer opportunities: we invited contributors to host online workshops, coffee hours, study jams, or lesson walkthroughs.
    • Triage squad updates: we prepared for upcoming biweekly issue triage sessions.
    • Contributor Day planning: we coordinated an online Training Team Contributor Day alongside WordCamp Europe 2025 Contributor Day.

    Amid all these items, I was honored when my badge was announced.

    My Translation Contributions

    Localization makes WordPress accessible worldwide. Over the past months, I’ve reviewed and pushed forward key Tagalog translations for lessons and documentation, including:

    1. Issue #3183 – translating new lesson content into Tagalog
    2. Issue #3144 – updating terminology for consistency
    3. Issue #3143 – refining translation style guidelines
    4. Issue #3139 – reviewing community-submitted translations
    5. Issue #3138 – testing translated pages for accuracy

    My attention to detail and clear feedback have helped the Training Team deliver high-quality, localized learning materials for Tagalog speakers.

    Feedback Validation Efforts

    Beyond translations, I’ve validated and acted on learner feedback to keep our lessons relevant and error-free. Recent issues I tackled include:

    1. Issue #3137 – consolidating user feedback on workshop formatting
    2. Issue #3159 – verifying reported typos and code snippet errors
    3. Issue #3181 – confirming accessibility improvements across lesson pages

    By stepping in to validate and apply this feedback, I help keep our content polished and learner-focused.

    How You Can Get Involved

    If you’re inspired by my work, here are a few ways to jump in:

    • Join a Meeting: we meet every Tuesday at 07:00 UTC in #training on Slack. Peek at the agenda before you hop on.
    • Help with Translations: pick an open issue from the “Content ready for review” board and lend your language skills.
    • Validate Feedback: spot a typo or bug? Check out “Feedback awaiting validation”, confirm it, then help fix it.
    • Host a Workshop: run a coffee hour or study session using lessons on Learn.WordPress.org, teaching is a great way to learn!

    About the WordPress Training Team

    We’re a global bunch of volunteers who love teaching and learning all things WordPress. Our playground is Learn.WordPress.org, where we create, polish, and translate bite-sized lessons on using, extending, and contributing to WordPress.

    What we’re aiming for in 2025:

    • Reach more folks by spreading the word about our free lessons
    • Make every lesson as clear and accessible as possible (think captions, screen-reader friendliness, simple language)
    • Grow our community so everyone, from total newbies to seasoned devs, can share knowledge and skills

    How we keep it rolling: weekly Zoom hangouts, biweekly GitHub triage sessions, tons of hands-on workshops, and a friendly Slack channel where no question is too small. Whether you write a line of lesson content, review a translation, or flag a typo, every bit of help counts.

    Come join us!

  • How I Earned My WordPress Meta Contributor Badge (And How You Can Too!)

    A badge of network icon wrapped in pink color with text describing the purpose.

    If you’re involved in the WordPress community, you’ve probably come across contributor badges, those cool little icons next to usernames that recognize contributions to WordPress projects. Recently, I earned my very own Meta Contributor badge, and I’m excited to share how it happened, what I learned, and how you can do the same!

    Check my WordPress.org profile to check it!

    My Journey to the Badge

    It all started when I noticed an accessibility issue on the Polyglots Team page at WordPress.org. Specifically, the “Download WordPress in [Locale]” button was using white text on a very light gray background, making it difficult to read and failing WCAG contrast standards.

    You can see the original ticket here: Meta Trac #7986.

    My initial report clearly outlined the accessibility issue and included screenshots to illustrate the problem. I also provided a simple CSS patch on https://github.com/WordPress/wordpress.org/pull/490 to correct the color contrast by removing the problematic CSS rule.

    Engaging with the maintainer

    What made this experience particularly rewarding was the collaborative effort that followed. Community maintainers quickly reviewed the issue, validated it, and encouraged me to move forward.

    I created a pull request on GitHub to clearly document my suggested changes:

    PR #490.

    The PR clearly explained the adjustments, and after some helpful exchanges and review, the maintainers acknowledged my concerns and decided to update within the day.

    Getting Recognized

    Although my specific patch wasn’t directly merged, since the committer opted for a different approach, updating the link to a button, the issue I highlighted was effectively resolved. Impressively, within just 24 hours, I proudly received the Meta Contributor badge on my profile, acknowledging my valuable contribution to WordPress.org’s accessibility efforts.

    How You Can Do It Too

    Want your own badge? Here’s what you need to know:

    • Identify an Issue: Explore Meta Trac for open tickets or identify issues yourself on WordPress.org.
    • Report Clearly: When creating a ticket, clearly describe the issue, provide screenshots if necessary, and explain its importance.
    • Engage Actively: Respond promptly to feedback, remain open to suggestions, and revise your contribution as needed.
    • Submit a PR: Once your issue is acknowledged, create a concise, well-documented pull request on GitHub.
    • Celebrate: After your PR is merged or your issue addressed, keep an eye on your profile—your badge will appear soon!

    Contributing to WordPress isn’t just about badges, it’s about joining a vibrant community, gaining new insights, and enhancing a platform that millions depend on. So, why wait? Jump in, share your skills, and enjoy the rewarding experience of contributing.

    Have you made contributions or do you have insights to share? I’d love to hear your story in the comments!

  • I Break Things (So You Don’t Have To) – Test Contributor Unlocked!

    An icon of a monitor with single eye at the center, surrounded by circle border in dark pink, with text to the right describing the purpose of the icon.

    I’m thrilled to share that I’ve officially earned the WordPress Test Contributor badge! 🎉

    You can find my name mentioned in the post on the Make/Test blog — a weekly recap that highlights testing contributions across the WordPress project. It’s a small but meaningful milestone in my ongoing journey as a contributor.

    What Did I Test?

    Recently, I contributed by testing Trac ticket #63254: “Introduce development mode for block editor styles”.

    This ticket addresses a common frustration among plugin and theme developers, having to manually clear browser cache to see style changes in the block editor.

    The update introduces a development mode where, when SCRIPT_DEBUG is set to true, CSS and JS assets for the block editor automatically use their file modification timestamps (filemtime()) as version parameters. This ensures that every change is instantly reflected in the editor without manual cache-busting.

    Here’s what I did as a tester:

    • Confirmed the issue by switching SCRIPT_DEBUG on and noticing that asset URLs didn’t update as expected.
    • Applied the patch and revisited the editor to check that each file change triggered a unique ?ver=… timestamp.
    • Tested both CSS and JS changes, ensuring updates were reflected immediately.
    • Verified that this behavior only applies in development mode, preserving production performance.
    • Submitted a thorough test report, detailing the improved workflow and confirming that no new issues were introduced.

    This feature was then marked “ready to ship” and will be included in WordPress 6.8.2, a direct boost to developer experience.

    Why Testing Matters

    WordPress powers more than 40% of the web. Every update to the platform introduces enhancements, bug fixes, and new features. Behind all of those improvements is a vital layer of protection: real-world testing.

    Here’s why testing is essential:

    • Quality assurance: Testing helps catch bugs before they reach end users, reducing the chance of regressions in future releases.
    • User empathy: Testers evaluate features from the user’s perspective, ensuring updates are intuitive, functional, and consistent across environments.
    • Stronger releases: Well-tested patches reduce the need for last-minute hotfixes and allow developers to ship with more confidence.
    • Inclusive contribution: You do not need to be a developer to make a difference. Clear feedback, step-by-step reproduction, or simply confirming an issue still exists are all valuable.

    Testing opened the door for me to start contributing without needing to write core patches. It is a powerful and accessible way to strengthen WordPress from the inside out.

    What’s Next?

    This is only the beginning. I plan to:

    • Help test upcoming betas and release candidates
    • Explore writing unit tests to improve coverage
    • Join testing efforts for major releases
    • Encourage others to start their own contributor journey through testing

    If you have ever thought about contributing to WordPress, testing is an excellent place to begin. It is inclusive, impactful, and essential to the health of the project.

  • How I Earned My First Core Contributor Badge with WordPress 6.1 “Misha”

    Two contrasting arrow pointing on reversed direction away from each other, wrapped in thick circular bright red border with text on the right describing the purpose.

    Back in 2021, Ticket #54483 was opened to address an accessibility concern on the WordPress login screen. The issue? After logging out (with ?loggedout=true in the URL), the form’s input fields were still using aria-describedby="login_error", even though no actual error was present. For screen reader users, that’s misleading.

    I didn’t open the ticket, but when I came across it, I realized the patch hadn’t been written yet, and I decided to help.

    The fix was straightforward: update the condition to exclude the logged-out state from triggering the aria-describedby reference. Here’s the relevant tweak:

    if ( $errors->has_errors() && empty( $_GET['loggedout'] ) ) {
        $aria_describedby_error = ' aria-describedby="login_error"';
    } else {
        $aria_describedby_error = '';
    }
    

    Simple. Clear. And enough to improve accessibility for thousands of users.

    That patch sat quietly for a while, like many Trac tickets do. But in the lead-up to WordPress 6.1 “Misha,” it was reviewed, refined, and finally merged.

    And with it, I earned my first Core Contributor badge.

    Recognition with “Misha”

    That patch merged into WordPress core during the release of version 6.1 “Misha, officially announced on November 1, 2022. The release included nearly 60 accessibility improvements, emphasizing the project’s ongoing commitment to inclusivity..

    When that PR landed, I received my first Core Contributor badge. A one-line patch, validated by a major, widely celebrated release.

    Why this matters

    • Proof of impact. The official “Misha” release announcement confirms the focus on accessibility, and my patch was part of it.
    • Open source works. A 2021 ticket made inroads and was included in a 2022 release.
    • Small changes, big difference. Accessibility tweaks like this enrich the user experience for all.

    What I took from the experience

    • Start where you can contribute. I didn’t start this ticket, but I helped finish it.
    • Even small changes matter. This wasn’t a flashy feature, just a logic tweak that helped accessibility.
    • Be patient. WordPress core moves with care. Your patch might take time, but it’s never wasted.
    • You don’t need to do it all. Contributing to someone else’s ticket is just as valid as opening your own.