Awesome work on the Theme Bridge proof of concept plugin!
Working on WP Engine! (frontity.wpengine.com)
Just needed to add this to make nginx look in the right place for the /static/ folder:
# Serve /static from node server through main domain
location ~* ^/static/?(.*) {
proxy_set_header Host $host;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header Cache-Control $http_cache_control;
proxy_pass [http://MY_NODEJS_SERVER_IP:3000];
}Awesome @403page 
I have moved the post to a new topic to talk about WP Engine and Frontity. I hope you don’t mind.
Is it working right now? I see in frontity.wpengine.com that the assets are loading, but they receive the WordPress HTML instead of Frontity’s JavaScript.
I was proxying to the wrong droplet.
This is what happens when I stay up far too late with far too little coffee.
Should be working well now.
Awesome, works great now!
Oh, I just noticed that what is up is the dev build (npx frontity dev), not the production build (npx frontity build).
Just in case you want to show it off, or do some perf testings 
Sweet!
For this version - Frontity exists entirely on it’s own Digital Ocean droplet that just has node.js running on it.
The theme-bridge-poc plugin is set inside Wordpress on WP Engine seperately and is configured to pull from the Droplet’s IP:3000 instead of localhost:3000.
That’s why I need that nginx proxy pass from above to pull /static/* from the Frontity instance.
Workflow-wise I can imagine a JS dev working on pushing changes to the Node instance, whereas admins take care of the content on the WP side. It’s a challenge for people who need permission for both - makes it a little awkward, but I think that’s going to be a challenge no matter what on hosts that don’t yet support node.js anyway.
Ya I was knocking it out super quick when I was testing I was so curious 
- didn’t even want to loose the seconds on running build I’ll do that now actually.
Btw this is what the top of the plugin file looks like (but with my ip instead if 123.123.123.123):
<?php
// Redirect Webpack HMR to the Frontity server.
if ( $_SERVER['REQUEST_URI'] === '/__webpack_hmr' ) {
header( 'Location: http://123.123.123.123:3000/__webpack_hmr' );
status_header( 301 );
exit();
}
// Build the URL to do the request to the Frontity server.
$url = 'http://123.123.123.123:3000' . $_SERVER['REQUEST_URI'];
I’m testing in the same file system now to see how that goes
Awesome, thanks for sharing the workflow.
Yeah, for DO (or any other VPS) people need to know how to configure Nginx/Apache so I guess it’s not much of a problem. They can use the approach they prefer. We are more worried about managed environments where people don’t know/want to change the Nginx and cache settings.
One question though: Is frontity.wpengine.com then running in WP Engine or it is still on DO?
Ya 100% agreed.
I think what made me start testing with this method is that the port number 3000 is specified in the plugin which won’t work on a managed hosting solution without nginx trickery. So the Frontity code is serving from DO, not truly WPE.
What way are you bundling this up for nginx out of the box so it can serve right from /build/?
You can replace http://localhost:3000 with whatever URL you want. It’s just a URL.
Does that help? If not, what is exactly the problem preventing you from using the Theme Bridge in WPE?
Oh for sure. That’s what I ended up doing originally to pull the frontity code from my node.js server.
I’m just wondering about how to do this best… putting the /build/ into /wp-content/ and pointing the plugin there. I’m assuming I have to manually construct an index.html to load the frontity JS?
Or is there a neater way?
I’m not sure I’m following you. Does WP Engine support Node or does it need to be hosted somewhere else?
Ya sorry. I think I got a bit confused myself. WPE doesn’t currently have node in the infrastructure so it needs to be hosted elsewhere. I was exploring a method to load the static Frontity code inside the same Wordpress filesystem.
The Theme Bridge plugin works on WP Engine currently so long as Frontity is setup externally.
I think the only current issue is what was already discussed in the other threads, primarily setting the requests for the /static/ resources from the node server (without the above nginx rule).
Ok, thanks for the info @403page!
Where do you think people host their Frontity code until WP Engine has Node support? Which one makes more sense (if any)?
Awesome. Any node-enabled machine public-facing would work. I used Digital Ocean in my tests for convenience.
Do you know if WP Engine has plans for Node and how would it work?:
We can try to make it work with an external Node server so people can still keep using WP engine until Node is added 
What would it be the best way to avoid the Nginx modification?
/static folder in the WordPress filesystem somehow?/static publich path to a different address, like https://my-frontity.app.now.sh/static/?It’s been a while, but WP Engine announced their Headless platform a couple of weeks ago, called Atlas 
Frontity works great in Atlas using the Embedded mode.