June 16, 2011

Dreamweaver FTP testing server and remote server problems

Hidden in the recent comments on the Dreamweaver FTP Can't Connect article is a solution to a new issue regarding Dreamweaver FTP testing server and remote server problems. Apparently when you set up a testing server (a local server) in Dreamweaver, you're unable to use Dreamweaver's FTP to upload to the remote server (the web hosting account). Or, as "ionrane" said:

I've had dreamweaver settup properly for my remote server.

I added a local testing server, which seems to be settup right – all works well UNTIL I try to "Put" files to the remote server.

For some reason, it seems, instead to connect to the local XAMPP server. Of course, that means it just looks to see about overwriting the file with itself.

Between a hint at the Adobe forums and a little thinking and discussion on our part, we've come up with a solution. I won't copy it here, as it's already in the comments of my article, formatted in a nice sequence. But, if you're having problems with FTPing to your remote server in Dreamweaver due to your testing server definition, have a read. The pertinent discussion starts around comment #74 and ends at Comment #80.

5 Comments to "Dreamweaver FTP testing server and remote server problems"

  1. Gordon says:

    Basic to the problem is configuring both:

    * Remote server
    * Testing server.

    Now "ionrane" did one thing weird — chose to point Dreamweaver source files at the testing server's files. Thus when 'uploading' to the _TESTING_ server, the files were moved over themselves. The normal way would actually be to have three different sets of files. 1) Source files for Dreamweaver to edit. 2) Testing server with copy of files. 3) Remote server with copy of files. (No need for these to be the same files, just tracking copies.)

    Then I noticed in Dreamweaver CS5 that the "synchronize" feature updates all sites including the remote server as well.

    Then the three solutions given are quite adequate. a) Use 'synchronize' as I described. b) Use FileZilla to copy to the actual production server, and possibly don't list in Dreamweaver at all (very fast, BTW). c) Use a separate 'site' definition in Dreamweaver with the same root source or local files, first 'site' for testing, second 'site' for uploading to the production server. The 'b' and 'c' options would also work with multiple level site definitions as one user commented, i.e. 3 servers for testing, staging (user testing), and production + the original local code file set for Dreamweaver separate from all 3 servers' — with a Dreamweaver 'site' for each combination. When getting that complicated I would suggest adding in the 4th option of Subversion version control so as to keep track of changes and be able to reverse errors. And probably define one of the sites as the official 'source code' for cheking in and out with Dreamweaver, and each developer (if more than one) having their own testing server (most likely on their own computer).

    Also that set of posts seemed to have some confusion about the role of the 'server model' and the 'testing' and 'remote' buttons. Server model just tells Dreamweaver what the server is running in order to perform certain debugging tasks. It should be set correctly for the way one is developing. And mostly it applies to the testing server as that is the only one that will have an active role for Dreamweaver in the server itself — the whole point of the 'testing' server.

  2. Diane Vigil says:

    Thanks, Gordon. I posted a note in the other thread (which was about Dreamweaver FTP inability to connect, rather than specifically about testing servers). Thanks so much for your input.

  3. Gordon says:

    OK, now I'm really confused. What I said above was working, I made some changes, and now Dreamweaver's behavior seems to have changed. (It could be we are dealing with both a bug AND dealing with a capabilities/documentation issue. So my 'a)' option above may need to be modified! (Once we figure it out…))

    Previously I was set up almost as "ionrane" but with separate local and testing server file locations. (This is AN essence of one level of problem — there are separate issues. First is the location to which the file transfer occurs. Second is whether the transfer works at all. "ionrane"'s problem in part was based on a seeming misunderstanding — that there is actually a transfer to the testing server, just as there is a transfer to the production server. Treat it that way and the issues reduce to a question of _which_ server is being 'put' to, not whether a transfer is occurring at all which was the major subject of that other thread as a whole.)

    Now the steps I went through are as follows. First I am using Dreamweaver CS5. Set up testing and production server, with testing a direct network connection COPYING files, and production on a normal remote service bureau (LAMP using SFTP). THEN I set up the remote server for checking out — I _think_ that is when a change of behavior occurred. (And I took that feature off again, but no relevant change in behavior in that step.)

    NOW both synchronize and put go to the same server — the one marked as "remote". Also I noticed that in CS5 with multiple servers entered I can select which _single_ server is "remote", and which single server is testing, but only one of each.

    SO I apparently can set the testing server (now) as both testing and remote. And _now_ with the production server set as remote both "put" and "synchronize" actions connect with the production server. If I change the selection to the testing server, then both "put" and "synchronize" relate to the testing server. The only multi-way path occurs if I have set the production server as "remote" and try one of the "live" debugging options it also uploads the file in question to the testing server.

    SO when this behavior is working, then option 'a)' would be changed to the option like discussed somewhere in the other thread, but in a more normal fashion in CS5. Normally work with the testing server for changes until happy–using the sites-edit-servers options to select the testing server as the "remote". Then synchronize or otherwise make sure the local files are correct. SWITCH to the production server (using sites menu) and synchronize or put–in this case synchronize probably is best.

    WHAT I DON'T KNOW is what triggered a change in behavior. Originally as with "ionrane", the selection of put server was not the one selected as "remote", now it is consistently working with the one selected "remote".

  4. Dawn says:

    Our website was developed by an outside consultant. We downloaded the website files from the host server into Dreamweaver and made edits. Now I want to upload two new html files to the server. The FTP connection is established and works to transport the files. The problem is that when I "put" the files, from my local folder onto the remote server, they do not upload into the correct folder. they show up under the root folder, but outside the correct folder. I can't drag and drop them into the correct folder (where all the other website files are), nor can I designate/select the correct folder initially. Can anyone tell this newbie what I'm doing wrong?
    Thank you!

  5. Diane Vigil says:

    Dreamweaver uploads files based on its understanding of your server folder structure. On your hard drive, the folder you specified as containing the website is the "website root".

    My guess is that, on your server, your website "root" is somewhere like this:

    /home/yourusername/public_html/

    where the folder public_html/ contains your home page (index.html, index.php, etc.). If that's true, then edit your Dreamweaver Site setup:

    > Site > Manage Sites > select your site
    > click Edit
    > click Servers
    > Double-click your server
    > in the panel, to the right of Root Directory, type this:

    public_html/

    Try that. If that isn't the correct folder, at least you'll know where to look to fix it.

Have your say ...

If this is your first comment, it will be held for moderation (but comments are appreciated). Otherwise, just be courteous, don't drop links unless highly pertinent — and no substituting keywords for your name. Posters must be 16 or older. We use Akismet, so if you don't see your non-spam comment posted, contact me.


Manage your subscriptions

Archives
© 2004-2012 DianeV Web Design Studio in Austin, Texas. All Rights Reserved.
27 queries. 0.172 seconds.