luangjokaj / wordpressify

🎈 Automate your WordPress development workflow.
http://www.wordpressify.co
MIT License
1.6k stars 142 forks source link

Windows broken since v0.2.9 #78

Closed luangjokaj closed 2 years ago

luangjokaj commented 3 years ago

preview https://nodejs.org/api/process.html#process_process_getuid @ribaricplusplus

ribaricplusplus commented 3 years ago

Oof that's not nice. I'll fix this, I just need to make sure that permissions on Windows work out okay. And it would probably be nice to setup a GitHub Action runner that tests Windows.

ribaricplusplus commented 3 years ago

@luangjokaj Maybe revert to pre-v0.2.9 until we're sure Windows works fine?

luangjokaj commented 3 years ago

I will keep v.0.2.9 because the previous version had anyways issues on Windows, and never worked properly without Linux. It would be nice if we can fix this since now we are using Docker. However also through the Linux sub-system there is still an issue: When exiting the Gulp process, Docker doesn't stop as it should.

preview

ribaricplusplus commented 3 years ago

@luangjokaj I think you are sending a suspend signal with Ctrl+Z, which doesn't stop the process. If you write 'jobs' you will probably see suspended background jobs. It should work if you use Ctrl+C, give it a try and tell me if it does.

(If you are still in that shell, write fg 1 and then Ctrl+C)

luangjokaj commented 3 years ago

@luangjokaj I think you are sending a suspend signal with Ctrl+Z, which doesn't stop the process. If you write 'jobs' you will probably see suspended background jobs. It should work if you use Ctrl+C, give it a try and tell me if it does.

(If you are still in that shell, write fg 1 and then Ctrl+C)

Yes, you are right. It works with Ctrl+C.

ribaricplusplus commented 3 years ago

Alright, though I'm still planning to fix this issue when I get the time; I'm just a bit busy right now. Notify me if it doesn't really matter so I don't spend time on it.

luangjokaj commented 3 years ago

Alright, though I'm still planning to fix this issue when I get the time; I'm just a bit busy right now. Notify me if it doesn't really matter so I don't spend time on it.

I think it would still be awesome if you can work on it when you have time.

adallaserra commented 3 years ago

I'm getting this too on BigSur 😩

`📦 Downloading 🎈 WordPressify files in: → pca

In the directory: /Users/adallaserra/Documents/Sites/pca This might take a couple of minutes.

✔ 1. Creating 🎈 WordPressify files inside → pca ✔ 2. Installing npm packages... ⠏ 3. Installing WordPress and building Docker images.../Users/adallaserra/.nvm/versions/node/v14.15.1/lib/node_modules/wordpressify/installer/index.js:59 throw err; ^

Error: Command failed with exit code 1: npm run env:build /bin/sh: docker-compose: command not found [17:29:15] 'buildContainers' errored after 11 ms [17:29:15] Error: Command failed: docker-compose up --build --no-start at checkExecSyncError (child_process.js:616:11) at execSync (child_process.js:652:15) at buildContainers (/Users/adallaserra/Documents/Sites/pca/gulpfile.js:134:2) at bound (domain.js:430:14) at runBound (domain.js:443:12) at asyncRunner (/Users/adallaserra/Documents/Sites/pca/node_modules/async-done/index.js:55:18) at processTicksAndRejections (internal/process/task_queues.js:75:11) [17:29:15] 'env:build' errored after 14 ms npm ERR! code ELIFECYCLE npm ERR! errno 1 npm ERR! wordpressify@0.2.9-29 env:build: gulp env:build npm ERR! Exit status 1 npm ERR! npm ERR! Failed at the wordpressify@0.2.9-29 env:build script. npm ERR! This is probably not a problem with npm. There is likely additional logging output above.

npm ERR! A complete log of this run can be found in: npm ERR! /Users/adallaserra/.npm/_logs/2021-02-01T22_29_15_679Z-debug.log

wordpressify@0.2.9-29 env:build /Users/adallaserra/Documents/Sites/pca gulp env:build

[17:29:15] Using gulpfile ~/Documents/Sites/pca/gulpfile.js [17:29:15] Starting 'env:build'... [17:29:15] Starting 'setupEnvironment'... [17:29:15] Finished 'setupEnvironment' after 618 μs [17:29:15] Starting 'buildContainers'... at makeError (/Users/adallaserra/.nvm/versions/node/v14.15.1/lib/node_modules/wordpressify/node_modules/execa/lib/error.js:59:11) at handlePromise (/Users/adallaserra/.nvm/versions/node/v14.15.1/lib/node_modules/wordpressify/node_modules/execa/index.js:114:26) at processTicksAndRejections (internal/process/task_queues.js:93:5) at async /Users/adallaserra/.nvm/versions/node/v14.15.1/lib/node_modules/wordpressify/installer/modules/run.js:213:4 { shortMessage: 'Command failed with exit code 1: npm run env:build', command: 'npm run env:build', exitCode: 1, signal: undefined, signalDescription: undefined, stdout: '\n' + '> wordpressify@0.2.9-29 env:build /Users/adallaserra/Documents/Sites/pca\n' + '> gulp env:build\n' + '\n' + '[17:29:15] Using gulpfile ~/Documents/Sites/pca/gulpfile.js\n' + "[17:29:15] Starting 'env:build'...\n" + "[17:29:15] Starting 'setupEnvironment'...\n" + "[17:29:15] Finished 'setupEnvironment' after 618 μs\n" + "[17:29:15] Starting 'buildContainers'...", stderr: '/bin/sh: docker-compose: command not found\n' + "[17:29:15] 'buildContainers' errored after 11 ms\n" + '[17:29:15] Error: Command failed: docker-compose up --build --no-start\n' + ' at checkExecSyncError (child_process.js:616:11)\n' + ' at execSync (child_process.js:652:15)\n' + ' at buildContainers (/Users/adallaserra/Documents/Sites/pca/gulpfile.js:134:2)\n' + ' at bound (domain.js:430:14)\n' + ' at runBound (domain.js:443:12)\n' + ' at asyncRunner (/Users/adallaserra/Documents/Sites/pca/node_modules/async-done/index.js:55:18)\n' + ' at processTicksAndRejections (internal/process/task_queues.js:75:11)\n' + "[17:29:15] 'env:build' errored after 14 ms\n" + 'npm ERR! code ELIFECYCLE\n' + 'npm ERR! errno 1\n' + 'npm ERR! wordpressify@0.2.9-29 env:build: gulp env:build\n' + 'npm ERR! Exit status 1\n' + 'npm ERR! \n' + 'npm ERR! Failed at the wordpressify@0.2.9-29 env:build script.\n' + 'npm ERR! This is probably not a problem with npm. There is likely additional logging output above.\n' + '\n' + 'npm ERR! A complete log of this run can be found in:\n' + 'npm ERR! /Users/adallaserra/.npm/_logs/2021-02-01T22_29_15_679Z-debug.log', failed: true, timedOut: false, isCanceled: false, killed: false } adallaserra@ozsmacbookpro pca % `

ribaricplusplus commented 3 years ago

@adallaserra

This seems to be unrelated. It says the command docker-compose is not available. Make sure that you have Docker Compose installed (info in README) and that it is available on your $PATH.

adallaserra commented 3 years ago

@ribaricplusplus You're right. I was being stupid... just realized that and it now works. ps: LOVE wordpressify—saves the day everyday!

h08831n commented 3 years ago

Has anyone found a solution to this issue? Will installing the older versions of the train solve the problem? If installing the older version fixes the problem, how should this be done? I used the Linux terminal in Windows and the following error occurred:

[23:10:31] 'startContainers' errored after 1.79 [23:10:31] Error: Command failed: docker-compose up -d at checkExecSyncError (child_process.js:639:11) at execSync (child_process.js:676:15) at startContainers (/mnt/c/Users/hossein/Desktop/filmara/gulpfile.js:127:2) at bound (domain.js:425:14) at runBound (domain.js:438:12) at asyncRunner (/mnt/c/Users/hossein/Desktop/filmara/node_modules/async-done/index.js:55:18) at processTicksAndRejections (internal/process/task_queues.js:79:9) [23:10:31] 'dev' errored after 1.8 s error Command failed with exit code 1.

jeremyevans6 commented 3 years ago

@h08831n, I don't have a specific answer to your error. That said, I love WordPressify and spent an inordinate amount of time to get the latest version running on Windows. I'm going to be verbose, apologies, and I hope this helps you get it running.

First, I attempted to use older versions of WordPressify that have worked for me in past. I recently switched Windows machines and, while this worked just 2 months ago, I could not get this approach to work on the new machine. There is probably a working method here, relying on using a pre-docker version and WAMP.

Next, I got into WSL. Having never used WSL, I found many small inconsistencies from normal Linux which I cannot enumerate here (forgotten at this point). I set up WSL 2 with Ubuntu 20. I used the home directory of the Ubuntu user and use explorer.exe . to see the directory in Windows Explorer. There may be a requirement of using VS with the WSL extension to edit these files, though I'm unsure about this.

Finally, let's talk about installing WordPressify. I tried many things, but ultimately could use npx wordpressify, almost as intended. I fixed some small issues here and there which I've forgotten, but the last error corrected is worth documenting. Docker installed on WSL apparently doesn't work, necessitating the use of the Windows GUI version. The Windows Docker installs a number of packages and has an automagic integration with WSL 2, great. I couldn't tell you if I still had docker-compose installed on my WSL or Windows (it's included in the GUI version), but I had those set up nicely and could run a hello-world as my non-root user.

Where Wordpressify specifically hitches here and could likely be corrected, is the version specified at the top of the docker.yml file. I got an incompatibility with the 3.8 version pulled by Wordpressify and the latest docker Windows version. (I'm rather bumbling, if you couldn't tell, so I don't even know how to check the Windows version number.) This was resolved by replacing the version with the last major version, in which it introduces syntactic breaks in the config file, i.e., version 3. Now, you can't run npx again because it will pull the original config, so run the previously failed command: docker-compose up.

Predictably, this produced another error: UID 0 is not empty returned by usermod while building docker's Wordpress package, or something to that effect. I'd screwed the whole environment several times over by this point, so this was resolved by deleting the Wordpressify directory and running npx in a new directory. This probably won't happen if you didn't make all of the mistakes I did in this process.

After docker pulled all images, it started the container successfully. Stop the container (ctrl + c) and run npm run dev like normal.

I also had some issues with my local Windows node install interfering with the wordpressify command/npx wordpressify. Make sure WordPressify is completely uninstalled from Windows if attempting to use the WSL method, something that wasn't accomplished for me with a simple npm rm -g wordpressify. I ran a find -name wordpressify and wiped it from AppData/Roaming (I think). You can check if Wordpressify is currently installed via wordpressify -v: a non-npx installation will yield a version number, whereas using npx will not result in a global package being found.

luangjokaj commented 3 years ago

@h08831n, I don't have a specific answer to your error. That said, I love WordPressify and spent an inordinate amount of time to get the latest version running on Windows. I'm going to be verbose, apologies, and I hope this helps you get it running.

First, I attempted to use older versions of WordPressify that have worked for me in past. I recently switched Windows machines and, while this worked just 2 months ago, I could not get this approach to work on the new machine. There is probably a working method here, relying on using a pre-docker version and WAMP.

Next, I got into WSL. Having never used WSL, I found many small inconsistencies from normal Linux which I cannot enumerate here (forgotten at this point). I set up WSL 2 with Ubuntu 20. I used the home directory of the Ubuntu user and use explorer.exe . to see the directory in Windows Explorer. There may be a requirement of using VS with the WSL extension to edit these files, though I'm unsure about this.

Finally, let's talk about installing WordPressify. I tried many things, but ultimately could use npx wordpressify, almost as intended. I fixed some small issues here and there which I've forgotten, but the last error corrected is worth documenting. Docker installed on WSL apparently doesn't work, necessitating the use of the Windows GUI version. The Windows Docker installs a number of packages and has an automagic integration with WSL 2, great. I couldn't tell you if I still had docker-compose installed on my WSL or Windows (it's included in the GUI version), but I had those set up nicely and could run a hello-world as my non-root user.

Where Wordpressify specifically hitches here and could likely be corrected, is the version specified at the top of the docker.yml file. I got an incompatibility with the 3.8 version pulled by Wordpressify and the latest docker Windows version. (I'm rather bumbling, if you couldn't tell, so I don't even know how to check the Windows version number.) This was resolved by replacing the version with the last major version, in which it introduces syntactic breaks in the config file, i.e., version 3. Now, you can't run npx again because it will pull the original config, so run the previously failed command: docker-compose up.

Predictably, this produced another error: UID 0 is not empty returned by usermod while building docker's Wordpress package, or something to that effect. I'd screwed the whole environment several times over by this point, so this was resolved by deleting the Wordpressify directory and running npx in a new directory. This probably won't happen if you didn't make all of the mistakes I did in this process.

After docker pulled all images, it started the container successfully. Stop the container (ctrl + c) and run npm run dev like normal.

I also had some issues with my local Windows node install interfering with the wordpressify command/npx wordpressify. Make sure WordPressify is completely uninstalled from Windows if attempting to use the WSL method, something that wasn't accomplished for me with a simple npm rm -g wordpressify. I ran a find -name wordpressify and wiped it from AppData/Roaming (I think). You can check if Wordpressify is currently installed via wordpressify -v: a non-npx installation will yield a version number, whereas using npx will not result in a global package being found.

Just merged a fix for Windows thanks to @imjlk (#102). If you are on Windows all you need is WSL (Windows Subsystem for Linux), then should be as easy as it's here: https://www.youtube.com/watch?v=dDl0pMtTdSg

jeremyevans6 commented 2 years ago

Hey there, revisiting this. Still using WordPressify in WSL. Thanks again for the best dev environment in WP history!

Two small issues: one for the docs and one for that would pose an obstacle for new users.

1) I forgot I was running a frozen node version for another project, got some cryptic failures with npx. Switched to the latest branch of n and resolved.

2) I still get an issue from the version: '3.8' in the docker-compose.yml. I can simply change it to version: '3' and re-run npm run env:build to conclude the installation successfully. This is similar to an issue I mentioned before.

luangjokaj commented 2 years ago

2. I still get an issue from the version: '3.8' in the docker-compose.yml. I can simply change it to version: '3' and re-run npm run env:build to conclude the installation successfully. This is similar to an issue I mentioned before.

@ribaricplusplus can you reproduce this?