I couldn’t figure out how to contact cfx any other way. Sorry for the OT branching.
http://discourse.roots.io/t/development-using-roots/72/42
@cfx, I think the idea is plugins shouldn’t be mucking with anything in the wp submodule. That’s core WordPress–wp-includes, wp-admin, default wp templates. Aren’t plugins supposed to hook into those rather than changing them?
Possibly. But let’s take Roots as an example. If you add Roots as a submodule to Jaquith’s original WordPress-Skeleton then clone it in your local environment, the moment you activate Roots it changes the uploads directory (if you want it to). When this happens, git reports that the WordPress submodule has untracked content and unstaged changes. When you head to that submodule you can see that it’s stemming from Roots adding the media/ directory. At least I think Roots is what added that.
My strategy is to clone the Roots repo (local) into a theme directory for the site (in content/themes), .gitignore that directory in WP-Skeleton, and manage the theme as a separate repo during development.
At least, that’s my theory today. I’m still experimenting with workflow. I’m taking notes on what works. I’m planning to write that up and explain what I found and why some of the complexity I’m introducing might be worthwhile to some (but definitely not all) developers (target: sometime this month).
Your comment comes at an ideal time. I should be ready to activate Roots in the setup later this week (I’m slow because I’m documenting as I go), so I’ll be on the lookout for issues in the wp submodule.
If a plugin/theme is modying the WP submodule then they’re doing something wrong. And that goes for Roots as well in this case. We’ll look into how we change the uploads directory to fix this from happening.
I personally don’t think your theme should be a separate repo considering its the most important part of a website (and in this case, a repository). You’d only use a submodule (or Composer package) for a theme if it was a parent theme and never modified.
It’s modifying .htaccess to add the rewrites. Timestamps tell the story.
I need to reset and retest because there were some anomalies in my testing process (did a couple of steps out of order and reset in a way I think should have worked). I’m seeing some results that don’t make sense (sometimes it writes .htaccess in the wp submodule, sometimes it writes .htaccess in the site folder) and want to make sure the issues aren’t caused by my process goofs.
More tomorrow after I have a chance to rebuild the test setup and get results with a clean test process. Right now, I need to go kill some orcs.
Okay. Stayed up to early but I got through this. Sparing you the detail of my test log, I set up two sites that were identical except one was called site1 and the other site2 (directory, database name, site name in WP) and they treated Roots differently (something for my own workflow/process testing). Everything was taken from master branches in my local clone repos. The master branches are clean clones from Github forks.
After setting up the directories from the WordPress-Skeleton repo and the Roots repo, but before installing WordPress or running npm install for Roots, I did the following.
Check site1, site2 for .htaccess in site root and site1/wp, site2/wp.
(site1 root: .htaccess 9/6, 12:14, site1/wp: no .htaccess)
(site2 root: .htaccess 9/6, 12:21, site1/wp: no .htaccess)
I checked frequently during the process and that’s how it stayed until…
Site1: Activate Roots, yes to the five questions.
Check site1 for .htaccess in site root and site1/wp.
(site1 root: .htaccess 9/6, 12:14, site1/wp: .htaccess 9/6 1:11)
Site1: navigate to Settings, Permalinks. Click Save Changes.
Check site1 for .htaccess in site root and site1/wp.
(site1 root: .htaccess 9/6, 12:14, site1/wp: .htaccess 9/6 1:13)
Site2: Activate Roots, yes to the five questions.
Check site2 for .htaccess in site root and site2/wp.
(site2 root: .htaccess 9/6, 12:21, site1/wp: .htaccess 9/6 1:14)
Site2: navigate to Settings, Permalinks. Click Save Changes.
Check site2 for .htaccess in site root and site2/wp.
(site2 root: .htaccess 9/6, 12:21, site1/wp: .htaccess 9/6 1:17)
Note that I checked .htaccess immediately before activating Roots in both themes and it was the same as the first check.
Based on this, both activating Roots (which sets permalinks and other rewrites in .htaccess) and saving permalink settings WordPress (which sets permalink rewrites in .htaccess) are writing .htaccess to the wp submodule. I’m going to suggest maybe that’s how it’s supposed to be.
Backing up this theory, I use a GUI tool for git and can inspect the changes in the wp submodule. The only change git detects is in .htaccess (for rewrites). There is no .gitignore in the wp submodule, so git should report any other changes.
Removed this message.
If I understand you correctly problem is where is .htaccess. There is no problem because it depend on way you install WP. If you after installation (in subdirectory) first set permalinks your site address is stil on subdirectory and .htaccess will endup there if you first setup site address (delete wp/ or whatever) then set permalinks .htaccess will endup in root directory. With first method you will endup with two .htaccess and with second with only one. There is no relation with Roots theme except that Roots use same method when changes .htaccess.
So you and I are in agreement. 
Based on this, both activating Roots (which sets permalinks and other
rewrites in .htaccess) and saving permalink settings WordPress (which
sets permalink rewrites in .htaccess) are writing .htaccess to the wp
submodule. I’m going to suggest maybe that’s how it’s supposed to be.