@alwaysblank so he developed and launch 5+ sites with the Sage framework theme that he designed. All of them have the complete folder structure in the theme directory. There is a git repo for each site. Plus there is a git repo for the “master” template that he built, which is what they are starting every new site with, it’s basically blank, just setup and configured with the settings he put in place.
But after reading some of the Sage documentations, he either didn’t know what he was doing or he wasn’t 100% complete and just started building new sites anyway.
I guess I’m not totally following what your problem is then. The repos should be the source of truth for each site, so if you need to update a site make your changes locally, run the build process, check your work in your local development environment, and then push any changed files to the remote server (or, ideally, use a system like Trellis that allows for no-downtime deploys).
Well I’m not sure if its a problem, I’m trying to get a better understanding of how Sage and the deployment process should work.
It looks like they are only using Sage 10, not using Bedrock or Trellis.
We are using Kinsta, so I went into each website’s server that is live and looked at the theme folder and each site has the complete folder structure of the git repo (everything that you would see when your building it locally for the firs time). They don’t have the repo connected to the server in anyway, so it looks like when the developer went to push a site live for the first time, he just manually copied everything from his local environment over to the server and than installed yarn & node on the server, then ran the build script.
So right now if I wanted to work on a live site in a local environment, I would have to clone the repo, then either use like a migration plugin like Duplicator to copy over the WP Database & plugins, etc., from the live site. Use a tool like Local by FlyWheel to run WP locally, run the migration tool locally and whatever else to get it up locally. Then when im done editing it and I run the build script, I could either copy over the changed files like you said or do what he did and probably just dragged the whole folder over to the server.
Or like I said earlier, since he has yarn/node installed on the server I can just SFTP to the server, edit the files and run the build right there on the server BUT when I was told that’s how they have been doing it, it just didn’t seem right. Which leads me to believe that the developer either didn’t fully know what he was doing or just didn’t care.
One should avoid to develop on a production server.
The developers usually have their own development system, like a VM (Vagrant) or Containers (e.g. Docker).
Often a staging server is put between the developers and the production system for more extensive review.
Generally you shouldn’t run the build process on a production server. It exposes you to potential vulnerabilities in the node ecosystem that are otherwise not a concern, and it uses up system resources on a system that shouldn’t be used for that. Always run the build process locally and transfer files to the production server. The only thing the production server should do is serve your site. If the previous developer was running builds on production, he was doing it wrong.
Well it sounds like my suspicions were correct. I’m new to WordPress development, so I just wanted to double check. My background is mainly JavaScript, React/Nextjs, so this is a little bit of a learning curve, although I have built my far share of WordPress websites but using prebuilt themes/frameworks.
I followed the steps from: https://github.com/roots/sage, did yarn start, browsersync started with no errors, the last line in the terminal is:
[Browsersync] Watching files...
So I edited a few different files and noticed that in the terminal browsersync did nothing after I saved the changes, meaning that it did not run/re-compile any of the files, it still said Watching files…
Any ideas why it would be working? This issue does not seem to be related to Local by Flywheel, seems to be Browsersync or something on my computer.
What OS are you using? OS X; WSL 2; Linux? Maybe BrowserSync has issues watching on that file system - which would mean it has to use polling - or it has issues doing both?
I’m on Windows 10 with WSL 2, using VSCode and using WSL 2 as the terminal. I’ve tried using PowerShell in VSCode terminal, same outcome.
I’m guessing it has issues watching the files because when I run yarn start, everything is the terminal looks normal, browsersync launches and displays the proxy & urls for the localhost and the last line says “[Browsersync] Watching files…” but like I said once I edit any files and save them, nothing changes/happens in the terminal.
Are you sure the files are really changed? Have you tried to directly change a file in the console (e.g. nano)? I noticed that sometimes WSL 2 can be in a wrong directory although it shows the path to the directory. cd out of it and then cd back in, maybe this helps.
It looks like this is a problem with WSL2 and Flywheel Local. I don’t think there’s anything in Sage that’s going to affect this particular issue. WSL2 is running its own virtual file system thingie and I haven’t used Flywheel’s Local in years but it probably either wants to do something similar or it wants file/system resources that it can’t get at when they’re in WSL2. In any event you may have better success talking to Flywheel, webpack, or WSL2 support.
I just tried it with Docker, I don’t get the webpack errors, but Browsersync still does not update when I edit & save any files (i.e. resources>styles>app.scss).
Can I ask what you guys use to run WordPress locally?
I use Local by Flywheel on MacOS and haven’t had trouble with the filesystems/browsersync problem. That said, when I look at Local forums, Windows users seem to have more issues with filesystems, so you’re not crazy there!
You may try flywheels “Open Site Shell” option and then run yarn start from there?
I’ve used several things. On Windows iirc I had the best luck w/ devilbox, although it wasn’t totally without problems. I’ve also used Laravel Homestead.
My experience w/ doing Roots development on Windows was that the more you rely on a solution that “just works” (i.e. Local) the more it will just not work–the ones I had the most success with were the ones “closest to the metal” as they say. I was able to get the whole Roots stack (i.e. using Trellis for VMs & deploys) running on Windows, which worked reasonably well, although I haven’t done that in a very long time. IME the fewer layers of abstraction you use to set up your dev environment on Windows, the easier it’s going to be to work with and debug.
Eventually though I just switched over the Linux which was a far more pleasant development experience.
Well after much time spent trying to get browsersync to work, I figured it out.
I have been using the WSL terminal, which is my default for VSCode, so I decided to try good old PowerShell, I switched to PS and ran Yarn, then Yarn start. BOOM! browsersync is working.
So far I have tested it with Flywheel Local, DevKinsta (which is using docker) and I have tried just Docker by itself, all working just fine with browsersync!!
Hello @alwaysblank - I’ve got an aside question about the 12-factor-wordpress workflow (probably is a stupid question) - and it’s about the Factor #1 (“One codebase tracked in revision control, many deploys”).
When it said “1 WordPress site = 1 repo (1 codebase per app)” it means only the theme folder or the whole WP site?
