Bryan Veloso

Tag: Wordpress

  • WordPress Just Gave My AI Assistant a Brain Upgrade (Agent Skills Changed My Workflow Again)

    Last month I wrote about how Claude changed everything for me with custom Gutenberg blocks. I thought I had reached peak workflow. Cursor + Claude, my `.cursor/rules` file, my master prompt template. I was shipping blocks in 15 minutes instead of 6 hours.

    Then WordPress itself dropped something that made half of my “secret sauce” obsolete — in the best possible way.

    Enter: Agent Skills for WordPress

    The WordPress project quietly released an official repo called [agent-skills](https://github.com/WordPress/agent-skills). The tagline says it all:

    “Teach AI coding assistants how to build WordPress the right way.”

    Agent Skills are portable bundles of instructions, checklists, and scripts that AI assistants — Claude, Copilot, Codex, Cursor, whatever you use — read *before* they touch your WordPress code. Instead of the model guessing from its training data (which is often 2 years out of date), it follows documented, contributor-reviewed procedures.

    If you read my last post, you’ll remember my Step 1 was writing my own rules file: “Always use apiVersion 3, prefer render.php, follow WordPress Coding Standards, proper escaping and i18n…”

    That’s exactly what these skills are. Except written from official Gutenberg and WordPress documentation, reviewed by WordPress contributors, and way, way more thorough than my little rules file.

    Why This Matters (The Problem Nobody Talks About)

    AI assistants are amazing, but if you’ve done serious WordPress work with them, you’ve hit these walls:

    1. Outdated patterns. Ask for a theme and you might get a classic PHP theme when you wanted a block theme with `theme.json`. Ask for a block and sometimes you get apiVersion 2 or — the horror — a shortcode.
    2. Missing security. Escaping, sanitization, nonces, capability checks. The AI *knows* about them but doesn’t always apply them unless you nag.
    3. The dreaded “Invalid block” error. If you’ve ever changed a block’s markup and broken every existing instance on a client’s site because you skipped deprecations… you know the pain. This one has bitten me twice.
    4. Ignoring your existing tooling. The AI happily reinvents your build setup instead of using what’s already in the repo.

    Agent Skills solve all four. There’s literally a skill dedicated to block deprecations.

    What’s in the Box

    The repo currently ships 15 skills. Some highlights:

    – wp-block-development — everything I was manually prompting for: `block.json`, attributes, rendering, and yes, deprecations
    – wp-block-themes — `theme.json`, templates, patterns, style variations
    – wp-plugin-development — plugin architecture, hooks, Settings API, security
    – wp-interactivity-api — remember in my last post when I told Claude “make the carousel use the new Interactivity API”? Now there’s a whole skill teaching it the `data-wp-*` directives properly
    – wp-rest-api, wp-performance, wp-wpcli-and-ops, wp-phpstan, wp-playground, and more

    There’s even a wordpress-router skill that classifies your repo and routes the AI to the right workflow, and wp-project-triage that auto-detects your project type, tooling, and versions. So the AI stops assuming and starts checking.

    Installing It (Took Me 3 Minutes)

    I installed globally so every project gets the skills:


    git clone https://github.com/WordPress/agent-skills.git
    cd agent-skills
    shared/scripts/skillpack-build.mjs --clean
    shared/scripts/skillpack-install.mjs --global

    That drops everything into `~/.claude/skills/` where Claude Code auto-discovers them. Cursor users, there’s a `–targets=cursor-global` option that installs to `~/.cursor/skills/`.

    For client repos, you can install per-project and even pick specific skills:

    node shared/scripts/skillpack-install.mjs --dest=../client-site --targets=claude,cursor --skills=wp-block-development,wp-block-themes

    It supports Codex and VS Code / GitHub Copilot targets too. Whatever your assistant, it’s covered.

    The Before/After Test

    I did an experiment. Same prompt, same model, two fresh plugin folders — one with skills installed, one without.

    The prompt: “Create a native Gutenberg block called Team Grid. 2–4 columns, photo, name, role, social links. Then change the markup structure of the name field.”

    Without skills: Great block (Claude is still Claude). But when I asked for the markup change, it just… changed it. Any existing instance would have thrown “Invalid block” in the editor.

    With skills: It generated the block, and when I asked for the markup change, it *automatically wrote a deprecation entry* with the old save function and a migration. Unprompted. It also ran through a verification checklist at the end — escaping, i18n, accessibility — like a senior dev reviewing its own PR.

    That deprecation thing alone would have saved me an embarrassing client call back in May.

    My Updated Workflow (June ? July 2026)

    So here’s what changed from last month’s post:

    1. Write my own `.cursor/rules` with WordPress standards ? Install agent-skills once, globally
    2. Master prompt template? still useful, but now shorter. I describe the “what”, the skills handle the “how”.
    3. Iterate in chat? unchanged, still magic

    My prompts have gotten lazier and my output has gotten better. That’s the dream, right?

    Honest Limitations (Again, Not Selling You Anything)

    – It’s v1. The skills were AI-generated from official docs, then reviewed and edited by WordPress contributors, and they’re upfront about that. Expect rough edges and improvements over time.
    – It targets WordPress 6.9+ — if you’re maintaining older client sites, the guidance may not always fit.
    – You still need to test in a real WordPress environment. Skills make the AI dramatically more reliable, not infallible.
    – And you still need to understand WordPress basics. This is still “super-code,” not “no-code.”

    The Bigger Picture

    What excites me most isn’t even the skills themselves. It’s that **WordPress, the project, is officially treating AI assistants as first-class citizens of the ecosystem**. The repo is GPL, community contributions are welcome, and most skills are just Markdown — you don’t need to be a coding wizard to improve them. If you’ve got hard-won WordPress expertise, this is a genuinely great way to give back.

    Last month I said Claude changed what a solo developer can ship. This month, WordPress made sure your AI ships it the right way.

    Go install it. Your future self — the one who doesn’t get the “Invalid block” support email — will thank you.

    Enjoy (properly skilled) vibe coding!

  • Writing my first blog post on WordPress 7.0

    Feels great, feels new. It’s awesome! There’s something magical about firing up a fresh WordPress install and realizing you’re not just using the platform, you’re stepping into its next evolution. Today, May 2026, I upgraded to WordPress 7.0 “Armstrong”, and I’m genuinely excited to share this journey with you. Whether you’re a longtime user like me or just getting started, this release feels like a breath of fresh air.

    This isn’t a revolutionary overhaul that breaks everything you know. It’s a mature, confident step forward. WordPress is growing up without losing its friendly soul. If you’re hesitant about updating, do it on a staging site first (always good practice). But from what I’ve seen in the first few hours, it’s stable, exciting, and genuinely fun to use.

    What’s next? I’ll be experimenting more with AI connectors for outlining future posts, testing the collaboration features with guest writers, and pushing the new design tools on a redesign project.

    What do you think of WordPress 7.0 so far? Have you upgraded yet? Drop your thoughts in the comments—I’d love to hear how it’s working for you. And if this is your first blog post too, welcome to the club. There’s never been a better time to start.

  • Too many new features in WP 6.9

    I recently upgraded my blog to 6.9 and I love how WP progressed over the years. Back then I just use this for blogging, but now, it’s everything. You can even create apps, dashboards, booking systems, and everything you can think of using WP. Now, you can even leave comments like using Figma.

    The drag and drop editor Gutenberg that was so bad back then, really improved this 2026.

    I’m still using Classic Editor btw, but I’m gonna switch again and will just use the default Gutenberg editor moving forward. So far so gooooood!

    Also, I recently discovered vibe coding, and you can actually deploy professionally built websites and blog, that’s already headless in just a few seconds. Worst case scenario is minutes. lol! Now everyone is a web / app developer!

    Anyway, I know this guy who is bragging too much about he deployed this and that, and made this and that, with zero coding knowledge. Now this guy deployed a CRM where the company is actually using. One day, there’s an issue about it and he cannot fix it, nor the AI. I think it’s server related issue or some capacity as the code is not that optimized. It frequently goes down. He can’t fix it, AI can’t fix it, and it went down. He has zero clue how to fix it, so he resigned.

    Lesson here is, don’t overly rely on AI. Even a simple CSS issue, AI overcomplicates it, even if it’s just a simple one line fix.

    Gotta learn the basics, instead of just telling the artificial intelligence everything what you want.

    A solid foundation in basics is better than zero foundation at all.

    Stay humble. Stay foolish. Stay Hungry. Thank you Steve Jobs!

  • Clean Login custom user meta fields WP snippet

    I just made extra fields in my user registration and made it appear in the clean login [edit-profile] shortcode. Here’s a wp snippet that you can modify to do the same. I registered two custom user meta fields via formidable forms, but I can only view it if I display the form in the frontend. Formidable Forms lack the confirm email functionality when you change the email address in the web form, so I used clean login to achieve a frontend edit profile with e-mail confirmation.

    Below is an example snippet to add more fields in your clean login edit profile page.

    <?php
// Add custom user meta fields to the Clean Login edit form
add_action( 'clean_login_edit_profile_fields', function( $user_id ) {
    $contact   = get_user_meta( $user_id, 'contact', true );
    $territory = get_user_meta( $user_id, 'territory', true );
    ?>
    <p>
        <label for="contact"><?php _e( 'Contact', 'clean-login' ); ?></label><br>
        <input type="text" name="contact" id="contact" value="<?php echo esc_attr( $contact ); ?>" />
    </p>
    <p>
        <label for="territory"><?php _e( 'Territory', 'clean-login' ); ?></label><br>
        <input type="text" name="territory" id="territory" value="<?php echo esc_attr( $territory ); ?>" />
    </p>
    <?php
});

// Save the custom fields when user updates profile
add_action( 'clean_login_save_profile_fields', function( $user_id ) {
    if ( isset( $_POST['contact'] ) ) {
        update_user_meta( $user_id, 'contact', sanitize_text_field( $_POST['contact'] ) );
    }
    if ( isset( $_POST['territory'] ) ) {
        update_user_meta( $user_id, 'territory', sanitize_text_field( $_POST['territory'] ) );
    }
});

  • What’s Coming in WordPress 7.0: A Look at the New Features and Improvements

    WordPress has come a long way from its humble beginnings as a blogging platform. With every major release, it continues to evolve into a more powerful and user-friendly content management system. As we look ahead to WordPress 7.0, set for release later this year, the core team has announced some exciting new features that promise to enhance both the user and developer experience.

    Here’s a breakdown of what’s coming in WP 7.0 and why it matters.

    Full-Site Editing (FSE) Gets Smarter

    While Full-Site Editing was introduced in previous versions, WP 7.0 will refine and expand its capabilities. Expect:

    – Smarter block-based theme tools
    – Global style variations that make switching between designs seamless
    – Improved template browsing and creation directly from the Site Editor
    – Enhanced navigation block customization, finally matching the flexibility of traditional menus

    These updates are designed to give both designers and non-coders greater control over site appearance—without needing to touch PHP.

    Performance Boosts

    Performance remains a top priority, and version 7.0 introduces several under-the-hood improvements:

    – Improved object caching, especially for REST API responses
    – Enhanced lazy loading for images and iframes, reducing page load times
    – A new defer” attribute added to script loading for better Core Web Vitals
    – Database query optimization in multisite setups

    Whether you’re running a blog or a WooCommerce store, these enhancements will help your site run faster and smoother.

    Block Editor Enhancements

    The Gutenberg editor gets a significant upgrade with:

    – New blocks: Table of contents, image comparison, progress bar
    – Block-level revisions, letting you revert changes to individual blocks
    – Improved drag-and-drop functionality and block locking to prevent accidental edits
    – Better accessibility and keyboard navigation throughout the editor

    The block editor continues to mature into a more intuitive page builder, closing the gap with premium solutions.

    Better Security and Access Control

    Security updates in WordPress 7.0 include:

    – Role-based block access, so certain blocks can be hidden from non-admin users
    – Tighter REST API permission checks
    – Support for passkeys as a login method
    – Continued work toward Core auto-updates by default, reducing risk on neglected installs

    Security-conscious users will appreciate these thoughtful additions.

    Plugin and Theme Developer Improvements

    For developers, WordPress 7.0 brings:

    – New interactivity API for building dynamic blocks without React overhead
    – Script module support type=”module”
    – Better block style registration and tooling in the theme.json
    – Early support for PHP 9.0 compatibility checks

    These improvements not only modernize development workflows but also lay the groundwork for future innovation.

    Multilingual Support on the Horizon?

    One of the most requested features—native multilingual support—is finally getting traction. While full support may not land in 7.0, early groundwork is being laid. Expect:

    – Language switching APIs for developers
    – Basic language context awareness in block themes
    – UI components that will make it easier to build multilingual plugins

    It’s a strong hint that core multilingual capabilities may be included in future 7.x releases.

    WordPress 7.0 isn’t just about adding flashy features—it’s about refining the experience, improving performance, and moving closer to a modern, decoupled CMS. Whether you’re a blogger, developer, or agency, this release is shaping up to be one of the most impactful updates in recent memory.

  • Matt vs WP Engine: Open-source ethics versus commercial enterprise

    Matt Mullenweg’s frustration with WP Engine seems to stem from two key issues: WP Engine’s monetization practices and its contribution to the WordPress community. His criticisms are centered on the fact that WP Engine, while profiting heavily from the WordPress ecosystem, allegedly doesn’t support or contribute enough to its open-source foundation. This is important because WordPress is built on a collaborative, open-source philosophy, and Mullenweg likely sees WP Engine’s approach as undermining those values.

    However, WP Engine argues that they are acting within the bounds of open-source usage, suggesting that they have the right to use WordPress’s trademark without additional licensing fees. They also push back on Mullenweg’s claims, asserting that they provide significant value to users and that their business practices are in line with the expectations of their customers.

    From Mullenweg’s perspective, his stance could be seen as reasonable if you consider the long-term sustainability and fairness of open-source projects. He may see WP Engine’s actions as detrimental to WordPress’s community-driven spirit, especially when a commercial entity profits without contributing back. However, calling WP Engine a “cancer” might be viewed as overly harsh, particularly when many WP Engine customers feel satisfied with the services they provide .

    In essence, the reasonableness of Mullenweg’s actions depends on one’s perspective on open-source ethics versus commercial enterprise. If you value strict adherence to open-source principles, Mullenweg’s stance may resonate. However, if you view WordPress as a platform open to free-market usage, WP Engine’s approach might seem justified.

  • Formidable: Adding Dynamic Link to Parent Values in a View with Child (Repeater) as the Source.

    There are instances that you need to add a dynamic link to a Formidable Form view when your data source is the child table, instead of the parent table. Here’s a javascript snippet that will do the magic.


    function load_jquery() {
    wp_enqueue_script("jquery");
    }
    add_action('wp_enqueue_scripts', 'load_jquery');

    function custom_href_shortcode_fix() { ?>

    To ensure the modification of links applies to all pages of a jQuery DataTable and not just the first, we must utilize DataTables' callback functions to reapply our changes after every table draw (which occurs on pagination, searching, or ordering). Because DataTables rebuilds the elements in the table when you paginate or change the data view, changes made to the DOM are lost after the initial page load. Here's how you can adapt your JavaScript to handle this situation:

    1. First, ensure DataTables is loaded and initialized on your table. I'm going to assume you've done that as part of your setup since you mentioned you're working with jQuery DataTables.

    2. Modify your `custom_href_shortcode_fix` function to use DataTables' `drawCallback` option to reapply custom link configurations after every draw.

    Here's an example update for your code:


    function custom_href_shortcode_fix() { ?>

    A few key points:

    - Ensure you have your DataTables initialized in the script where you're implementing the `drawCallback`. Replace `'#yourTableId'` with the actual ID of the table you are using.
    - The `drawCallback` option is used here to specify a function that is called whenever the table is drawn on the page, including when the page is changed, sorted, or filtered.
    - We've included the initial application of the link modification logic outside of the `drawCallback` as well to ensure it's applied when the page first loads, before any DataTable actions may trigger a redraw.

    Make sure you replace the specific selectors and IDs (`'#yourTableId'` and `'a.dynamic-href'`) with ones that match your HTML structure and requirements.

    What if you encounter the error Cannot reinitialise DataTable?

    The error message "Cannot reinitialise DataTable" typically indicates that DataTables has been initialized on an element more than once. This is a common issue when attempting to apply DataTables configurations dynamically or when the page's state changes without proper cleanup.

    Given the context of your setup, where you might not control the initial initialization of the DataTables (especially in WordPress environments where plugins or themes might automatically apply DataTables to certain elements), we need to approach this with a method that checks if a DataTable instance already exists on an element and only apply modifications without reinitializing.

    Let's adjust your code to handle this scenario. Since you're working with a class selector and you might not be able to directly control the DataTable initialization process, you can use the `$.fn.dataTable.isDataTable()` function to check if an element is already initialized as a DataTable. Here's how you could modify your script:


    function custom_href_shortcode_fix() { ?>

    Additional adjustments:

    1. I wrapped the DataTable initialization in a check using `$.fn.dataTable.isDataTable()` to prevent reinitializing an already initialized DataTable.

    2. I kept the original logic for applying the hyperlink modifications outside the initialization block, which means it will run on page load for all matching elements immediately.

    3. I added an event listener `draw.dt` to the table, which DataTables triggers after each draw. This is useful if your tables are being modified or interacted with dynamically after the initial page loads. This ensures that your `href` modifications are reapplied after actions like pagination, searching, or sorting.

    Please ensure you replace `.yourTableClass` and `'a.dynamic-href'` with the actual selectors used in your project.

  • WordPress 6.4 first impressions!

    WordPress 6.4 was released today and here are my first impressions. It’s cool and it’s fast and I love the modern Twenty Twenty four theme! Other features include the following.

    User Experience Improvements: WordPress tends to focus on refining the user experience with each update. My first impressions might include appreciation for a more streamlined interface, smoother navigation within the dashboard, and enhancements to the site-building experience provided by the block editor (Gutenberg).

    Block Editor Enhancements: With every release, the Gutenberg block editor usually receives new features or improvements. I might notice new blocks, block patterns, or improved handling of media elements within the editor that further simplify the content creation process.

    Performance Enhancements: WordPress developers continuously work to optimize the script loading and database queries for a faster experience. Thus, my first impressions could include faster page load times and more efficient backend performance.

    Full-Site Editing Features: Since the incorporation of full-site editing (FSE) functionality, users expect robust enhancements in this area. Any improvements to the site editor, template creation, and global styles would stand out as significant to me.

    Accessibility: Given WordPress’s commitment to making the web accessible to everyone, I might be impressed by newly introduced features or improvements that make the CMS more accessible for users with disabilities.

    Default Theme – Twenty Twenty-Four: Typically included with a new major WordPress release is a default theme that showcases the latest features. I would be eager to see the aesthetics and functionality of the Twenty Twenty-Four theme, expecting a design that is both modern and optimized for a wide range of use cases.

    Developer Tools and Hooks: As a developer, I might look for new APIs, hooks, or enhanced coding tools that allow for more extensive customizations and integrations, enabling developers to build more robust themes and plugins.

    Can’t wait to explore the rest of the new features in 6.4.