What is left, and the things I am not going to build

Atelier went from v0.1.1 to v0.3.0 in about a week. Design tokens, shared section controls, revisions, a sitemap, redirects, multiple layouts, structured data, CI, a security policy. 122 tests.

This is where it actually stands, and what comes next.

What works

A page is a JSON tree of typed blocks rendered by Blade at request time. Nine blocks. A three-pane editor with a live preview that renders the real page through the real layout and the real stylesheet. English and Arabic in one tree with dir="rtl" and hreflang. Draft and published as separate columns, so editing cannot touch a live page. Design tokens read by the editor and the front end from the same place. Multiple layouts picked per page. A sitemap, robots.txt, per-page indexing control, 301s when a slug changes, and a JSON-LD graph on every page.

That is enough to build a client site on. I would.

What is missing and should exist

Four blocks. Header, footer, contact form and raw HTML. The last one is the escape hatch the spec named for one-off markup, so right now there is no way to put arbitrary markup on a page at all, which is a real limitation with a one-hour fix.

Drag to reorder. It is arrow buttons. They work and persist correctly, but "drag a section up and the page reorders in front of you" is what the plan asked for, and buttons are not that. Adding a section also always appends, so putting one in the middle of a twelve-section page means clicking up eleven times.

A revisions UI. Snapshots are written on every publish and restoring works from code. There is no screen for browsing or comparing them, which means the delete confirmation in the editor is still telling the truth about being permanent.

Language files. This one came from filling in the plugin directory submission and deciding not to tick the translation support box. Atelier translates the content a client writes; its own interface is hardcoded English. Those are different features that share a word, and the honest fix is publishable lang files.

Performance work. Per-block asset loading, a page cache, and actual numbers. There are no Lighthouse figures recorded anywhere, so optimising now would be guessing. Measure first.

What I am not going to build

Review schema from testimonials. Google ignores reviews a business publishes about itself, and the block has no rating field. It would be markup that is at best ignored and at worst a manual action.

HowTo schema. Its rich results were dropped in September 2023. Markup for nobody.

Animation as a plugin feature. This was planned as a dropdown of GSAP presets and is now formally dropped. A block is already your PHP class and your Blade view, so it animates however you like without a preset system in the way. The cost, stated plainly, is that there is no animation control for a client.

A submissions table for the contact form. The block will be presentational, posting to a route you wire per site. Your app already knows how to store a submission, and a page builder that quietly becomes a data processor is a liability on every client site it ships to.

Block types authored from the panel. That is v2 and it is parked on purpose. It has its own security problems, starting with the fact that compiling user input as a template turns a textarea into remote code execution. The raw HTML block is the v1 answer.

The two gaps I cannot close by writing code

Nobody who is not me has used the editor. The verification plan has a run where somebody who has never seen it builds a page with hero, features, testimonials, CTA and FAQ, and publishes it, with no help and no documentation. Watch, do not assist, write down every hesitation. If that run goes perfectly first time, either the tester was coached or the task was too easy.

Nothing has been validated by Google. The structured data has 122 tests covering the shape of the graph. Neither the Rich Results Test nor the Schema.org validator has seen it, because both need a public URL. Those tools answer different questions too: one tells you what Google will do with it, the other whether it is correct.

Both of those are worth more than the next feature, and neither is something I can finish alone at a keyboard.

The pattern in this week

Looking back at seven releases, the useful bugs were not found by testing. They were found by using the thing.

The nested slug returning 200 with the wrong page: found while checking whether a sentence in a document was true. The head vanishing when a layout is replaced: found from a report that a social share image was not appearing. The preview crashing on a custom layout: found because writing a second layout gave a reason to read $page. The catch-all shadowing every application route since the first release: found while adding a demo blog route to a test app.

Every one of those was in a path I had never walked, and each was invisible from inside the code. The lesson I keep relearning is that building the next feature is a better bug-finding tool than staring at the last one.

Next

Fix the four missing blocks, do drag to reorder, then get somebody else in front of the editor and watch.