0

I work for a company that wants me to update their Wordpress site. In the past, the developers seem to just change the files locally then upload them to the dev server via FTP. So, I copied the site's theme files to my computer, made my changes, complied the css (they're using Sass), then upload those changed files back to the dev server. But, none of this seems efficient to me.

I'm not familiar with this so I'm a bit confused on how I should go about this. The sites I have worked on in the past have been pretty low scale. For my own site, because it was static, I made my changes locally, used Gulp for the Sass and other tasks and pushed it to GitHub. And since I hosted it on GitHub, that was it.

But, right now, I'm doing a bit of "cowboy coding" and that isn't the right way. So, I would love if someone could give some suggestions on an efficient way to go about this? Thanks in advance!

0

I assume you mean "load them to the live server".

Once you have this workflow set up it's not actually that hard to maintain. You always do the work on the dev server and just keep pushing live.

usually the flow is dev --> live or local -->live. No need for an in between.

If you are looking for version control here are some options:

https://pantheon.io/blog/top-9-resources-wordpress-version-control

  • No, not the live server. There's a dev site and a live site. So, I've just been making changes on the dev site for now. But, it's been a lot of changing code, uploading, checking for errors then repeat. Also, they don't want all the changes pushed to the live site at once. That is why I feel version control needed. – user115558 Mar 16 '17 at 15:42
  • So you're working local, uploading to a dev site, then re-uploading to a live site? – rudtek Mar 16 '17 at 15:45
  • Right. I only have access to the dev site though. Someone else is doing the uploading to the live site right now. I don't really know why. – user115558 Mar 16 '17 at 15:46
  • Okay. Why not do the work on the dev site directly? That's what it's for! Then when you give the okay let them send the site over to live. added bit more info above. – rudtek Mar 16 '17 at 15:50
0

For any project i work i have the following workflow, first what i have setup:

  • Dev environment, local for your own changes, in a server for testing, code review, if you are only one person you can just do it in the server, there is also multisite.
  • Production, or live environment.
  • The project is versioned in github.
  • There are 2 branches master and dev.
  • Loading the repo in my IDE (you can also work remote and have the repo locally, i use Netbeans).

Now the workflow is:

  1. An update is requested (a fix, feature etc).
  2. I create a branch from the dev branch and name it something like fix-bug-23.
  3. I commit the changes and create a pull request to be code reviewed and merged to dev if good.
  4. When the week is complete, dev has all the updates that were completed in that week (i use scrum so there needs to be a "time-box" 1 week in this case) .
  5. The dev branch is QAed so it can be merged to master
  6. dev is merged to master if all is good then then there is a test in prod for the updates.

This way you can also work within a team so everyone will do his branch for his update, if you are only 1 person you can just commit directly to dev.

  • dev -> dev enviroment
  • master -> prod/live environment

if you have access only to the dev server thats ok, just make sure the person who is uploading to prod, uses the master branch.

if you need something that needs to be in prod right away, create a hotfix branch creating a new branch based on master then merge back to it.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy