I'm curious as to how useful this will be. Tying it to SQLite makes it portable, but abstracting it so that it can be used with any db would be far more powerful. Why? Because the SQLite implementation is enough to get it working in the browser, but it does not make WordPress 100% SQLite compatible. For example, a WordPress site built on MySQL can't be migrated into an SQLite powered WordPress using a common migration plugin. I know, because I tried.
I installed WordPress in a standard PHP environment, and use the db.php dropin and SQLite compatibility plugin, and actually got WordPress installed on the file system. It works, but when I tried to migrate using all-in-one-wp-migration, it failed.
A neat concept with niche use, but not a panacea for agencies and other devs who need an extensive playground, even if it's self hosted on a persistent PHP server.
> For example, a WordPress site built on MySQL can't be migrated into an SQLite powered WordPress using a common migration plugin. I know, because I tried.
Ok, didn't expect that response! I tried this today.
I admit I didn't try super hard- I have a lot of other things to work on, was a 20 minute curiosity mission. I just downloaded the zip file and grabbed the files out of that. Don't get me wrong- it worked- but I couldn't do an import as mentioned.
If you want lots of detail, I can spend more time on it. Email me at my hn user at the google mail.
the Playground can connect to a MySQL instance when running in a Node environment. it's not supported in the browser because there's no existing mechanism to relay the necessary socket connection there.
I installed WordPress in a standard PHP environment, and use the db.php dropin and SQLite compatibility plugin, and actually got WordPress installed on the file system. It works, but when I tried to migrate using all-in-one-wp-migration, it failed.
A neat concept with niche use, but not a panacea for agencies and other devs who need an extensive playground, even if it's self hosted on a persistent PHP server.