wp-now: don't expect a full wp-content directory in wp-content mode

[adamziel]

wp-now in wp-content mode expects a theme to be in place and won't apply the default WordPress theme.

I had to use the installTheme step to install twentytwentyfour. The assumption seems to be that my wp-content directory is complete and contains all it needs, but in https://github.com/adamziel/playground-docs-workflow I'm shipping just a subset of the files.

I see two solutions:

• Add CLI options to run a vanilla WordPress server where specific wp-content/* subdirectories would be mounted via --mount= or so flags (or do that via Blueprints v2)
• Instead of mounting the entire wp-content, mount specific plugins and directories found inside wp-content.

Context: The work on static site generator

[flexseth]

related issues

• 32

• https://github.com/WordPress/playground-tools/issues/232
• https://github.com/WordPress/playground-tools/issues/241

[mhsdef]

Yeah, this was one of the first things I tried, and I ran into this. wp-content with just a plugins directory.

I like option two in UX. Mount what you find and fill in anything missing.

[adamziel]

@mhsdef I'm exploring a Playground CLI tool that doesn't make any assumptions and only mounts and serves what you tell it to – maybe that would be useful.

[mhsdef]

@adamziel No worries, ten minutes later, I realized i could just do this one liner and it met our needs for that particular item. 💪

{
    "step": "writeFile",
    "path": "wp-content/mu-plugins/cors.php",
    "data": "<?php add_action('send_headers', function() { header('Access-Control-Allow-Origin: *'); });"
}

wp-now's current behavior of effectively expecting an explicitly theme too just surprised me as first time user so I saw and plus one'd this thread.

[flexseth]

@adamziel No worries, ten minutes later, I realized i could just do this one liner and it met our needs for that particular item. 💪

{
  "step": "writeFile",
  "path": "wp-content/mu-plugins/cors.php",
  "data": "<?php add_action('send_headers', function() { header('Access-Control-Allow-Origin: *'); });"
}

wp-now's current behavior of effectively expecting an explicitly theme too just surprised me as first time user so I saw and plus one'd this thread.

@mhsdef - I'm working on some docs about CORS in the Playground, would you mind linking more context to what you're working on so I can take a look at it?

[mhsdef]

@flexseth at the moment, my exact use case isn't public code (yet) and it's hacky exploratory stuff so we may not even need what we're doing now at all in the end.

tl;dr: we're using a seperate frontend to directly query posts and all their HTML/CSS/JS glory on a WP Playground instance.

So we run into two levels of CORS problems immediately.

1. Typical CORS when hitting PHP pages and loading most linked CSS/JSS.
2. font static file loads in Firefox which are handled more stringently.

For the first case, shunting in a mu-plugin like you see above opens things up for development purposes just fine. Quick and easy. But, since it doesn't set headers on requests for static files, Firefox nopes out of font file loads.

Soooo, see https://github.com/WordPress/playground-tools/issues/249 for more, what we do at the web server level. I think having ways to easily dial CORS both within WP and at the webserver level will be win for all the weird janky stuff we devs do. 😅