-
-
-
SurveyJS
Open-Source JSON Form Builder to Create Dynamic Forms Right in Your App. With SurveyJS form UI libraries, you can build and style forms in a fully-integrated drag & drop form builder, render them in your JS app, and store form submission data in any backend, inc. PHP, ASP.NET Core, and Node.js.
-
-
wordpress-develop
WordPress Develop, Git-ified. Synced from git://develop.git.wordpress.org/, including branches and tags! This repository is just a mirror of the WordPress subversion repository. Please include a link to a pre-existing ticket on https://core.trac.wordpress.org/ with every pull request.
> Is there a reason why using OPFS directly from SQLite doesn't work?
I'm guessing this means using SQLite WASM's built-in OPFS integration as described in these articles:
- sqlite3 WebAssembly documentation - Persistent Storage Options: OPFS - https://sqlite.org/wasm/doc/trunk/persistence.md#opfs
- SQLite Wasm in the browser backed by the Origin Private File System - https://developer.chrome.com/blog/sqlite-wasm-in-the-browser...
Within the Playground, SQLite interacts with the database file in MEMFS only, and the Playground coordinates the syncing from MEMFS to OPFS.
https://github.com/WordPress/wordpress-playground/tree/trunk...
The reason for this, I believe, is that the primary use case is/was to have the entire file system in memory, including SQLite's database file. This was the original implementation, and is still the default behavior. Persistence was later added as an optional feature.
The good news is that browser support for OPFS seems to be getting better. From the SQLite docs:
As of March 2023 the following browsers are known to have the necessary APIs:
> 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.
Out of curiosity, how recently did you try?
We're using a new SQLite integration that seems to be pretty good at translating SQL to SQLite: https://github.com/WordPress/sqlite-database-integration
We'd be curious to learn more about how it failed. It's definitely an area we'd like to improve.
The problem is architectural.
Wordpress at its core execute most of its user-facing code trough an un-parallelizable, self-modifying single threaded queue, which has to be run at every page reload[1] and everything and anything will have to inject stuff in it. From handling your pictures in your media library, to checking your server can actually send mails, to managing your page and posts content and layout, everything goes trough it. It's also a system that doesn't really play ball very easily with most PHP accelerators outside of baseline PHP opcache. You may have better luck using a static cache or memcached. Depending on the theme you're using (90% of what's available from envato themeforest, for example) the improvement will be negligible.
All of the data you're accessing is also for the most part queried from two tables of a single database instance[2] which again handles everything from your mail configuration, page routing and redirection, page layout, contents, stored forms, etc. No sharding, load balancing is natively available. Heck, most WP hosted solutions run MySQL on the same instance running Apache and PHP. Also the data is usually stored as serialized php values, which have to be parsed and reformatted, again, at every page load using the system described beforehand.
[1]https://github.com/WordPress/wordpress-develop/blob/6.2/src/...
[2]https://codex.wordpress.org/Database_Description