Discussion :

[Bill Fassinou]

WordPress envisagerait de prendre en charge officiellement SQLite
afin de réduire les coûts d'hébergement et la consommation d'énergie des sites et blogues de petite taille

WordPress aurait commencé à envisager sérieusement le support de SQLite, une base de données plus légère que MySQL. Dans un billet de blogue lundi, Ari Stathopoulos, un des principaux contributeurs de WordPress, a expliqué le contexte et les raisons de cette décision. L'intéressé explique que MySQL n'est pas adapté pour certains scénarios et que les sites et blogues de petite et moyenne taille n'ont pas nécessairement besoin d'une base de données MySQL à part entière. L'équipe a donc conclu que SQLite semble être la solution idéale pour ces scénarios.

WordPress est un système de gestion de contenu (CMS) permettant d'héberger et de créer des sites Web. Il est le CMS le plus utilisé au monde. WordPress contient une architecture de plug-ins et un système de modèles, de sorte que vous pouvez personnaliser n'importe quel site Web pour l'adapter à votre entreprise, votre blogue, votre portfolio ou votre boutique en ligne. Selon le billet de blogue de Stathopoulos, le succès de WordPress s'explique en partie par le fait qu'il est extensible et qu'il peut être utilisé et modifié pour accomplir presque toutes les tâches sur le Web. Cependant, il y a un aspect de WordPress qui n'a jamais changé.

MySQL n'est pas adapté à certains cas d'utilisation de WordPress

Malgré l'augmentation des cas d'utilisation et de la popularité de WordPress, la base de données est restée la même. Le CMS nécessite l'installation de MySQL/MariaDB sur un site. Mais MySQL n'est sans doute optimal que pour certains scénarios : les sites de taille moyenne. Les grands sites mettent généralement en œuvre des piles de bases de données personnalisées en fonction de leurs besoins spécifiques. À l'extrémité inférieure du spectre, on trouve les sites simples et de petite taille. Ils sont nombreux et comprennent tous les blogues, les pages d'entreprise et les sites qui n'ont pas des milliers d'utilisateurs ou des milliers de messages, etc.

L'équipe estime que ces sites n'ont pas toujours besoin de la complexité d'une base de données MySQL/MariaDB. La nécessité d'un serveur MySQL dédié augmente leur coût d'hébergement et la complexité de l'installation. Sur les serveurs bas de gamme, les performances sont également réduites puisque la même "boîte" doit accueillir à la fois un serveur PHP et un serveur MySQL/MariaDB. « Idéalement, WordPress nous permettrait de choisir le type de base de données lors de l'installation. Cela pourrait se faire à l'aide d'un guide d'installation, ou d'une simple constante dans wp-config.php », a écrit Stathopoulos dans son billet e blogue.

Pour ce faire, WordPress devrait disposer d'une couche d'abstraction de base de données. Il ne s'agit pas d'une idée innovante ou radicale dans l'espace CMS ; Drupal dispose d'une couche d'abstraction de base de données solide depuis plus d'une décennie. Laravel, Symfony et d'autres incluent également des ORM qui permettent d'utiliser plusieurs types de bases de données. Toutefois, l'équipe pense que construire une couche d'abstraction de base de données pour WordPress serait une tâche colossale - même si à un moment donné dans le futur, elle devra peut-être l'entreprendre pour assurer l'évolution continue et la longévité du projet.

Implémentation de SQLite dans WordPress Core

En attendant, l'équipe a pensé à une solution intermédiaire : SQLite. Stathopoulos estime que l'utilisation de SQLite dans WordPress est, à ce stade, simple. Il existe des implémentations qui existent et évoluent depuis plus de 8 ans. Ces dernières ont été testées de manière approfondie et fonctionneraient de manière transparente. Elles sont des fichiers wp-content/db.php que les utilisateurs peuvent ajouter à leur installation. Cependant, la plupart des gens ne les connaissent pas. Ils ne savent pas qu'ils ont la possibilité d'acheter un hébergement moins cher sans-mysql et d'installer WordPress en utilisant une base de données SQLite.

Mais selon Stathopoulos, ils ne devraient pas non plus avoir à le savoir. Après tout, ils veulent juste un simple site d'entreprise ou un blogue. WordPress envisage donc de supporter officiellement SQLite en incluant l'une des implémentations SQLite existantes dans WordPress Core. « Nous devrions nous assurer qu'elle est correctement testée et prise en charge, et en outre, sensibiliser et exposer l'option aux utilisateurs », a écrit Stathopoulos. Pourquoi cela devrait-il être dans Core et non dans un plug-in ? Stathopoulos explique que choisir un type de base de données est quelque chose qui devrait se faire lors de la première installation d'un site.

Ce n'est pas quelque chose qui devrait être fait après coup, car cela nécessiterait de migrer les données d'une base de données à une autre, ce qui peut souvent être complexe. WordPress inclut l'implémentation de MySQL dans le noyau, donc l'équipe estime que si elle doit supporter SQLite, alors cette implémentation devrait cohabiter avec l'implémentation de MySQL. La migration des données peut (et devrait) se faire dans un plug-in afin de faciliter les migrations pour les sites existants s'ils le souhaitent, mais le moteur de base de données lui-même appartient au noyau.

Quels seraient les avantages de la prise en charge de SQLite ?

Selon Stathopoulos, le support officiel de SQLite dans WordPress pourrait avoir de nombreux avantages. En voici quelques-uns :

• des performances accrues sur les serveurs et les environnements bas de gamme ;
• potentiel de croissance de WordPress sur des marchés où il n'a pas accès en raison des exigences du système ;
• potentiel de croissance sur le marché de l'hébergement en utilisant des "scénarios" d'installation ;
• réduction de la consommation d'énergie - durabilité accrue pour le projet WordPress ;
• poursuite de la mission de WordPress visant à "démocratiser l'édition" pour tous ;
• plus facile de contribuer à WordPress - télécharger les fichiers et exécuter le serveur PHP intégré sans autre configuration requise ;
• suite de tests automatisés plus facile à utiliser ;
• les sites peuvent être "portables" et autonomes.

La prise en charge officielle de SQLite par WordPress a été discutée au WordCamp Europe 2022 en juin de cette année, et le projet semble avoir été lancé au WordCamp US 2022 le week-end dernier.

Source : Billet de blogue

Et vous ?

Quel est votre avis sur le sujet ?
Que pensez-vous de la décision de WordPress de prendre en charge SQLite ?
Quels seraient les avantages pour les utilisateurs et les développeurs ?

Voir aussi

La vulnérabilité d'un plug-in WordPress a ouvert un million de sites à une prise de contrôle à distance, cette faille permet à toute personne non identifiée d'accéder aux informations sensibles

WordPress envisage de traiter FLoC de Google comme un problème de sécurité et pourrait le désactiver automatiquement des sites Web, le CMS rappelle qu'il alimente environ 41 % du Web

Les sites WordPress seraient piratés dans les secondes qui suivent l'émission des certificats TLS, les cybercriminels utilisent abusivement le protocole Certificate Transparency proposé par Google

Des milliers de sites Web utilisent un plug-in WordPress bogué qui permet une prise de contrôle complète d'un site, toutes les versions seraient concernées et il n'y a pas de correctif

Des portes dérobées ont été trouvées dans plus de 90 thèmes et plugins WordPress, affectant plus de 360 000 sites actifs, suite à une attaque massive de la chaîne d'approvisionnement

[Depix]

Ce serait vraiment bien. J'ai quelques sites wordpress presque statiques, et je serais heureux de me débarrasser de MySQL qui utilise beaucoup de ressources.

[Pierre Louis Chevalier]

Pas sur que le gain en performance versus MySQL soit si notable que ça, et encore faudra-il que les hébergeurs décident de le supporter.

[chrtophe]

Ca risque pas de poser de problèmes aux plugins tiers ?

[smarties]

C'est sur que MySQL c'est la grosse artillerie pour un site web qui ne possède que quelques articles ou qui a un faible trafic.

De plus SQLite est très rapide, les soucis de concurrence en écriture sur les petits sites devraient être rarissimes.

Je ne fais pas de PHP mais je pense que l'on doit pouvoir laisser une connexion ouverte/avoir un pool pour pouvoir passer les requêtes

[esperanto]

ça me paraît tellement évident que je m'étonne que ce ne soit pas encore le cas. Wordpress, c'est du blog, donc généralement maintenu par une seule personne, donc les avantages de MySQL en termes de concurrence ne s'appliquent pas ici. Sauf éventuellement pour un site unique hébergeant des milliers de blogs.

L'idée ici n'est pas seulement un gain en performances (quoi qu'on économise au moins le réseau ou à minima une communication inter-processus). Le principal avantage que je vois, c'est la rapidité du déploiement. Et je préfère les sites qui pratiquent l'auto-hébergement plutôt que les grandes plateformes centralisatrices, alors tout ce qui peut faciliter le déploiement est bon à prendre.

Je serais plus réservé en revanche si Drupal ou Joomla adoptaient un jour une politique similaire. Des problèmes de concurrence avec SQLite, j'ai pu en expérimenter (j'avais un site dont la version prod utilise Postgres mais j'avais rapidement testé une version SQLite pour le dev, j'ai vite laissé tomber)

[chrtophe]

De toute façon, si ça abouti on pourra certainement choisir entre MySQL ou sqlite.

[okegima]

Bien qu'il soit possible d'ajouter plusieurs site wordpress statiques sur la même base mysql si l'on veut réduire les coûts et la consommation. Avec des suffixs différents, ça passe. De plus, d'un point de vue maintenance c'est plus facile. Mais le revers, d'un point de vu sécurité, si ça plante ou si y a un hack, c'est tous les sites qui sont indisponibles.

[Bruno]

Support officiel de SQLite pour WordPress : un nouveau module permettant de tester l'implémentation de SQLite,
introduit par Ari Stathopoulos

Dans une publication datant du 11 septembre, Ari Stathopoulos, développeur WordPress, et qui se présente également comme un évangéliste du développement durable, plaide pour un support officiel de SQLite dans WordPress. Dans un appel à l'action, Stathopoulos écrit : « Faisons-en sorte que WordPress supporte officiellement SQLite ». Plus tôt, cette semaine, il introduit un module permettant de tester l'implémentation de SQLite dans WordPress.

Il s'agit d'un travail continu en cours, mais il fonctionnerait suffisamment bien pour être inclus en tant que module expérimental. « Les problèmes ne concernent pas tant l'implémentation de SQLite elle-même que l'activation/désactivation du module et l'expérience globale de l'utilisateur au cours de ce processus », écrit Stathopoulos.

À la base, WordPress est le moyen le plus simple et le plus populaire de créer votre propre site Web ou blog. En fait, WordPress alimente plus de 43,3 % de tous les sites Web sur Internet. Oui, plus d'un site Web sur quatre que vous visitez est probablement alimenté par WordPress. D'un point de vue un peu plus technique, WordPress est un système de gestion de contenu open source sous licence GPLv2, ce qui signifie que tout le monde peut utiliser ou modifier le logiciel WordPress gratuitement. Un système de gestion de contenu est essentiellement un outil qui permet de gérer facilement les aspects importants de votre site Web, comme le contenu, sans avoir besoin de s'y connaître en programmation.

Le résultat final est que WordPress rend la création d'un site web accessible à tous, même aux personnes qui ne sont pas des développeurs. Le succès de WordPress s'explique en partie par le fait qu'il est extensible, accrochable et qu'il peut être utilisé et modifié pour accomplir presque toutes les tâches sur le Web. Cependant, un aspect de WordPress n'a jamais changé, malgré l'augmentation des cas d'utilisation et de la popularité de WordPress : la base de données.

« WordPress nécessite l'installation de MySQL/MariaDB sur un site. MySQL n'est sans doute optimal que pour certains scénarios : les sites de taille moyenne. Les grands sites mettent généralement en œuvre des piles de bases de données personnalisées en fonction de leurs besoins spécifiques, ce qui dépasse le cadre de cette proposition », écrit Stathopoulos.
SQLite est un moteur de base de données relationnelle léger accessible par le langage SQL.

Contrairement aux serveurs de bases de données traditionnels, comme MySQL ou PostgreSQL, sa particularité est de ne pas reproduire le schéma habituel client-serveur, mais d'être directement intégrée aux programmes. Selon l'équipe de développement de SQLite, le SGBD est probablement l'un des cinq modules logiciels les plus déployés, toutes descriptions confondues. Étant donné que SQLite est largement utilisé dans tous les smartphones et qu'il y a plus de 4,0 milliards de smartphones en service, chacun contenant des centaines de fichiers de base de données SQLite, il est probable qu'il y ait plus d'un trillion de bases de données SQLite en service. Cette présentation de SQLite est-elle suffisante pour plaider en faveur d’un support officiel de SQLite dans WordPress ?

Idéalement, WordPress permettrait de choisir le type de base de données lors de l'installation. Cela pourrait être fait à l'aide d'un guide d'installation, ou d'une simple constante dans wp-config.php. Pour ce faire, WordPress devrait disposer d'une couche d'abstraction de base de données. Il ne s'agit pas d'une idée innovante ou radicale dans l'espace des systèmes de gestion de contenu (content management system ou CMS en anglais); Drupal dispose d'une couche d'abstraction de base de données solide depuis plus d'une décennie. Laravel, Symfony et d'autres incluent également des ORM (Object-Relational Mapping ) qui permettent d'utiliser plusieurs types de bases de données.

Construire une couche d'abstraction de base de données pour WordPress serait une tâche colossale bien que selon Stathopoulos, ce serait une tâche que, à un moment donné dans le futur, nous devrons peut-être entreprendre pour assurer l'évolution continue et la longévité du projet. En guise de solution intermédiaire, Stathopoulos propose de mettre en œuvre une solution pour les sites et blogs de petite et moyenne taille. « Ces sites n'ont pas nécessairement besoin d'une base de données MySQL à part entière », estime-t-il. Pour lui, SQLite semble être la solution idéale :

• c'est la base de données la plus utilisée dans le monde (déjà dit) ;
• elle est multiplateforme et peut fonctionner sur n'importe quel appareil ;
• Elle est incluse par défaut dans toutes les installations PHP (sauf si elle est explicitement désactivée).

SQLite s'efforce d'être flexible en ce qui concerne les types de données du contenu qu'il stocke. Par exemple, si une colonne de la table a pour type INTEGER, SQLite essaie de convertir tout ce qui est inséré dans cette colonne en un nombre entier. Ainsi, une tentative d'insertion de la chaîne 123 se traduit par l'insertion d'un nombre entier 123. Mais si le contenu ne peut pas être converti sans perte en un nombre entier, par exemple si l'entrée est 'xyz', alors la chaîne originale est insérée à la place.

SQLite est probablement plus utilisé que tous les autres moteurs de base de données réunis. Des milliards et des milliards de copies de SQLite existent dans la nature. SQLite est présent dans :

• tous les navigateurs web Firefox, Chrome et Safari ;
• la plupart des téléviseurs et des décodeurs câble ;
• la plupart des systèmes multimédias automobiles ;
• d'innombrables millions d'autres applications ;
• toutes les instances de Skype ;
• chaque instance d'iTunes ;
• chaque appareil Android ;
• tous les clients Dropbox ;
• PHP et Python ;
• chaque Mac.

Certains développeurs apprécient la liberté qu'offrent les règles de typage flexibles de SQLite et utilisent cette liberté à leur avantage.
De l’avis de Stathopoulos, la configuration minimale requise pour WordPress serait un simple serveur PHP, sans besoin d'un serveur de base de données distinct. La prise en charge de SQLite permettrait de réduire les coûts d'hébergement, de diminuer la consommation d'énergie et de réduire les coûts de performance sur les serveurs bas de gamme.

Implémentation de SQLite dans WordPress Core

L'utilisation de SQLite dans WordPress est, à ce stade, simple ; il existe des implémentations qui existent et évoluent depuis plus de 8 ans. Elles ont été testées de manière approfondie et il a été prouvé qu'elles fonctionnent de manière transparente. Ces implémentations sont des fichiers wp-content/db.php que les utilisateurs peuvent ajouter à leur installation ; elles ne sont pas difficiles à utiliser. Cependant, la plupart des gens ne les connaissent pas. Ils ne savent pas qu'ils ont la possibilité d'acheter un hébergement moins cher sans-mysql et d'installer WordPress en utilisant une base de données SQLite.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
/**
* Plugin Name: WP SQLite DB
* Description: SQLite database driver drop-in. (based on SQLite Integration by Kojima Toshiyasu)
* Author: Evan Mattson
* This project is based on the original work of Kojima Toshiyasu and his SQLite Integration plugin.
*/
 
namespace WP_SQLite_DB {
 
use DateTime;
use DateInterval;
use PDO;
use PDOException;
use SQLite3;
 
if (! defined('ABSPATH')) {
exit;
}
 
/**
* USE_MYSQL is a directive for using MySQL for database.
* If you want to change the database from SQLite to MySQL or from MySQL to SQLite,
* the line below in the wp-config.php will enable you to use MySQL.
*
*
* define('USE_MYSQL', true);
*
*
* If you want to use SQLite, the line below will do. Or simply removing the line will
* be enough.
*
*
* define('USE_MYSQL', false);
*
*/
if (defined('USE_MYSQL') && USE_MYSQL) {
return;
}
 
function pdo_log_error($message, $data = null)
{
if (strpos($_SERVER['SCRIPT_NAME'], 'wp-admin') !== false) {
$admin_dir = '';
} else {
$admin_dir = 'wp-admin/';
}
die(<<"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
 
$message
 
$data
 
HTML
);
}
 
if (version_compare(PHP_VERSION, '5.4', '<')) {
pdo_log_error('PHP version on this server is too old.', sprintf("Your server is running PHP version %d but this SQLite driver requires at least 5.4", phpversion()));
}
 
if (! extension_loaded('pdo')) {
pdo_log_error('PHP PDO Extension is not loaded.',
'Your PHP installation appears to be missing the PDO extension which is required for this version of WordPress.');
}
 
if (! extension_loaded('pdo_sqlite')) {
pdo_log_error('PDO Driver for SQLite is missing.',
'Your PHP installation appears not to have the right PDO drivers loaded. These are required for this version of WordPress and the type of database you have specified.');
}
 
/**
* Notice:
* Your scripts have the permission to create directories or files on your server.
* If you write in your wp-config.php like below, we take these definitions.
* define('DB_DIR', '/full_path_to_the_database_directory/');
* define('DB_FILE', 'database_file_name');
*/
 
/**
* FQDBDIR is a directory where the sqlite database file is placed.
* If DB_DIR is defined, it is used as FQDBDIR.
*/
if (defined('DB_DIR')) {
if (substr(DB_DIR, -1, 1) != '/') {
define('FQDBDIR', DB_DIR . '/');
} else {
define('FQDBDIR', DB_DIR);
}
} else {
if (defined('WP_CONTENT_DIR')) {
define('FQDBDIR', WP_CONTENT_DIR . '/database/');
} else {
define('FQDBDIR', ABSPATH . 'wp-content/database/');
}
}
 
/**
* FQDB is a database file name. If DB_FILE is defined, it is used
* as FQDB.
*/
if (defined('DB_FILE')) {
define('FQDB', FQDBDIR . DB_FILE);
} else {
define('FQDB', FQDBDIR . '.ht.sqlite');
}
 
/**
* This class defines user defined functions(UDFs) for PDO library.
*
* These functions replace those used in the SQL statement with the PHP functions.
*
* Usage:
*
*
* new PDOSQLiteUDFS(ref_to_pdo_obj);
*
*
* This automatically enables ref_to_pdo_obj to replace the function in the SQL statement
* to the ones defined here.
*/
class PDOSQLiteUDFS
{
/**
* The class constructor
*
* Initializes the use defined functions to PDO object with PDO::sqliteCreateFunction().
*
* @param PDO $pdo
*/
public function __construct($pdo)
{
if (! $pdo) {
wp_die('Database is not initialized.', 'Database Error');
}
foreach ($this->functions as $f => $t) {
$pdo->sqliteCreateFunction($f, [$this, $t]);
}
}

« Ils ne devraient pas non plus avoir à le savoir... Après tout, ils veulent juste un simple site d'entreprise ou un blog. » WordPress pourrait officiellement supporter SQLite en incluant l'une des implémentations SQLite existantes dans Core. Nous devrions nous assurer qu'elle est correctement testée et prise en charge, et en outre, sensibiliser et exposer l'option aux utilisateurs.

SQLite dans Core ou dans un plugin

Le Développeur WordPress, évangéliste du développement durable, Ari Stathopoulos, étale les raisons pour lesquelles il pense que SQLite devrait être dans WordPress Core plutôt que dans un plugin. Selon lui, choisir un type de base de données est quelque chose qui devrait se produire lors de la première installation d'un site. Ce n'est pas quelque chose qui devrait être fait après, car cela nécessiterait de migrer les données d'une base de données à une autre, ce qui peut souvent être complexe.

WordPress inclut l'implémentation de MySQL dans le noyau, alors l’implémentation de SQLite devrait doit cohabiter avec elle. La migration des données peut (et devrait) se faire dans un plugin pour faciliter les migrations pour les sites existants s'ils le souhaitent, mais le moteur de base de données lui-même devrait appartnir au noyau.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
/**
         * Method to change the MySQL field types to SQLite compatible types.
         *
         * If column name is the same as the key value, e.g. "date" or "timestamp",
         * and the column is on the top of the line, we add a single quote and avoid
         * to be replaced. But this doesn't work if that column name is in the middle
         * of the line.
         * Order of the key value is important. Don't change it.
         *
         * @access private
         */
        private function rewrite_field_types()
        {
            $array_types = [
                'bit' => 'integer',
                'bool' => 'integer',
                'boolean' => 'integer',
                'tinyint' => 'integer',
                'smallint' => 'integer',
                'mediumint' => 'integer',
                'int' => 'integer',
                'integer' => 'integer',
                'bigint' => 'integer',
                'float' => 'real',
                'double' => 'real',
                'decimal' => 'real',
                'dec' => 'real',
                'numeric' => 'real',
                'fixed' => 'real',
                'date' => 'text',
                'datetime' => 'text',
                'timestamp' => 'text',
                'time' => 'text',
                'year' => 'text',
                'char' => 'text',
                'varchar' => 'text',
                'binary' => 'integer',
                'varbinary' => 'blob',
                'tinyblob' => 'blob',
                'tinytext' => 'text',
                'blob' => 'blob',
                'text' => 'text',
                'mediumblob' => 'blob',
                'mediumtext' => 'text',
                'longblob' => 'blob',
                'longtext' => 'text',
            ];
            foreach ($array_types as $o => $r) {
                if (preg_match("/^\\s*(?<!')$o\\s+(.+$)/im", $this->_query, $match)) {
                    $ptrn = "/$match[1]/im";
                    $replaced = str_ireplace($ptrn, '#placeholder#', $this->_query);
                    $replaced = str_ireplace($o, "'{$o}'", $replaced);
                    $this->_query = str_replace('#placeholder#', $ptrn, $replaced);
                }
                $pattern = "/\\b(?<!')$o\\b\\s*(\([^\)]*\)*)?\\s*/ims";
                if (preg_match("/^\\s*.*?\\s*\(.*?$o.*?\)/im", $this->_query)) {
                    ;
                } else {
                    $this->_query = preg_replace($pattern, " $r ", $this->_query);
                }
            }
        }
 
        /**
         * Method for stripping the comments from the SQL statement.
         *
         * @access private
         */
        private function rewrite_comments()
        {
            $this->_query = preg_replace("/# --------------------------------------------------------/",
                "-- ******************************************************", $this->_query);
            $this->_query = preg_replace("/#/", "--", $this->_query);
        }

Selon Stathopoulos, cela garantira que l'implémentation est correctement supportée, correctement testée, et que WordPress pourra en bénéficier. Le support officiel de SQLite dans WordPress pourrait avoir de nombreux avantages. Voici quelques-uns des avantages présentés par Stathopoulos :

• des performances accrues sur les serveurs et les environnements bas de gamme ;
• un potentiel de croissance de WordPress sur des marchés où il n’a pas accès en raison des exigences du système ;
• potentiel de croissance sur le marché de l'hébergement en utilisant des « scénarios » d'installation ;
• réduction de la consommation d'énergie - durabilité accrue pour le projet WordPress ;
• Poursuite de la mission de WordPress visant à "démocratiser l'édition" pour tous ;
• Plus facile de contribuer à WordPress - télécharger les fichiers et exécuter le serveur PHP intégré sans autre configuration requise.

Source : Github

Et vous ?

Êtes-vous pour ou contre un support officiel de SQLite pour WordPress ?

Partagez-vous, l'avis d'Ari Stathopoulos, pour une intégration dans le noyau et non dans un plugin ?

Quel est votre avis sur le sujet ?

Voir aussi :

SQLite 3.40 est disponible, le moteur de base de données léger apporte le support officiel de Wasm, une API de récupération qui pourrait récupérer une partie du contenu d'un fichier de BD corrompu

Il y'aurait plus de mille milliards de bases de données SQLite en utilisation active, faisant du SGBD le composant logiciel le plus largement déployé et utilisé

[smarties]

C'est une bonne idée car les petits sites sans les commentaires n'ont pas besoin d'accès concurrents en écriture.
La migration de MySQL vers SQLite semble possible mais l'inverse n'est pas dit explicitement.
Pour les sauvegarde de BDD c'est aussi hyper simple avec SQLite

[floyer]

Effectivement, une base de données SQLite se sauvegarde très simplement : une simple copie de fichiers. (toutefois, si on sauve le fichier pendant une transaction, cela posera problème).

Avec Mariadb, on a mariabackup qui sauvegarde les fichiers et rejoue les transactions en cours, donc pas de problème de fichier corrompu même pendant une transaction. mysqldump fonctionne assez facilement aussi (mais la restauration et longue pour des grosses bases). Par contre, à la restauration, il faut recréer une base vide (create database ...), les droits associés (grant ...). Bref, tout n'est pas si simple.