[WordPress] 外掛分享: Gallop

首頁 › 外掛目錄 › Gallop
WordPress 外掛 Gallop 的封面圖片
全新外掛
安裝啟用
—
尚無評分
剛更新
最後更新
—
問題解決
WordPress 6.4+ PHP 8.1+ v1.4.0 上架:2026-06-21

內容簡介

Gallop 是一款針對 Next.js 的無頭 WordPress REST API,提供快速且簡單的解決方案。用戶可以在不受佈景主題影響的情況下,透過單一請求獲取整個頁面內容,提升開發效率。

【主要功能】
• 單一請求獲取整個頁面內容
• 無需 JWT 認證,直接使用 WordPress 用戶表
• 支援 WordPress 評論功能,無需額外設定
• 自動處理 SEO,與 Yoast 整合
• 無需程式碼即可註冊自定義文章類型
• 即時發佈,自動更新 Next.js 路由

外掛標籤

開發者團隊

⬇ 下載最新版 (v1.4.0) 或搜尋安裝

① 下載 ZIP → 後台「外掛 › 安裝外掛 › 上傳外掛」
② 後台搜尋「Gallop」→ 直接安裝(推薦)
📦 歷史版本下載

原文外掛簡介

Gallop is the headless WordPress REST API for Next.js that’s FAST and SIMPLE. Keep the WordPress you write in, lose the theme that slows you down — and ship your whole page from one request.

The WordPress editing experience your team already knows, with the speed of a fully decoupled Next.js front end. One endpoint, one response, done.

Visit the Gallop homepage & documentation →

Most headless setups make you stitch together a waterfall of core WordPress REST calls per page — /wp/v2/posts, /wp/v2/media, meta, and taxonomy — then bolt on a JWT layer and an auth service just to log a user in. Gallop replaces all of that.
One request. The whole page. Hand Gallop a URI and it returns the post body, an SEO block, and your global site data — already joined, already resolved, ready to render. The API is the point: a dedicated, Next.js-shaped REST namespace (/wp-json/gallop/v1) so your front-end code stays simple — one fetch, one response, ready to render.
Why choose Gallop?

One round trip instead of five. Everything a page needs — post, seo, and site — in a single response.
No JWT, no separate auth service. Members log in, sign up, and reset passwords against WordPress’s own user table, through your front end’s server, and reading content needs no key at all.
Comments that stay in WordPress. Visitors comment on your front end; WordPress stores, moderates, and notifies exactly as it does for its own comment form.
SEO done for you. With Yoast active, the seo block ships search-ready out of the box.
No-code custom post types. Register REST-enabled CPTs from the admin — no register_post_type() boilerplate.
Instant publishing. Publish in WordPress and Gallop revalidates the affected Next.js routes automatically — no full redeploy.
Framework-agnostic JSON. Next.js is the reference target, but any HTTP client can consume the API.
Keep your workflow. Your editors keep the exact WordPress publishing experience they already rely on.

Everything a page needs, in one request
Hand Gallop a URI and it returns the whole page in a single response: the full post, its seo metadata, and your global site data, already joined, already resolved, ready to render. GET|POST /gallop/v1/post handles posts and pages, and POST /gallop/v1/category does the same for taxonomy archives. No waterfall of /wp/v2/posts, /wp/v2/media, meta, and taxonomy calls per page — one round trip instead of five, with no JWT, API keys, or complicated authentication to set up. Your front end stays simple, and your pages load fast.
The SEO is done for you. With Yoast active, the seo block is populated straight from Yoast’s indexables (canonical, meta description, OpenGraph, robots flags, reading time) so every page ships search-ready out of the box. Without Yoast, seo comes back as an empty object instead of disappearing, so your front end can check it and fall back to its own defaults.
Login, members, and comments, already wired up

Moving off a WordPress template usually means rebuilding everything it gave you for free. Gallop ships with it already done. Readers log in, sign up, reset a password, and edit their profile on your Next.js site, and every one of them is an ordinary WordPress user. Editors sign in with their normal WordPress credentials. There is no JWT layer and no separate auth service to stand up: your front end’s server talks to WordPress with one key, and keeps its own session for each member.
Comments stay in WordPress too. Visitors and members comment on your front end; WordPress stores, moderates, and notifies exactly as it does for its own comment form.
Settings and custom post types, configured from WordPress

Point Gallop at your Next.js production URL and it 301-redirects public WordPress front-end requests to the matching path on your headless host. Admin, REST API, and previews are left untouched.
Register REST-enabled custom post types from the Post Types tab and they’re immediately available through the Gallop namespace — no register_post_type() boilerplate, no developer round trip. Core post types are left alone, and content you create survives a deactivate/uninstall.
Trusted on real production sites
Gallop isn’t a proof of concept — it powers live production sites today:

douglasnewby.com
cmwelectric.com
winx.gallop.software

Every one edits in WordPress and ships a fast Next.js front end — headless content, real Google rankings and structured data, no theme holding it back, and the same WordPress publishing experience your team already knows.
See how Gallop powers headless WordPress →
REST endpoints
All endpoints live under the gallop/v1 namespace.

GET|POST /gallop/v1/post — Resolve a post and return post, seo, and site payloads. Accepts uri, id, or slug with type.
GET|POST /gallop/v1/posts — A filtered, paged collection of posts of one type. Accepts category, include, meta_key / meta_value / meta_compare, orderby, order, size, offset, and fields.
GET|POST /gallop/v1/posts/list — Slug, uri, and modified date for every published post of a type, for sitemaps and static builds. Optional parent.
POST /gallop/v1/category — Resolve a category URI to a term and return category, seo, and site payloads.
GET /gallop/v1/comments — The approved comments on a post, oldest first, as a flat list with parent ids. Public.
POST /gallop/v1/comments — Submit a visitor’s or a member’s comment. Requires the API key.
POST /gallop/v1/members/login, POST /gallop/v1/members, POST /gallop/v1/members/confirm, POST /gallop/v1/members/create, POST /gallop/v1/members/reset-request, POST /gallop/v1/members/reset, GET|PATCH /gallop/v1/members/{id} — Members: log in, sign up, confirm an address, create an account the front end confirmed, reset a password, read and edit a profile. All require the API key.
POST /gallop/v1/auth/login, POST /gallop/v1/auth/logout, GET /gallop/v1/auth/session — The older cookie-based login, kept for front ends on the same registered domain that use it.

Members
Readers get accounts, and WordPress is the only place they live. Every route takes the API key with the Manage members permission and is called by your front end’s server, which keeps its own session for the member; WordPress is asked only when someone logs in or changes something.

Log in with an email address or username and a password, checked by wp_authenticate() as the visitor, so login-protection plugins see the visitor’s address. No WordPress cookies are set.
Sign up: nothing is created until the reader opens the confirmation email; then they become a Subscriber, verified, and logged in, with a one-time key so the front end can offer them a password at once. An address that already has an account is only marked subscribed. An email is never a way past a password.
Reset a password with WordPress’s own reset keys, emailed as a link to your front end.
Profiles: name, email, password, and two email choices. Changing the email or password needs the current one and ends every session the front end holds, through a sessionVersion handed back with each request.
Comments as themselves, recorded as theirs, and accepted where only registered users may comment.

A password set through Gallop, by /members/create, /members/reset, or a profile change, must be 8 to 128 characters. Logging in accepts whatever password the account already has.
Five wrong passwords for one login name from one address within fifteen minutes return HTTP 429; each address is sent at most one email every ten minutes and five a day; login, sign-up and reset answer the same whether or not the address is known.
Comments
Show WordPress comments on a headless front end, and let visitors leave them, without giving up anything WordPress does with a comment.

GET /gallop/v1/comments?post= returns the post’s approved comments, oldest first, each with id, parent, authorName, authorUrl, isPostAuthor, avatar, dateGmt, and rendered content. Build the thread from parent. It also returns open, count, requireNameEmail, threadDepth, and truncated. A commenter’s email address, IP address, and browser are never returned.
POST /gallop/v1/comments takes post, parent, authorName, authorEmail, authorUrl, content, and the visitor’s ip, userAgent, and referer. It answers 201 with the comment, its status (approved, hold, spam, or trash), and the post’s new count.

A submitted comment is handed to wp_handle_comment_submission(), the function WordPress’s own comment form uses. Your Discussion settings, moderation, the duplicate and flood checks, anti-spam plugins such as Akismet, and notification emails all behave as they do for a comment left on a WordPress site. Core’s own REST route for comments sends no notification emails.
Send the request from your front end’s server, never from the browser: it carries the API key.
API key
Reading from Gallop needs no key. Writing does: a request that changes something in WordPress on a visitor’s behalf has to prove it comes from your front end’s own server.

Generate it under Gallop → Settings → Front-end connection. It is shown once. Gallop stores only a hash of it.
Send it in the X-Gallop-WP-Key header, over HTTPS.
Keep it on your server, in a secret environment variable such as GALLOP_WP_API_KEY. Never give it a NEXT_PUBLIC_ prefix, and never put it in code.
Or set it in wp-config.php with define( 'GALLOP_WP_API_KEY', 'gallopwp_…' );. A key set there takes priority over a generated one.
Permissions are off by default. A key can do only what you tick: “Submit comments” and “Manage members”. A permission added by a later version is never switched on for you.
Regenerating replaces the key at once.

Gallop removes the key from the request as soon as it has been checked, so other plugins that read or forward request headers never see it.
SEO integration
When the Yoast SEO plugin is active, the seo block in the post and category responses is populated from Yoast’s indexable data (canonical, meta description, OpenGraph fields, robots flags, reading time, etc.). Without Yoast, seo is returned as an empty object so clients can branch safely.
Data stored

gallop_post_types (option) — your custom post type definitions.
gallop_nextjs_production_url (option) — the redirect target, if configured.
gallop_trust_forwarded_ip (option) — whether to trust reverse-proxy IP headers when rate-limiting auth (default off).
gallop_api_key_hash (option) — a hash of your API key, with the date it was generated and its last four characters. Never the key itself.
gallop_api_key_permissions (option) — what the key is allowed to do.
gallop_verified, gallop_subscribed, gallop_reply_emails, gallop_session_version (user meta) — whether a member’s address is waiting for confirmation, their email choices, and their session version. _gallop_reply_notified (comment meta) — a reply already emailed about.
gallop_auth_* (transients) — short-lived login rate-limit counters.
gallop_pending_* (transients) — sign-ups awaiting confirmation, up to 48 hours: address, names, and a hash of the link’s key.
gallop_confirm_sent_* (transients) — when each address was last emailed, for a day.
gallop_key_fail_* (transients) — short-lived counters of wrong API keys, by address.
gallop_key_reveal_* (transient) — a newly generated key, held for up to two minutes so it can be shown once after the page reloads, then deleted.

Comments submitted through Gallop are ordinary WordPress comments, and members are ordinary WordPress users, stored where WordPress stores them.
Privacy
Gallop does not send any data to external services. All data stays on your WordPress site.
The login endpoints authenticate users with WordPress’s built-in functions. To mitigate brute-force attacks, Gallop temporarily stores failed-login counters in WordPress transients keyed by a hash of the login name and the visitor’s IP address. These counters expire automatically (typically within 15 minutes) and are removed on plugin uninstall.
A sign-up is kept as a transient for up to 48 hours (the address, the names typed, and a hash of the confirmation key), then becomes a WordPress user or expires. Gallop emails members through wp_mail() only what they asked for: confirmation and reset links, a note that an address already has an account, and replies to their comments if they turned that on. It records when each address was last emailed, for a day, to limit how often one can be written to.
When a request presents a wrong API key, Gallop counts it in a transient keyed by a hash of the requesting IP address. That counter also expires within 15 minutes and is removed on uninstall.
A comment submitted through /gallop/v1/comments is stored by WordPress with the commenter’s name, email address, IP address, and browser, as WordPress stores every comment. Those details are supplied by your front end, and the IP address and browser are presented to other active plugins while the comment is saved, as they would be for a comment left on the site itself: an anti-spam plugin may send them to its own service, under its own privacy terms. Comments are returned by /gallop/v1/comments without the email address, IP address, or browser. If avatars are switched on, each comment includes an avatar address from your avatar service (Gravatar by default), which contains a hash of the commenter’s email address, as WordPress’s own themes and REST API expose.
No personal data is shared with third parties. No tracking, analytics, or telemetry is performed.

延伸相關外掛

文章
Filter
Mastodon