Cyberduck 101

Uploading work to your server via Cyberduck is mostly relatively straightforward, but there are a few wrinkles to note and learn.

• Files placed in the public_html folder show up in the root of your domain. That is, placing testfile.html in your public_html folder means that the file can be accessed at yoursite.com/testfile.html
• Similarly, folders placed in public_html become directories in your URL. If you create a folder called assignment-one in public_html and then place testfile.html inside of it, the URL for that file will be yoursite.com/assignment-one/testfile.html
• Don’t include any spaces in the names of files you place on your server.
• Use all lowercase letters in your filenames, or use camelCase. Domain names aren’t case sensitive (that is apple.com, Apple.com, APPle.com, and applE.com all work), but folder and file names are (that is, apple.com/mac will take you to a valid page, but apple.com/MAC will not).
• Additionally, name your files semantically—give them descriptive names, and separate multiple words with dashes. For example, page1.html is not a very good name. page-one.html is better. go-dawgs.html (or some other name reflecting the content of this page) is best.

In this class, all files for a given assignment should live in the designated location of your course file structure. This was introduced in the Homepages & Course File Structure lesson and makes it easy for your instructor to find everyone’s work in a consistent location.

Additionally, the main page for each assignment should be named index.html (this is the only “magic” filename in that web browsers, that when pointed to a folder, will automatically look for and load a page named index.html). 1

Workflows

For the first two projects, a great workflow is to do all development locally (AKA on your laptop or desktop) and then upload your files to the server when they’re done. To upload using Cyberduck, simply open Cyberduck and click on your site’s bookmark. Navigate to your site’s public_html folder, and then drag and drop your entire assignment folder (project-one, etc.) into the Cyberduck window. Once the upload is complete, you can now access your work at yoursite.com/webdev/project-one!

Once your work is uploaded to your server, you can make changes to your files in two ways.

First, you can continue to work on the files on your local machine and then upload them when you’re done. This is the recommended way to work on your files for this class. The main benefit is that you can noodle around in private and then make your work publicly visible only when you’re ready. That is, there’s no auto-syncing between the files on your local machine and those on your server. The main benefit of this workflow is it’s pretty hard to make a big mistake; the second method comes with a couple of risks that we have outlined below. Those risks are real, so, again, the workflow I recommend is this first one: edit the local file and then upload it to your server whenever you make those changes public.

The second (riskier) option works only if you’ve made Visual Studio Code the default editor in Cyberduck (to do so, go to the menu bar and select Cyberduck > Preferences or hit ⌘ + , and select Editor (the pencil icon), click the dropdown menu, click Choose…, select Visual Studio Code, and be sure to check the box for “Always use this application.”

Once you’ve done that, you can click on any file in Cyberduck and click “Edit.” Make your changes, then hit save and wait for the “Upload Complete” notification—your changes are now live on your site!

There are, however, two perils with this method. The first is that you’re editing your site live, with no backup. Accidentally delete something, and it’s gone forever. Write some great code or content, but then there’s an issue with your server, and again, gone forever. Also, you’re working in public. Right now, your site likely doesn’t have much traffic, but it’s something to be cognizant of.

The second peril is more real, and you need to understand the way Cyberduck achieves the magic of editing files live on your server with Visual Studio Code. When you click edit, Cyberduck downloads a temporary working copy of the file you’ve chosen to edit and saves it to your computer in a cache folder (a randomly named folder that exists just for this type of thing). Then, when you click save, it uploads the edited cached copy back to your server.

The place where this can bite you is this: if you use this method, but then fail to close the cached/temporary copy in Visual Studio Code and disconnect from the server, Visual Studio Code will still show you this file even though Cyberduck no longer holds any association between it and the file on your server. It’s not uncommon for students to work in a non-associated cached copy and not understand why their site is updating. This can get messy quickly, but thankfully, it has an easy solution: always close the cached copy of anything you’re “editing” in Visual Studio Code through Cyberduck.

Again, the easiest way to avoid this messiness is to edit the local copy of your files, save them to your Dropbox, and then upload them to your server when you’re ready to make them public! Once you feel super comfortable with the process you can test out the second method, but until then the first method is the simplest way to go!