Andrew Wilkinson

<p>A lightweight plugin that <strong>forces login for backend access</strong> in a headless WordPress setup. Keeps your WordPress dashboard private while allowing your front end (e.g. Astro, Next.js) to pull content via GraphQL/REST.</p>
<h4>What it does</h4>
<ul>
<li>Requires authentication for <code>/wp-admin/</code> and other backend pages</li>
<li>Always allows the login page to avoid redirect loops</li>
<li>Leaves key endpoints open for headless use:
<ul>
<li><code>/wp-json/</code> (REST API)</li>
<li><code>/graphql</code> (WPGraphQL)</li>
<li><code>/wp-admin/admin-ajax.php</code> (AJAX)</li>
<li><code>/wp-cron.php</code> (cron)</li>
<li><code>/robots.txt</code></li>
<li><code>/sitemap*.xml</code> (sitemaps and indexes)</li>
<li><code>/wp-content/uploads/*</code> (media)</li>
<li><code>/favicon.ico</code></li>
<li><code>/newrelic</code> (New Relic monitoring)</li>
</ul>
</li>
<li>Logged-in users visiting the backend root get redirected to the dashboard</li>
<li>Works with Bedrock layouts (handles root path vs <code>/wp/</code>)</li>
</ul>
<h4>Use case</h4>
<ul>
<li>WordPress is the content backend</li>
<li>Public site is built with Astro/Next.js/etc</li>
<li>Editors log in to WordPress. Visitors never see the backend</li>
<li>Front end builds and live pages can still query GraphQL/REST without authentication</li>
</ul>
<h4>Customization</h4>
<p>Developers can customize allowed endpoints using the <code>force_login_allowed_patterns</code> filter:</p>
<pre><code>add_filter('force_login_allowed_patterns', function($patterns) {
    $patterns[] = '#^/healthz$#';           // custom health check
    $patterns[] = '#^/status$#';            // uptime checks
    $patterns[] = '#^/wp-json/acf/v3/.*#';  // specific REST namespace
    return $patterns;
});
</code></pre>


Headless Login Guard

Forces login for backend access in headless WordPress setups while allowing GraphQL/REST API endpoints and essential paths.

Stellate

<h3>Stellate plugin for WordPress</h3>
<p>This plugin is an addon for the popular <a href="https://github.com/wp-graphql/wp-graphql" rel="nofollow ugc">WPGraphQL</a> plugin. It helps set up <a href="https://stellate.co" rel="nofollow ugc">Stellate</a> in front of a WordPress GraphQL API by automatically invalidating the cache when content is updated in WordPress. It works no matter the source of the update, whether that is via the WordPress admin panel, a GraphQL mutation, the REST API, or another method. It also supports custom post types and custom taxonomies that are exposed over the GraphQL API.</p>
<p>This plugin only works when you already have the WPGraphQL plugin installed. After adding this plugin, you’ll see a new menu item named “Caching” in the “GraphQL” section of the dashboard sidebar. Here you can:</p>
<ul>
<li>Add the name of your Stellate service and a purging token (without that, the plugin will do nothing).</li>
<li>Toggle between soft and hard purging. (Soft purging means the cache will continue serving stale data even after the purge while Stellate updates the data in the background.)</li>
<li>Purge the entire Stellate cache right from the WordPress dashboard.</li>
</ul>
<p>For more information, check out our <a href="https://stellate.co/docs/integrations/wordpress-plugin" rel="nofollow ugc">documentation</a>.</p>


Headless Login Guard vs Stellate