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.

[Christophe]

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)

[Christophe]

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.