Gutenberg Developer for Hire

Yes - Gutenberg and the WordPress block editor are the same thing. Gutenberg was the project name during development and the name still used in the plugin repository for the bleeding-edge version. The block editor is what ships in WordPress core.nnGutenberg replaced the Classic Editor (TinyMCE) as the default WordPress editor in version 5.0 in December 2018. It introduced a block-based editing model where every piece of content - headings, paragraphs, images, columns - is an independent block that can be inserted, configured, and rearranged.nnSince 5.0 it has expanded significantly. Gutenberg now powers Full Site Editing, which extends block editing to headers, footers, and page templates. The Gutenberg plugin (installed separately from the WordPress plugin directory) contains features that are in active development before they ship in WordPress core.

The right choice depends on who will be maintaining the site and what it needs to do.nnGutenberg is the better choice when: the site is primarily content-driven (blog, news, documentation), the editorial team is comfortable with a block-based interface, you want the lightest possible front-end output with no page builder overhead, or the site uses a block theme and Full Site Editing for template management.nnElementor is the better choice when: the site needs complex visual layouts that Gutenberg's core blocks cannot achieve without custom development, the client needs a visual editing experience for marketing pages rather than editorial content, or the project is a WooCommerce store that benefits from Elementor's WooCommerce Builder templates.nnMany sites use both - Elementor for designed pages and landing pages, Gutenberg for blog posts, news articles, and standard content pages. This hybrid approach is valid but requires clear documentation so editors know which tool to use for what.

A static block stores its rendered HTML at the time the editor saves the post. Every time someone views the page, WordPress serves that saved HTML. Static blocks are appropriate for content that does not change based on context - a custom call-to-action block, a styled quote block, a testimonial block with fixed content.nnA dynamic block has a PHP render_callback function that generates the HTML fresh on every page request. The block stores its attributes (configuration values) in the post content, but the output is built at render time by querying the database or processing current data.nnDynamic blocks are necessary when the output needs to be current - a latest posts block, a block that shows the current user's name, a product availability block, or any block whose output depends on data that changes after the post is published. ACF Blocks always use dynamic rendering via a PHP template.

Full Site Editing is the extension of Gutenberg's block editor to the entire site structure - not just post and page content but also headers, footers, sidebars, and page templates. FSE requires a block theme (a theme that uses HTML template files with block markup instead of PHP templates).nnWith FSE enabled, site editors can open the Site Editor from the WordPress admin, edit the header block template, add or rearrange blocks in the footer, change the single post template layout, and modify the archive page structure - all without touching a PHP file.nnGlobal styles are managed through theme.json and the Styles panel in the Site Editor - colors, typography, spacing, and button styles set once and applied everywhere.nnFSE is the future direction of WordPress theming. Classic PHP themes will continue to work but new WordPress core investment is focused on FSE.

Blocks displaying as raw HTML or 'This block contains unexpected or invalid content' is one of the most alarming Gutenberg error states. It almost always has one of these causes:nnPlugin or theme deactivated that registered the block - when a plugin that registered a custom block is deactivated, WordPress cannot parse the block markup and displays it as raw HTML. Fix: reactivate the plugin, or use the block recovery option to convert to Classic blocks.nnBlock markup modified outside the editor - if someone edited the post_content directly in the database or a migration script processed the content incorrectly, the block comment delimiters get broken. Fix: use the block recovery tool in the editor toolbar to attempt automatic repair.nnSwitching from Classic Editor to Gutenberg on existing content - content written in Classic Editor parses as a single Classic block in Gutenberg, not broken HTML. If it is showing raw HTML, the content has malformed block markup from a partial migration.

Install the Classic Editor plugin from the WordPress plugin directory. Once activated, it replaces the block editor with the old TinyMCE editor sitewide.nnYou can configure it per post type: in Settings > Writing, choose whether all users get the Classic Editor or whether users can switch between editors per post.nnImportant: the Classic Editor plugin is officially supported until at least 2024 and still receives updates. However, Full Site Editing and block themes require the block editor to function. If your theme is a block theme, disabling Gutenberg will break the Site Editor.nnFor sites using Elementor or Bricks for page building: you do not need to disable Gutenberg entirely. These builders open their own editor interface when you click Edit with Elementor or Edit with Bricks, bypassing the block editor for those pages while Gutenberg still handles posts and non-builder pages.

theme.json is a configuration file in a WordPress theme's root folder that defines the global design system for the block editor and the site's front end. It is the central source of truth for colors, fonts, spacing, and layout.nnWhat theme.json controls: the color palette available in the block editor's color picker, the font families and sizes available as block typography options, the spacing scale used for padding and margin controls, whether certain editor features are enabled or disabled (custom colors, custom font sizes, padding control), global default styles applied to specific block types, and the site's content width and wide alignment width.nnChanges in theme.json propagate to every block on the site automatically. It replaces dozens of add_theme_support() calls that were previously needed in functions.php and produces CSS custom properties that both the editor and front end consume, ensuring the editing experience matches the published output.

Block patterns are pre-designed layouts made of multiple blocks that editors can insert with a single click. They appear in the block inserter under the Patterns tab. Once inserted, every block in the pattern is individually editable - patterns are starting points, not locked templates.nnRegistering a custom pattern in PHP:nregister_block_pattern('myplugin/hero-section', [n 'title' => 'Hero Section',n 'content' => '...',n]);nnThe content is the raw block markup for the pattern layout. You can generate it by building the layout in the editor, switching to Code Editor view, and copying the block markup.nnBlock patterns are one of the most underused tools for maintaining design consistency while giving editors genuine flexibility. A well-designed pattern library means editors never start from a blank page.

ACF Blocks is the most practical option for building custom Gutenberg blocks without React.nnWith ACF PRO, you register a block in PHP with acf_register_block_type(), define its fields as an ACF field group, and create a PHP template that renders the block's HTML using get_field(). The editor displays the block using a live preview rendered by the PHP template, with an ACF field panel in the sidebar for editing.nnThis approach produces blocks that are identical in behavior to native blocks but built entirely in PHP. No Node.js, no Webpack, no JSX. The output is plain HTML with no React runtime on the front end.nnThe trade-off: ACF Blocks requires ACF PRO and does not support some advanced block features like InnerBlocks nesting. For most content block use cases - testimonials, team members, feature cards, CTAs - ACF Blocks is faster to build and easier to maintain than native React blocks.

Gutenberg is generally good for SEO when used correctly, and in some ways better than page builders for SEO output.nnBecause Gutenberg outputs standard HTML from registered block types, the markup is clean, semantic, and predictable. Core blocks like Heading, Paragraph, and List output exactly the HTML elements you expect. There are no extra wrapper divs, no inline CSS framework overhead, and no render-blocking JavaScript unless a plugin adds it.nnThe SEO risks with Gutenberg are editorial rather than technical - editors using Heading blocks at the wrong level (H3 before H2), using Bold text instead of actual heading blocks for visual hierarchy, or adding images without alt text through the Image block. These are solved by editor training and block customizations that enforce correct usage, not by the technology itself.