Publishing to an Astro site or site repository

If your site lives in a Git repository — an Astro site, or any static site — WordPresto publishes by editing the real source files and opening a pull request. It never pushes to your live branch, and it never invents a file.

Connecting the repository

Connect from Project Settings → Destinations. The main path is a normal GitHub authorisation, after which you pick the repository; WordPresto then appears in your GitHub Authorized OAuth Apps like any other tool. Pasting a personal access token is the fallback when you would rather not authorise an app.

It edits your real files

This is not a content API writing into a box WordPresto controls. It reads and edits the actual source — .astro, .ts, .md — applying your approved content as copy while leaving the code around it intact.

Every target file is read before any edit runs, so a wrong path costs nothing and fails immediately instead of part-way through.

The unit of work is a change set, not a file

A real page’s copy is usually spread across several files. On a live Astro site, one long-form article can be:

• the body in src/content/pillars/{slug}.md;
• the title, SEO title and meta description in a registry such as src/data/pillars.ts;
• a route under src/pages/.

Publishing those one at a time would open a pull request per file, and none of them would be valid on its own — a registry entry pointing at a file that does not exist yet, a route importing a missing module. Merged in any order, the site is broken in between.

So one logical change is one change set, one branch, one pull request. And because the unit above that is the repository, ten approvals against the same site batch onto a single job: one clone, one build, one pull request, not ten.

Nothing is written until you approve the diff

The publish step is a planner. It produces a draft change set — the exact before and after for every file it intends to touch — and writes nothing. You read the diff, approve it, and only then does a single repo write happen.

That means there is an auditable record of who approved what, and a human has seen the change before it exists anywhere.

It builds before it asks you to merge

The work runs on a build machine rather than inside a web request, because a real install and build takes over a minute and would otherwise be racing a timeout on every publish. WordPresto clones the repository, applies the change set, runs your build, repairs what it broke if it can, and stops at a green pull request.

It stops there deliberately. Merging to your default branch is what ships production, so it stays a separate, explicit action — you merge, or you ask WordPresto to, and your normal deploy takes it from there.

Translated sites

If your repository holds locale copies of the same content, WordPresto detects the locale keys an edit touches and reports which locales are now stale, rather than silently updating English and leaving five other languages disagreeing with it.

If no repository is connected

You see a connect card. You never see a fabricated file list or a preview of a change against a repository that is not there.