WordPress 6.8 “Cecil” arrived on April 15, 2025. It was not a flashy redesign. Its most important changes were quieter: faster page transitions, stronger password hashing, a better Style Book, accessibility improvements, and performance work inside the editor and database.
More than a year later, WordPress has moved through 6.9 and 7.0 to WordPress 7.1 “Mary Lou,” released August 19, 2026. That makes 6.8 an older release, but it is still worth understanding because several ideas that felt new then became part of the platform’s current direction.
WordPress 6.8 Was Released April 15, 2025
WordPress 6.8 was code-named “Cecil” in honor of jazz pianist Cecil Taylor. The release focused on refinement rather than forcing site owners to learn a completely new interface.
The official WordPress 6.8 release announcement highlighted four especially visible areas: a redesigned Style Book, speculative loading, bcrypt password hashing, and more than 100 accessibility fixes and enhancements.
There were also editor changes, query and caching improvements, developer updates, and work on the Interactivity API. In other words, 6.8 was less about one giant feature and more about making everyday WordPress work feel cleaner.
Speculative Loading Was the Performance Headline
WordPress 6.8 added speculative loading to Core using the browser’s Speculation Rules API. The basic idea is simple: when the browser has a strong hint about where a visitor may go next, it can begin preparing that page before the visitor actually completes the navigation.
That can make some internal page transitions feel nearly instant. It is especially useful on sites where visitors naturally move from a home page to an article, from a category to a post, or from one piece of related content to another.
The original article described this as the browser merely “warming up” links. That was too vague. WordPress can use prefetching or prerendering behavior through the Speculation Rules API, depending on configuration and browser support.
Speculative Loading Does Not Fix a Slow Site by Itself
A slow database, oversized images, poor hosting, too much JavaScript, weak caching, or a badly built theme will still be slow. Speculative loading can improve the transition to a page, but it does not erase the underlying work needed to generate and render that page.
That is why performance still begins with the foundation. Our WordPress hosting guide explains why server resources, caching, PHP configuration, backups, and support quality can matter more than one performance feature in Core.
It also means site owners should measure real pages instead of deciding a site is “fast” because clicking around feels better on one browser.
Older Browsers Simply Ignore the Feature
Speculative loading depends on browser support. WordPress designed the feature so unsupported browsers can continue navigating normally rather than breaking the site.
That graceful fallback is important. Performance improvements should not require every visitor to use the newest browser on the newest device.
The Style Book Became More Useful
WordPress 6.8 reorganized the Style Book with clearer labels and a more structured layout. The Style Book lets site owners preview how common blocks and design elements look together instead of opening many pages just to check headings, buttons, lists, quotes, and other elements.
The bigger change was broader availability. In 6.8, the Style Book became available for qualifying Classic themes that use editor styles or a theme.json file, not only block themes.
That made global design work more approachable for sites that had not moved fully into block-theme architecture.
Global Styles Work Best When the Theme Has a System
A Style Book is most useful when typography, color, spacing, and block styles are treated as a system rather than one-off choices.
If every page has hand-set font sizes, custom colors, and inline spacing, changing the theme later becomes harder. Our guide to customizing a WordPress theme covers the larger principle: use theme-level rules for repeated design decisions and page-level exceptions only when they are actually needed.
WordPress 6.8 Changed Password Hashing to bcrypt
One of the most important 6.8 changes happened where most site owners never saw it. WordPress replaced its old default phpass-based password hashing with bcrypt.
Password hashing does not store a readable copy of your password. It transforms the password into a value that can be checked later. A strong password-hashing algorithm is intentionally expensive for attackers to brute-force if a password database is stolen.
WordPress handled the transition automatically. Existing passwords continued working and could be rehashed using bcrypt after a successful login. Site owners did not need to reset every user’s password just because they upgraded to 6.8.
Other Security Keys Also Changed
WordPress 6.8 also changed hashing for application passwords, password-reset keys, personal-data request keys, and recovery-mode keys to use BLAKE2b through Sodium.
These changes were mostly invisible in the dashboard, which is exactly how good infrastructure security often feels. The site keeps working while the underlying protection improves.
Security Still Depends on More Than Core
Moving to bcrypt did not make every WordPress site automatically secure. Weak administrator passwords, abandoned plugins, vulnerable themes, stolen credentials, excessive user privileges, and poor server security can still create serious problems.
Core improvements reduce risk. They do not replace updates, backups, least-privilege accounts, multifactor authentication where appropriate, and sensible hosting security.
Accessibility Work Was Larger Than One Feature
WordPress reported more than 100 accessibility fixes and enhancements in 6.8. Those changes touched bundled themes, navigation-menu management, the Customizer, labeling, blocks, Data Views, and other editor experiences.
Accessibility releases can feel less dramatic than a new visual feature because many improvements involve keyboard behavior, labels, focus, semantics, contrast, or screen-reader experience. For people who depend on those details, however, they determine whether the interface can be used at all.
Data Views Improved, but the Old Article Overstated Them
WordPress 6.8 included improvements to Data Views and made options easier to see. The original article went further and described a polished system of saved role-specific views and workflows as though all of that were already a finished Core feature.
That was too broad. Data Views were—and remain—an evolving part of WordPress administration. Site owners should distinguish what Core actually provides from workflows created by plugins or custom development.
The Query Loop Also Got a Useful Small Change
One practical 6.8 editor change was the ability to exclude sticky posts from Query Loop results. It is a small option, but it solves a real publishing problem when a sticky post should remain prominent on one page without being duplicated inside another automated content list.
WordPress releases are often full of improvements like this. They are not headline features, but they remove repeated friction from real publishing work.
Performance Work Went Beyond Page Navigation
The WordPress performance team documented two dozen performance-related changes around 6.8. Work included query caching, block registration, editor performance, the Interactivity API, and other Core optimizations.
The lesson is important because site speed rarely comes from one switch. Small improvements in database queries, block loading, browser behavior, caching, and rendering can add up across millions of page views.
WordPress 6.9 Arrived in December 2025
The old version of this post included a long section titled “How We Get Ready for 6.9.” That advice is now historical. WordPress 6.9 “Gene” shipped on December 2, 2025.
Among its visible changes were Notes for block-level collaboration, broader Command Palette capabilities, and the Abilities API, which helped establish a more standardized foundation for AI-capable WordPress tools.
WordPress 7.0 Followed in May 2026
WordPress 7.0 “Armstrong” was released May 20, 2026 after its release schedule shifted from an earlier target. It pushed WordPress further toward AI integration, collaboration, and a refreshed administrative experience.
That broader AI direction also helps explain the interest in tools that can build or edit sites from plain-language instructions. Our article on WordPress.com’s AI Site Builder looks at one product-layer example while keeping it separate from the features that ship in open-source WordPress Core.
WordPress 7.1 Is the Current Major Release
As of August 31, 2026, WordPress.org lists WordPress 7.1 “Mary Lou” as the latest major release. It shipped on August 19.
WordPress 7.1 continues the move toward a more responsive and collaborative editing system. The release includes stronger responsive styling controls, a redesigned media editor, richer Notes with mentions and inline feedback, image-processing improvements, and continued work across the admin and editor experience.
That context changes how we should read a 6.8 article today. We are no longer deciding whether to prepare for 6.9. We are looking back at the release that helped establish several foundations still being extended in 7.x.
Do Not Stay on 6.8 Just Because It Was a Good Release
A historical article praising 6.8 should never be read as advice to keep a production site frozen on 6.8.
WordPress security and maintenance releases continue after major releases. Running an old branch longer than necessary can leave a site without current fixes and can eventually create plugin, theme, PHP, and hosting compatibility problems.
The normal goal should be a supported, current WordPress version that your active theme and plugins have been tested against.
A Better WordPress Upgrade Routine
- Back up files and the database. Confirm that the backup can actually be restored.
- Use staging for important sites. Test the Core update with the same theme, plugins, PHP version, and major configuration used in production.
- Update supported plugins and themes. Read compatibility notes when a release changes APIs your site depends on.
- Test critical workflows. Logins, forms, checkout, search, account pages, scheduled jobs, email, caching, and custom admin screens deserve attention.
- Check the front end on mobile and desktop. Look for layout changes, JavaScript errors, broken menus, and unexpected styling.
- Review logs. PHP warnings and fatal errors often reveal compatibility problems before users report them.
- Have a rollback path. Know how to restore the database and files if the update fails.
Custom Plugins Deserve Extra Testing
Sites with custom plugins, custom blocks, unusual admin interfaces, or deep WooCommerce modifications deserve more testing than a basic brochure site.
A Core release can change CSS, editor components, REST behavior, deprecated functions, block markup, or JavaScript dependencies without breaking ordinary sites. Custom code may rely on the exact behavior that changed.
That is why “WordPress updated successfully” is only the first test. The real test is whether the business workflow still works.
Measure Performance Instead of Describing It
The original article said pages simply “felt faster.” That can be useful as an observation, but it is not enough to prove a performance improvement.
Measure representative pages before and after major changes. Look at Core Web Vitals, server response time, cache hit rate, database behavior, JavaScript execution, image weight, and real-user data where available.
A feature such as speculative loading may make navigation feel excellent while an uncached landing page still has a poor Largest Contentful Paint. Both facts can be true at once.
Why 6.8 Still Matters
WordPress 6.8 matters less because of its version number and more because of the direction it showed.
- Performance became smarter at the browser level with speculative loading.
- Password storage moved to a stronger modern hashing approach.
- The Style Book became useful to more themes.
- Accessibility work continued across many parts of Core.
- Data Views and the editor kept moving toward a more unified administrative experience.
- Performance improvements were spread through Core instead of being presented as one magic optimization.
Those are durable ideas. WordPress 7.1 looks different from 6.8, but the larger direction is recognizable: faster navigation, more consistent design systems, better collaboration, stronger platform APIs, and less friction between the person managing the site and the work they are trying to publish.
From Cecil to Mary Lou
WordPress 6.8 was a good release because much of its value did not demand attention. Password protection improved automatically. Supported browsers could navigate faster. Designers got a better global view of styles. Editors received dozens of smaller improvements.
The right way to use that history in 2026 is not to stay frozen on 6.8. It is to understand what changed, keep the useful lessons, and run a current WordPress release after proper compatibility testing.
WordPress has already moved from Cecil to Gene, Armstrong, and Mary Lou. A well-managed site should move too—carefully, with backups and testing, but without turning an old version into a permanent home.