Hacktoberfest 2026: những issue maintainer đã đánh dấu cho tháng Mười, đang mở và phù hợp người mới. Xem issue Hacktoberfest

Editor workflow: per-entry 'Ready to publish' flag + 'Publish all marked' action (beyond branches)

Đang mở
  • Có gì không ổn?
#1,541 1 bình luận 2 reaction 0 người được giao Xem trên GitHub

Maintainer thường phản hồi trong vòng 1 ngày

Chưa có ai nhận issue này.

Đánh giá

Độ khó
5/5
Thời gian dự kiến
Hơn một tuần
Mức phù hợp với người mới
35/100
Loại issue
Tính năng
Độ rõ ràng
Khá rõ ràng
Mức độ hoạt động
Ít trao đổi
Công nghệ
github, typescript
Lĩnh vực
content

Hướng nghiên cứu

Start with PREVIEW.md and the existing branch-picker and branch-based editing flow described in the issue; trace how GitHub-mode saves and the GitHub App handle branches and pull requests. Done means a decided, in-product draft-to-publish workflow that covers the ready status, staged-entry view, publishing action, and any smaller-scope configuration option, with appropriate validation and tests.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

Use case

We run a marketing site on Keystatic in GitHub mode. Editors make 5–20 small content edits throughout the day (typo fixes, copy tweaks, swapping a tagline, adding a testimonial, etc.). Today, every Save commits straight to main, which:

  • Triggers a fresh production build per Save (Cloudflare Workers Build, in our case — but the same applies to Vercel, Netlify, etc.).
  • Clutters git history with one micro-commit per change ("Update Hero", "Update Hero", "Update Hero", …).
  • Means a typo in any save ships to production immediately.

What's already possible

We know about branchPrefix + branch-based editing — we use it, and PREVIEW.md in our repo documents a workflow where editors pick a long-lived cms/staging branch in the picker, save many times, then merge a PR to publish.

That does solve the deploy-per-save problem, and we recommend it as the answer today. Thank you for that primitive — it's the foundation.

The UX gap

Non-technical editors still need to:

  1. Remember to flip the branch picker to cms/staging before every session (easy to forget; defaults to main).
  2. Leave Keystatic and go to GitHub to open + merge the PR to publish.
  3. Understand what "merge a PR" means.

For technical users this is trivial. For marketing/content editors who have never opened a PR, it's the bottleneck — they often default to editing on main because the picker is right there.

Proposed feature

A first-class "draft → publish" workflow built on top of the existing branch primitive, expressed in admin-friendly language:

  1. A per-entry "Ready to publish" flag in each entry's Save dialog (or as a toggle in the entry form). When unchecked, Save commits to a staging branch. When checked + Save, the entry is marked as ready in the staging branch.
  2. A dashboard surface listing entries currently staged (changed on the staging branch vs. main), with their "Ready to publish" status.
  3. A single "Publish all ready" / "Publish all changes" button that merges the staging branch into the production branch (i.e. opens + auto-merges the PR via the GitHub App).
  4. Optional: a defaultBranch config (e.g. "cms/staging") so the picker doesn't default to main — this alone would already remove a big footgun.

The branch primitive stays exactly as it is; this is purely a UX layer on top, so technical users who prefer raw branches lose nothing.

Why this isn't easily DIY-able

We can — and probably will — build a custom admin page that lists open cms/* branches and exposes a merge button via the GitHub App token. But:

  • Re-implementing the auth Keystatic already does on a sibling route is non-trivial.
  • It's a separate admin surface that editors have to remember exists.
  • It drifts as Keystatic evolves.

A first-class flow inside Keystatic itself would be a much better fit, and would benefit every team running Keystatic at any reasonable editing volume.

Smaller-scope wins, if a full design is out of scope

Either of these alone would already be a big improvement:

  • defaultBranch config option — pick cms/staging so editors don't accidentally land on main.
  • A "Publish to production" action in the branch picker when the current branch is cms/* — one click to open + merge the PR (instead of leaving Keystatic).

Happy to test any of this on a live editorial site if useful.

Ngôn ngữ chính
TypeScript
Star
2.5k
Fork
176
Merge trung bình
5 giờ 46 phút
Pull request đã merge (30 ngày)
3

Chuẩn bị môi trường

Dự án này không cung cấp dev container, Dockerfile hay hướng dẫn đóng góp, nên bạn cần tự thiết lập môi trường: hãy bắt đầu từ README và xem hướng dẫn đóng góp lần đầu của chúng tôi để biết các bước chung.

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của Thinkmill/keystatic

Tất cả issue của Thinkmill/keystatic

Issue tương tự

Thêm issue về TypeScript

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.