muhammad.dev

Tag: development

  • My 2026 Development Workflow: Claude Code Desktop + Cursor

    My 2026 Development Workflow: Claude Code Desktop + Cursor

    I’ve been refining my development workflow over the past few months, and I’ve landed on a combination that feels incredibly productive: Claude Code from the Desktop app paired with Cursor for code review. Let me walk you through how I work.

    Anthropic recently added a native “Code” tab directly inside the Claude Desktop app. It is a GUI for the engine that powers the CLI. One notable feature is its support for isolated Git worktrees. This means you can have a brainstorming conversation in one tab while a “Code” session runs in another, making changes in a separate worktree that won’t touch your main working directory until you’re ready to merge.

    Why not git worktree? My workflow is simple enough that I just work directly in my main/feature branch and review everything in Cursor before committing. But if you’re juggling multiple experimental features or want that extra safety net, the worktree support is there.

    Why not the CLI? I know many developers swear by the Claude Code CLI, but I’ve found the Desktop app suits my workflow better. There’s something about having a dedicated window for my AI conversations that keeps things organized. I can easily reference previous discussions, and the interface feels more natural for the kind of back-and-forth dialogue I have when working through complex problems.

    The Workflow

    Here’s how my typical development session looks:

    1. Brainstorm with Claude Desktop

    Before writing any code, I start by talking through the problem with Claude. I describe what I’m trying to accomplish, share relevant context about my project, and bounce ideas back and forth. This conversation helps me clarify my thinking and often surfaces edge cases I hadn’t considered. It’s like having a patient colleague who’s always available to rubber duck with.

    I then ask Claude to generate a prompt for Claude Code based on this discussion.

    2. Generate Code with Claude Code

    I open Claude Code in the Desktop app and paste in the prompt generated from step 1. It would have context about my project structure, the technologies I’m using, and any constraints I’m working with. Claude generates code, explains its reasoning, and I can ask follow-up questions right there in the conversation.

    3. Review in Cursor

    Once Claude has generated the code, I switch to Cursor. This is where I put on my reviewer hat. I don’t just blindly accept what the AI produces—I read through it carefully, understand what it’s doing, and verify it aligns with my project’s patterns and standards.

    Cursor’s diff view makes this review process smooth. I can see exactly what’s being added or changed, accept individual hunks, or modify the suggestions before committing.

    4. Test, Accept, and Commit

    After reviewing and testing, I accept the changes I’m happy with and commit them with meaningful commit messages.

    Why This Combination Works (for me)

    The separation of concerns is what makes this workflow powerful:

    • Claude Desktop for Brainstorming — This is where ideas take shape. I describe the problem I’m solving, share context about my project architecture, and have a back-and-forth conversation to explore different approaches. Claude helps me think through edge cases, consider alternative implementations, and refine my requirements before writing any code. By the end of this phase, I have a clear mental model and a well-crafted prompt ready for code generation.
    • Claude Code Desktop for Generation — With the refined prompt from brainstorming, I switch to Claude Code which has direct access to my codebase. It understands my project structure, existing patterns, and dependencies. The code it generates is contextually aware—it follows my naming conventions, integrates with existing modules, and respects the architectural decisions already in place. I can iterate here too, asking for adjustments or alternative approaches.
    • Cursor for Review — This is my quality gate. I examine every diff carefully, understanding not just what changed but why. Cursor’s interface makes it easy to accept good changes, reject problematic ones, and make surgical edits where needed. This deliberate review process ensures I never ship code I don’t understand. It’s also a learning opportunity—I often discover new patterns or techniques by studying what the AI produced.

    This two-step process forces me to slow down and actually review what the AI produces. It’s easy to fall into the trap of accepting AI-generated code without understanding it. By deliberately switching tools for the review phase, I create a mental checkpoint that keeps me engaged with the code.

    Tips for This Workflow

    1. Be specific with Claude — The better your prompts, the less cleanup you’ll need in Cursor
    2. Review as much as possible — Don’t let the convenience of AI make you lazy about code review
    3. Commit incrementally — Small, atomic commits make it easier to track what the AI contributed
    4. Keep learning — Use the review phase as an opportunity to understand patterns you might not have written yourself

    Final Thoughts

    AI coding assistants are powerful tools, but they work best when you stay in the driver’s seat. My Claude Code Desktop + Cursor workflow keeps me productive while ensuring I remain the decision-maker for every line of code that ships.

    If you’ve been looking for a way to integrate AI into your development process without losing control, give this approach a try. The key is finding the right balance between leveraging AI’s capabilities and maintaining your own understanding of the codebase.

    Thanks for reading. Let me know whether you agree/disagree or have a different take.

  • Once You Go Mac — Should You Go Back?

    Once You Go Mac — Should You Go Back?

    One of my first bosses, on the day I joined the company asked “Why are we using Windows?” as they saw me struggle with setting up a project using Docker on my Windows laptop. The following day I got a MacBook Pro. I thought I would not look back.

    And look back I did. And here I am writing a blog post on a Windows desktop 7 years later.

    As the walled garden kept getting richer, the walls started climbing higher. That is not the issue really. The cost of staying within those walls increased as well.

    By December 2025, I caved in and got a Nothing Phone. Boy do I love a nice clean Android phone.

    Shortly after, I realized what started with an innocent Mac purchase had sucked me in deep in to the ecosystem. Time to get in control, I decided.

    That was when I realized I suddenly wanted a PC. In this economy, you may ask. Well, several friends advised that it is better to get it TODAY than to wait another day. So, by the last week of December, I went and purchased a PC with 32GB memory and a GeForce 5060 TI Graphics with 8GB video memory. Plan is to try and run some local LLMs and hoping it speeds up development work.

    Now, Should You Go Back?

    I am still seeing some issues around npm modules installing on Windows. Either that or I need to figure how to do it the Windows™ way.

    At this point in time, I am giving myself a few months – iPhone on left pocket and Android on the right. MacBook on the desk and a Windows tower on the ground. Hoping to go like this and see where it takes me.

    Here are my past writing on this topic:

    Let me know your thoughts on the whole ecosystem war!

  • Why I Still Bet on WordPress

    Why I Still Bet on WordPress

    Every few months, someone declares that WordPress is dead.

    I keep building outside it — and still coming back.

    Not because I’m stuck.

    Not because I don’t know better tools.

    But because after a decade of shipping real products, WordPress continues to win in places most comparisons ignore.

    Yes, I’ve built outside WordPress

    I’ve pulled Gutenberg out of WordPress entirely to build editor experiences. I’ve shipped headless setups where WordPress is nothing more than a content API. I’ve built React applications that never touch PHP. I’ve worked on projects where WordPress would have been the wrong choice — and I knew it.

    I’m not betting on WordPress because it’s all I know.

    What I got wrong about headless & decoupled frontends

    For a long time, I believed headless and fully decoupled frontends were the inevitable future — and not without reason. I chased cleaner architectures, React-first workflows, and the promise of total flexibility. In many cases, they delivered exactly that.

    What I got wrong was treating this approach as a default instead of a tool.

    The hidden cost wasn’t performance or technical complexity — it was friction. Previews broke. Editorial workflows slowed down. Simple changes required deploys. Teams gradually lost autonomy in ways that were easy to ignore at first.

    Headless isn’t the problem; uncritical adoption is. Over time, I learned that most projects don’t need maximum flexibility. They need reliability, ownership, and a stack that doesn’t fight back.

    That realization is a big part of why I still bet on WordPress today.

    What Gutenberg quietly got right

    Gutenberg’s value isn’t the editor — it’s the architecture underneath.

    Blocks are portable UI contracts. A block defines its structure, its attributes, its allowed variations. That definition travels with the content, not the theme. Switch themes, the content survives. Query blocks programmatically, the structure is already there. This is what years of shortcode chaos never gave us.

    Then there’s the shift toward declarative configuration. block.json and theme.json moved WordPress away from scattered PHP hooks toward predictable, tooling-friendly JSON. You can lint it, version it, generate it. It’s not perfect, but it’s a direction that finally aligns with how modern development works.

    The separation of structure from styling matters more than people realize. Classic WordPress tied content to presentation so tightly that switching themes meant rebuilding pages. Blocks broke that coupling. Structure lives in the content layer; styling lives in the theme. Long-term projects benefit from this in ways that aren’t obvious until year two or three.

    Blocks also scale better than their reputation suggests. Patterns, variations, and InnerBlocks let you build component systems without page builder bloat. Agencies are shipping block libraries now — not plugins full of shortcodes, but composable pieces with real contracts.

    Gutenberg is misunderstood by both its critics and its fans. Critics see it as a slow page builder chasing Elementor. Fans oversell it as a design tool for non-developers. Both miss the point. The real value is that WordPress finally has a content model that isn’t just HTML in a database column. That’s a foundation you can build on for years.

    Why I still bet on WordPress

    At this point in my career, I care less about architectural purity and more about leverage.

    WordPress gives me distribution, mature editorial workflows, and a content model that has finally caught up with modern development. It lets me choose when to decouple, when to go headless, and when to keep things boring — without forcing that decision upfront.

    Most platforms push you toward extremes. WordPress lets you stay in the middle longer, and that’s where most real projects live.

    I don’t bet on WordPress because it’s perfect. I bet on it because it compounds. The skills last. The ecosystem lasts. The content lasts. And with Gutenberg, the architecture finally does too.

  • DIY Breadcrumbs in WordPress with Full Site Editing

    DIY Breadcrumbs in WordPress with Full Site Editing

    Let’s look at how you can use Gutenberg and Full Site Editing to create Breadcrumbs for your WordPress site.

    You would need to install the latest version of WordPress and a plugin that has FSE (Full Site Editing) support.

    You would also require the The Icon Block by Nick Diego.

    Here’s the code. You can copy it and paste it in your Single Post template.

    <!-- wp:group {"layout":{"type":"flex","flexWrap":"nowrap"}} -->
<div class="wp-block-group"><!-- wp:outermost/icon-block {"iconName":"wordpress-home","iconColor":"secondary","iconColorValue":"#0099ff","linkUrl":"/","width":"24px"} -->
<div class="wp-block-outermost-icon-block"><a class="icon-container has-icon-color has-secondary-color" href="/" style="color:#0099ff;width:24px"><svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24" aria-hidden="true"><path d="M12 4L4 7.9V20h16V7.9L12 4zm6.5 14.5H14V13h-4v5.5H5.5V8.8L12 5.7l6.5 3.1v9.7z"></path></svg></a></div>
<!-- /wp:outermost/icon-block -->

<!-- wp:outermost/icon-block {"iconName":"wordpress-chevronRight","customIconColor":"#7e7e7e","iconColorValue":"#7e7e7e","width":"24px"} -->
<div class="wp-block-outermost-icon-block"><div class="icon-container has-icon-color" style="color:#7e7e7e;width:24px"><svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24" aria-hidden="true"><path d="M10.6 6L9.4 7l4.6 5-4.6 5 1.2 1 5.4-6z"></path></svg></div></div>
<!-- /wp:outermost/icon-block -->

<!-- wp:post-terms {"term":"category","style":{"elements":{"link":{"color":{"text":"var:preset|color|secondary"}}}},"textColor":"secondary","className":"text-decoration-none","fontSize":"small"} /-->

<!-- wp:outermost/icon-block {"iconName":"wordpress-chevronRight","customIconColor":"#7e7e7e","iconColorValue":"#7e7e7e","width":"24px"} -->
<div class="wp-block-outermost-icon-block"><div class="icon-container has-icon-color" style="color:#7e7e7e;width:24px"><svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24" aria-hidden="true"><path d="M10.6 6L9.4 7l4.6 5-4.6 5 1.2 1 5.4-6z"></path></svg></div></div>
<!-- /wp:outermost/icon-block -->

<!-- wp:post-title {"style":{"typography":{"fontStyle":"normal","fontWeight":"400"},"color":{"text":"#4a4949"}},"fontSize":"small"} /--></div>
<!-- /wp:group -->

<!-- wp:separator {"style":{"color":{"background":"#a8a8a8"}},"className":"is-style-wide"} -->
<hr class="wp-block-separator has-text-color has-alpha-channel-opacity has-background is-style-wide" style="background-color:#a8a8a8;color:#a8a8a8"/>
<!-- /wp:separator -->

    Once copied and saved, the frontend of the template would look something like this:

    Enjoy!

  • Add Multiple Products to WooCommerce Cart at Once

    Add Multiple Products to WooCommerce Cart at Once

    We were working on a WooCommerce project that required us to add multiple products to the cart from a single click of a button.

    We wanted a solution from the JavaScript side, and we came up with the following code. This should fire when the “add to cart” button is clicked:

    const productsToAdd = [
        { 'add-to-cart': 68, 'quantity': 2 }, // 68 is Product ID
        { 'add-to-cart': 69, 'quantity': 3 },
        { 'add-to-cart': 70, 'quantity': 4 }
    ];

    for (const product of productsToAdd) {
        try {
            const response = await fetch(window.location.pathname, {
                method: 'POST',
                body: new URLSearchParams(product),
                headers: {
                    'Content-Type': 'application/x-www-form-urlencoded'
                }
            })
            if (response.ok) {
                console.log('Product added to cart:', product['add-to-cart']);
            }
        } catch (e) {
            console.error(e);
        }
    };

    Here’s a gist that contains the solution.

  • WP REST API can still cut it

    WP REST API can still cut it

    Most developers have used an API (and more specifically the REST API) in some point in their careers; and a WordPress developer is no exception. We may have used the WordPress REST API for fetching data from a remote WordPress instance, or update some record somewhere with authentication or to create a Headless WordPress site. Perhaps we simply used it within a Gutenberg block.

    GraphQL is an alternative to the REST API, and also a great technology. However, using GraphQL with WordPress requires the installation of a new plugin. If you are using GraphQL to merely solve the under-fetching/over-fetching problem for basic queries, you might want to continue reading this post.

    WP REST API 101

    The easiest way to play with the WP REST API is to visit any WordPress site’s URL followed by /wp-json. I’d recommend a REST client like Postman or Insomnia. In case you do not download these apps, you can visit the URL on your browser. If you go this route, however, I’d recommend an extension to view JSON data. You can find them on your Browser’s extensions library. Taking this site as example, let’s say you visit the following URL:

    https://muhammad.dev/wp-json

    You will get a huge chunk of JSON data. There will be multiple namespaces. I’d recommend you go explore the the WP namespace first:

    https://muhammad.dev/wp-json/wp/v2

    You will get the endpoints inside of the core WP namespace. Let’s look at the latests posts:

    https://muhammad.dev/wp-json/wp/v2/posts

    Solve over-fetching using _fields

    If you followed the last link, you would have seen a bunch of fields for the latest 10 posts. Let’s say you only need the title, and excerpt. Here comes the key part: you use the _fields URL parameter to limit the fields to just what you want:

    https://muhammad.dev/wp-json/wp/v2/posts?_fields=title,excerpt

    The above will only return the posts’ titles and excerpts. This would reduce the load time significantly since it’s much less data as compared to retrieving the entire dataset from the posts endpoint.

    Get the full categories, tags, and featured image

    Another “limitation” with the REST API is that you cannot see the name or slug of the attached category or tag for a post if you go to the /posts endpoint.

    The solution to this is to pass the _embed param to the URL.

    https://muhammad.dev/wp-json/wp/v2/posts?_embed

    The above will give you the terms (categories, tags) used for the posts. Additionally, you will also get the featured image details for the give post. This will save you from making multiple calls to the remote endpoint, thus saving time and money.

    Although this is not a full-on nested call like you can do with GraphQL, this is good enough for a lot of use cases.

    A note on using _fields and _embed

    As you try to use these tips, you would be tempted to use both the _fields and _embeds params in one call. You will notice that it is not possible to do so.

    When I tried the above scenario, it returned empty results. So, I followed this solution StackOverflow to get over this roadblock.

    TLDR;

    Perhaps you are discouraged from using the WP REST API because it fetches fields you do not need. Perhaps it is because the results do not contain the featured image URL or the category/tag name and slug. If so, then you might want to consider sticking to the REST API before looking elsewhere.

  • New to WordPress Development? Here’s a 2025 Guide!

    New to WordPress Development? Here’s a 2025 Guide!

    Precursor

    Let me start with a personal take.

    I started dabbling with WordPress 10 years ago in 2015.

    In that period, there have been changes several changes. Still, there have also been things that have stayed the same.

    I’ve learned an important trick; to develop foresight, you need to practice hindsight.

    Jane McGonigal

    Let’s focus on the fundamentals, first – the things that stood the test of time and will do in future.

    We can use WordPress for many purposes. It can serve as a tool builder, like a resumé maker. It can also be a platform or even a billboard. Nevertheless, the fundamental reason we use WordPress is for content.

    When we say content, it can mean many things – including Instagram reels or TikToks. However, with WP, content primarily means the written word. That’s what I believe the Word in WordPress stands for.

    Although, we can upload and embed videos and images, the power of words is what makes WordPress, well, powerful.

    So, it is a Content Management System as its core.

    The Foundations

    Now that we know what WordPress is (a CMS), let’s dive into what you need to learn to become a developer in the short term.

    By near term, I mean a quarter of a year. Let’s say you start now; you could hopefully become a Junior WordPress Developer by June 2025.

    These are the tools you need to master to get going:

    1. An understanding of the WordPress basics. What is a post and how does it differ from a page? What is a post type? What is a taxonomy? How do I change a theme or install a plugin? And so on.

      There is an endless list of questions you may have as you follow through. I recommend you befriend your friendliest AI tool to ask questions and get clarity.
    2. A Development Environment. Avoid working on projects without a dev environment if you can. Do not work on projects with just a single production site where all the work happens. I also recommend having a local WP environment. This way, all your development work is on your computer. You can do this while you are working. LocalWP and Studio by WP.com are both great for beginners.

      Think of it this way. Would you be doing carpentry at the location of your customer or at your work shed? I would do it at my work shed or a home office shed (remote work FTW). So, let’s use a local development environment.
    3. Basic Web Development. I would say you should possess the basics of HTML, CSS, and JavaScript. I am not a purist, so w3schools.com is a good resource for learning that. If you happen to be a purist, head over to mdn!
    4. Some backend knowledge. It is also good to know some PHP and MySQL. Or even the basic syntax and ideas are sufficient.

      Again, ChatGPT is your friend. Pester it with your questions and test yourself against it.

    Intermediate

    Now, we are getting to where most developers should get to. However, a lot of them will take a false path. Others will stop with the foundations. For instance, they will still use the Classic Editor. They will rely solely on a Page Builder. They will also stick to store bought themes and plugins without considering any customizations.

    WordPress Hooks (filters and actions) 🪝 are an important part of advancing as a WordPress developer. It’s crucial we learn it right – and practice it.

    Gutenberg was merged to core in 2018 and there has been a mixed reaction from the community. I believe it is about time (albeit a bit too late) to embrace the block editor with both arms.

    There are so many terms when it comes to the block editor. But keeping abreast of the nuances pays off handsomely in the long run.

    With that said, let me throw some words:

    1. Blocks – they can be core or custom
    2. Block Patterns
    3. Block Filters
    4. Block Styles
    5. Block Variations
    6. Block Plugins
    7. Block Themes and Full Site Editing
    8. Block Templates
    9. Reusable Blocks
    10. Dynamic Blocks – as opposed to Static Blocks

    I do not want to explain here what each means. Nor do I want to be considered an expert in critiquing the decisions that went into its nomenclature. You could learn a ton about these from fullsiteediting.com or through Google / ChatGPT.

    You can also learn from wpdevelopment.courses. Please note, it is a paid resource and I am a student of the course. The course helped me a ton to level up in block theme development. And no, I am not being paid to say this.

    ES2015+ or ES6 is also a decade old now. And React is 12 years old now; almost a teenager. The reason I mention it is so that we are aware its about time we learned these. So along with learning Gutenberg, it’s essential to also learn modern JS.

    Of course, here comes the other essentials like security best practices. Escaping, Sanitizing, Validating – the whole nine yards.

    An excellent resource is WPVIP’s course on security.

    It could take a year or more to get comfortable at this.

    Advanced

    You are in the big boy league now.

    It can take a several years to become great at WordPress.

    Courses from here are great to get good at some advanced WP concepts.

    Also, feel free to go through these best practices.

    The best way to become great, in my opinion, is to go through the works of the best people in the industry.

    For example, reading through WP Core or Gutenberg Core’s code on GitHub, perhaps reading through a major plugin’s code like Google Site Kit, or by contributing to core and other open source software yourself.

    An obvious way to get advanced is by working on large site rebuilds or plugins that touch many sites and has great impact.

    Closing Thoughts

    Do not forget about the community.

    You would be doing yourself a great favor by participating in dialog with the WordPress community, over on Twitter or at local events such as Meetups and WordCamps. A friend I made at a meetup 10 years ago is my almost like a mentor now!

    Of course, when you get to the advanced level, it’s good to contribute back to WordPress in the form of code, events, teaching, encouraging, documenting, organizing, volunteering, and so on.

    So, how do I get started?

    It depends on what you want to achieve with WordPres.

    If I were to give you one call to action, it would be that you register as a member of WordPress.org – you will hopefully look back and thank yourself that you did so.

    The more important CTA, however, is to head over learn.wordpress.org and choose your path!

    Closing Thoughts

    I initially set out to write about the WordPress ecosystem—the so-called bubble where outsiders often dismiss WordPress developers as “not real developers.” Instead of merely highlighting a problem, I decided to offer a solution: a practical roadmap to becoming a proficient WordPress developer. I hope this approach provides real value and inspires you to embrace the journey ahead.

    Thank you for reading this far.

  • Siri-controlled DND 🎧 for my office room

    Siri-controlled DND 🎧 for my office room

    Pausing notifications on your phone is great. The iPhone’s Do Not Disturb (DND) feature is also great. Would it not be awesome if we had a DND for our room/office? Well, that was when I had an idea for a mini project.

    My nephews and I went to a local electronics store and bought some gadgets. I just bought the ESP32-C3, which has two USB-C ports.

    These were the steps I did in order. Of course, ChatGPT helped me every step of the way.

    1. I ensured the ESP32 was working by running a blinking sketch, which I created using Arduino IDE.
    2. I then created an on-off switch using the BOOT button on the ESP32. This would turn the LED to switch between Green and Red alternatively each time you press the BOOT button the the microcontroller.
    3. Then I connected the ESP32 to Blynk.
    4. Once it was connected to Blynk with the token, etc. I used three links:
      • One would turn the Green light on when a GET request is sent to it.
      • The other would turn the Red light on when a request was sent to it.
      • The third one would give the current status of the light.
    5. Then I did some configurations using Siri Shortcuts. They were:
      • Office Green: which would essentially visit the above link I spoke about followed by turning off Do Not Disturb on the iPhone/Apple Watch.
      • Office Red: which would essentially visit the second link above, followed by turning on Do Not Disturb on the iPhone/Apple Watch.
      • Office Switch: this would get the current status of the light. If the currentStatus was 1, it would run Office Green, otherwise it would run Office Red.

    The end result was something like this:

    In case you have any inspiring ideas for such projects, feel free to build on it and share to the world!

    If you find this post inspiring, I have done my job. If you asked yourself why not just close the door instead of this contraption? Well, then you have done your job of critical thinking.

    Cheers!

  • Create a “mini-app” using Core Gutenberg Blocks and some JavaScript

    Create a “mini-app” using Core Gutenberg Blocks and some JavaScript

    While it’s tempting to reach out to build a custom block every time you need custom functionality, it may not always be the best decision. Before committing to developing a custom block, it’s essential to evaluate the needs of your website.

    Custom blocks can offer flexibility and can provide a precise set of features tailored to your content. They can integrate with your site’s unique design system and provide custom experiences that generic blocks cannot. However, developing custom blocks requires time, expertise, and resources.

    You can use the core blocks alongside Gutenberg filters to customize its looks or behavior. You can also use block variations to create a slightly different way of utilizing the same core blocks. Or, if you want to change the look of the core blocks, you could employ block styles to achieve it.

    Having said all that, what if your requirements differ from the above? What if you want the flexibility of creating using the block editor, utilizing any color and style you want? But you also need to make that bit of HTML you built behave precisely how you want.

    The following is my take on using core blocks with some custom JS sprinkled on them to create a mini-app.

    Demo

    This is a Stopwatch mini-app that uses some blocks and JavaScript. You can play around with its functionality:

    00:00:00:000

    Start
    Pause
    Reset

    Now, let’s explore how I built this.

    The Blocks Used

    In this website, I use the Twenty Twenty Four theme.

    The above demo uses the following blocks:

    1. Group
    2. Stack (a variation of the Group block)
    3. The Icon Block by Nick Diego (not compulsory but used for aesthetics)
    4. Heading
    5. Row (a variation of the Group block)
    6. Buttons and the Button block

    The code for it looks like this (you may copy it to your WordPress site as you wish):

    https://gist.github.com/m-muhsin/d20b21c3765e5b913cd39b05a54b89b4

    You might notice I have used a few class names. This is so that I can use JavaScript to select those elements.

    After adding the above HTML and Block markup into this post, I wanted to add some JS.

    So, I used the Custom HTML block and added the following JS code to it within <script> tags.

    https://gist.github.com/m-muhsin/a685d5bed947020407dc802ecc0ffe4c

    That’s about it really!

    Some thoughts

    This idea that I presented is familiar in the WordPress world. We have used HTML generated using the classic editor coupled with enqueued JavaScript to power up custom experiences for ages.

    Also, this idea is excellent for when we need to add Google Analytics scripts, for example. We can have buttons with a certain class name and use a global script to target all those buttons to then add tracking scripts to them.

    Hope this small demo and explanation helps anyone out there!

  • What Makes up a Gutenberg Developer?

    What Makes up a Gutenberg Developer?

    Summary: This article explores what it means to be a Gutenberg Developer in the WordPress ecosystem. You’ll learn about Gutenberg’s evolution from a plugin to WordPress core, its four development phases, and how it has become the de facto page builder for WordPress. We’ll break down the essential skills needed—a blend of WordPress, React, and frontend development expertise—and provide resources, courses, and actionable steps to help you start your journey as a Gutenberg Developer.

    This article contains 3 things:

    1. A brief introduction to Gutenberg and its purpose of existence
    2. Introducing the Gutenberg Developer and their skillset
    3. How to become a Gutenberg Developer

    Gutenberg, which started off as the codename for the new WordPress Block Editor has been used to define many things. The new editor has been built to replace the previously used TinyMCE editor which has been in WordPress for a long time. Gutenberg started off as a plugin and was merged into WP core in WordPress 5.0 which was 5 years ago. Time flies, right?

    Coming back to the point. Gutenberg has been used to define the following items:

    1. The plugin that was built to replace the “Classic Editor” also known as the TinyMCE editor. Unfortunately, it has a very low rating on the WordPress plugin repository. As a developer, it’s difficult to understand the hate for this plugin, but it is what it is.
    2. The “content editor” which replaced the post/page editor which was using TinyMCE.
    3. The Full Site Editor also known as the “site editor”.

    Now, Gutenberg has 4 phases:

    1. Content Editing, which was started in 2018 with WP 5.0
    2. Site Customization, which started last year with WP 5.9
    3. Collaborative Editing which is being worked upon
    4. Multilingual Support which is scheduled next

    Replacement for page builders?

    Although it did not start off as as replacement for page builders when first released, it has become so. Since the site editor allows you to replace every bit of the site using blocks, isn’t Gutenberg essentially another page builder? That’s what I believe so. It’s not “just another” page builder. But it is the de facto page builder that is built by the team building WordPress core. In other words, if you want to use the default way of page building / site building, you are best off choosing Gutenberg,

    Atomic in nature?

    Another important point we must realize is that Gutenberg has atomized the aspects of site building. The idea is that the site is broken down into smaller and smaller pieces of blocks until you get to the smallest “single block”.

    A group of blocks can be categorized as the following:

    1. Block Pattern (synced and unsynced)
    2. Block Template Parts
    3. Block Themes

    I first saw this idea in WordPress, but other CMSs (primarily Headless CMSs) also have adapted this idea of slicing up the site into atomic pieces or blocks (as referred to in WordPress).

    Gutenberg Developer 101

    This is a popular job role within the WordPress space. It is still a hot and trendy job title although it’s been over 5 years since we first heard of Gutenberg. So, what makes up a Gutenberg Developer? Let’s find out!

    I created this Venn Diagram to represent what I believe makes up a Gutenberg Developer.

    It essentially comprises of the skills of the following 3 job roles:

    1. WordPress Developer
    2. React Developer
    3. Frontend Developer

    You might think that’s a lot of things to learn just to be able to do one job role. Well, that is not the case so!

    How do I say that?

    For example, if you have rudimentary WordPress skills, but are very good at React, you can still do a lot by reading about the Gutenberg documentation and learning the WP REST API as well as brushing up on CSS.

    If you are a WordPress expert, but have basic React skills, that’s more than enough. Because building blocks requires little React knowledge to get started.

    Likewise, if you are a frontend developer strong in CSS and JS, you might have to learn some React and the WordPress knowledge necessary to build blocks or a block theme.

    In other words, you do not need to ace all 3 of these roles just to be able to build with Gutenberg.

    So, what skills do you need to get there?

    Gutenberg Developer skills

    Matt Mullenweg said in 2015, “Learn JavaScript Deeply”. It still stands true. You need to know JavaScript. I believe most WordPress developers and Frontend Developers already know JS. React Developers definitely know it since React is a JS library.

    Apart from JS knowledge you might need these core skills to work with Gutenberg:

    1. React
    2. Some basic build config knowledge like webpack and friends
    3. PHP
    4. HTML + CSS
    5. JSON

    How do I learn to become a Gutenberg Developer?

    There a few aspects to becoming a Gutenberg Developer.

    For example, you can build individual blocks or be able to build block themes, or plugins that house multiple blocks to solve specific problems.

    For example, the Jetpack plugin uses an array of blocks to solve niche problems with content creation. Twenty Twenty Four is an example of a block theme – a theme built entirely out of blocks.

    There are a few resources I can recommend to learn these:

    1. Gutenberg Blocks for WordPress and React Developers by Ali Alaa – this is a great course for someone who has knowledge of React and WordPress but wants to speed up their learnings with block building.
    2. The Block Theme Academy by Fränk Klein – this is an awesome set of courses to be able to build out block themes, the right way.

    I have taken both these courses and have found them to be very helpful.

    Getting a job as a Gutenberg Developer

    There are many companies hiring for this role. WordPress development agencies look for these folks with this skillset as they need to build client sites and apps that make use of Gutenberg.

    So are product companies looking for these roles. Product companies need to “blockify” their products sooner or later. If their products do not play nicely with the block editor, it could mean death to their product as more and more users adopt the new block editor and move away from the Classic Editor.

    Theme shops also need Guetenberg Developers as they start to replace classic themes with either hybrid themes or block themes.

    Mindset of a Gutenberg Developer

    As Gutenberg Developers, we need to think of future/modern WordPress sites as pieces of a blocks inside blocks inside blocks, up until we reach a single block.

    What makes up a block? They can be made using PHP or JS. The editor side is mostly written using React. The frontend uses a React-like structure, but is not, in fact, React that powers it. It gets serialized to HTML. You can also use PHP to replace the frontend code, which I quite like because of the power of PHP within the context of WordPress. I will stop here because speaking at length about this topic is cannot be covered in a single blog post.

    Having said that, it’s important to decide which language to use where. You can even use React by enqueueing it to the fronend and make use of its dynamic nature to build complex UIs. However, it’s better to use PHP and vanilla JS as much as possible before reaching out to React for the frontend.

    Here is an architecture diagram of a block:

    It looks quite complex to understand. But you will soon realize how it works once you start working with it.

    Some helpful resources

    Here are some resources that can help you start off in this journey:

    1. WordPress Builders playlist by WP Engine Builders YouTube channel
    2. Block Editor Handbook as a reference point
    3. Jamie Marsland’s YouTube channel
    4. Tutorials by Bill Erickson
    5. The writings of Rich Tabor
    6. The works of Nick Diego

    So, you want to become a Gutenberg Developer?

    If you have read up to this point and want to become a Gutenberg Developer, here are some steps you can take:

    1. Learn as much as possible from the courses and resources listed above.
    2. Build out a simple block using block.json. This is a helpful tutorial.
    3. Build more blocks!
    4. Build out a basic block theme
    5. Apply for jobs
    6. ???
    7. Profit

    Let’s keep in touch!

    I hope you found this piece helpful. Let me know if you’d like me to cover another similar topic, or something else you’d like to read!

    If you have questions about blocks or block themes or want to get in touch with me, feel free to reach out! I am also active on X and LinkedIn if you want to follow me over there. I also provide consultancy as a Gutenberg Developer, so feel free to get in touch!

    Shoutout: If you’re looking for reusable Gutenberg components and blocks to speed up your development workflow, check out useReuse.com – a great resource for Gutenberg developers!