Category: wordpress

1. Enhanced Full Site Editing (FSE) and Block-Based Evolution

• Trend: Full Site Editing, built on the Gutenberg block editor, will become the standard for WordPress site creation. FSE allows users to customize every aspect of a website (headers, footers, templates) using blocks, reducing reliance on coding.
• Prediction: By 2025, block-based themes will largely replace traditional themes, offering modular, dynamic designs. Expect more block patterns, reusable templates, and intuitive design tools, making website creation accessible to non-developers.
• Impact: This democratizes web design, enabling small businesses and individuals to build professional sites without technical expertise, while developers benefit from streamlined workflows.

2. AI Integration

• Trend: Artificial intelligence is already influencing WordPress through plugins for content generation, SEO optimization, and chatbots.
• Prediction: By 2025, AI will be deeply integrated, offering:
  • Content Creation: AI-driven plugins will suggest topics, headlines, and full articles based on user behavior and trends.
  • SEO: Real-time AI tools will optimize content for search engines, focusing on voice search and long-tail keywords.
  • Design: AI will recommend layouts, color schemes, and personalized user experiences.
  • Automation: AI will handle backend tasks like updates, backups, and security monitoring.
• Impact: AI will make WordPress more efficient, reducing manual work and enhancing personalization, though it may challenge users to keep up with rapidly evolving tools.
• Example: Recent posts on X highlight WordPress’s launch of a free AI website builder, indicating early steps toward AI-driven site creation. (Note: This is not conclusive evidence but reflects sentiment.)

3. Headless WordPress and Omnichannel Flexibility

• Trend: Headless WordPress, where the backend (content management) is decoupled from the frontend (display), is gaining traction. It allows developers to use modern frameworks like React or Vue.js for faster, custom frontends.
• Prediction: By 2025, headless setups will become more accessible, supported by third-party services and plugins. This will improve site performance, scalability, and integration with apps, IoT devices, and other platforms.
• Impact: Businesses will deliver consistent experiences across websites, mobile apps, and wearables, but non-technical users may require developer support for headless setups.

4. E-Commerce Growth with WooCommerce

• Trend: WooCommerce, powering 39% of e-commerce sites, continues to dominate.
• Prediction: By 2025, WooCommerce will integrate AI for personalized shopping (e.g., product recommendations) and headless e-commerce for faster load times. Enhanced multilingual and currency support will boost global reach.
• Impact: WordPress will solidify its position as a leading e-commerce platform, competing with Shopify and others, especially for small to medium businesses.

5. Improved Security

• Trend: As a major target for cyberattacks, WordPress is prioritizing security.
• Prediction: By 2025, expect:
  • AI-Powered Security: Real-time threat detection and neutralization.
  • Blockchain: Secure data storage and transactions.
  • Zero Trust Architecture: Mandatory authentication for all users/devices.
  • Default 2FA and Automated Updates: Enhanced protection against vulnerabilities.
• Impact: Stronger security will maintain user trust, though users must adopt best practices like regular updates.

6. Mobile-First and Performance Optimization

• Trend: With 58% of global web traffic from mobile devices, mobile optimization is critical.
• Prediction: WordPress will prioritize mobile-first themes, plugins, and designs, alongside performance tools to reduce load times. Sustainable web design (e.g., energy-efficient hosting) will also gain traction.
• Impact: Improved mobile experiences and faster sites will boost SEO rankings and user engagement.

7. Multilingual Support and Global Expansion

• Trend: WordPress’s roadmap includes native multilingual support as part of Gutenberg’s final phase, expected by 2024–2025.
• Prediction: AI-powered translation tools and native multilingual features will make WordPress more accessible globally, increasing its user base in non-English-speaking regions.
• Impact: Businesses will reach diverse audiences, strengthening WordPress’s global dominance.

8. Community and Open-Source Strength

• Trend: WordPress’s open-source nature and community of developers, designers, and enthusiasts ensure its resilience. The “Five for the Future” initiative encourages contributions.
• Prediction: The community will drive innovation, with more contributors improving documentation, plugins, and core features. In-person events like WordCamps will strengthen collaboration.
• Impact: Community support will keep WordPress adaptable and competitive, unlike proprietary CMS platforms.

9. Shift to JavaScript and APIs

• Trend: WordPress is moving toward JavaScript-driven interfaces and REST API integration, reducing reliance on PHP.
• Prediction: By 2025, JavaScript will dominate frontend development, enabling real-time editing (e.g., Google Docs-style collaboration) and custom dashboards.
• Impact: Developers will need to upskill in JavaScript, but this shift will make WordPress a robust application framework, not just a CMS.

10. Challenges and Competition

• Challenges:
  • Market Share Fluctuations: Recent data shows slight declines (e.g., 42.9% in June 2022 vs. 43.3% in March), though WordPress remains dominant.
  • Complexity: Features like headless setups and AI may overwhelm non-technical users.
  • Community Drama: Issues like the 2024 WP Engine lawsuit and forks (e.g., by major hosts) could fragment the ecosystem, though their impact is expected to be minimal.
• Competition: Platforms like Wix and Squarespace offer simpler interfaces, but WordPress’s open-source flexibility and community keep it ahead.
• Prediction: WordPress will maintain its lead by simplifying user experiences and leveraging its community to innovate.

11. Release Strategy

• Trend: WordPress announced a shift to one major release per year starting in 2025, with regular maintenance and security updates.
• Impact: This allows more focus on significant updates (e.g., multilingual support) while ensuring stability.

Critical Perspective

While WordPress’s dominance is likely to continue, its success hinges on balancing innovation with usability. The shift to AI and headless setups risks alienating non-technical users unless paired with intuitive interfaces. Community disputes, like the WP Engine lawsuit, highlight governance challenges, but the open-source model mitigates risks of fragmentation. Competitors may gain ground if WordPress doesn’t address complexity, but its ecosystem’s depth—plugins, themes, and community—remains unmatched. The narrative of WordPress as “king” can overshadow legitimate criticisms, like Gutenberg’s initial flaws, but its iterative improvements show responsiveness to feedback.

Conclusion

By 2025, WordPress will evolve into a more powerful, AI-enhanced, mobile-first, and globally accessible platform, doubling down on its strengths as an open-source CMS and application framework. Full Site Editing, headless setups, and WooCommerce advancements will cater to diverse needs, while security and performance improvements will maintain trust. The community’s passion, as seen in record WordCamp contributor days, ensures WordPress’s longevity. For users, staying updated with plugins, themes, and skills (e.g., JavaScript) will be key to leveraging its potential. WordPress is not just surviving—it’s poised to thrive, potentially for a century, as co-founder Matt Mullenweg envisions.

If you’d like deeper insights into specific aspects (e.g., AI plugins, developer skills, or e-commerce), let me know!

Babel is a JavaScript compiler that converts modern JavaScript (ES6+) into backward-compatible JavaScript (ES5). This ensures compatibility across a wide range of browsers, including legacy ones like Internet Explorer 11, which is critical for WordPress themes and plugins serving diverse user bases.

Why Babel Matters for WordPress Developers

WordPress powers sites accessed by users on various browsers, from modern Chrome to older systems. When developing custom themes, plugins, or Gutenberg blocks, Babel enables developers to:

• Write modern JavaScript (e.g., arrow functions, classes, import statements, async/await) for improved productivity and code clarity.
• Ensure compatibility with older browsers by transpiling modern code into widely supported ES5.

Example

Without Babel (ES6+ code):

const greet = () => console.log('Hello, World!');

Older browsers may fail to parse this.

With Babel (transpiled to ES5):

var greet = function() { console.log('Hello, World!'); };

Compatible with virtually all browsers.

Integrating Babel into a WordPress Workflow

Babel is commonly paired with Webpack in WordPress development, particularly for:

• Gutenberg block development using @wordpress/scripts.
• Custom themes or plugins leveraging modern JavaScript.
• Headless WordPress setups requiring optimized front-end code.

Setup Overview

1. Install Dependencies:

   npm install --save-dev webpack webpack-cli babel-loader @babel/core @babel/preset-env

2. Configure Babel (babel.config.js or .babelrc):

   module.exports = {
     presets: [
       [
         '@babel/preset-env',
         {
           targets: {
             browsers: ['> 1%', 'last 2 versions', 'ie >= 11'],
           },
         },
       ],
     ],
   };

The @babel/preset-env preset automatically determines necessary transformations based on your target browsers.

3. Configure Webpack (webpack.config.js):

   module.exports = {
     module: {
       rules: [
         {
           test: /\.js$/,
           exclude: /node_modules/,
           use: 'babel-loader',
         },
       ],
     },
   };

4. Write Modern JavaScript:

   import { __ } from '@wordpress/i18n';

   const MyComponent = () => {
     console.log(__('Hello from a Gutenberg block!', 'text-domain'));
   };

Babel ensures this code is transpiled for broad compatibility.

Practical Application: Gutenberg Blocks

The @wordpress/scripts package, commonly used for Gutenberg block development, leverages Babel and Webpack to:

• Transpile ES6+ and JSX into browser-compatible JavaScript.
• Bundle assets into a single file (e.g., /build/index.js).
• Allow developers to enqueue the resulting script in WordPress:

   wp_enqueue_script(
     'my-block',
     plugins_url('build/index.js', __FILE__),
     ['wp-blocks', 'wp-element', 'wp-editor'],
     filemtime(plugin_dir_path(__FILE__) . 'build/index.js')
   );

Key Benefits for WordPress Development

Feature	Benefit
JavaScript Transpilation	Write modern ES6+ code while supporting legacy browsers.
Integration with Webpack	Streamline asset bundling for themes, plugins, or blocks.
Used in @wordpress/scripts	Simplifies Gutenberg block development with preconfigured tools.
Customizable Configuration	Target specific browsers via .babelrc or babel.config.js.

What is theme.json?

theme.json is a special file used in WordPress block themes to control the design of your site, like colors, spacing, fonts, and more — all without touching CSS or PHP.

What is Typography (Font Family)?

Typography refers to how text looks on your website. A font family is just the name of a group of fonts, like "Arial, sans-serif" or "Roboto".

Where do you add fonts in theme.json?

You add fonts in this section:

"settings": {
  "typography": {
    "fontFamilies": [ ... ]
  }
}

Each font entry looks like this:

{
  "fontFamily": "Arial, sans-serif",
  "slug": "arial-sans",
  "name": "Arial"
}

• fontFamily: the actual font (like in CSS)
• slug: a unique ID used in the background
• name: what shows in the WordPress editor

The WordPress content management system has undergone a significant architectural evolution with the Gutenberg project and Full Site Editing (FSE). This shift marks a transition from traditional “Classic Themes” to modern “Block Themes.” This evolution presents WordPress developers, agencies, and site administrators with a crucial choice: stick with the proven reliability of Classic Themes or embrace the enhanced flexibility and future-oriented architecture of Block Themes.

This analysis dissects the fundamental differences between WordPress Block Themes and Classic Themes across several critical dimensions to help technically knowledgeable WordPress professionals make informed strategic decisions.

WordPress Block Themes and Full Site Editing (FSE)

Block Themes represent a fundamental departure from traditional theme structures, using “blocks” to construct all parts of a website, including headers, footers, content areas, navigation menus, sidebars, and templates. These themes are intrinsically linked to Full Site Editing features progressively introduced into WordPress core.

Full Site Editing is the umbrella term for features enabling users to edit their entire website using the block editor interface. Block Themes are required to unlock FSE capabilities, most significantly the Site Editor. Activating a Block Theme makes the Site Editor available, often replacing traditional interfaces like the Customizer and Widgets screen.

Architecturally, Block Themes differ significantly from their predecessors. Instead of relying on PHP files for HTML rendering, their templates are constructed using HTML files located in dedicated /templates and /parts directories. These HTML files contain structured block markup that WordPress parses to render the site structure. PHP remains available via functions.php, but its role is diminished.

Central to Block Theme architecture is the theme.json file, acting as a “single source of truth” for defining global settings and styles. It controls aspects like layout widths, color palettes, typography scales, spacing presets, available editor features, and default block styles.

The Site Editor is the primary interface for interacting with a Block Theme’s structure and appearance. Accessible via Appearance > Editor, it provides a visual environment for editing templates, template parts, site-wide styles, navigation menus, and pages.

FSE introduces “Theme Blocks” designed to pull in site or post-specific data, replacing traditional PHP template tags. Examples include Site Title, Site Logo, Post Title, Post Content, Navigation, and Query Loop blocks.

Block Themes signify an architectural transition from server-side PHP template execution towards a declarative, component-based model using structured HTML markup and centralized JSON configuration. This democratizes website design, potentially lowering barriers for users without coding expertise to make significant site-wide changes.

Traditional WordPress Themes (Classic Themes)

Classic Themes represent the established method of structuring WordPress site appearance prior to FSE adoption. They are built primarily using PHP files organized according to the WordPress template hierarchy, which dictates which file WordPress uses to render different site views.

The architecture revolves around PHP template files containing a mix of HTML markup and PHP code. The functions.php file acts as a theme’s plugin for essential setup tasks like registering navigation menus, widget areas, enqueuing stylesheets and scripts, and implementing custom functions. Presentation is controlled via CSS stylesheets.

The WordPress Customizer has historically been the primary interface for modifying Classic Theme appearance without editing code. It provides a live preview alongside controls for adjusting theme-defined options. Common Customizer sections include Site Identity, Colors, Background Image, Menus, and Widgets.

Widgets are modular blocks of content or functionality added to predefined “widget areas” within the theme’s layout. These areas are registered by the theme in functions.php and managed via the Widgets screen or Customizer.

Many Classic Themes provide dedicated Theme Options pages offering additional settings and configurations specific to that theme, outside the standardized Customizer interface.

“Hybrid Themes” have emerged as a transitional category. These are essentially Classic Themes incorporating certain Block Theme features, such as using theme.json to enhance styling options for the block editor content area. However, they still fundamentally rely on PHP templates and typically use the Customizer as the main configuration interface.

Classic Themes benefit from a long history and mature ecosystem, with extensive documentation, vast libraries of existing themes and plugins, and widespread familiarity among PHP-proficient developers. While Block Themes represent WordPress’s future direction, the stability and significant investment in Classic Themes ensure their continued relevance, particularly for legacy websites or PHP-centric development teams.

Comparative Analysis: Customization and Control

Scope of Customization

A fundamental divergence between theme types lies in the scope and granularity of customization they afford end-users.

Block Themes provide comprehensive control over virtually every site element through the Site Editor interface. Users can visually manipulate headers, footers, sidebars, navigation menus, and templates defining the layout for different content types. Global styles affecting typography, colors, and spacing can be managed centrally. This extends the editing paradigm previously limited to content areas to the entire site canvas, allowing direct structure modification without coding.

Classic Themes typically offer customization within more constrained boundaries. The primary avenues for user customization are the WordPress Customizer, widget areas, and sometimes theme options panels. While these tools can offer significant flexibility, they generally provide options to tweak existing elements rather than allowing fundamental template restructuring. Modifications beyond the provided options typically require direct code edits or child themes.

This difference reflects a philosophical shift regarding user control. Block Themes democratize site design by making previously developer-exclusive domains accessible through a visual interface. Classic Themes maintain a clearer separation between the theme’s underlying structure and specific user-modifiable settings, providing a more guided experience but limiting the ability to make fundamental structural changes without technical intervention.

Tools and Workflow

The customization tools and workflows differ significantly between theme types.

Block Themes centralize customization within the integrated Site Editor, serving as a hub for editing templates, template parts, styles, navigation, and pages.

Classic Themes utilize a more fragmented set of tools: the Customizer for theme-specific settings, the Widgets Screen for widget arrangement, the Menus Screen for navigation management, and potentially custom Theme Options pages.

Block Themes effectively absorb or replace older tools’ functionality. The Customizer is largely superseded by the Site Editor’s Styles panel, and fixed widget areas are replaced by the flexibility of inserting any block into any template location.

This consolidation represents a significant effort towards a more unified site-building workflow. By bringing template editing, styling, navigation management, and page creation under the Site Editor umbrella, Block Themes provide a more cohesive experience compared to the disjointed process of navigating multiple interfaces in Classic Themes.

Comparative Analysis: Site Building User Experience (UX)

Editing Interface

The site building and editing experience differs markedly between theme types due to their distinct interfaces.

Block Themes offer a highly visual direct manipulation interface through the Site Editor, extending the block-based editing experience to the entire site structure. Users can directly click on elements within a template preview and modify them using familiar block tools. This approach provides a closer WYSIWYG experience for the entire site layout, with strong visual parity between editor and output.

Classic Themes rely on more abstract interfaces. The Customizer presents settings alongside a live preview pane, but users interact with controls that indirectly affect appearance rather than directly manipulating elements. Widget and Menu management occurs in separate, non-visual screens. Content creation is distinctly separate from theme customization tasks.

The core difference is integration and visual directness. Block Themes integrate site structure, style, and content editing within a unified, visually representative environment, reducing the cognitive distance between making changes and seeing effects. Classic Themes maintain separation between content editing and theme customization, often relying on abstract controls across multiple interfaces.

Workflow Efficiency & Learning Curve

Efficiency and learning curves present another contrast area.

Block Themes aim to create a unified workflow by consolidating customization within the Site Editor. However, this introduces concepts like block-based templates, global styles, and block patterns, presenting a steeper initial learning curve, particularly for users familiar with traditional workflows. Once understood, however, tasks like modifying global elements, creating complex layouts, or ensuring design consistency can become more efficient, often without requiring code or external plugins.

Classic Themes benefit from user familiarity. Many long-time WordPress users are comfortable with the Customizer, widget management, and menu screens, making basic customization tasks feel intuitive within theme-defined limits. However, efficiency decreases significantly when customization exceeds built-in options, often requiring PHP/CSS code, child themes, or page builder plugins.

There’s a trade-off between initial ease-of-use and long-term flexibility. Classic Themes offer a gentler start for basic tasks due to familiarity. Block Themes demand greater initial learning investment but potentially unlock higher code-free customization capabilities and streamlined workflows for complex design tasks, reducing reliance on custom code or third-party plugins.

Comparative Analysis: Performance Implications

Website performance critically influences user experience, conversion rates, and search engine rankings. The architectural differences between theme types have significant implications for site speed.

Architectural Impact

The fundamental technologies underpinning each theme type contribute to performance variations.

Block Themes primarily use HTML files with block markup for templates and leverage theme.json for styles and settings. This modern architecture is designed to generate cleaner, more optimized code. By reducing dynamic PHP execution for basic template structures, Block Themes can potentially lower server-side processing load, shifting processing towards parsing structured HTML and applying JSON-defined styles.

Classic Themes depend heavily on PHP for dynamic template rendering. Each page request involves server execution of PHP code to generate HTML output, potentially increasing processing time and database queries, especially in complex themes. Classic themes often load comprehensive CSS stylesheets covering all potential theme features.

The shift from dynamic PHP rendering to a more declarative model based on HTML markup and JSON configuration provides Block Themes with a theoretical performance advantage. WordPress core is actively optimizing template loading mechanisms specifically for Block Themes, reinforcing this potential.

Asset Loading & Dependencies

How themes load assets and manage dependencies significantly impacts performance.

Block Themes incorporate mechanisms for efficient asset loading, including conditional loading where styles are loaded only for blocks actually present on a page. The style management in theme.json helps optimize CSS delivery, reducing redundancy and preventing specificity conflicts. Additionally, Site Editor capabilities can often replace functionality previously requiring third-party plugins, potentially reducing code bloat and external dependencies.

Classic Themes frequently load large, monolithic CSS stylesheets including styling for all components, regardless of page usage. Due to more limited built-in customization options, they commonly rely on additional plugins for desired layouts and functionality, introducing extra code, potential conflicts, and increased page weight.

Block Themes address common performance bottlenecks through optimized loading strategies and reduced plugin dependencies, offering significant potential advantages for Core Web Vitals and overall site speed.

Real-World Performance Variability

While architectural advantages suggest Block Themes should be faster, real-world comparisons present a nuanced picture.

Some analyses indicate Block Themes exhibit improved performance due to leaner architecture and optimized loading. However, highly optimized Classic Themes like GeneratePress, Kadence, or Astra can still achieve excellent loading speeds, sometimes surpassing current Block Themes, especially on mobile.

Performance is multifactorial, influenced by hosting quality, caching strategies, CDN usage, image optimization, plugins, and page content complexity. A poorly coded Block Theme on an unoptimized site can still be slow, while a meticulously optimized Classic Theme remains competitive.

The emerging consensus is that Block Themes provide a more inherently performance-oriented architecture. As FSE technology matures and WordPress core continues introducing performance enhancements targeting the block paradigm, Block Theme performance advantages are likely to become more pronounced and consistent.

Comparative Analysis: Design Consistency

Maintaining consistent visual identity across a website is crucial for branding and user experience. Block and Classic Themes approach this challenge differently.

Achieving Uniformity

Block Themes introduce Global Styles via theme.json as the central mechanism for enforcing design consistency. This file allows defining presets (colors, typography, spacing), default styles for elements and blocks, layout defaults, and feature toggles. By defining these “design tokens” in a structured file, theme.json acts as a powerful engine for maintaining cohesion across both front-end and editor interfaces. Block Themes also support Style Variations, allowing users to switch between predefined visual schemes while maintaining underlying structure.

Classic Themes lack a standardized, core-level configuration file for comprehensive global design rules. Consistency typically relies on well-structured CSS, Customizer settings, Theme Options panels, and developer discipline. While achievable, the fragmented nature of styling controls makes it more challenging to enforce unified design systems, especially across large sites or with multiple content editors.

The introduction of theme.json is a significant Block Theme advantage regarding design consistency. It provides a standardized, centralized mechanism for defining, managing, and enforcing visual identity in ways previously more difficult and less standardized in Classic Theme architecture. This facilitates design system implementation and helps ensure user customizations preserve brand integrity.

Comparative Analysis: Development Approaches

The methodologies, technologies, and required skillsets differ substantially between theme types.

Theme Structure & Technology

Block Themes use a distinct structure and technology stack: HTML files in /templates and /parts containing block markup instead of PHP rendering logic; theme.json controlling global settings, styles, and features; optional functions.php for specific tasks not covered elsewhere; and potentially custom blocks requiring JavaScript/React knowledge.

Classic Themes adhere to traditional WordPress development: PHP template files following the template hierarchy, mixing HTML and PHP; essential functions.php for theme setup, script enqueuing, and WordPress hook interactions; and styling via CSS files (primarily style.css) with interactivity added using JavaScript/jQuery.

This represents a significant paradigm shift in required developer skills. While PHP knowledge remains valuable, Block Theme development emphasizes understanding block architecture, JSON configuration, HTML structure, and potentially modern JavaScript frameworks for extending the block system. Classic Theme development remains PHP-centric, utilizing server-side rendering and established WordPress APIs.

Developer Workflow & Tooling

Day-to-day workflow and tools also diverge between theme types.

Block Theme development incorporates more visual, iterative workflow: developers can leverage the Site Editor to visually assemble templates and parts, adjust styles via Global Styles, and see real-time changes; export these changes into theme files for code refinement; and use tools like Create Block Theme for scaffolding. This visual nature allows designers with limited coding knowledge to participate more directly in theme construction.

Classic Theme development follows a more traditional code-centric workflow: working primarily in a code editor writing PHP for templates, adding logic to functions.php, and crafting CSS; programmatically interacting with WordPress APIs; and applying PHP debugging techniques. This requires solid understanding of PHP, the template hierarchy, and core WordPress development principles.

The integration of the Site Editor into Block Theme development represents a key workflow difference. While code remains essential for robust development in both paradigms, Block Themes allow greater visual construction, potentially accelerating layout prototyping and iteration. Classic Theme development remains fundamentally grounded in writing code according to established WordPress conventions.

The Future Trajectory: WordPress Core Direction

Understanding WordPress core development direction is essential when evaluating long-term theme viability.

Emphasis on Block Themes and FSE

WordPress core development efforts are overwhelmingly concentrated on refining and expanding FSE capabilities and the Block Theme ecosystem. This is not a fleeting trend but a core part of the long-term Gutenberg roadmap.

Recent and planned WordPress releases reveal a consistent pattern: most new features and enhancements target FSE. This includes Site Editor improvements, theme.json capability expansion, new APIs (Block Hooks, Block Bindings, Interactivity), core block refinements, template and pattern management tools, and block-specific performance optimizations.

Furthermore, official default themes bundled with WordPress since version 5.9 are all Block Themes, serving as reference implementations and best practice demonstrations.

Adopting Block Themes is consistently framed as the path toward future-proofing websites and aligning with ongoing platform innovation. While Classic Themes continue to function and receive maintenance, strategic investment and core development resources are clearly directed toward the block-based FSE system.

The Diminishing Role of the Customizer

The rise of FSE directly impacts the traditional Customizer’s relevance. When a Block Theme is active, the Customizer menu item is hidden by default, reappearing only if specific plugins require it.

Core tasks previously handled by the Customizer are now intended to be performed within the Site Editor, primarily through the Styles panel and direct block manipulation.

While not officially deprecated for Classic or Hybrid themes, the Customizer’s functional role is being superseded by the more comprehensive Site Editor. Its default hidden state in the future-facing theme paradigm signals a clear shift away from it as a central customization tool.

Implications for Developers and Site Owners

This clear strategic direction has significant implications for the WordPress ecosystem:

Developers need to invest in learning Block Theme development to remain current and leverage the latest WordPress capabilities. This includes understanding HTML block templates, mastering theme.json, utilizing block patterns, becoming proficient with the Site Editor workflow, and potentially acquiring React skills for custom block development. While Classic Theme skills remain valuable for maintaining existing websites, new projects aiming for longevity will increasingly benefit from or require an FSE approach.

Site Owners face considerations when migrating from Classic to Block Themes. This involves learning the Site Editor and carefully remapping customizations previously handled elsewhere. However, the transition offers substantial long-term benefits: greater code-free design flexibility, potential performance improvements, alignment with future updates, and potentially easier theme switching. For new websites, starting with a Block Theme is strongly recommended.

The entire WordPress ecosystem is gradually adapting to support FSE and Block Themes, partly aimed at addressing market share concerns by keeping the platform competitive and appealing to modern web development practices.

The trajectory is clear: adaptation to the block-based paradigm is becoming increasingly crucial for all WordPress stakeholders. While the transition presents challenges, the core commitment coupled with potential benefits in flexibility, control, performance, and future-readiness makes embracing Block Themes and FSE a strategic imperative for leveraging the platform effectively moving forward.

Block Themes vs. Classic Themes: Key Differences

Primary Technology

• Block Theme: HTML Templates, Block Markup, theme.json
• Classic Theme: PHP Templates, Template Hierarchy, functions.php

Editing Interface

• Block Theme: Site Editor (Visual, Integrated for entire site)
• Classic Theme: Customizer, Widgets Admin, Menus Admin, Theme Options (Separate Panels)

Customization Scope

• Block Theme: Entire Site (Header, Footer, Templates, Content, Global Styles)
• Classic Theme: Predefined Areas & Options via Customizer/Widgets/Options; Code required for structural changes

Core Styling Control

• Block Theme: Global Styles via theme.json (Centralized, Standardized)
• Classic Theme: CSS Files, Customizer Settings (Fragmented, Theme-dependent)

Widget Handling

• Block Theme: Any Block can be placed anywhere within Templates via Site Editor
• Classic Theme: Dedicated Widget Areas populated via Widgets Admin/Customizer

Performance Potential

• Block Theme: Generally Higher (Modern Architecture, Optimized Asset Loading, Fewer Plugin Dependencies)
• Classic Theme: Variable (Highly dependent on theme quality & optimization; Can be fast but prone to bloat)

Development Paradigm

• Block Theme: Block-centric, HTML/JSON focus, theme.json mastery, React for custom blocks
• Classic Theme: PHP-centric, Template Hierarchy, Hooks/Filters, functions.php essential

Future Outlook

• Block Theme: Primary Focus of WordPress Core Development & Innovation
• Classic Theme: Supported & Maintained, but less focus for new core features

Conclusion & Recommendations

The analysis reveals a clear divergence between WordPress Block Themes and Classic Themes, representing two distinct platform evolution eras. Block Themes offer a paradigm shift towards a unified, visual, and highly flexible site-building experience with strengths in granular control, design consistency through centralized configuration, and architecture designed for better performance. They align with WordPress’s future strategic direction but come with a steeper learning curve.

Classic Themes benefit from decades of development, familiar workflows, vast libraries of existing themes and plugins, and extensive documentation. However, their customization capabilities are often constrained, requiring code or page builders for significant structural changes, and they can be prone to performance issues from monolithic stylesheets and plugin dependencies. While still supported, they are no longer the primary focus of WordPress core innovation.

Recommendations:

For New Website Builds: Strongly recommended to use Block Themes to leverage FSE power, maximize design flexibility, align with modern web standards, gain potential performance advantages, and position for future WordPress updates.

For Existing Classic Theme Sites: Migration decision requires careful evaluation. If the site is stable, meets business needs, and doesn’t require significant redesign, remaining with the Classic or Hybrid theme is viable, though it may diverge from core innovation. If major redesign is planned or greater flexibility desired, migration to a Block Theme is advisable with adequate resources allocated for transition.

For Developers: Investing in Block Theme development skills is crucial for ecosystem relevance. This includes mastering Site Editor, theme.json, HTML block templates, and potentially React for custom blocks. Classic Theme skills retain value for legacy sites, but future opportunities will increasingly favor FSE paradigm proficiency.

Regarding Performance: While Block Themes offer architectural advantages, performance isn’t guaranteed by theme type alone. Prioritize well-coded, lightweight themes and implement web performance best practices regardless of choice. However, Block Themes’ inherent optimizations provide a stronger foundation for excellent performance.

Block Themes and Full Site Editing represent a transformative step for WordPress, modernizing the platform, empowering users with sophisticated design tools, and establishing a more flexible, consistent, and potentially performant foundation. While transition involves learning curves and adaptation challenges, the clear WordPress core commitment and tangible block-based paradigm benefits suggest embracing this evolution is a strategic necessity for those seeking to fully leverage WordPress capabilities now and in the future.

The WordPress landscape shifted dramatically with the introduction of the Gutenberg block editor. It promised a more visual, intuitive way to build posts and pages. But this left many users wondering: What about shortcodes? Are they obsolete now?

If you’ve relied on those handy [bracketed_codes] to add forms, galleries, or other special features, you might be concerned about their future. Do you need to replace them all? Are they holding your site back?

Let’s dive deep and clarify the role of WordPress shortcodes in the age of Gutenberg blocks in 2025.

First, What Exactly Are WordPress Shortcodes? (A Quick Refresher)

For years, shortcodes were the go-to method for embedding dynamic content or complex functionality directly into your WordPress posts, pages, and widgets without writing long chunks of code. Think of them as shortcuts – simple tags like or [contact_form] that WordPress processes to display something more complex on the front end. They were powerful tools offered by themes and plugins.

Enter Gutenberg: The Block Editor Revolution

Gutenberg replaced the classic WordPress editor with a block-based system. Instead of one big text area, you build content using individual blocks for paragraphs, headings, images, buttons, columns, and much more. This offers a significantly more visual (WYSIWYG – What You See Is What You Get) and structured approach to content creation. Many functionalities that previously required shortcodes now have dedicated blocks.

So, Are Shortcodes Dead? Not Quite!

Here’s the good news: Shortcodes are NOT dead or deprecated in WordPress.

WordPress prioritizes backward compatibility. The core Shortcode API remains functional. Shortcodes you implemented years ago should still work even with the latest WordPress versions using the block editor.

How Do Shortcodes Work with the Gutenberg Editor?

While blocks are the native language of Gutenberg, you can still easily use your existing shortcodes:

1. The Dedicated Shortcode Block: Gutenberg includes a specific block named “Shortcode”. Simply add this block to your page or post and paste your shortcode (e.g., [your_plugin_shortcode attribute="value"]) into the provided field. This is the cleanest, recommended method.
2. Pasting into Paragraph Blocks: Often, simply pasting a shortcode directly into a standard Paragraph block will work. WordPress is usually smart enough to recognize and render it correctly on the front end.
3. The Classic Block: If you have older content originally built with the Classic Editor, it might open within a “Classic” block in Gutenberg. Your shortcodes within this block will continue to function as before.

Why Gutenberg Blocks Are Often the Better Choice Now

While shortcodes still work, blocks represent the evolution and generally offer several advantages:

• Visual Editing: The biggest win! Blocks provide a live preview or a close representation of the final output directly within the editor. No more guessing what a shortcode will look like until you hit “Preview.”
• User-Friendliness: Blocks offer intuitive controls (buttons, sliders, color pickers) instead of requiring you to look up and type specific shortcode attributes.
• Better Integration: Blocks are designed to work seamlessly together, allowing for more complex layouts and consistent styling within the native WordPress environment.
• Performance: While not always a dramatic difference, blocks can sometimes be more performant as they don’t rely on the same parsing process as shortcodes.
• Developer Focus: The future of WordPress development is heavily focused on blocks. Expect new features and integrations to primarily leverage the block system.

When Do Shortcodes Still Make Sense?

Despite the advantages of blocks, shortcodes retain their relevance in several key scenarios:

• Legacy Content: If your site has years of content built with shortcodes, there’s often no urgent need to convert everything to blocks, especially if it works fine.
• Plugin Functionality: Many plugins, particularly older or very complex ones, still rely heavily on shortcodes to deliver their features. Some offer both blocks and shortcodes for flexibility.
• Specific Embed Needs: Occasionally, a shortcode might be the only way provided by a plugin or service to embed specific third-party content or achieve a very particular function not yet covered by a standard block.
• Theme Independence (Plugin Shortcodes): Shortcodes provided by plugins are generally portable. If you switch themes, your plugin and its shortcodes will likely continue to work.

A Word of Caution: Theme-Based Shortcodes

Be very wary of shortcodes that come built into your theme. While convenient initially, they create theme lock-in. If you ever decide to switch themes, those theme-specific shortcodes will stop working, potentially leaving broken code snippets scattered across your site. It’s generally better to get functionality like sliders, buttons, or grids from dedicated plugins that provide blocks or plugin-based shortcodes.

The Future Outlook: Blocks Leading the Way

The trend is undeniable: blocks are the future of WordPress content creation. While shortcodes will likely be supported for a long time due to backward compatibility, expect to see less emphasis on them for new development. More plugins will offer blocks as the primary (or only) way to integrate their features. Some platforms, like the popular Divi builder, are even planning future versions that move away from their own shortcode systems entirely.

Conclusion: Shortcodes Live On, But Embrace the Blocks!

So, are shortcodes still relevant after Gutenberg? Yes, absolutely. They are supported, functional, and necessary for many existing sites and plugin functionalities. You can continue using them, especially via the Shortcode block.

However, Gutenberg blocks are the modern, preferred standard. They offer a superior user experience, better integration, and represent the future direction of WordPress. Where a block alternative exists for a function you need, it’s generally advisable to use the block for new content.

Don’t panic about your existing shortcodes, but embrace the power and convenience of blocks as you move forward with your WordPress site!

Published: April 2025

If you’ve ever tried to embed raw block markup like <!-- wp:post-title /--> directly inside a WP_Query loop and scratched your head wondering why it only renders the same title repeatedly—or throws validation errors—you’re not alone.

Let’s clear up the confusion, understand why this happens, and look at how to do it the right way using modern WordPress tools.

---

🧩 The Problem: Mixing Block Markup With Server-Side PHP

❌ What doesn’t work:

<!-- wp:post-title /-->

…inside a loop like this:

while ( $query->have_posts() ) {
    $query->the_post();
    echo '<!-- wp:post-title /-->';
}

At first glance, this feels intuitive: WordPress supports block markup, and <!-- wp:post-title /--> is a valid block, right?

But here’s the catch: This block syntax is for the Block Editor (Gutenberg), not for PHP-rendered frontend templates.

When you echo block markup like this from PHP, it’s not parsed as a real block. It’s just plain HTML from PHP’s point of view. The editor might recognize it as a block comment, but the frontend won’t treat it as a live, dynamic block unless you specifically render it as a block.

---

✅ The 2025 Solution: Use render_block() or Stick to Classic PHP Functions

If you want to dynamically render block content inside PHP, you need to convert the block into rendered HTML. That’s where render_block() or do_blocks() come in.

But for most devs building themes or custom blocks, the simpler, safer approach is to just use classic template functions like the_title() and the_permalink()—especially when you’re in a WP_Query.

---

🛠️ Modern Example: Rendering a Portfolio Grid (2025 Style)

Let’s say we’re building a custom “Most Viewed Projects” section. Instead of misusing block markup, we’ll go full PHP with clean HTML and modern practices:

<?php
$args = array(
    'post_type'      => 'project',
    'posts_per_page' => 6,
    'meta_key'       => 'project_views',
    'orderby'        => 'meta_value_num',
    'order'          => 'DESC'
);

$popular_projects = new WP_Query( $args );

if ( $popular_projects->have_posts() ) : ?>
    <section class="popular-projects">
        <h2>🔥 Trending Projects</h2>
        <div class="project-grid">
            <?php while ( $popular_projects->have_posts() ) : $popular_projects->the_post(); ?>
                <article class="project-card">
                    <h3><a href="<?php the_permalink(); ?>"><?php the_title(); ?></a></h3>
                    <div class="project-excerpt"><?php the_excerpt(); ?></div>
                </article>
            <?php endwhile; ?>
        </div>
    </section>
    <?php wp_reset_postdata(); ?>
<?php endif; ?>

---

🧠 Why This Works (And Matters)

• ✅ Uses WordPress core functions like the_title() and the_excerpt() — built to be context-aware.
• ✅ Avoids block markup confusion, which only works when rendered by the block editor or explicitly parsed via block-rendering functions.
• ✅ Faster and more reliable on the frontend without triggering block validation errors or caching issues.

---

📋 Quick Checklist: Rendering Content in Custom Loops

✅ Do	❌ Don’t
Use the_title(), the_excerpt() in loops	Echo raw <!-- wp:post-title /-->
Use render_block() if you must output blocks in PHP	Assume blocks will parse magically from PHP
Leverage block patterns in the editor for layout	Overcomplicate frontend with raw block markup
Stick to static block markup in template files	Try dynamic loops inside static block patterns

---

💡 Bonus Tips

• If you want to lock down a layout using the block editor, use Block Patterns and pre-built Query Loops — don’t try to generate them with raw PHP.
• Tracking views via post_meta is discouraged in high-traffic sites. Consider offloading to an analytics service or caching system for scalability.

---

📚 Learn More

• render_block() docs →
• How to use Block Patterns →
• Creating Custom Post Types →

---

Final Thought

WordPress in 2025 gives you incredible flexibility — but it’s important to understand the separation between editor-side blocks and PHP-rendered templates. Stick to each system’s strengths, and you’ll build more reliable, scalable experiences for both editors and end users.

Happy coding! ✨

If you’ve ever uninstalled a plugin or removed a custom post type in WordPress and started seeing odd PHP notices, you’re not alone. Recently, I ran into a warning that popped up on every page load in the admin dashboard:

PHP Notice: map_meta_cap was called incorrectly. The post type eventhub is not registered…

Sound familiar?

This happens when WordPress tries to check capabilities (like edit_post) for a post type that no longer exists. The problem: orphaned entries in your database. If a plugin registered a post type like eventhub, and you removed that plugin without deleting its content, those posts remain — and WordPress doesn’t like that.

🧠 Why This Matters

Even though these leftover posts aren’t visible in the UI, they still exist in the wp_posts table. When WordPress sees them, it tries to load the post type logic — and fails, because that post type is no longer registered. This can clutter your debug log, slow things down, or even break some admin functionality.

🚀 The Solution: WP-CLI to the Rescue

Here’s a simple, modern WP-CLI command that safely removes all posts from a custom post type — even if that post type no longer exists in your codebase:

wp post delete $(wp post list --post_type='eventhub' --format=ids) --force

🔍 What This Command Does

• wp post list --post_type='eventhub' --format=ids: This lists all post IDs of the now-orphaned eventhub type.
• The $() syntax feeds those IDs into the next command.
• wp post delete ... --force: Deletes all the listed posts permanently, skipping the trash bin.

Replace eventhub with whatever your orphaned post type is (like portfolio, project, customform, etc.).

✅ Cleanup Checklist

Here’s a quick checklist to avoid this kind of issue in the future:

• Before removing a plugin or custom post type, check if it added a post type.
• Use wp post list --post_type='your_post_type' to confirm if any data remains.
• Back up your database before running destructive WP-CLI commands.
• Consider writing a small migration script if you need to preserve the data elsewhere.

🛠 Bonus Tip

If you’re not sure what custom post types exist in your database, this command is a handy starting point:

wp db query "SELECT DISTINCT post_type FROM wp_posts;"

It will return all post types currently present in the database — even if they’re no longer registered in your theme or plugins.

📚 Learn More

• WP-CLI Command Reference
• Debugging in WordPress
• Registering Custom Post Types

💬 Final Thoughts

It’s 2025, and managing a modern WordPress site is easier than ever — if you keep your data clean. WP-CLI continues to be an essential tool in every developer’s toolbox. When in doubt, script it out.

Happy coding — and may your debug log always be silent. 🧘‍♂️

AI is churning out code at breakneck speed, and everyone’s jumping on the bandwagon. But what happens when we let the machines do the typing? As someone deep in the trenches of web development, I’ve been watching this unfold with equal parts fascination and concern.

I’ve witnessed the WordPress ecosystem transform almost overnight as developers increasingly ask Claude, ChatGPT, or whatever shiny new LLM has dropped this month to handle their coding tasks. Need a custom post type? An LLM can spit it out faster than you can say “register_post_type” — certainly faster than you can search the plugin directory and evaluate options. Want some CSS without the headache? The AI will take a first crack while you grab coffee, giving you something to refine rather than a blank slate to stare at.

It goes deeper, too, extending well beyond these surface-level conveniences. Why struggle with complex data migrations when you can have an AI write you a custom WP-CLI command tailored to your exact specifications? Why spend hours figuring out how WP All Import works when an AI can craft a bespoke solution in minutes? The appeal is undeniable—instant solutions without diving into documentation or wrestling with someone else’s plugin that does almost, but not quite, what you need.

This rapid shift in development practices isn’t unique to WordPress, of course. Across the programming landscape, developers are discovering the time-saving magic of having an AI assistant that can translate their intentions into functional code with minimal fuss. It’s like having a junior developer who works at the speed of light and never needs a coffee break.

When AI code generation first hit its stride, open source advocates celebrated: “This will be revolutionary for open projects!” The logic seemed sound—LLMs excel at generating code for frameworks like React, Express, and WordPress partly because these projects have mountains of publicly available code examples. Open codebases provide the very training material that makes these models effective, so it made sense that open projects would reap the greatest rewards from AI assistance.

But is simply generating more downstream private code actually benefiting the open source ecosystem? When a developer asks an LLM to create a WordPress plugin that they’ll use once for a specific client need and never share back with the community, is that really advancing open source? Or is it just extracting value without reciprocating?

Here’s where it gets interesting: proprietary systems are likely seeing similar benefits. Once LLMs understand programming’s fundamental structures, the openness of the original codebase becomes less relevant. A company running on a closed-source stack probably has enough internal code examples to feed to an LLM and get equally impressive results. The machines are learning to code, period—not just to code in open frameworks.

Don’t get me wrong—AI is far from a perfect developer. It shines with small, concrete tasks but stumbles when dealing with large codebases or complex features. It can build something new with surprising competence but struggles with maintenance tasks and often introduces subtle bugs that only emerge later. Ask it to add a feature to an existing codebase, and you might end up with beautiful code that completely misunderstands the project’s architecture or introduces security vulnerabilities that won’t be apparent until production.

For projects like WordPress—already drowning in over a thousand unreviewed pull requests—more code isn’t necessarily what’s needed most. The bottleneck isn’t code generation; it’s thoughtful review, strategic direction, and the human wisdom to know which features should be built in the first place.

This raises a question that keeps me up at night: What might open source be losing in the age of AI-generated code?

Before AI, if I needed to solve a problem, I had two primary options: write the solution myself or find someone else’s code to use or modify. This second path often led me down a rabbit hole of discovery. I’d find a plugin or library that almost worked, dig into its code, learn how it approached the problem, and then either adapt it or create my own solution informed by what I’d learned. I might publish my improvements or send them back as a pull request. This exchange—this public collaboration—is the lifeblood of open source. It’s not just about using code; it’s about improving it together in the sunshine.

When developers skip the search for existing solutions and jump straight to AI generation, something valuable is lost in that process. The serendipitous discovery of projects you didn’t know existed. The appreciation for another developer’s elegant solution to a problem you’ve been struggling with. The community connections formed when you contribute back improvements. All of these become rarer in a world where private AI conversations replace public code repositories as our first stop when solving problems.

Open source thrives when developers take those extra minutes to make their solutions universal and shareable. It builds community when we publish our work publicly so others can build upon it. The magic happens when the best solutions bubble up through collective effort and gain widespread adoption. This virtuous cycle has given us the digital infrastructure that powers modern computing—but it requires participation to sustain itself.

While established open source projects will likely continue to thrive, I worry about the disappearing on-ramp for new contributors. How do you become a valued open source contributor if you never need to read other people’s code because an AI can explain everything? How do you develop the habit of sharing your solutions if every problem is solved in a private conversation with a machine?

WordPress itself has become increasingly challenging for newcomers to contribute to—partly due to the shift from PHP to React/JavaScript, which raised the technical bar substantially, but also because repositories like Gutenberg operate more like rapid prototyping labs than welcoming community spaces. Documentation lags behind implementation, features appear and vanish mysteriously, and getting answers often means awkwardly tagging strangers on Twitter rather than consulting proper resources.

In this environment, AI might seem like a savior—helping developers navigate complexity without needing to understand every nuance. But that surface-level understanding rarely translates to meaningful contributions. You can’t effectively guide a project’s direction without the deep knowledge that comes from struggling with its codebase over time.

What open source truly needs isn’t just more code—AI has that covered. It needs knowledgeable humans who can lead projects, make thoughtful decisions, exhibit good taste, maintain ownership over features, and welcome newcomers. As Brooks argued in The Mythical Man-Month, throwing more manpower (or in this case, machine power) at a project often increases communication overhead faster than it resolves coding challenges. The bottleneck in mature open source projects isn’t usually code production but coordination and decision-making—things AI currently does poorly.

AI might generate code summaries or even scan issue threads, but it can’t develop the deep understanding needed for meaningful project decisions. It can’t feel the pain points that should drive prioritization. It can’t build consensus among stakeholders with different needs. The path to becoming a valuable contributor isn’t just about understanding code—it’s about absorbing the culture of collaboration that makes open source work.

I’m not suggesting we abandon AI tools—that would be like refusing to use power tools because hand saws build character. There’s nothing inherently wrong with using AI-generated code—I rely on it regularly myself, and it’s unquestionably making certain aspects of development more efficient. But I’d encourage all developers to remember the true value of open source: it’s not just the code you take, but the code you give back. And more importantly, it’s the relationships you build with contributors across the globe as you collectively craft something better than any individual—or machine—could create alone.

Perhaps the answer lies in finding ways to integrate AI assistance without losing the collaborative essence of open source. Maybe we need AI tools that don’t just generate code but help us discover related projects. Tools that encourage us to contribute back improvements rather than generating one-off solutions. Tools that facilitate human connections rather than replacing them.

We might be gaining efficiency, but are we losing the collaborative spirit that makes open source special? That’s the question we need to answer before the robots do all our typing. And unlike most coding challenges, this isn’t something we can simply outsource to an AI—it requires human wisdom, foresight, and a commitment to preserving what makes open source valuable beyond just the code itself.

In the meantime, next time you ask an LLM to generate that WordPress plugin, consider taking a few extra minutes to package it up and share it with the community. The future of open source might depend on such small acts of generosity.

Modernizing WordPress block icon customization with SVGs, Dashicons, and beyond

---

If you’re building custom blocks with ACF (Advanced Custom Fields) in 2025, chances are you’ve wanted to add a fitting icon to your block to make it visually stand out in the Gutenberg editor. The challenge? Finding the right icon format — and knowing where to get those icons.

Let’s walk through how to add icons to your custom ACF blocks the modern way, what your options are in 2025, and why choosing the right icon approach matters for both clarity and user experience.

---

💡 Why Block Icons Matter

When building a custom Gutenberg block, the icon you assign:

• Appears in the block inserter UI
• Helps users recognize your block at a glance
• Reinforces your brand or design system

But icon handling in WordPress can feel like a moving target: Dashicons, inline SVGs, and now a full React icon library.

---

🛠️ Three Ways to Add Icons to ACF Blocks (and When to Use Them)

1. Use Dashicons by Name (Old School, Still Works)

If you want quick and easy, Dashicons are still supported. These are the original WordPress icon font.

'icon' => 'admin-site-alt3', // Dashicon slug

✅ Great for simplicity
❌ Limited design options; not all icons are available

Reference: Dashicon Cheat Sheet

---

2. Inline SVG Icons (Best for Full Control)

If you’re using ACF PHP registration, you can directly paste an SVG icon’s markup. This method gives you complete freedom over your icon’s look.

🔁 Example: Registering a “Project Showcase” Block with a Custom SVG Icon

add_action('acf/init', 'register_acf_project_block');

function register_acf_project_block() {
    if (function_exists('acf_register_block_type')) {
        acf_register_block_type([
            'name'              => 'project-showcase',
            'title'             => __('Project Showcase'),
            'description'       => __('Highlight a portfolio project.'),
            'render_template'   => 'template-parts/blocks/project-showcase.php',
            'category'          => 'media',
            'icon'              => '<svg width="24" height="24" viewBox="0 0 24 24"><path d="M4 4h16v2H4V4zm0 4h10v2H4V8zm0 4h16v2H4v-2zm0 4h10v2H4v-2z"/></svg>',
            'keywords'          => ['portfolio', 'project', 'showcase'],
        ]);
    }
}

✅ Perfect for branding and full design control
❌ You’ll need to get or create your SVGs manually

Tip: Grab icons from WordPress Icon Library or tools like Heroicons or Feather.

---

3. Custom Icons via CSS (Rare in 2025, but Possible)

Some devs still attach a custom class and add the icon with background CSS. While functional, this is dated and not recommended unless you’re styling something unique or backwards compatible.

'icon' => 'custom-class-name',

Then in CSS:

.custom-class-name {
    background-image: url('/wp-content/themes/yourtheme/assets/icons/custom-icon.svg');
    background-size: contain;
    background-repeat: no-repeat;
}

✅ Can integrate with legacy styling
❌ Not editor-native; fragile in modern block editors

---

📋 Developer Checklist

• ✅ Choose between Dashicons, inline SVG, or React-based icons
• ✅ Test the icon inside the block inserter
• ✅ Keep SVGs optimized (tools: SVGOMG)
• ✅ Use accessible, descriptive markup (aria-labels if needed)

---

🔗 Bonus Resources

• ACF Block Registration Docs
• WordPress Icons Explorer (Gutenberg)
• Heroicons — Popular SVG set
• Feather Icons — Clean and minimal

---

💬 Final Thoughts

In 2025, Gutenberg is more powerful and visual than ever — and icons play a small but crucial role in user experience. Whether you’re building blocks for clients or your own portfolio, don’t overlook this detail.

SVGs offer the most flexibility and future-proofing, but if you’re in a hurry, Dashicons will still do the trick.

Need help optimizing SVGs or creating a custom block icon strategy? Drop a comment or ping me on Mastodon/X/GitHub!