Conversation
Contributor
🤖 Lexer benchmarkChanges to lexer-related files were detected and triggered a benchmark:
Note: Hosted runners are noisy, and absolute numbers vary. Treat the results with caution and verify them locally. To reproduce locally: |
JanJakes
commented
Aug 3, 2026
| define( 'DB_ENGINE', 'sqlite' ); | ||
| } elseif ( defined( 'DATABASE_ENGINE' ) ) { | ||
| // backwards compatibility with previous versions of the plugin. | ||
| define( 'DB_ENGINE', DATABASE_ENGINE ); |
Member
Author
There was a problem hiding this comment.
Drop the DATABASE_ENGINE input alias now that DB_ENGINE is the supported configuration API.
Delete the broken development-only MySQL crosscheck path from the runtime plugin and its release contents.
JanJakes
force-pushed
the
removals
branch
3 times, most recently
from
August 3, 2026 10:02
004e0b2 to
ed06848
Compare
Stop exposing magic access to private driver state and remove the private-method relay that existed only for compatibility tests. Remove the redundant facade assignment that depended on the magic setter.
Make translation helpers and self-contained constant maps private.
Keep parser, native bridge, connection, schema, and diagnostic plumbing outside the public 3.0 compatibility contract.
Document WP_SQLite_Driver as deprecated in 3.0 with WP_MySQL_On_SQLite as its replacement.
The migration path has been broken since 2023, when direct file deletion was replaced with $wp_filesystem->delete() without initializing the WordPress filesystem. Remove its upgrade handler, UI, and notice compatibility now that the former module is obsolete.
Expose the active MySQL-on-SQLite driver through WP_SQLite_DB and its underlying SQLite PDO through WP_MySQL_On_SQLite. Stop treating the compatibility global as a connection input. Retain it temporarily as a deprecated output alias while consumers migrate to the explicit accessors.
Align the exception class with the WP_MySQL_On_SQLite API name. Do not retain the obsolete class name because no external runtime usage was found.
Align the concrete statement class with the WP_MySQL_On_SQLite API name and replace the obsolete proxy terminology. Do not retain an alias because public code searches found no external dependency on the old class name.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
This narrows the API surface that WordPress SQLite Integration 3.0 will commit to by removing obsolete compatibility paths and explicitly classifying implementation details. It keeps
WP_MySQL_On_SQLiteas the primary driver while retainingWP_SQLite_Driveronly as a deprecated compatibility facade until 4.0.DATABASE_ENGINEinput alias in favor ofDB_ENGINE.$wp_filesystemwithout initializing the WordPress filesystem.@access privateannotations.WP_SQLite_Driverin favor ofWP_MySQL_On_SQLite, with removal planned for 4.0.