Let’s make WordPress officially support SQLite

WordPress can be (and is) used for any kind of site, regardless of size or complexity. Some common use-cases include:

  • Single-page landing sites
  • Simple company sites with just a few pages. These sites are usually rarely updated and are essentially static sites with an administration aspect.
  • Simple, single-user blogs
  • Complex news sites
  • e-Commerce sites
  • Full-fledged CMS solutions

Part of the success of WordPress is because it is extendable, hookable, and can be used and tweaked to accomplish almost any task on the web.

However, one aspect of WordPress has never changed, regardless of the increase in WP’s use cases and popularity: The database. WordPress requires MySQLMySQL MySQL is a relational database management system. A database is a structured collection of data where content, configuration and other options are stored. https://www.mysql.com/./MariaDB to be installed on a site. MySQL is arguably only optimal for some of the scenarios: The “mid-tier” range of site types.

Large sites usually implement custom database stacks depending on their specific needs, so are beyond the scope of this proposal.

On the lower end of the spectrum, there are small and simple sites. These are numerous and consist of all the blogs, company pages, and sites that don’t have thousands of users or thousands of posts, etc. These websites don’t always need the complexities of a MySQL/MariaDB database. The requirement of a dedicated MySQL server increases their hosting cost and the complexity of installation. On lower-end servers, it also decreases performance since the same “box” needs to cater to both a PHPPHP The web scripting language in which WordPress is primarily architected. WordPress requires PHP 5.6.20 or higher and a MySQL/MariaDB server.

The ideal scenario

Ideally, WordPress would allow us to choose the type of database during installation. That could be done using an installation guide, or a simple constant in wp-config.php. To accomplish that, WordPress would need to have a database-abstraction layer. This is not an innovative or radical idea in the CMS space; Drupal has had a solid database-abstraction layer for more than a decade. Laravel, Symfony, and others also include ORMs that allow using multiple database types.

Building a database abstraction layer for WordPress would be a colossal task – though it might be one that, at some point in the future, we may have to undertake to ensure the project’s continued evolution and longevity.

A middle ground

As a middle ground, we could implement a solution for the bottom tier: small to medium sites and blogs. These sites don’t necessarily need a full-fledged MySQL database.

SQLite seems to be the perfect fit:

  • It is the most widely used database worldwide
  • It is cross-platform and can run on any device
  • It is included by default on all PHP installations (unless explicitly disabled)
  • WordPress’s minimum requirements would be a simple PHP server, without the need for a separate database server. 
  • SQLite support enables lower hosting costs, decreases energy consumption, and lowers performance costs on lower-end servers.

Implementing SQLite in WordPress CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress.

Using SQLite in WordPress is, at this point, simple; There are implementations out there that have been around and evolving for more than 8 years. They have been thoroughly tested and proved to work seamlessly. These implementations are drop-in wp-content/db.php files that users can add to their installation; they are not hard to use. 

However, most people are not aware of them. They are not aware that they have the option to buy cheaper hosting sans-mysql and then install WordPress using an SQLite database. Nor should they have to know about it… After all, they just want a simple company site or a blogblog (versus network, site)

WordPress could officially support SQLite by including one of the existing SQLite implementations in Core. We would need to ensure that it is properly tested and supported, and additionally, raise awareness and expose the option to users.

Why should this be in Core and not a pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party

Picking a database type is something that should happen when a site is first installed. It is not something that should be done after the fact because that would require migrating data from one database to another, which can often be complex. 

WordPress includes the MySQL implementation in Core, so if we support SQLite then that implementation should live alongside it. 

Data migrationMigration Moving the code, database and media files for a website site from one server to another. Most typically done when changing hosting companies. can (and should) be in a plugin to facilitate migrations for existing sites should they wish to do that, but the database engine itself belongs in Core. 

That will ensure that the implementation is properly supported, properly tested, and WordPress will be able to benefit, as detailed in the following section.

What would the benefits of SQLite be?

Officially supporting SQLite in WordPress could have many benefits. Some notable ones would include:

  • Increased performance on lower-end servers and environments.
  • Potential for WordPress growth in markets where we did not have access due to the system’s requirements.
  • Potential for growth in the hosting market using installation “scenarios”.
  • Reduced energy consumption – increased sustainability for the WordPress project.
  • Further WordPress’s mission to “democratize publishing” for everyone.
  • Easier to contribute to WordPress – download the files and run the built-in PHP server without any other setup required.
  • Easier to use automated tests suite.
  • Sites can be “portable” and self-contained.

Next steps

The next steps would need to be discussed in the comments section of this proposal. If there is consensus to implement SQLite in WordPress Core, an outline of the next steps would look something like this:

  • Create the necessary TracTrac An open source project by Edgewall Software that serves as a bug tracker and project management tool for WordPress. tickets
  • Decide how the database type would be defined. The most simple scenario would be a DATABASE_TYPE constant in wp-config.php, allowing users to choose if their new site would use a MySQL or SQLite database, but there can be other solutions that come up during a later discussion.
  • Port an SQLite implementation to WordPress Core, applying the necessary changes like coding standards, in-code documentation, migrate tests, etc.
  • Test WordPress Core functionality with SQLite
  • Outreach to plugin developers for testing.

The subject of database abstractions and using SQLite was discussed at length during WCEU 2022, in an unofficial capacity, in the hallways. This post is a distilled culmination of these conversations to bring the discussion to the broader community for serious consideration.

Props @zieladam, @mamaduka, @jonoaldersonwp, @tweetythierry, @SergeyBiryukov, @joostdevalk, @dingo_d, @desmith, @crixu, @williampatton, @costdev, @adamsilverstein, @JavierCasares, @robinwpdeveloper, @aaemnnosttv, @jessibelle for reviewing and contributing to this proposal.

#database, #install, #performance, #sustainability

Dev Chat Summary: September 16 2020

Greetings! Here’s what happened in the coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. dev chat on Wednesday, September 16, 2020, 05:00 UTC and Wednesday, September 16, 2020, 20:00 UTC, following this agenda.

05:00 UTC core dev chat

@thewebprincess facilitated the meeting and took notes. Find the full Slack archive here.

20:00 UTC core dev chat

@thelmachido facilitated the meeting and @laurora took notes. The full Slack archive can be viewed here.

Both groups followed this agenda: https://make.wordpress.org/core/2020/09/15/dev-chat-agenda-september-16th-2020/ 

Announcements

@pbiron shared that there will be an Upgrade/Install component bugbug A bug is an error or unexpected result. Performance improvements, code optimization, and are considered enhancements, not defects. After feature freeze, only bugs are dealt with, with regressions (adverse changes from the previous version) being the highest priority. scrub today (September 17) at 18:00 UTC. Everyone is welcome to attend! More info can be found here: https://make.wordpress.org/core/2020/09/16/upgrade-install-component-bug-scrub-for-wordpress-5-6 

@flixos90 would like more thoughts and feedback on a proposal to enhance image preview: https://make.wordpress.org/core/2020/09/15/enhancing-image-preview-core-proposal/. Please leave your comments on the post.

Due to the speed WP5.6 is moving at, and some unexpected items (oEmbed & PHPPHP The web scripting language in which WordPress is primarily architected. WordPress requires PHP 5.6.20 or higher 8.0), @chanthaboune has organized a meeting with the 5.6 release squad to discuss. This will take place today (September 17) at 20:00 UTC. @helen proposed streaming the meeting and the squad is still deciding whether to do this. In any case, notes will be taken and published.

Highlighted Posts

A bug scrub was held before the 20:00 UTC dev chat: https://make.wordpress.org/core/2020/09/15/i18n-component-bug-scrub-for-wordpress-5-6/. @helen explained that updates were left on tickets reviewed from the TracTrac An open source project by Edgewall Software that serves as a bug tracker and project management tool for WordPress. reports, and @justinahinon added that progress has been made on all i18ni18n Internationalization, or the act of writing and preparing code to be fully translatable into other languages. Also see localization. Often written with a lowercase i so it is not confused with a lowercase L or the numeral 1. Often an acquired skill. 5.6 slated tickets.

Updates from Component Maintainers/Focus Leads

Upgrade/Install
Will explore adding some UIUI User interface elements to manage email notifications on pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party and theme auto-updates.
@audrasjb highlighted the bug scrub taking place today (September 17) at 18:00 UTC.

Privacy
@carike reported: “We have been receiving a lot of feedback, for which we are very grateful. Will update tickets over the next few days with more details on the proposed application design.”

Comments
@imath requested a second opinion on ticketticket Created for both bug reports and feature development on the bug tracker. #50521, and also shared that he’s been working with @dshanske on writing a kick-off post to launch a project to develop the WP Comment Types feature from a plugin. They would like guidance on how to make this post public on make.wordpress.org/core.

Site Health
@clorith shared that they’re doing some multisitemultisite Used to describe a WordPress installation with a network of multiple blogs, grouped by sites. This installation type has shared users tables, and creates separate database tables for each blog (wp_posts becomes wp_0_posts). See also network, blog, site work for this cycle and besides that general bug watching.

(Classic) Menus and Widgets
@audrasjb reviewed some tickets with a patchpatch A special text file that describes changes to code, by identifying the files and lines which are added, removed, and altered. It may also be referred to as a diff. A patch can be applied to a codebase for testing. and put a few of them into milestone 5.6.

Build/Test Tools
@johnbillion noted the continued progress on PHP 8 compatibility.

Design
@karmatosed shared “A little note if any components/focuses want design help this release just pop a keyword on or hop into #design. There’s an awesome group of people ready to help this release so great to catch all those little tickets and things.”

Open Floor

@bduclos asked if there are any mockups of the new Twenty Twenty One theme available, and will the project be on GithubGitHub GitHub is a website that offers online implementation of git repositories that can easily be shared, copied and modified by other developers. Public repositories are free to host, private repositories require a paid subscription. GitHub introduced the concept of the ‘pull request’ where code changes done in branches by contributors can be reviewed and discussed before being merged be the repository owner. https://github.com/. @melchoyce will be sharing more details about this in a post, due to be published soon.

There was a lot of discussion regarding the announcement from Facebook & Instagram that they’ll be dropping unauthenticated oEmbed support; mainly around timing and how to communicate this update to WordPress users.
It was noted that the removal of those blocks in v9.0 of GutenbergGutenberg The Gutenberg project is the new Editor Interface for WordPress. The editor improves the process and experience of creating new content, making writing rich content much simpler. It uses ‘blocks’ to add richness rather than shortcodes, custom HTML etc. https://wordpress.org/gutenberg/ is complete – if need be it can be reverted.
@whyisjake volunteered to put a post together so that the conversation could be continued.

There was an update in response to privacy/data deletion request in issue #43437. It is not anticipated that there will much of a change to the current tools. Concluding with it is not foreseen that there will be any significant breaking type changes for the ticket.

A proposal was put forward to create a #sustainability SlackSlack Slack is a Collaborative Group Chat Platform https://slack.com/. The WordPress community has its own Slack Channel at https://make.wordpress.org/chat/. channel for those interested in improving the sustainability of WP, through performance enhancements and more. @isabel_brison is putting together a blogblog (versus network, site) post to discuss further. @webcommsat shared this post: https://make.wordpress.org/marketing/2020/06/01/sustainability-working-group-update/ which details some of the work that has been done in this area so far.

@webcommsat highlighted that a week celebrating WordPress translationtranslation The process (or result) of changing text, words, and display formatting to support another language. Also see localization, internationalization. will take place from 28 September to 4 October 2020. If you have any ideas on how the translation process for WordPress releases could be promoted, please leave comments on this post: https://make.wordpress.org/polyglots/2020/09/09/lets-celebrate-international-translation-day-together/.

Next Dev Chat meetings

The next meetings will take place on Wednesday, September 23, 2020, 05:00 UTC and Wednesday, September 23, 2020, 20:00 UTC in the #core Slack channel. Please feel free to drop in with any updates or questions.

#5-5-1#5-5-2#5-6#dev-chat#summary

#5-6, #dev-chat, #summary