I understand that I can copy all files from localhost to my URL.
What I would like to understand is when I change configuration what files change.
Can I just transfer the specific directories like the obvious sites/all and wherever
my configuration changes are stored?
Which actually makes this a 2 part question. With the database at the URL, I
suspect data will be modified while I modify and test on localhost. If configuration is kept in the database are there just a few specific tables that need to be updated?
The beginner books don't seem to explain what happens. They also don't mention the possibility of getting the databases out of sync.
Specifically, does the sqldump or export just append modified data and can a subset of all the files be uploaded? Thanks for any clarification of these newbie issues.
By Bill Hatch on
Comments
Clarifications
I am sorry, but your question(s) is somewhat confusingly worded.
To Clarify
1) I assume you developed your site on a localhost and now wish to deploy to a specific URL?
2) What file URL's are you referring to?
Some partial answers based on my best guess of what you are looking for:
1) Drupal configurations are stored in the database, this makes deployment to a new URL relatively painless.
2) Drupal tends to use relative paths, so deploying to a new URL will only require you to modify your settings.php file in two places
i) database settings - You must specify where the database will now be found (since it was likely hosted by localhost before)
ii) base_url - often optional, but this may need to be changed depending on your dev environment prior to deploying to a new URL
2b) NOTE - if you linked file resources (e.g. images, pdfs etc) using absolute links in your node content this may cause problems prior to deployment.
Sorry For the Confusion
I have Drupal 7 on my shared web host. I then copied the drupal7 directory to my localhost and made my changes.
However I don't want to continually ftp the thousand or so files of the entire drupal7 directory back to my shared web host. I know I have changes in the drupal7/sites/.... Did my changes potentially change any other directories? This may not be the right terminology but do I need to copy back the core directories such as the d7/includes, d7/modules, d7/profiles, etc. (d7 = drupal7 for abbreviation) or is d7/sites/... good enough?
Both localhost and and shared web host have the same database and original drupal7 files so that is not the issue. The database issue is whether a sqldump will just overwrite the tables potentially loosing any data entered at the web host during the time developing at local host. Obviously just copying localhost tables back to the web host will not include the new data entered at the web host while I was developing. Can I just update the settings table whatever that might be instead of a sqldump? We are dealing with the same database structure but could a sqldump of the localhost database be out of sync or worse overwrite the production data at the web host?
I would prefer to ftp only what has changed on localhost instead of hundreds of files that never changed.
I also want to make sure data between test and production does not get out of sync or corrupted. That might be a question for a MySQL forum instead of this forum.
Thanks for your reply it helps. I hope this is a clearer explanation of my actual concern. I appreciate your reminder about the settings.php and base_url so I don't forget and accidentally set those to localhost.
Files vs database
The only filesystem changes made by a Drupal site are (typically) in the sites/default/files directory -- uploaded images, et cetera. If you are changing a single file on a test site, such as a template, that's all you need to FTP to your production site.
Other than images, Drupal stores all content and configuration in the database.
If your live site is changed after you take a database snapshot for your test server, then replacing the live site's database with the test image will destroy anything that's happened on the live site in the interim. Merging two sites is not a trivial exercise.
Some Drupal modules, such as Views and Panels, make it possible to export configuration/content changes and move them to a live site. Often this is just a matter of clicking an "export" tab, copying the results to your clipboard, then doing "import" and paste on the live site.
More clarifications
You have very ambiguous statements, such as
"I know I have changes in the drupal7/sites/.... Did my changes potentially change any other directories? "
What changes did you make? For example, if you are developing a module on your localhost, then you will have to transfer the updated files to your site on shared hosting (I will call this the "production" site). Perhaps you only installed some contrib modules on your localhost through the D7 interface (this is new to D7) and now want them on your production site? In this case the new files will be located in sites/all/modules and there will be new settings in your database that depend on the module setting defaults and any additional setting changes you have made. Transferring these changes to your production site (en bulk) will not be straight forward.
If you are looking how to recreate functionality, e.g., I uploaded modules x, y, and z and configured them as a, b and c and you want on your production site. You may want to look at the features project. Otherwise you will need to recreate these changes on your production site in a stepwise manner or do a complete swap between your localhost and your production site (files and database)
Scenario 2 - if you are adding content to your localhost then wish for the same content to appear on your production site then things are again complicated, especially if your content has additional files associated with it. If we assume you just have new content, without uploaded files, then even swapping database tables from your localhost to your production site may be problematic and cause errors. I suggest only updating content on your production site. There are projects however that can help in transferring content, such as the node export and node import. You can keep content as unpublished (and unviewable) until you are ready to flip the switch
In regards to importing a database dump, overwriting the table depends if your dump has the 'drop table' command before a specific table definition. If so then yes it will replace the contents.
Finally, if after the above explanation you intend to simply 'sync' files between a localhost and production site, you should really consider version control, for example CVS, Subversion or Git. This would allow you for example to commit changes to files from your localhost to a repository, then update your production site by pulling these changes from the repository. It will take a bit to set up, but will be worth it. If you were unaware, the Drupal community has now moved from CVS to git. I personally use subversion, but that is simply preference.
Also if you are using a *nx operating system (e.g. linux, mac os x) then the rsync command is much more efficient at keeping files in a localhost and production environment in sync as it will only move changed files. This is another option in addition to the repository suggestion above.
Great Responses
Thanks. My questions have been answered. It looks like some study is needed. Version Control sounds like something that would be useful to figure out. It is helpful to know about over-writing the database. Data is not critical during initial development but once useful data is collected it would be extremely important to protect.