// wordpress-develop, pinned per branch
"gutenberg.sha": "<commit SHA from the wp.7.0 branch>"That property decides which editor code ships in a WordPress release. The build tooling from ticket #64393 landed during the 7.0 cycle, and it pulls code from the gutenberg repository into core by pinning an exact SHA for each branch. At WordCamp Asia the committers spent real time on the follow-up question: when to bump it. The working idea was to sync the week after each Gutenberg plugin release, so any .1 and .2 patch releases happen first, and to sync weekly during beta and RC with a SHA from the matching wp/X.Y branch.
It reads like process talk, and most of it is. Jonathan Desrosiers published the meeting notes on Make WordPress Core, and they follow Chatham House Rule, so you get positions without names (which is why I won’t quote anyone directly). Between the 7.0 freeze discussion and the 7.1 wishlist there’s one paragraph about WordPress SQLite support, and I think that’s the part plugin and WooCommerce extension authors should read twice.
What the committers settled
Three decisions came out of it. First, trunk was frozen for anything unrelated to 7.0, and findings on the remaining milestone tickets went back onto the tickets themselves. Second, the gutenberg.sha pin stays on the wp.7.0 branch for 7.0, while SVN trunk moves to the upstream trunk branch after the release, which bends the old “commit to trunk first, then backport” habit. Third, the Performance Team is down to a small group of regularly active contributors maintaining 7 to 10 plugins, and the meeting agreed to write up each plugin’s status and goals so new people can step in.
The 7.1 ideas floated were the 7.0 reversals (client-side media, template organization), view transitions for logged-in users, per-template styles, and the auto-sizes work on responsive images.
Where SQLite already runs WordPress
Playground runs WordPress on SQLite, in the browser, with no server. That’s where PR previews, plugin demos and agent sandboxes happen now, and it’s where your MySQL assumptions meet a different engine. Core hit the same wall: the real-time collaboration work proposes new table structures, and the committers flagged that structures reviewed against MySQL and MariaDB may not behave the same under SQLite. Their conclusion was that core needs a firmer policy on what supporting SQLite promises.
That gap reaches plugin authors before core closes it, because nobody waits for a policy before clicking a Playground demo link.
The schema habits that fail silently
The easy assumption is that wpdb abstracts the database, or that one manual click through Playground counts as testing. wpdb abstracts the connection, and the SQLite drop-in translates a lot of MySQL syntax, but neither one rewrites your DDL. FULLTEXT indexes, zero dates, ON DUPLICATE KEY UPDATE and several ALTER TABLE forms translate differently or fail without a visible error, and a skipped ALTER you never notice is worse than a crash, because you find out later from bad data.
Here’s a table that will install cleanly on MySQL and misbehave under SQLite:
CREATE TABLE wp_example_events (
id bigint(20) unsigned NOT NULL AUTO_INCREMENT,
object_key varchar(191) NOT NULL default '',
body longtext,
created_at datetime NOT NULL default '0000-00-00 00:00:00',
PRIMARY KEY (id),
FULLTEXT KEY body_ft (body)
);The version I’d ship instead drops the MySQL-only parts:
function bbioon_create_events_table() {
global $wpdb;
$table = $wpdb->prefix . 'bbioon_events';
$charset = $wpdb->get_charset_collate();
$sql = "CREATE TABLE $table (
id bigint(20) unsigned NOT NULL AUTO_INCREMENT,
object_key varchar(191) NOT NULL default '',
body longtext,
created_at datetime NOT NULL default '1970-01-01 00:00:00',
PRIMARY KEY (id),
KEY object_key (object_key)
) $charset;";
require_once ABSPATH . 'wp-admin/includes/upgrade.php';
dbDelta( $sql );
}There’s no FULLTEXT, so search becomes a LIKE or a normalized keywords column. There are no zero dates either, which strict MySQL modes and SQLite both dislike. And dbDelta still wants its quirks respected: two spaces after PRIMARY KEY, KEY rather than INDEX, one statement per table.
What I’d test first
- Copy a staging site onto SQLite with the SQLite database integration plugin and run activation plus every migration you ship.
- Load the heaviest pages: search, anything sorting on a custom column, admin list tables with
meta_query. - Check
$wpdb->last_errorafter schema changes, because a skippedALTERcan pass silently.
If you ship a plugin or a WooCommerce extension with custom tables and want a second pair of eyes on the schema plus a proper SQLite test pass, that’s work I do regularly, so get in touch before your next release rather than after the support ticket.
When you can skip this
If your code only touches core tables through $wpdb->insert, $wpdb->update and WP_Query, your risk is low, because core’s own compatibility work covers most of that path. Custom tables, importers and hand-written SQL are where the divergence shows up. Until core publishes a support level, treat SQLite as “installs and keeps data intact” rather than “behavior is guaranteed identical”, and watch the follow-up discussion on Make Core before you promise a client anything stronger.
