Looking for some handy Dreamweaver features

I'm running Dreamweaver CS4 and there are a few things that would really make my development easier, and I'm wondering if maybe they're hidden in  there somewhere and I just haven't found them.

I have a live site that the public accesses and I also have a "sandbox" version of the site that looks like the live site and is 100% functional, where we try new risky things and get them working before we move the code to the live site.It's also handy to have a private place out on the web where geographically separated team members can view and comment on the work-in-progress.  I maintain both sites with Dreamweaver.

The thing I'm always afraid of doing is accidentally (at 3AM after a long day, for example) uploading the sandbox version of a page to the live site, since I'm often switching Dreamweaver back and forth between the two sites. One thing that would help me to never do that is to color code the directories so that the tabs at the top of Dreamweaver that show the open files would have different colors depending on the directory they came from: sandbox greenish, live orangish.  Is anything like this available?

I'd also like to be able to lock a project from being uploaded to the remote server. For example, I would say, "I'm going to be working exclusively on the sandbox site for the next six hours and under no circumstances do I want to change anything on the live remote site, as by accidentally, for example, having Dreamweaver pointing to  the wrong site."  I could just set the lock on the live site and not worry about it.  Anything like that available?

And finally, how about an asterick, or some other mark, next to a file in the local files listing at the lower right of the work area, that indicates that that file has been changed locally and has not yet been synchronized with the remote version of the file?

Thanks for any ideas.
stevaAsked:
Who is Participating?
 
Jason C. LevineNo oneCommented:
>> I maintain both sites with Dreamweaver.

This is built-in.  When you define the site, you specify a Remote Server (live) and a Testing Server (testing).  Switching the Files View to the Testing Server should then lock all Puts to the Testing Server.  So you end up with three copies of your content: Local, Remote, Testing.

If you upgrade to CS 5 or 5.5 you can also throw Subversion into the mix.

http://www.adobe.com/devnet/dreamweaver/articles/setup_testing_server.html

>> color code the directories

Nope.

>> lock a project from being uploaded to the remote server

Nope.  But see above on how best to use a Testing Server and below for Check In/Check Out.

>> how about an asterick, or some other mark, next to a file in the local files listing at the lower right of the work area, that indicates
>> that that file has been changed locally and has not yet been synchronized with the remote version of the file?

This is what Check In/Check Out does.  When a file is checked out, the most recent copy from the Remote Server is transferred locally.  You then work on it and use Preview in Browser to get it to the Testing Server for preview and test, but Check In should always work with the Remote Server exclusively.  When a file is checked out, it has a green checkbox next to it and a lock when checked in.
0
 
stevaAuthor Commented:
Or on the last feature, maybe a way to turn on a mode that automatically uploaded the file to the remote server when you did a Save All locally.
0
 
stevaAuthor Commented:
Thanks for responding.

I'm not a big fan of testing servers. I've set up an XAMPP server locally, before,  to run PHP locally, but the local version of the site was never the same as the remote.  For one thing,you have to make your links relative to work both locally and on  the remote (or the link takes you right back out to the remote version of the site), but this is not easy (possible?) to set up when the links a're going through an SSL connection.

The check in/check out option means making the server version the latest, rather than the local version, which makes me uncomfortable and would be a big change from the way I've been working for years, with the local version the latest.

I did find a way to block the remote site from updates: change the directory permissions on the server with Filezilla to 444.  But even this is clunky because just changing the directory permissions won't do it.  You have to check recursive, so that Filezilla then goes through every file in the directory and changes its permissions.  

Oh well.  I thought I wold throw the questions out there in case I missed some corner of the documentation.  I guess not.  Thanks.  I gave you the points.
0
 
Jason C. LevineNo oneCommented:
>> I'm not a big fan of testing servers. I've set up an XAMPP server locally, before,  to run PHP locally

I was actually saying to make your testing site the testing server.  There's nothing that says it has to be a local thing.  

>> but this is not easy (possible?) to set up when the links a're going through an SSL connection.

If you have to use SSL then it gets tricky.  I would use relative links for everything but the switch to SSL and then a little PHP magic to detect which site I was on and return that in the link code instead of a straight static URL.  Probably more trouble than it's worth depending on how many ways you have to switch to SSL. We used to use staging servers and networking/DNS tricks to handle URL issues but now that we are mainly developing with WordPress, local WAMP installations and version control is all we really need.  Hell, it's been weeks since I even opened DW.

>> would be a big change from the way I've been working for years, with the local version the latest.

Yeah but in a multi-developer environment the live copy is always the latest unless you all using the same local repository.  It sounds like that is not the case for you?

>> change the directory permissions on the server with Filezilla to 444

Well, that would work but it's a giant PITA to do and undo.

I've found that the more complicated the dev environment, the less likely DW is to be used.  It works well for the solo web person or a small shop environment but really big and complex setups are hard for it to handle well.
0
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.