Open davidjeba opened 1 year ago
Hello, I didn't want to create new issue, but I ask how to install this plugin in server that suppose to not have MySQL or functional WP website?
when I tried to activate it i got this message :-
The SQLite plugin cannot be activated because a different wp-content/db.php drop-in already exists.
I'm sing the older wp-sqlite-db
plugin which required copy the file db.php
into wp-content/db.php
but that not
With this plugin I found it path is /wp-content/plugins/sqlite-database-integration-2.0.0/wp-includes/sqlite/db.php
should I copy it again t0 wp-content folder?
Can you consider CockroachDB, SurrealDB, Mongo Realm
@davidjeba This is a really potent idea! The first step would be identifying all the MySQL-specific constructs in WordPress core. Here's a few examples:
DELETE from a, b
wpdb
methods that are only relevant when MySQL is usedI'm sure there's more than that – these just come from the chat I had with @OllieJones and @aristath last week about this specific subject.
Once the MySQL-specific parts are clear, there are a few ways to proceed:
Furthermore, @OllieJones had an idea to support dedicated table schemas for different database engines – e.g. PostgreSQL could use FULLTEXT indexes out of the box.
I ask how to install this plugin in server that suppose to not have MySQL or functional WP website?
@SalimF I encourage you to start a new issue. Let's keep this one focused on supporting additional DB backends.
Something else that came up during the chat I mentioned above:
Another thing to contemplate: Some applications out there in the world implement a lot of so-called "business logic" directly in SQL (with a code base containing hairy JOIN statements &c) Others use an abstraction layer -- an ORM -- to implement the business logic. WordPress's abstraction layer is WP_Query and friends, and the SQL layer is $wpdb.
A lot of code violates the layering, using WP_Query and $wpdb.
It's not easy to change a deployed app to move its SQL-layer business logic to an ORM layer. So I think it might be good to approach the problem from a SQL-centric point of view, rather than an enforce-ORM point of view.
Can you consider