Make WordPress

> There is far less separation between data and how it's presented than there ever was with the "classic" editor.

This is not correct, surely?

Yes, if you're using FSE you're getting a template from that which is more or less a page. FSE replaces the header/footer/sidebar/widget area thing with an editable scheme.

That is, on one level, a big chunk of HTML -- but it is stored as a block graph (see below). And as far as I am aware the work has been done to allow it to produce HTML5 semantic tags?

There is an insertion point in the FSE template for content from hooks or the loop, which may or may not be returning block graphs. Post content can also now contain loops as created by query blocks, etc.

And yeah, Gutenberg stores as HTML internally.

But the distinction I am drawing here still holds.

The classic model was a blob of post content that was minimally post-processed to expand shortcodes. It didn't attempt to understand the HTML except in a minimal way to figure out if a shortcode should end up in a wrapper tag.

The rest of it was sent straight out into the page (after autop). TinyMCE then tried to deal with it, and had to recognise shortcode patterns. That is what I mean by a "blob": most HTML was handled in an unthinking, unprocessed manner. As text.

In the Gutenberg era they still do store HTML in post_content (for good reason) but it is in a form that can be serialised and deserialised into blocks -- it is not simply markup; it's a complete serialisation…

This line of discussion ("Make it so we can pay you $xxK/mo, don't ask for donations.") comes up a lot on HN.

Here's what I did:

First, I spent four years developing security libraries for PHP developers that can be considered core infrastructure. Random_compat was an API-compatible polyfill of PHP 7's random_bytes() and random_int() functions for PHP 5 projects (and has over 100 million downloads). sodium_compat reimplemented most of libsodium in pure-PHP, and currently powers WordPress's signature verification functions. That's just two examples, I have over a dozen of distinct and useful libraries-- many of which have been adopted into popular frameworks-- that make your software materially more secure. If you're a serious player in the industry and your code base is PHP, you're running my code.

Okay, value delivered through open source? Check.

All of the above was also published through an LLC rather than just under an individual's name.

Then, I began offering the usual HN recommendations (support contracts, especially for EOL versions of PHP for Enterprise Linux customers).

I even created a streamlined workflow section on the company website and linked all of our open source projects to it: https://paragonie.com/enterprise

To date, the SQL tables that power that section of our website only has test records I created to make sure it was turned on correctly.

So I believe this to mean one of two things:

1. There's a missing step that I'm not doing that, once…

> trivial to build

The point was it isn't built, where as there's auto completion support for emojis which wouldn't even need that "trivial" software. That's in the matrix's sdk. If it's so trivial, please, build for the IRC community. I use hexchat on my desktop and weechat on the server. Would you mind building me one if it is trivial?

> That's irrelevant. You claimed that the simplicity of the IRC protocol was something unobtainable with those features. That's what I am disputing.

Fine, I concede. But I'm surprised you're still going for this. I tried out a bunch of different IRC applications and couldn't find search in any. Oh well.

> It's precisely about whether it's possible. You claimed that simple protocols for chat were not compatible with the features you listed.

My argument was about the ecosystem and the applications and the contributors worked on those applications. You can extend any protocol to worked with other servers and your own extensions to work with your own version of the server code.

If IRC protocol is so amazing, then do you have a reason why it is constantly changed? I've seen it adopted to XMPP, Jabber and others. No sane person today will use the default IRC protocol in an application they intend to keep proprietary.

Discussing what's possible is a waste of time because any feature can be built given time and effort. The point is how easy and how maintainable/stable. More importantly, is it available now?

>I agree that IRC was never…

It probably wouldn't be suitable for a blog or classic CRUD app. The use cases I've heard about are more for education and online editor/IDE.

For example: interactive documentation that runs code in the browser with an ephemeral/temporary database, possibly imported from the user's desktop. For teaching programming languages in the browser, with the compiler compiled to WASM, so the student doesn't have to set up a local development environment. Or a database explorer that's a purely static site with no server, neither remote nor directly on user's computer - just virtually in the browser, which is a more secure sandbox. You could have a folder of HTML, CSS, JS that's a full-stack application with client UI and server (theoretically).

Further reading:

• SQL Databases in the Browser, via WASM: SQLite and DuckDB - https://blog.ouseful.info/2022/02/11/sql-databases-in-the-browser-via-wasm-sqlite-and-duckdb/

• Pyodide - https://pyodide.org/en/stable/ - Pyodide is a Python distribution for the browser and Node.js based on WebAssembly.

• Client-side WebAssembly WordPress with no server - https://make.wordpress.org/core/2022/09/23/client-side-webassembly-wordpress-with-no-server/

• Stackblitz - Instant development environments - https://stackblitz.com

Author here, it is super encouraging to see this trending on HN, thank you for the great discussion, links, and ideas!

I hope to change how learning, using, and contributing to WordPress looks like. This writeup explores how WASM WordPress works and why it's useful:

https://make.wordpress.org/core/2022/09/23/client-side-webassembly-wordpress-with-no-server/

Here's a few possible applications: try a theme without affecting your current website, have live themes and plugins demos right in the directory, enable first contributions directly on wordpress.org without any setup steps, learn WordPress in the browser, or replay and debug failed tests right in the CI.

Technically most of these things are possible today with a specialized backend. The problem is that it's either expensive and time-consuming to maintain, like a fleet of custom WP instances, or limited, like iframing a preconfigured 3rd party solution. WASM-based solution is open-source, cheap to run, and doesn't seem to have deal-breaking limitations.

I wouldn't run production websites on this just yet, as it sometimes crashes in Chrome and the bundle size is 50MB+, but both problems can be solved. Once they are, this will be so much more than just a cool tech demo.

Regulation would have to start with simple coding standards. Updated yearly. Much like building codes. A project could pick what standards they wanted to adhere to, and then everyone on the project would have to adhere to those standards -- the whole project would be audited by a third-party after the fact for compliance.

There are plenty of good, short, concise coding standards to draw from. Especially useful in giving non-technical people the confidence that things were built consistently... if not correctly even. This is about as simple as it gets:

* WordPress Coding Standards – Make WordPress Core || https://make.wordpress.org/core/handbook/best-practices/coding-standards/

I'm sure there are others that aren't terrible.

I do think having more standards would help, standards defined by the devs on the project. If they get to choose their benchmark, then it's just about consistency of approach. Not a bad thing, right? Currently it's the wild west, and the only thing a dev can do is say, "It's my word against theirs, their code is bad."