Exciting news here Quick update for anyone who’s been following the WASP project: After lots of work, WordPress is now running fully on ICP; frontend and wp-admin. No external database, no off-chain cache, no proxy or TEE VPS. Just canisters.
The thing that was blocking us for months was ICP’s per-message instruction limit. A single WordPress admin page does a lot of work, and it kept blowing past the budget and 503-ing. We didn’t make the limit bigger, we changed the shape of the app so we don’t need it to be.
The new setup is three canisters instead of one:
-Router: a tiny front door with a page cache. Anonymous visitors hit a cached page via a query call, which is basically free and instant. Most of your site’s traffic never even touches PHP.
-Worker: where PHP actually runs. It’s now a wasm64 canister with 8 GB of memory, and it can pause a request when it runs out of budget and resume it on the next call. So a heavy admin page just spans a few messages instead of dying on one.
-WASQL: the database, in its own canister, in stable memory. WordPress talks to it through a normal mysqli driver, so plugins don’t know anything weird is happening.
Result: the public site feels snappy (cache hits are query-fast), wp-admin works.
Wow congrats this is exciting! Maybe DFINITY can provide useful support to help you take this further. Separately to Wordpress, there are probably lots of ways this can be a lightning rod for general improvements to ICP, and we’re looking at a lot of things right now.
How much work do you think it would take to allow people to migrate their existing WordPress sites to the IC? I’d be very interested to know what sort of cycle burn rates can be expected for different types of example WordPress sites.
very awesome. kinda obvious in retrospective despite tech obstacles. lets see if blog based websites have any future but thats another story. is it expensive to run on the ic?
Thanks Dom Would be glad to get whatever help you guys can provide. Will be waiting for a call and until then, will be trying to optimize and speed up the beast.
Migrating will be very easy, I have a beta Wordpress plugin that will move a site from your hosting to a canister automatically then, only need to change and setup your DNS and everything should be up and running. Cost wise, my expectation for a 10 page site, should be under 15$/month at 80% cache hit and 2000 visits/month. This is a rough evaluation, maybe subject to change I have version that is running WooCommerce but it is very slow and consuming, need more work.
Could you explain more details about how it works?
For example can you explain that 80% cache hit? What that means? Or it’s just some HashMap variable in canister?
What is this WASQL in this case? Have you implemented mysql driver on motoko? How does it work under the hood? Or since canister is just wasm file you build php to wasm and it works with stable storage directly through wasm interface?
What if you create some submit form on WordPress is that data stored in canister? Is this again some kind of php → wasm → storage direct communication?
How WP web communicates with canisters? Is it through http protocol or candid?
By the way have you any relations with WP organization it self or you just communicty dev?
Orbit or some sort of DAO consensually keeping a blog / website up-to-date
For example, something like this but with powerful CMS options readily available (just need to find a way of hooking that up a proposal system, so changes require DAO consensus)
WordPress has many other system templates (CRMs, social media, etc.)
For example, why don’t we migrate this entire forum to WordPress and run it onchain? Previous reasoning for not doing this centered around Discourse being so full-featured. WordPress is full of features too…
Hey! All good questions, I’ll try to be brief.
Cache hit : Simply, instead of rendering a page every call, we put the result in a file and serve it. Its a lot faster like this. With ICP, we dont need to run updates queries every call, so we burn less cycles, cost less. Your browser use cache to avoid downloading js, css, images, html for the same page everytime.
WASQL : I developed a version of SQLITE that runs on a canister in stable memory, except that I added multi-user support and transaction support, much like MySQL. This would be a product on its own once I’m done with Wordpress.
Forms : It goes to WASQL, like a normal Wordpress.
Communication : Through Candid and Http, depends
WP organisation : No, simple dev
Quick update for anyone who’s been following the WASP project: After lots of work, WordPress is now running fully on ICP; frontend and wp-admin. No external database, no off-chain cache, no proxy or TEE VPS. Just canisters.
