New thread from Local development on Windows because this is affects more than Windows.
Ben, thanks for taking time to respond. It’s great to get support from the people actually building the code.
Based on what I see in the Codex page, all those scenarios put the WordPress index.php and .htaccess in the host root. They assume navigating to the host root url (http://localhost in my test setup) will go to a specific WordPress site.
With XAMPP (and similar local AMP stacks based on what I’ve seen), http://localhost lands on the XAMPP main page. To get to xyz-site I navigate to http://localhost/xyz-site. To get to abc-site I go to http://localhost/abc-site.
Each site subdirectory includes a standalone WordPress install (including index.php and .htaccess), but the host root’s .htaccess and index.php are not the same as those in any of the WordPress subdirectories. This isn’t really multisite because the WordPress network function isn’t enabled.
This is the model most developers using XAMPP, and I’m assuming WAMP and MAMP will use because that is how those tools are designed to work.
I’ve done some more testing based on your questions. I know I spent several days with rewrites failing very consistently, but now it won’t unless I’m using WordPress-Skeleton. Chalk it up to too long spent trying to solve the same problem then versus coming back with fresh eyes later. I’m sure I’m doing something different, but I’m not sure what. If I figure it out, I’ll let you know.
Meanwhile, here’s what’s going on with WordPress-Skeleton in this case. After activating Roots, .htaccess looks like
# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /wp_rt/wp/
RewriteRule ^index\.php$ - [L]
RewriteRule ^assets/(.*) /wp_rt/wp/http://localhost/wp_rt/content/themes/roots-test/assets/$1 [QSA,L]
RewriteRule ^plugins/(.*) /wp_rt/wp/http://localhost/wp_rt/content/plugins/$1 [QSA,L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /wp_rt/wp/index.php [L]
</IfModule>
# END WordPress
Obviously, that isn’t going to work. Both the WordPress Address and Site Address in General Settings are http://localhost/wp_rt/wp, but changing the site address to http://localhost/wp_rt (trying to mimic the Codex instructions) gets a rewrite to /wp_rt/wp/content/themes/roots-test/assets/$1, which is better, but isn’t going to work either.
Changing the rewrite rules to the following does work.
RewriteRule ^assets/(.*) /wp_rt/content/themes/roots-test/assets/$1 [QSA,L]
RewriteRule ^plugins/(.*) /wp_rt/content/plugins/$1 [QSA,L]
So, if you’re using WordPress-Skeleton in a subdirectory of the host root, you’ll need to edit site-subdir/wp/.htaccess and remove the address up to and including the host root (in this example, through http://localhost).
Wish I’d been able to figure that out before, probably too many hours spent beating my head against the wall complicated by uncertainty about whether I should be using /assets or assets without the leading / to use assets in the assets directory (different examples I saw did it differently). But there it is for the next person. And use assets without the leading /.
Looking at the code in rewrites.php leads me to config.php and this line for the content path. (There’s a similar line for plugins above it.)
define('RELATIVE_CONTENT_PATH', str_replace(home_url() . '/', '', content_url()));
I echoed home_url and content_url and got the following values.
home_url: http://localhost/wp_rt/wp
content_url: http://localhost/wp_rt/content
The code searches for the first string plus a ‘/’ in the second and finds no match. Without WordPress-Skeleton and with no WordPress and Site Addresses the same, I get rewrites like the following. (Don’t remember what I was getting a couple of weeks ago when testing.)
RewriteRule ^assets/(.*) /wp_rt/wp-content/themes/roots-test/assets/$1 [QSA,L]
RewriteRule ^plugins/(.*) /wp_rt/wp-content/plugins/$1 [QSA,L]
Which works. So it’s strictly an issue with WordPress-Skeleton in a subdirectory. If there was a way to get the host root URL instead of the site root and remove that from the content URL, it seems like the code would work in all cases. I’m not finding it at the moment, so for now I’ll either skip WordPress-Skeleton or manually edit the file. Probably skip WordPress-Skeleton.
Sorry for the earlier confusion.