opened
alexfornuto
username_0
Closes #4495 
Closes #4494 

## Effect
PR includes the following changes:
- Fixes the invalid order of `find` flags.
- Adds to our `grep` exclusionary filter additional files we know we don't want to move into a nested docroot.

## Remaining Work
- [ ] Technical Review
- [ ] Copy Review

## Post Launch
To be completed by the docs team upon merge: 
- [ ] Update Status Report
- [ ] Archive from **Done** in Waffle
update git mv grep filtering
issue
created
alexfornuto
username_0
@username_1 feel free to review.
comment
created
slavafomin
username_1
Hello! Thank you for the PR, however, I still believe, that it's a bad idea to use exclusion filter, because you would never know what files end developers are storing in the project's root. I can easily give you another examples of files, which could be stored there, e.g.: `.editorconfig`, `.idea`, `docker-compose.yml`.

As I stated in #4495 the only viable strategy here is to use inclusion filter and specify exact files used by WordPress. This rarely changes and the list of files is fixed, so it could be easily maintained over time.
comment
created
alexfornuto
username_0
@username_2 request for comment, since you suggest being more exclusionary instead of switching to inclusionary.
comment
created
davidstrauss
username_2
The intent for documentation on moving to a nested docroot should be (1) to preserve the functionality of the site and (2) not introduce security issues. Since we're starting with content that was already in the docroot, I think the latter is a low risk.

So, we need to look at how we can preserve functionality. A whitelist of files and paths to move to the nested docroot will introduce problems for sites with content that needs to be in the docroot but won't be on our whitelist. I've seen many sites drop things like PDFs and images right into their existing docroot, even through it's not a best practice.

For some of the file types mentioned by @username_1, it's unclear what the right choice is. For example, a `.editorconfig` file might be more appropriate in the docroot if it concerns the CMS and uses paths that expect the CMS directories to be immediate children. It would potentially break the configuration to hold it outside the nested docroot while moving the other files into one.

So, I would support expanding the blacklist of patterns to exclude from nested docroot migration, but I'd be reluctant to adopt a whitelist approach for the reasons above. If we haven't already, we should also encourage developers to inspect the split of files and potentially make the modifications of their choice.
comment
created
alexfornuto
username_0
Thanks for the additional input! I thinking the best way to move forward is to add a note describing how to add items to the exclusion list, and using the `-n` flag for `git mv` to perform dry runs first.
comment