Headless CP - suggestion about plugins

I’m going to work on an headless site for a customer. And also I’d like to have another headless site por plugin updates.

Headless mode is the one I’ve used, but I have to tweak it to accept update in query_vars.

Someone have plugins to do so to suggest?

I’m not happy with solutions I’ve found and was even thinking to build one.


I believe @Code_Potent would the best to advice since he’s already done one: https://classicpress.slack.com/archives/CCNEEH86P/p1579474761114600

Maybe a tuts for us clueless ones, please? :slight_smile:


It so happens that I built a solution for exactly the goal @Simone wants to achieve. It’s pretty simple and straight forward. This is a theme-driven technique that bypasses the need for 3rd party plugins or complicated solutions.

Getting Started

Get your update domain setup with a fresh install of ClassicPress and a security plugin of your choice. From there, install the Update Manager plugin and create a first endpoint to test with. I used a subdomain for mine.

Custom Theme

Since you (presumably) won’t be publicly serving anything except plugin update endpoints, your theme can consist of a simple index.php file. Give the directory whatever name you like. Here’s the important bits from my own file. Set this as your active theme.


// Prevent direct access.
if (!defined('ABSPATH')) {

// Redirect all requests to the homepage.
if ($_SERVER['SCRIPT_URL'] !== '/') {
	header('Location: https://your.updateserver.com');

// Page content.
<!doctype html>
<html lang="en-US">
<meta charset="UTF-8">
<meta name="viewport" content="width=device-width, initial-scale=1">
<meta name="description" content="Update Server for Code Potent Plugins">
<meta name="generator" content="Code Potent">
<link rel="icon" href="https://static.codepotent.com/images/logotype/code-potent-logotype-lettermark-64x64.png">
<p>This content displays on every frontend page.</p>
<p>Add branding, some trendy JS effect, or just use a blank page.</p>


Set your permalink structure to Post name. This ensures that any 404s are routed through your theme’s index file.

Config File

Optional: You can shave a few extra nanoseconds off requests by adding the following at the very top of your wp-config.php file, just inside the opening PHP tag. This directive ensures that your domain (as a whole) is compressed for all frontend requests (much like how you compress images, scripts, styles via .htaccess.)

if (!strstr($_SERVER['REQUEST_URI'], '/wp-admin/')) {

Additional Notes

  • Are my endpoints faster when served from the subdomain? Yes.
  • I couldn’t get this working with the SHORTINIT constant; this would make it even faster.
  • Here are a slew of htaccess directives to further improve domain performance.
  • Do test your update endpoints from both the old and new domains for comparison.
  • It took longer to write this post than to set the whole thing up.

Wrapping Up

Using the above, my implementation serves up a JS-animated logo for all requests, unless the request is for an update endpoint. I still have full access to the backend and have used htpasswd for an extra layer of security over the login and admin.


Great! :clap:
Thank you!

I’m out of office so can’t try but seems that this is not going to block REST api or it’s easy to allow it (which is what i’m searching for for another project).

My initial idea was building a plugin around this with the option to enable queries like update.

Using a theme is an awesome idea!


The technique laid out here is intended to redirect general frontend requests to your theme index – the REST requests are not affected (unless you block them with a security plugin or codesnip.)

Notably, the Update Manager plugin is written to allow its posts to be displayed in the public REST API (as basic post-type items), however, since they use their own dedicated endpoints (which construct the data differently than a typical post-type item), you could even conceivably disable the REST API altogether and still serve your plugin update data at the Update Manager’s endpoints.

Thanks – I was very happy with the simplicity of the implementation. :slight_smile:


Perfect solution, thank you.


It certainly beats the classic include_once( 'wp-load.php' ) routine, because then you’d still require to build your own kind of theme setup and stuff.

ie. this one here:

if( !defined( 'WP_USE_THEMES' ) ) {
	define('WP_USE_THEMES', false);

require_once( $_wp_path . 'wp-load.php');

cu, w0lf.


This topic was automatically closed 2 days after the last reply. New replies are no longer allowed.