External Server Theming Workflow

Question

Running into a slight workflow problem, and finding out that a lot of us being new to Drupal doesn't help. =) Thank you in advance.

The issue being is that a lot of the front-end developers at my company are used to working locally with every project. But our new Drupal CMS I would like to only have running in one location, not on their local machine or our internal server, but only running on a remote server and installed once. We will have many running for our clients and I need to keep the code maintained properly, and would hate a front-end developer to work on it locally to only find out their version is behind now during the length of their project. Or worse yet, they are working on five projects at once and they have to maintain all of those on their machine.

We figured out a small hack to get CodeKit to work on their machine while still seeing the files on the server refresh, so SASS isn't an issue. But they are so used to working locally, they are having a hard time grasping theming on a remote server. I am very much used to working in larger applications that need several environments or complicated compiles, so using Drupal in one place seems SO easy to me.

How does everyone else work on themes? What does your workflows look like? What advice can you give? Anything will help!

Answer 1

Working locally should be a priority - not working on a remote server, that would cause the most confusion and complications. To work in a team environment for theming, it's best if you use Git for version control and Drush for moving content from the remote server to local. Ideally everyone would compile locally and push up.

[remote server] <--- [Bitbucket/Github repo] <---> [local environment]

Main code repository would be stored in a central location like Github or Bitbucket. You can go directly to the server, but if you manage multiple projects, it's a lot easier to keep all of them under a team account and manage access to the team.

[repository] <---> [local environment]

Developers pull down current code from repo. This ensures everyone has the latest updates. Commit often, push semi-often. This makes merges easier if there's a conflict.

[remote server] <--- [repository]

Have the remote server pull in changes from the repo. If you have Drush aliases set up, this can be as simple as drush @remote.alias pull. You should never make changes directly on the server and push them back to the repo as there wouldn't be any really good records of who made that change if you all share the same SSH account.

Also having Drush aliases set up, developers can then use sql-sync or sql-sync-pipe to pull down the databases with ease. Whenever new content is added - just sync. As for files, you can use Stage File Proxy, one of my favorites.

Answer 2

I mount the remote drive locally using 'Transmit' so I can use my local dev stack (sublime, livereload, sass, compass etc...). This does not always play nicely with file permissions and kinda urks some of the devs who are used to working locally then to git and staging servers for testing. I just backup alot and like to fly by the seat of my pants on the live server... although I feel i should be working git in there more!

Answer 3

1. Mount your FTP/WebDAV server as a drive using e.g. NetDrive.
2. Add a new Drupal theme with CSS and JS files.
3. Open you website in Google Chrome/Opera and open DevTools.
4. Make modifications of your CSS/JS files and save them using Ctrl-S in the mounted drive.

Using this workflow you don't have to switch between Chrome/Opera, text editor and FTP/WebDAV client.