Home » Leveraging Drupal: Getting your site done right - Workshop Central

Go directly to workshop page for Leveraging Drupal

Chapter 3 - Getting Organized

Enhancing the initial development environment with a Subversion source and assets repository, plus a Trac instance.

Growing the on-line literary workshop website application prototype with Drupal itself... implementing business objects... deployment from development workstation to test site... getting feedback from the client.

Important Errata p. 81

The entries in the third column of the table (Primary menu) should not be capitalized! They should be "blog", "forum", "book", "node/add/application".


Another Errata p. 111

Thanks also to drupalista Alan Page, who spotted another typo in one of the commands during the discussion of the .cvsignore file on page 111. The command listed to create the file uses the cat command:

$ cat sites/default/settings.php > .cvsignore

Should be the ls command instead:

$ ls sites/default/settings.php > .cvsignore

Bookmark/Search this post with:
tags:

Errata re: .cvsignore on page 111?

Submitted by AlanPage (not verified) on Sat, 2010-01-23 16:11.

Victor,

Firstly, great book! If just for the CVS and Subversion explanations, but also for the encouragement to use the drush module. Those three have helped me tremendously.

I found a typo in one of the commands during your discussion of the .cvsignore file on page 111. The command listed to create the file uses the cat command:

$ cat sites/default/settings.php > .cvsignore

Shouldn't the ls command be used instead:

$ ls sites/default/settings.php > .cvsignore

The first one puts the contents of the settings.php file into the .cvsignore file, but I believe that CVS wants a list of filenames instead.

Thanks again,
Alan

Thanks, Alan, for your encouragement on the book

Submitted by victorkane on Sun, 2010-01-24 06:48.

That's just what I wrote it for! drush has metamorphosed since then, and some of us are using Git instead of good old SVN (or WITH good old SVN), but the idea is, precisely, to get organized.

Thanks for catching the typo. Yes, "cat" certainly is wrong for the reason you state; yes, "ls" will do it, and so will "echo" ("ls" is better because it will give error message if file doesn't exist).

Thanks again for your feedback, I am so happy people are still learning from the book.

Victor

I am working through

Submitted by Anonymous (not verified) on Sun, 2009-06-21 16:58.

I am working through exercises with Drupal 6. Now in Chapter 3, Getting Organized, I am finding that the exercises are not consistent with the interface. Any ideas?

Leveraging Drupal is equally useful for Drupal 5 and Drupal 6

Submitted by victorkane on Mon, 2009-06-22 07:31.

Here's an idea: embrace change!

All the exercises are equally useful, Anonymous, they can be followed perfectly well in Drupal 6 also.

Victor Kane

How about bzr?

Submitted by CrashTest_ (not verified) on Fri, 2009-03-13 01:13.

Is it possible to do this using bzr instead of svn? I guess the real question is whether it is possible to do what trac does, using bzr as the source control?

bzr plugin does exist for Trac

Submitted by victorkane on Sat, 2009-03-14 10:15.

So it is possible!

See https://launchpad.net/trac-bzr

I have been using SVN for years, which is why I use it in the book in real world examples, given my feeling very comfortable with it, and given that it is a main stream version control system.

More recently I have been using the distributed version control system Git.

I realize that many are turning to bzr.

In addition to Trac, the author's own http://projectflowandtracker.com/ (now in pre-alpha) will replace Trac for me (login as user drupal, password rocks to look around) as soon as I implement link-up with version control via the Drupal version control API, and sooner rather than later bzr will be supported.

Thanks so much for sharing your question here!

Victor

Modifications to the local and remote test environment

Submitted by FilmKnurd (not verified) on Sat, 2009-02-07 21:38.

Following Sacha Chua's lead I configured my development and test environment a bit differently.

1. On my VPS
I created the litworkshop user with a public_html directory. However, I also created a test_html directory. In my vhosts conf file I set litworkshop.com and test.litworkshop.com to point to public_html and test_html respectively.

I also created two separate databases: dr_workshop and tst_dr_workshop. This way, test.litworkshop.com serves as a permanent staging area in the same environment as the deployment server.

2. On my local machine
Conveniently, my Mac is configured by default to check the local hosts file before anything else. So, I created the following entries in /etc/hosts
127.0.0.1 local.litworkshop.com
remote_ip test.litworkshop.com
remote_ip litworkshop.com
#127.0.0.1 litworkshop.com

Now I can flip between my local and remote test areas by simply inserting the appropriate subdomain.

Very interesting development environment options

Submitted by victorkane on Sat, 2009-02-07 21:48.

Thanks for sharing!

Victor Kane

great blog

Submitted by andy (not verified) on Wed, 2009-08-05 07:47.

great blog