| 开发者 | gallopsoftware |
|---|---|
| 更新时间 | 2026年6月23日 04:09 |
| PHP版本: | 8.1 及以上 |
| WordPress版本: | 7.0 |
| 版权: | GPLv2 or later |
| 版权网址: | 版权信息 |
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?
post, seo, and site — in a single response.wp_signon().seo block ships search-ready out of the box.register_post_type() boilerplate.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, editing, and cache revalidation, already wired up
https://vimeo.com/1200535505
Moving off a WordPress template usually means rebuilding everything it gave you for free. Gallop ships with it already done. Cookie-based login is wired into the front end through the Gallop plugin, so editors sign in on your Next.js site with their normal WordPress credentials — no JWT layer, no separate auth service to stand up, and no API keys to manage.
Editing works the way your team already knows. Publish or update a post or page in WordPress and Gallop tells your Next.js site to revalidate the affected routes and clear their cache, so changes and new posts go live instantly with no full redeploy. Login, editing, and cache invalidation are all baked in, so you keep the WordPress workflow your team relies on and still ship a fast Next.js front end.
Settings and custom post types, configured from WordPress
https://vimeo.com/1196416170
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:
gallop/v1 namespace.
GET|POST /gallop/v1/post — Resolve a front-end URI to a post and return post, seo, and site payloads. Accepts uri as a parameter.POST /gallop/v1/category — Resolve a category URI to a term and return category, seo, and site payloads.POST /gallop/v1/auth/login — Cookie-based login for a headless front end. Accepts username, password, and optional remember. Rate-limited per username/IP.POST /gallop/v1/auth/logout — Log out the current user.GET /gallop/v1/auth/session — Return the current user payload, or { "user": null } when not logged in.POST /gallop/v1/auth/login, which calls WordPress's built-in wp_signon() and sets the standard auth cookies. A Next.js front end on the same registered domain can then make authenticated requests with credentials included.GET /gallop/v1/auth/session, so your front end can tell whether a visitor is logged in and render accordingly.POST /gallop/v1/auth/logout.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.
Action hooks
gallop_auth_login_success — fires after a successful REST login. Args: WP_User $user, WP_REST_Request $request.gallop_auth_login_failed — fires after a failed REST login. Args: string $username, WP_REST_Request $request.gallop_auth_logout — fires after a REST logout. Args: WP_User $user, WP_REST_Request $request.gallop_trust_forwarded_ip — filter the boolean controlling whether reverse-proxy IP headers (CF-Connecting-IP, X-Forwarded-For) are trusted when rate-limiting REST auth. Defaults to the "Trust proxy IP headers" setting. Only enable behind a trusted proxy that overwrites these headers, otherwise the per-IP rate limit can be bypassed by spoofing them.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_auth_* (transients) — short-lived login rate-limit counters.gallop folder to /wp-content/plugins/, or install the ZIP from the Plugins screen.https://your-wp-site.example/wp-json/gallop/v1 and start fetching post, category, and auth endpoints.No. Gallop's REST endpoints are framework-agnostic JSON. Next.js is the reference target and the redirect feature is named for it, but any HTTP client can consume the API.
No. The redirect runs on template_redirect only, skips any request with a preview=true or _wp* query parameter, and never touches /wp-admin or /wp-json. Leave the Next.js URL setting blank to disable redirection entirely.
/gallop/v1/auth/login calls wp_signon() and sets the standard WordPress auth cookies. A Next.js front end on the same registered domain can then call /gallop/v1/auth/session (or any other authenticated REST endpoint) with credentials included. There is no JWT layer — cookie auth is intentional.
Yes. Five failed attempts per username + client IP within fifteen minutes return HTTP 429 until the window expires. Successful logins clear the counter.
By default Gallop uses REMOTE_ADDR for the per-IP portion of the login rate limit. If your site sits behind a trusted reverse proxy (Cloudflare, a load balancer, etc.) that overwrites the client-IP headers, enable Trust proxy IP headers on the Gallop settings screen so CF-Connecting-IP / X-Forwarded-For are used instead. Leave it off on direct-served sites — turning it on without a trusted proxy lets attackers spoof those headers to bypass the rate limit. The setting can also be overridden in code via the gallop_trust_forwarded_ip filter.
No. If Yoast is not active the seo field in responses is an empty object. With Yoast active, Gallop reads from its indexables to populate canonical, OpenGraph, and robots data.
No. Posts, pages, media, and built-in taxonomies are left alone. Only post types you create through the Gallop admin screen are registered by this plugin.
Deactivating stops Gallop from registering its post types and REST routes; content created under those post types stays in the database. Deleting the plugin (via the Plugins screen) additionally removes the gallop_post_types, gallop_nextjs_production_url, and gallop_trust_forwarded_ip options plus any leftover login rate-limit transients. Posts authored under your custom post types are intentionally left in place so they survive an uninstall/reinstall.
/gallop/v1/post and /gallop/v1/category endpoints with optional Yoast SEO payloads./auth/login, /auth/logout, /auth/session) with per-username/IP rate limiting.