How to organize the process of editing sites on Wordpress?

Question

Denver

I'm trying to make the process of editing a site (in this case on wordpress) convenient for myself and painless for site users (so that users do not stumble upon intermediate options with a broken design).
I use: OS Win7, Denwer, Sublime Text 3 + sftp hosting access. I'm trying to switch to sass and then to grunt.
Option 1:
Edit files and database on hosting.
+ Convenient;
- Users see all the changes that happen to the site.
- There is no possibility to use sass, compass, grunt and others.
Option 2:
Create a copy of the site and the database on a local computer, and after editing, unload the database and upload it to the hosting along with the rest of the files.
+ Users do not see intermediate jambs;
- If you use the same domain name, then part of the data is loaded from the hosting (and disconnecting from the Internet during editing is somehow not ice ..
- If you change the domain name, then the question arises with the paths to the files - use only relative ones;
- No access to the site to other users (sometimes you need to coordinate something with the designer, customer, ..)
Option 3
Create a sub-domain name of the site (for example, temp.sitename.ru) and already play with it
+ The working conditions of the temporary site are as close as possible to the conditions of the original site;
+ There is access for other users;
+ Users of the main site do not see the editing process;
- Fuss with the import / export of the database;
- Lack of ability to use sass, compass, grunt and others.
Actually I wanted to ask - how is it more correct and how do you do it?

Answer 1

Kind of a stupid question.
Local server -> test/demo hosting -> "combat" hosting. Of course, you need to deploy all this using the version control system, and not drag folders in the FTP client with the mouse.

Answer 2

It is best of course to forget about Windows and Denwer. Use sass, compass, grunt, and others on a local machine (or better in a virtual machine), creating a copy of the site and database on it, and using only relative file paths.
Learn how to use git with private repositories on BitBucket. 1): you will always have a backup, 2): the ability to roll back to any stage, 3): easy access to the code from any computer. 4) After some fiddling with the settings, an easy deployment in one command, without the pain of FTP. All the fuss with the import / export of the database is the normal configuration of scripts for this business. Then you forget about it. The need to use absolute file names is not very clear to me.
Using git hooks, automatically deploy a test branch to test.sitename.ru to check normal operation on a server, and deploy a branch with clean, working and tested code ready for release to sitename.ru.

Answer 3

1. Edits on the sale (hosting) - this is only a diploma, or a solution to emergency problems of the level "the main page does not work" and above. Other edits are usually a sign of shit))
2. VCS - required, for example git. In case your site is hacked, you will be able to quickly understand which files have been touched, otherwise not.
3. Do development on an environment as close as possible to the production, if there are Win7 and Denwer OS - use them, otherwise DO NOT use. A completely normal solution is development under vagrant. You can look at raising the environment here .
4. Be sure to use migrations for database changes.

Answer 4

I see no problem using sass / compass / etc on the dev server (development subdomain). It all compiles to pure html\css anyway.
In general, any self-respecting company has a production server, a development server, and a repository where all changes made by developers on the local machine are merged.