Proposal to remove the wordpress directory from tracking.

[kopepasah]

Due to the currently necessity to keep the wordpress directory, there is no way to use wp-local-docker efficiently with git://develop.git.wordpress.org. In addition, sites which use the full WordPress install as a repo are also limited in the ability to use wp-local-docker, without modifications.

• Is there a specific reason the wordpress must exist in the repo?
• Could it not be removed from tracking and added upon docker-compose up (or some other method)?

Removing the wordpress directory from the repo and creating it on the fly (when needed) would open the doors to different ways of utalizing wp-local-docker.

[kopepasah]

Currently, my method of using wp-local-docker with git://develop.git.wordpress.org is as follows:

• rm -r wordpress
• ln -s [path to wp-develop]/build wordpress
• docker-compose up

While this does work temporarily, there are two problems:

1. wp-local-docker now has uncommitted changes which, when reset, require the process above to be repeated.
2. Running docker-compose down breaks the symlink reference due to the creation of wordpress/wp-cli.local.yml, requiring the process above to be repeated.

[moraleida]

Thinking of ways we could implement this, I think the main barriers right now are that the composer file relies on the wordpress folder being the install root to set up mappings inside the containers.

@kopepasah does it work for you If clone from the develop repo inside the wordpress folder and change the volume paths in docker-composer.yml from ./wordpress:/var/www/html to ./wordpress/src/build:var/www/html?

[kopepasah]

@moraleida I will try that, but it still does not solve the issue of cloning an entire repo (which not uncommon). Any thoughts on addressing that issue?

[kopepasah]

@moraleida actually, I tried something similar, but not the same. I cannot clone WordPress develop into the wordpress directory because the path already exists and is not empty (which is the same issue with full WordPress repos). As such, I cloned WordPress develop into a directory at the root of the wp-local-docker root (i.e. [wp-local-docker]/core). This is possible, because I can just exclude core from the wp-local-docker repo and do not have to worry about changes.

Using this structure, I added docker-compose.override.yml with the following config:

version: '3'
services:
  phpfpm:
    volumes:
      - "./core/build:/var/www/html"

That did not work.

Second, I removed the docker-compose.override.yml file and edited the docker-compose.yml directly (with the expectation that this would also not work because the override and main file just merge - I assume).

That did not work either.

---

I still propose this directly be removed from tracking.

Regarding the composer files you mentioned, where are these?

[moraleida]

@kopepasah sorry I wasn't clear before. I'm cool with the idea of removing the wordpress folder, but thinking of how we setup the structure of the project for when it's gone. Right now the setup auto-downloads the current stable version into that folder and we would have to add at least another prompt to check if the user wants to auto-download - which is simple enough. We could even add support for command line args to the setup script to automate building from trunk - which gets us closer to what VVV has, but in a simplified way.

If one could clone wordpress-develop into that folder and just change the association on docker-compose.override.yml (this is what I called a "composer file" btw) this would be a simple solution. We should check why that is not working and maybe go from there.

[tlovett1]

@kopepasah I see the issue.

The WordPress directory is just www essentially. I actually think we should rename it to something like www or web.

Here's a a proposed solution.

1. Rename wordpress to www
2. Add wp-develop-compose.yml:

   version: '3'
   services:
   phpfpm:
   volumes:
     - "./www/src:/var/www/html"
     - "./config/php-fpm/php.ini:/usr/local/etc/php/php.ini"
     - "./config/php-fpm/docker-php-ext-xdebug.ini:/usr/local/etc/php/conf.d/docker-php-ext-xdebug.ini"
     - "./config/php-fpm/wp-cli.local.yml:/var/www/html/wp-cli.local.yml"
     - ~/.ssh:/root/.ssh

3. On startup run docker-compose up -f docker-compose.yml -f wp-develop-composer.yml

Then you would of course just setup the develop repo in /www.

Thoughts?

[kopepasah]

@tlovett1 I like this approach. However, it does not address the case in which a site exists as a full WordPress install (or sometimes more, like WordPress Develop). If we keep the www directory, a developer has to jump through some weird (albeit simple) hoops to get the site running. We are currently working on a project that has this exact setup and my steps for getting it running on wp-local-docker is as follows:

1. Clone wp-local-docker and change to its directory.
2. Remove the .gitkeep file from wp-local-docker: rm wordpress/.gitkeep
3. Clone the WordPress repo into the wordpress directory of wp-local-docker: git clone git@[REPO].git wordpress
4. Change into the new repo directory: cd wordpress
5. Add the .gitkeep file back: touch .gitkeep (required to show unchanged status in wp-local-docker
6. Edit .git/info/exclude of the new WordPress repo to exclude .gitkeep from this repository.

While this does work, it is quite tedious.

In addition, these steps would still need to be followed if working with WordPress Develop repo, if cloning into the www directory.

Is there a specific reason we need to track the www directory?

[cmmarslender]

V2 of WP Local Snapshots allows selecting WordPress core as an option when installing WordPress and should solve problem this issue was intending to resolve

[kopepasah]

@cmmarslender not entirely, but happy to continue the conversation in the new repo.