Category: Development

  • Taming WordPress 6.9 Accordions: The Right Way to Style Them

    Just last week, I had a client reach out. They were revamping their FAQ page, and naturally, they wanted a sleek, branded accordion look. Easy enough, right? Except when we dropped in the new Accordion block in WordPress 6.9, it was… well, let’s just say it was bare bones. A functional accordion, absolutely, but miles away from the custom styling they envisioned. Total mess. This is a problem many of you are probably facing or will face soon. The new Accordion block is a fantastic addition, but out of the box, it’s a blank canvas. If you want it to truly blend with your theme and provide a polished user experience, you need to know how to approach styling WordPress Accordion blocks systematically. My first thought, and I’ll admit it, was to just start throwing custom CSS at it. A `border-radius` here, a `background-color` there, maybe an `!important` to override something stubborn. It worked, for a minute. But then the client wanted a different style for another section, and suddenly, I had a spaghetti of CSS that was a total nightmare to manage. This isn’t scalable, and it certainly isn’t the “right” way to leverage modern WordPress development. Trust me on this, you’ll regret it later. The real fix, the maintainable solution, lies in embracing `theme.json` first, and then using targeted custom CSS for the fine-tuning. WordPress 6.9’s Accordion block isn’t just one block; it’s a nested structure: `core/accordion`, `core/accordion-item`, `core/accordion-heading`, and `core/accordion-panel`. Each offers a hook for proper styling.

    Styling WordPress Accordion Blocks with theme.json

    You want to start by defining your base styles in your `theme.json` file. This is where you set the global or block-specific styles that become your foundation. Let’s look at a simplified example for the `core/accordion-item`, which acts as the wrapper for each question and answer pair.
    {
    	"styles": {
    		"blocks": {
    			"core/accordion-item": {
    				"border": {
    					"color": "#d5dae2",
    					"style": "solid",
    					"width": "1px",
    					"radius": "12px"
    				},
    				"color": {
    					"background": "#f6f7f9",
    					"text": "#343b46"
    				},
    				"shadow": "0 10px 15px -3px #80000080, 0 4px 6px -4px #80000080",
    				"spacing": {
    					"blockGap": "0"
    				}
    			}
    		}
    	}
    }
    See how clean that is? We’re defining borders, background, text color, and even a shadow right within the JSON. You should, of course, be referencing presets here in a real-world scenario, but this snippet illustrates the power. Next, we address the `core/accordion-heading` and `core/accordion-panel`. The heading is actually an `<h3>` element, so any existing heading styles will apply. You might need to reset or refine them.
    {
    	"styles": {
    		"blocks": {
    			"core/accordion-heading": {
    				"css": "&__toggle { padding: var(--wp--preset--spacing--40) var(--wp--style--block-gap); }",
    				"typography": {
    					"fontFamily": "inherit",
    					"fontSize": "inherit",
    					"fontStyle": "inherit",
    					"fontWeight": "500",
    					"lineHeight": "inherit",
    					"textTransform": "inherit"
    				}
    			},
    			"core/accordion-panel": {
    				"spacing": {
    					"padding": {
    						"top": "var(--wp--style--block-gap)",
    						"bottom": "var(--wp--style--block-gap)",
    						"left": "var(--wp--style--block-gap)",
    						"right": "var(--wp--style--block-gap)"
    					}
    				}
    			}
    		}
    	}
    }
    The `css` property within `theme.json` is a lifesaver for those tricky nested elements you can’t target directly, like the `__toggle` button within the heading. This keeps your styles localized. For a deeper dive into these techniques and more comprehensive examples, the original article on developer.wordpress.org is a fantastic resource.

    Fine-Tuning with Custom Block Stylesheets

    While `theme.json` gets you most of the way, some dynamic styling—like hover states or specific open/closed appearances—are best handled with a dedicated block stylesheet. We’re talking about creating `block-accordion.css` in your theme’s assets and enqueueing it properly with `wp_enqueue_block_style()`. This gives you precise control without bloating your `theme.json`.
    /* Add toggle button background on open/hover/focus. */
    .wp-block-accordion-item.is-open .wp-block-accordion-heading__toggle,
    .wp-block-accordion-heading__toggle:hover,
    .wp-block-accordion-heading__toggle:focus {
    	background: #eceff2; /* Use a preset here. */
    }
    This snippet, placed in your custom `block-accordion.css` file, applies a subtle background change when the accordion is open or hovered. It’s a clean way to handle these dynamic visual cues. You can also define block style variations, like a “Minimal” style, through separate JSON files and additional CSS, offering your users more design choices directly in the editor. This modular approach is key for extensibility and maintainability.

    So, What’s the Point?

    The WordPress Accordion block is a powerful tool, but like any new feature, knowing how to properly integrate and style it makes all the difference. Don’t fall into the trap of quick-fix CSS. Embrace `theme.json` for your foundational styles and leverage block stylesheets for the more nuanced, interactive elements. This approach ensures your accordion styling is robust, maintainable, and scalable, whether you’re building a simple FAQ or a complex interactive content section. It’s about working *with* WordPress, not against it. Look, this stuff gets complicated fast. If you’re tired of debugging someone else’s mess and just want your site to work, drop my team a line. We’ve probably seen it before.
  • Finally, a Real Pipeline for WordPress Contribution Talent

    I had a client recently, a mid-sized agency, tearing their hair out. They’d just hired a couple of junior devs, sharp kids with decent PHP and JS skills. But when it came to tackling anything beyond basic theme tweaks—say, proposing a patch for a core bug or understanding the release cycle for a new Gutenberg block—they were completely lost. It wasn’t about raw coding ability; it was about knowing *how* WordPress actually gets built, and more importantly, how to contribute to it effectively. This problem, man, it’s a constant.

    For years, finding reliable junior talent with a solid grasp of the WordPress contribution ecosystem has been a crapshoot. You get coders, sure, but true contributors? That’s different. This is why I’m actually pretty hyped about what I read recently on the official WordPress news site about “WordPress Credits,” a new contribution internship program.

    The struggle is real. We’ve all seen it. A client wants a custom solution that aligns with WordPress best practices, but their newly hired dev, despite being technically proficient, just isn’t speaking the same language as the wider open-source community. They might implement something that works, but it’s a standalone hack, not a proper integration that respects the platform’s architecture or future-proofs the project. My first thought? Just tell them to hire experienced senior devs, but junior roles are essential for growth. The vulnerability here, the mistake I made for a while, was assuming raw technical skill alone would naturally lead to effective open-source contribution. It just doesn’t. You need mentorship; you need a pathway. Period.

    Building Real WordPress Contribution Pathways

    That’s where the WordPress Credits program aims to step in. It’s a structured internship designed to bring university students, from all fields, into the WordPress open-source project with real guidance. Think of it: structured onboarding, personalized contribution projects, and direct mentorship from experienced contributors. This isn’t just teaching them to code; it’s teaching them *how to contribute* to a massive, global project. The foundational training covers everything from open-source principles to getting familiar with community tools like Slack and the Make blogs. This builds muscle memory for proper contribution.

    Students pick an area—could be translating documentation, contributing code, testing, design, or even developing training materials for Learn WordPress. They get a dedicated mentor and a contact person from the WordPress Foundation. Their contributions? They’re integrated directly into official projects. This means they’re not just doing busy work; they’re making real, tangible impacts. This kind of hands-on, mentored experience is what produces the next generation of developers who understand not just *how* to build, but *why* we build things a certain way in an open-source context. It’s about cultivating that core developer mindset, which is critical for scalable, maintainable projects.

    Imagine a junior dev tasked with adding a new custom field to a post type. Without understanding core contribution, they might just add it directly to a theme template with a custom query. With the WordPress Credits approach, they learn the proper way to extend functionality:

    <?php
    /* Initial, less optimal approach (hypothetical, simplified) */
    function bad_custom_field_display() {
        global $post;
        if ( get_post_type( $post->ID ) == 'product' ) {
            $data = get_post_meta( $post->ID, '_my_custom_field', true );
            echo '<p>My Field: ' . esc_html( $data ) . '</p>';
        }
    }
    add_action( 'the_content', 'bad_custom_field_display' );
    
    /* More 'contribution-aware' approach using proper hooks and APIs */
    function register_my_custom_meta() {
        register_post_meta( 'post', '_my_custom_field', [
            'show_in_rest' => true,
            'single' => true,
            'type' => 'string',
            'auth_callback' => function() {
                return current_user_can( 'edit_posts' );
            }
        ]);
    }
    add_action( 'init', 'register_my_custom_meta' );
    
    function my_custom_field_display( $content ) {
        if ( is_single() && get_post_type() === 'post' ) {
            $my_field = get_post_meta( get_the_ID(), '_my_custom_field', true );
            if ( ! empty( $my_field ) ) {
                $content .= '<!-- wp:paragraph --><p><strong>Custom Insight:</strong> ' . esc_html( $my_field ) . '</p><!-- /wp:paragraph -->';
            }
        }
        return $content;
    }
    add_filter( 'the_content', 'my_custom_field_display' );
    ?>

    The code block illustrates a foundational lesson: don’t just hack it; understand the API and proper extension points. This kind of thinking is what this program cultivates. It’s about contributing *to* WordPress, not just building *on* it. You can find more details about the pilot program and how to get involved for universities and companies at wordpress.org/news. They even have a company guide for those interested in sponsoring mentors, which, trust me, is a solid investment in the future talent pool.

    Why This Matters for Your Project

    Look, the takeaway is simple: we need more developers who understand the nuances of open-source contribution, especially within WordPress. This program is a direct answer to that. It’s creating a generation of developers who are not only technically skilled but also deeply integrated into the community and its best practices. For clients, this means more robust, maintainable, and forward-thinking solutions. For agencies, it means a more reliable talent pipeline for junior roles. It’s a win-win, cultivating developers who truly “get” WordPress.

    Look, this stuff gets complicated fast. If you’re tired of debugging someone else’s mess and just want your site to work, drop my team a line. We’ve probably seen it before.

  • WordCamp US Scholarship: Fueling WordPress Developer Growth

    A client asked me recently why our agency’s WordPress developers always seem to bring fresh, innovative solutions to the table. They’d worked with other outfits, seen the same old approaches, and wanted to know our secret sauce. My answer? It always comes back to community engagement, and initiatives like the Kim Parsell Memorial Scholarship are critical for fostering that.

    Honestly, when I started out, my approach was heads down, just code, code, code. I thought raw coding chops were the only thing that mattered. For years, I was buried in tickets, optimizing queries, and wrestling with themes, thinking that was the peak of professional development. But man, I missed out. I saw other developers, sometimes younger, bringing a depth of insight and understanding that I just wasn’t getting from my silo. It was a total nightmare, really, realizing how much valuable perspective and potential I’d been missing by not engaging with the broader WordPress community. That kind of isolated development? It leaves you behind, fast. You end up building the same old solutions instead of pushing boundaries.

    This isn’t just about feeling good; it’s about tangible returns. Developers who are connected, who attend events like WordCamp US, who contribute to core, they bring that knowledge directly back to your projects. They know the upcoming changes, the best practices, the patterns that are actually gaining traction. The problem is, attending these events isn’t cheap. Travel, accommodation, time off – it adds up. And that’s where the Kim Parsell Memorial Scholarship for WordCamp US 2025 comes into play, addressing a very real barrier for dedicated contributors.

    Bridging the Gap with WordPress Community Scholarships

    The WordPress Foundation is stepping up again with the Kim Parsell Memorial Scholarship. This isn’t just some feel-good gesture; it’s a strategic investment in the future of WordPress and, by extension, in the talent pool available to clients like yours. This scholarship makes it possible for deserving community members to attend WordCamp US, folks who are actively contributing but might not have the means otherwise. It keeps the community vibrant, diverse, and, frankly, keeps developers sharp. The core mission, as detailed on the WordPress.org news page, is to honor Kim Parsell’s legacy by supporting those who embody her spirit of open source and inclusivity.

    The scholarship is specifically aimed at women who are active contributors, haven’t attended WordCamp US before, and demonstrate a financial need. This focus is intentional. It ensures we’re supporting new voices and diverse perspectives, which are vital for a healthy open-source project. If you meet these qualifications, get your application in before July 25, 2025. It’s a chance to immerse yourself in the highest level of WordPress discourse, learn from the best, and bring that knowledge back to your own work.

    So, What’s the Point?

    • Fresh Perspectives: Scholarship recipients bring diverse ideas and experiences back into the development ecosystem.
    • Skill Elevation: Direct exposure to core contributors and advanced sessions at WordCamp US sharpens skills beyond what online tutorials can offer.
    • Stronger WordPress: A more inclusive and well-represented community means a more robust and adaptable WordPress platform for everyone.
    • Direct Client Benefit: When your developers are plugged into the community, they’re better equipped to leverage the latest and greatest for your projects.

    Look, this stuff gets complicated fast. If you’re tired of debugging someone else’s mess and just want your site to work, drop my team a line. We’ve probably seen it before, and we know that a well-connected, continuously learning developer makes all the difference.

  • WP-CLI: Fixing WordPress When The Dashboard Dies

    I got a frantic call last Tuesday. A client, running a decent e-commerce setup, had just pushed an update. Classic story, right? Suddenly, their entire admin dashboard was a white screen of death. Total mess. They couldn’t log in, couldn’t deactivate plugins, couldn’t do *anything* through the browser. Panic was setting in, and honestly, who could blame them?

    My first thought, and probably theirs, was to start poking around with FTP, maybe manually rename plugin folders or dive into the database with phpMyAdmin. And yeah, that *might* work, but it’s slow, prone to errors, and frankly, a bit barbaric in 2024. That’s not how a senior dev tackles a critical outage. This was a job for WP-CLI – the WordPress Command Line Interface. It’s the tool you reach for when the GUI just gives up.

    Why WP-CLI Commands Are Your Best Friend in a Crisis

    Look, the WordPress admin UI is great, it makes things accessible for everyone. But when your site breaks so badly you can’t even get to it, or when you need to perform bulk actions across hundreds of posts or dozens of plugins, clicking around is a time sink. That’s the core pain WP-CLI solves. It allows you to interact with your WordPress installation directly from your terminal, executing commands with precision and speed.

    For my client’s white screen issue, the problem was almost certainly a plugin conflict. Instead of fumbling with FTP to rename plugin directories one by one, a few quick WP-CLI commands got us straight to the root cause. This kind of immediate, granular control, especially during a crisis, is game-changing. It’s about being able to manage your WordPress site efficiently, even when the front-end or admin is completely hosed.

    Let me show you a typical scenario. Say you suspect a plugin is causing trouble. With WP-CLI, you don’t need the admin panel. You connect via SSH, navigate to your WordPress root, and run:

    wp plugin deactivate <plugin-slug>

    Or, if you’re not sure which one, you can just nuke them all and reactivate them strategically:

    wp plugin deactivate --all

    In the client’s case, a quick wp plugin deactivate --all brought the admin back online. From there, we could reactivate them one by one to find the culprit. Ten minutes, tops. What would have been an hour of manual effort and guesswork was cut down to nothing. This flexibility extends to everything from user management, updating core, to even creating thousands of dummy posts for testing, as detailed in the official WP-CLI documentation.

    So, What’s the Point?

    • Time is Money: Manual tasks stack up. WP-CLI makes batch operations and quick fixes a breeze.
    • Crisis Management: When your site is down and the dashboard is inaccessible, WP-CLI is often your only direct line of defense.
    • Advanced Control: Do things the admin panel can’t, like database search-and-replace or creating a custom deployment script.
    • Developer Credibility: Knowing your way around WP-CLI tells me you’re a pro who understands the underlying mechanics, not just someone clicking buttons.

    Look, this stuff gets complicated fast. If you’re tired of debugging someone else’s mess and just want your site to work, drop my team a line. We’ve probably seen it before.