Let's say I have an existing website and want to convert that site to drupal.
What I have done in the past is something like this :
Where my original site is www.mydomain.com, create www.mydomain.com/new, require authorization and go to work. when done, move files form www.mydomain.com/new to www.mydomain.com, presumably overwritting the original directory.
What would be the 'drupalist' way to do that? URLs to topics on this subject would be perfectly fine. thanks
I generally prefer to set up subdomains rather than subdirectories of my existing domain, but your approach could be made to work, however you will not want to just copy over the top of an already existing site.
The stock drupal .htaccess file will load a file if it exists, which would mean that any old files still left in place would still be found and drupal would not be used.
Also in a new drupal installation you could just turn off the users ability to access content. (Uncheck the "access content" permissions from anonymous users in the permissions tab) rather than messing around with requiring authorization a different way.
I'm sure that there are many different ways that this is done in the drupal community as much depends on your hosting environment. Many of us do that development work on our laptops and then push them to a testing site for external use. I would certainly recommend that approach.
Anyway, welcome to the drupal community. Good luck with the site migration.
Dave
-----Original Message----- From: support-bounces@drupal.org [mailto:support-bounces@drupal.org] On Behalf Of Tim Johnson Sent: Wednesday, November 21, 2012 3:01 PM To: Drupal Support ML Subject: [support] Strategy for converting a site to drupal
Let's say I have an existing website and want to convert that site to drupal.
What I have done in the past is something like this :
Where my original site is www.mydomain.com, create www.mydomain.com/new, require authorization and go to work. when done, move files form www.mydomain.com/new to www.mydomain.com, presumably overwritting the original directory.
What would be the 'drupalist' way to do that? URLs to topics on this subject would be perfectly fine. thanks
* Metzler, David metzlerd@evergreen.edu [121121 15:00]:
I'm sure that there are many different ways that this is done in the drupal community as much depends on your hosting environment. Many of us do that development work on our laptops and then push them to a testing site for external use. I would certainly recommend that approach.
My preferred method is maintain an internal test site - I.E. on my local network workstation and upload changes as they are finalized.
My projects are configured so that each has a utility that maps all dependencies of files composing that project so that when I upload any one file, any dependencies are also uploaded. (sort of a "makefile" for FTP).
Is there a drupal module that would would enable something like that?
To illustrate, let's say I have an internal test site at http://localhost/timslocal and I upload tested changes (with dependencies also) to http://www.tj49.com/timsremote
Anyway, welcome to the drupal community. Good luck with the site migration.
:) Thank you
Some of the language you are using doesn't quite translate to the world of a CMS. You need to start thinking in separate terms of "content" vs. "code". These things are handled very differently and are not staged and deployed in the same way.
It's a bit over-simplistic but generally, code is generally created in dev environments and pushed to staging/production servers after testing.
Content is created in production and pulled back to dev environments to feed testing of code.
Up until the point that you are working with multiple people in a production CMS environment, you can push complete databases from dev to staging/production enviornments.
For this, you want to look at the backup_migrate module at http://drupal.org/project/backup_migrate which can be used to pull down copies of complete drupal databases, or push databse to production.
The "code" is transferred just like old static files to production.
Also, if you're not afraid of SSH and command line tools, drush (the drupal shell) is a must have: http://drupal.org/project/drush .
Dave
-----Original Message----- From: support-bounces@drupal.org [mailto:support-bounces@drupal.org] On Behalf Of Tim Johnson Sent: Wednesday, November 21, 2012 4:11 PM To: 'support@drupal.org' Subject: Re: [support] Strategy for converting a site to drupal
* Metzler, David metzlerd@evergreen.edu [121121 15:00]:
I'm sure that there are many different ways that this is done in the drupal community as much depends on your hosting environment. Many of us do that development work on our laptops and then push them to a testing site for external use. I would certainly recommend that approach.
My preferred method is maintain an internal test site - I.E. on my local network workstation and upload changes as they are finalized.
My projects are configured so that each has a utility that maps all dependencies of files composing that project so that when I upload any one file, any dependencies are also uploaded. (sort of a "makefile" for FTP).
Is there a drupal module that would would enable something like that?
To illustrate, let's say I have an internal test site at http://localhost/timslocal and I upload tested changes (with dependencies also) to http://www.tj49.com/timsremote
Anyway, welcome to the drupal community. Good luck with the site migration.
:) Thank you
* Metzler, David metzlerd@evergreen.edu [121121 15:31]:
Some of the language you are using doesn't quite translate to the world of a CMS. You need to start thinking in separate terms of "content" vs. "code". These things are handled very differently and are not staged and deployed in the same way.
I will strive to understand the distinction. I use an MVC approach which is of my own derivation, since I've been doing web development since 1995. I'm in the position of having to "empty the cup" before we can get the tea in, yes?
It's a bit over-simplistic but generally, code is generally created in dev environments and pushed to staging/production servers after testing.
Content is created in production and pulled back to dev environments to feed testing of code.
Up until the point that you are working with multiple people in a production CMS environment, you can push complete databases from dev to staging/production enviornments.
For this, you want to look at the backup_migrate module at http://drupal.org/project/backup_migrate which can be used to pull down copies of complete drupal databases, or push databse to production.
I installed this module earlier...
The "code" is transferred just like old static files to production.
Also, if you're not afraid of SSH and command line tools, drush (the drupal shell) is a must have: http://drupal.org/project/drush .
Am an 'old' (in more ways than one) unix hand. And I have drush and am studying it. Have Requena's Drush User Guide.
* Metzler, David metzlerd@evergreen.edu [121121 15:31]:
Also, if you're not afraid of SSH and command line tools, drush (the drupal shell) is a must have: http://drupal.org/project/drush .
Yeah, and yay : http://drupal.org/node/670460 for drush rsync ## etc. ...
-
Metzler, David -
Tim Johnson