WordPress history, from 4.9 to the Gutenberg era

#WordPress 4.9 Tipton release in 2017

Learn more about WordPress development services at WPPoland.

WordPress 4.9 “Tipton”, released in November 2017, occupies a unique place in WordPress history as the final major release before the step-change WordPress 5.0, which introduced the Gutenberg block editor. This version represented a moment of maturity for WordPress as a developer platform, introducing conveniences that I now consider standard but that were important at the time. A feature-by-feature walkthrough of the release itself is in what was new in WordPress 4.9; this article follows what came after it.

Looking from my 2026 perspective, version 4.9 stands as a fascinating historical artifact - a snapshot of WordPress at the precipice of its most significant transformation since the platform’s inception. The developers and designers who built sites in 4.9 witnessed an era where PHP template files still ruled supreme, where widget areas were managed through drag-and-drop interfaces, and where the concept of “blocks” was associated primarily with media blocks in content rather than the fundamental building element of entire pages.

The development cycle for WordPress 4.9 introduced several key improvements that enhanced the platform’s appeal to developers and site administrators alike. The focus on code quality, performance optimization, and user experience refinements demonstrated WordPress’ commitment to continuous improvement even as the team prepared for the massive undertaking that would become Gutenberg.

#What was new in WordPress 4.9

WordPress 4.9 brought several transformative features that shaped the development landscape for years to come. The most significant improvements focused on the Customizer, code editing capabilities, and widget management, each addressing pain points that developers and site administrators had long expressed frustration with.

The Customizer improvements in 4.9 represented a major step forward in the platform’s journey toward a more dynamic and user-friendly site editing experience. These enhancements laid important groundwork for the Full Site Editing vision that would emerge in subsequent releases, while the WordPress team kept developing the Customizer as the central place for site customization.

// Example of Customizer enhancements in WordPress 4.9
// Adding a new control with real-time preview
$wp_customize->add_setting('theme_options[accent_color]', array(
    'default'   => '#0073aa',
    'transport' => 'postMessage',
    'sanitize_callback' => 'sanitize_hex_color',
));

$wp_customize->add_control(new WP_Customize_Color_Control(
    $wp_customize,
    'theme_options[accent_color]',
    array(
        'label'    => __('Accent Color', 'my-theme'),
        'section'  => 'colors',
        'priority' => 5,
    )
));

The integration of CodeMirror into the WordPress core for theme and plugin editing was another landmark improvement. Before 4.9, editing theme files or adding custom CSS meant working with a basic textarea that offered no syntax highlighting, line numbers, or error detection. Developers who accidentally introduced syntax errors would often break their sites, leading to the infamous “white screen of death” and requiring FTP access to fix the problem.

#CodeMirror code editor in WordPress 4.9

The introduction of CodeMirror-based editors in WordPress 4.9 fundamentally changed how developers interacted with the platform’s code editing capabilities. Syntax highlighting, line numbering, bracket matching, and error detection became standard features, dramatically reducing the likelihood of site-breaking mistakes and improving overall developer productivity.

This enhancement was particularly significant for site administrators who frequently needed to add custom CSS or modify theme files. The visual feedback provided by syntax highlighting made it much easier to identify typos, missing semicolons, and other common coding errors before they could cause problems on the live site. Line numbers also facilitated collaboration when working with development teams or when seeking help from the WordPress community.

/* Example CSS with syntax highlighting - WordPress 4.9 CodeMirror support */
.site-header {
    background-color: #ffffff;
    padding: 20px 0;
    box-shadow: 0 2px 10px rgba(0, 0, 0, 0.1);
    transition: all 0.3s ease;
}

.site-header.scrolled {
    padding: 10px 0;
    background-color: #f8f9fa;
}

/* Responsive design with media queries */
@media screen and (max-width: 768px) {
    .site-header {
        padding: 15px 0;
    }

    .main-navigation {
        display: none;
    }
}

The CodeMirror integration also improved the “Additional CSS” section in the Customizer, making it a more viable option for storing custom CSS rules. The 4.9 release post lists two safeguards that came with it: WordPress warns before saving code that contains an error, and it warns that editing theme and plugin files directly from the admin is a dangerous practice. The bundled linters were CSSLint, JSHint, HTMLHint and JSONLint, according to the code editing dev note; PHP was highlighted but not linted.

#WordPress 4.9 gallery widget and widget changes

WordPress 4.9 introduced native gallery support for widgets, addressing a common need among site administrators who wanted to display photo galleries in sidebars and other widget areas without requiring custom code or third-party solutions. This feature built on the image, video and audio media widgets that WordPress 4.8 had added a release earlier.

The Text widget changed too. According to the WordPress 4.9 field guide, it gained support for shortcodes, images, galleries, video, audio and embeds, and the release post adds that menu and widget placement became more persistent when switching themes. These changes were incremental next to what the block editor would bring, but they moved widgets closer to post content.

#Why WordPress 4.9 widgets were called proto-blocks

The gallery widget looks like a minor sidebar feature, but the dev note that announced it ties it directly to Gutenberg. In Introducing the Gallery widget on make.wordpress.org (25 September 2017), Weston Ruter wrote:

“The media widgets are being developed with Gutenberg in mind, as widgets are essentially proto-blocks.”

The same note says that as Gutenberg matures, “widgets are planned to eventually transition over to use blocks”, and that the image, video, audio and gallery widgets would be migrated at that point. It also records the movement in the other direction: Gutenberg had already ported the Categories and Recent Posts widgets to dynamic blocks, so content that used to be restricted to sidebars could be placed inside posts.

That plan landed almost four years later. WordPress 5.8 “Tatum” (release post, 20 July 2021) brought blocks to “both the Block Widgets Editor and the Customizer”. Sites that were not ready can return to the old screens with Classic Widgets, an official plugin maintained by the WordPress team, which the plugin directory lists at more than 2 million active installations. For anyone maintaining a theme from the 4.9 period, widget areas built from text and media widgets are the part of the site that changes first when the block widget editor switches on.

#What changed in WordPress 4.9.6 and 4.9.8 before Gutenberg

Version 4.9 stayed the current branch for more than a year, and two of its maintenance releases changed more than bugs.

WordPress 4.9.6 (release post, 17 May 2018) was a privacy release. It added:

• a setting to designate a privacy policy page, which is then shown on the login and registration pages;
• an export tool that produces a ZIP file with a user’s personal data, including data collected by participating plugins;
• an erasure tool for the same data;
• an email-based method to confirm export and erasure requests;
• a checkbox in the comment form that lets logged-out commenters decide whether their name, email and website are saved in the browser.

WordPress 4.9.8 (release post, 2 August 2018) added the “Try Gutenberg” callout to the dashboard, described as “an opportunity for users to use the Gutenberg block editor before it is released in WordPress 5.0”. Who saw it depended on the site:

• with Gutenberg neither installed nor activated: single-site administrators and multisite super admins;
• with Gutenberg installed and activated: users with the Contributor role and above;
• with the Classic Editor plugin active: nobody.

The same release carried 18 privacy fixes for the tools added in 4.9.6. The order matters for anyone reading old changelogs: the block editor was never bundled in 4.9. It was a separate plugin, and 4.9.8 was the first core release that pointed users to it.

#WordPress 5.0 Gutenberg vs the Classic Editor

WordPress 5.0 “Bebo”, released on 6 December 2018, introduced the Gutenberg block editor and fundamentally changed how users create and edit content in WordPress. The community’s reaction to this change was, to put it mildly, polarized. The transition from the classic TinyMCE-based editor to a block-based approach represented the most significant change to the WordPress editing experience in the platform’s history.

The community split into two distinct camps following Gutenberg’s introduction. Traditionalists, including many experienced developers and site administrators, expressed concern about the learning curve, performance implications, and the loss of familiar workflows. This group adopted the “Classic Editor” plugin, which still has millions of active installations and continues to receive updates for users who prefer the traditional editing experience.

// Classic Editor plugin - maintaining the traditional WordPress experience
// The plugin has been installed by millions who prefer the classic approach
// Key features preserved:
// - TinyMCE-based content editing
// - No blocks required
// - Familiar keyboard shortcuts
// - Traditional metabox workflow

Modern creators, on the other hand, embraced the block-based approach, recognizing its potential for content flexibility and design consistency. The block editor introduced a new paradigm where content is constructed from reusable, configurable components rather than a single rich text field. This approach aligned with broader industry trends toward component-based architecture and made it easier to create consistent, responsive layouts without custom code.

#What shipped in WordPress 5.0 Bebo

The 5.0 release post names three parts of the release. The block editor, which it calls “the first step toward an exciting new future with a streamlined editing experience across your site”. Twenty Nineteen, a new default theme whose styles match the default blocks, so what an editor sees in the editor matches the live site. And a supported way back: sites could install the Classic Editor plugin from the plugins screen to restore the previous editor. The post records 423 contributors with props in the release, led by Matt Mullenweg with eleven co-leads.

#How long the Classic Editor plugin is supported

On 7 November 2018, a month before 5.0, Gary Pendergast published the Classic Editor plugin support window on make.wordpress.org:

“The Classic Editor plugin will be officially supported until December 31, 2021.”

The post defined “officially supported” as working as expected in the most recent major WordPress release and the one before it, and said that continued maintenance after 2021 would be evaluated based on usage. The answer is on the plugin’s own page, which now says it “will be fully supported and maintained until 2024, or as long as is necessary”. In October 2026 the plugin directory lists version 1.7.0, last updated in May 2026, with more than 8 million active installations. That is the “as long as is necessary” clause at work, and it is the number to keep in mind before calling the classic editor dead.

#How Full Site Editing evolved after WordPress 5.0

Following the introduction of the block editor, the WordPress team continued to push the boundaries of what was possible with blocks. The concept of Full Site Editing (FSE) emerged as the next logical evolution, extending the block paradigm from content editing to theme customization. With FSE, everything - from headers and footers to sidebars and template parts - could be built from blocks.

WordPress 5.8, released in 2021, marked a significant milestone in the FSE journey by introducing block-based widgets. This change replaced the traditional widget system with a block-based approach, allowing users to add and configure widgets using the same interface they used for content. While this change initially met with resistance from users accustomed to the classic widget system, it represented a crucial step toward the full site editing vision.

// Block template example - WordPress 5.0+
// Defining a custom block template for a theme
function my_theme_register_block_patterns() {
    register_block_pattern(
        'my-theme/hero-section',
        array(
            'title' => __('Hero Section', 'my-theme'),
            'description' => __('A full-width hero section with heading and button', 'my-theme'),
            'categories' => array('featured'),
            'content' => '<!-- wp:cover {"overlayColor":"primary","minHeight":600,"isDark":true} -->
                <div class="wp-block-cover is-dark" style="min-height:600px">
                    <span aria-hidden="true" class="wp-block-cover__background has-primary-background-color has-background-dim-100 has-background-dim"></span>
                    <div class="wp-block-cover__inner-container">
                        <!-- wp:heading {"level":1,"style":{"typography":{"fontSize":48}}} -->
<h1 class="wp-block-heading" style="font-size:48px">Welcome to My Site</h1>
                        <!-- /wp:heading -->
                        <!-- wp:paragraph {"style":{"typography":{"fontSize":20}}} -->
                        <p style="font-size:20px">Discover amazing content and services.</p>
                        <!-- /wp:paragraph -->
                        <!-- wp:button {"backgroundColor":"secondary"} -->
                        <div class="wp-block-button"><a class="wp-block-button__link has-secondary-background-color has-background">Get Started</a></div>
                        <!-- /wp:button -->
                    </div>
                </div>
                <!-- /wp:cover -->',
        )
    );
}
add_action('init', 'my_theme_register_block_patterns');

The Site Editor, introduced in WordPress 5.9, represented the culmination of the FSE vision to that point. This feature provided a unified interface for editing every aspect of a site using blocks, including templates, template parts, and global styles. For theme engineers, this meant learning block themes whose styling and presets live centrally in theme.json rather than drifting across ad hoc CSS files.

#WordPress milestones from 5.8 to 6.3 and the Gutenberg phases

The step from 5.0 to a fully block-based site took four more years. The release posts mark the points where it moved:

Note that theme.json arrived in 5.8, one release before the Site Editor, which is why a classic theme can adopt it without becoming a block theme. The 5.9 post goes as far as saying that with block themes “you no longer need the Customizer”, the tool 4.9 had spent a whole release improving.

The WordPress roadmap groups these releases into phases of the Gutenberg project. Phase 1 introduced the block editor in WordPress 5.0. Phase 2 focused on site editing and culminated in WordPress 6.3, which its release post calls “the capstone of Phase 2”. Phase 3, now underway, is centred on collaborative editing and workflows, and the roadmap’s goals for 2026 have WordPress 7.0 advancing Phase 3 collaboration features. The line back to 4.9 is direct: Customizer drafts, preview links and design locking were the first attempt at letting more than one person work on a change before it goes live, limited to the Customizer. Phase 3 takes the same problem to the whole editor.

#What are block themes and theme.json in WordPress

Fast forward to 2026, and the dispute between classic and block-based editing has largely been resolved in favor of blocks, though the Classic Editor plugin maintains a significant user base for specific use cases. The WordPress ecosystem has evolved dramatically, with block themes becoming the standard for new theme development, and the Gutenberg project continuing to introduce new features and improvements.

Block patterns have emerged as a powerful tool for site builders, allowing for reusable page layouts that can be easily inserted and customized. The Pattern Directory, integrated directly into the WordPress admin, provides a centralized repository of community-contributed patterns covering everything from hero sections to testimonial grids to pricing tables.

The Site Editor has matured into a robust site creation tool, enabling users to build entire sites without writing a single line of PHP code. Theme.json has become the standard mechanism for defining theme settings and styles, providing a more maintainable and performant alternative to traditional PHP-based theme customization.

// theme.json example - WordPress 5.9+
// Centralized theme configuration
{
    "version": 2,
    "settings": {
        "color": {
            "palette": [
                {
                    "slug": "primary",
                    "color": "#0073aa",
                    "name": "Primary"
                },
                {
                    "slug": "secondary",
                    "color": "#23282d",
                    "name": "Secondary"
                }
            ],
            "duotone": [
                {
                    "colors": ["#000000", "#ffffff"],
                    "slug": "grayscale"
                }
            ]
        },
        "typography": {
            "fontFamilies": [
                {
                    "fontFamily": "-apple-system, BlinkMacSystemFont, 'Segoe UI', Roboto, Oxygen-Sans, Ubuntu, Cantarell, 'Helvetica Neue', sans-serif",
                    "slug": "system"
                }
            ]
        },
        "spacing": {
            "units": ["px", "em", "rem", "%", "vw"]
        }
    },
    "styles": {
        "color": {
            "background": "#ffffff",
            "text": "#333333"
        }
    }
}

#Why WordPress 4.9 still matters for classic themes

As the WordPress platform continues to evolve, it’s worth remembering version 4.9 as the “last bastion” of the classic PHP theme building approach. For developers and designers who built their careers working with template hierarchies, functions.php customization, and the Customizer API, 4.9 represents a familiar landscape that has largely given way to new paradigms.

The transition from WordPress 4.9 to the Gutenberg era was not without its challenges and controversies. Plugin compatibility issues, theme adaptation requirements, and user training needs all demanded attention from the WordPress community. However, the long-term benefits of the block-based approach - content consistency, design flexibility, and reduced reliance on custom code - have proven to be significant advantages for the platform.

For historical context and educational purposes, understanding WordPress 4.9 remains valuable. Many existing sites continue to run on themes built using traditional PHP templates, and the skills required to maintain and extend these sites remain relevant. Additionally, understanding the pre-Gutenberg architecture helps developers appreciate the design decisions that shaped the block editor and Full Site Editing capabilities.

#Conclusion

The journey from WordPress 4.9 to the Gutenberg era represents one of the most significant transitions in the platform’s history. While the change was initially met with resistance and division, the WordPress community has largely embraced the block-based approach, recognizing its potential for content flexibility, design consistency, and reduced development complexity.

WordPress 4.9 will be remembered as a pivotal moment - a sophisticated platform that had reached a high level of maturity while standing at the threshold of transformation. The features introduced in that version, from CodeMirror integration to Customizer enhancements, represented the culmination of years of incremental improvement that had made WordPress the world’s most popular content management system.

As WordPress continues to evolve, with the Gutenberg project regularly introducing new features and improvements, the platform maintains its commitment to user empowerment and developer flexibility. Whether building sites using traditional PHP themes, hybrid approaches, or full block themes, developers and designers continue to have choices that suit their needs and preferences.

The legacy of WordPress 4.9 lives on not just in the sites that continue to run on its foundation, but in the lessons learned during the transition to the block era - lessons about community, change, and the ongoing quest to democratize publishing on the web.