Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Book Review: Drupal 7 Multi Sites Configuration

samzenpus posted more than 2 years ago | from the read-all-about-it dept.

Book Reviews 35

Michael Ross writes "All the leading content management systems (CMSs), including Drupal, use a combination of source code, in files, and user/configuration data, in a database. There may be some mixing of the two types of components — such as configuration settings stored in small files, or JavaScript code stored in the database — but most CMS-based websites generally employ this separation. One significant benefit is that updates to the non-custom code (the CMS's "core") can be easily made without overwriting user data or custom configuration settings. However, each website has its own copy of the core code, even if the websites reside on the same server — which wastes disk space and wastes developer time when all of those instances of core need to be updated. Thus there is growing interest in running multiple websites on a single core instance, despite the dearth of documentation for how to do so. For those in the Drupal world, one resource is a new book by Matt Butcher, Drupal 7 Multi Sites Configuration." Read below for the rest of Michael's review.Released on 26 March 2012 by Packt Publishing under the ISBN 978-1849518000, the book spans 100 pages, organized into five chapters. For developers familiar with the subject — particularly those who have read the (few) articles that cover Drupal multisite — it may seem inconceivable that such a subject could fill an entire book. Yet for the countless Drupal developers and administrators who have encountered critical problems in implementing the advice proffered in the aforesaid articles, a definitive book could be invaluable. Even a brief perusal of the book's table of contents will show that there are more topics to be covered than one might have imagined. This review is based upon a print copy of the book kindly provided by the publisher. An electronic edition is available as well. More details can be found on the publisher's page, where visitors will find an overview, a table of contents, a brief author biography, and links for purchasing the print and electronic versions of the book.

In the first chapter, the author presents the fundamental ideas and many benefits of basing multiple Drupal websites on a single code base, known as "multi-site hosting." He discusses the most common configuration options, and then focuses on the one used throughout the book, namely, Drupal's built-in multi-site capability. One thinks of Drupal (and any other PHP applications) as running on top of the web server layer (typically Apache); so readers will likely be confused by the statement that virtual hosting "is a layer higher than Drupal's multi-site feature" (page 8). Aside from that, the discussion is straightforward.

The second half of the chapter provides detailed instructions on two methods for setting up a server for multi-site usage. The first method utilizes virtualization, specifically VirtualBox and Vagrant, which supposedly are ideal for spinning up disposable websites. However, the instructions for "Installing our tailored Vagrant project" quickly become problematic: The MultiSite Drupal Vagrant Profile directs the user to perform a git clone command, and then "cd multisite_drupal_vagrant_profile," which works fine, as that directory exists. But the next step, on page 15 of the book, calls for the reader to cd into "multisite_vagrant," which does not exist. Was the aforesaid directory intended? Apparently so, as otherwise the third command, "vagrant up," fails. Windows users, at the very least, may find these steps and those that follow to be quite perplexing. In my case, both VirtualBox and Vagrant initially appeared to fail installation; yet upon trying them again, they were apparently running. But certain operations discussed in the book, were never executed. I slogged my way through numerous cryptic error messages, and eventually gave up. Any other reader who experiences anything similar may also chuckle at the author's claim that "This made it easy to get an entire server environment configured and running without dealing with the nuances of configuration" (page 17). The second method presented for setting up a multi-site environment is to manually configure Apache and MySQL. Even though this approach is probably what most readers will settle upon, it is sadly given a backseat to Vagrant.

In the second chapter, "Installing Drupal for Multi-site," the author explains how to perform the standard Drupal 7 installation, but for three example instances. For those readers unable to get the Vagrant method working fully, or who for some other reason choose not to use it, the author's frequent references to Vagrant will likely be increasingly annoying. Fortunately, it tapers off about halfway through the chapter, as the author explicates the details of multi-site configuration, concluding with some tips on where the reader can find assistance if she encounters any difficulties during an install. The only flaw is, on page 41, where the author states that "the lines that typically need changing are highlighted," but none of them are.

The complexities of sharing configuration settings among multiple websites, compose the first topic addressed in the third chapter. All of the technical information appears to be sound, except for the advice on page 46 to add the line "global $conf;" in the shared settings PHP file, which is included in the site-specific settings files. A "global" keyword would only be needed if the line setting the array value $conf['site_slogan'] were inside a function, in which case the variable $conf would have only local scope without the keyword. The PHP documentation on variable scope notes that, for a (non-global) variable, its "scope spans included and required files as well." (I confirmed this with a quick test, in which a shared settings file changed the slogans of two different websites.) The author then explains how to share modules and themes among multiple websites, or keep them separate. The chapter concludes with information on how subthemes in separate Drupal 7 instances can use a single base theme.

The fourth chapter, "Updating Multi-site Drupal," focuses on the administration of multiple websites sharing Drupal code. Readers will learn of the numerous pitfalls that can catch the unwary (or at least the inexact). The fifth and final chapter, "Advanced Multi-sites," continues the discussion of other factors that can complicate and undermine working off a single Drupal code base: favicons in themes, robots.txt files, shared authentication, shared content, and other topics that one may never encounter if only working with simple websites — but could be critical otherwise. The only readily apparent flaw is his referring to the project at http://drupal.org/project/virtual_site as "the Virtual Site module" (page 80), when in fact it is the Virtual Sites module — not be confused with the actual Virtual Site module.

Unlike most Packt Publishing books, this one contains relatively few errata: "served [a] few" (on the first "About the Reviewers" page), "start its" (page 17; should read "start it"), "Drupal looks for, for site configuration" (page 30), "trouble shooting" (42), and a missing ")" in the first sentence on page 67. Scattered throughout the book are several instances of title case used inappropriately when referring to generic concepts that are not proper names, e.g., "Version Control System" (page 10). Fortunately, all of these flaws are quite minor, and should have been caught by the publisher's production team.

Some of the narrative is a bit redundant, such as a question being asked at the end of one section, only to be repeated at the beginning of the next section, sometimes more than once. The (unneeded) chapter summaries add to the repetition, as do the introductory paragraphs of each chapter, many of which merely tell the reader what she just read in the previous chapter. Yet the author's narrative style is generally clear and easy to understand.

The main problem with this book is the VirtualBox and Vagrant pair — specifically, the (unjustified) heavy emphasis upon them, and the spotty instructions for configuring them, which could easily confuse and discourage readers. The information is mostly confined to the first two chapters, yet all of it should have been left out, or consolidated and relegated to an appendix — especially as most readers would not use Vagrant for their development environments, and probably no one would use it for a live production environment.

But for anyone interested in setting up multiple Drupal-based websites that share a single code base, these blemishes are of little consequence. Although modest in size, Drupal 7 Multi Sites Configuration provides the most thorough coverage to date of this worthwhile yet oft-neglected subject.

Michael J. Ross is a freelance web developer and writer.

You can purchase Drupal 7 Multi Sites Configuration from amazon.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

cancel ×

35 comments

Sorry! There are no comments related to the filter you selected.

And these instructions can't be found on the web? (1)

bobmorning (316459) | more than 2 years ago | (#40666711)

I'll find at least 3 links that have the same info and post them as a follow up. Need to get the first post, first time ever after 11 years!

Re:And these instructions can't be found on the we (0)

Anonymous Coward | more than 2 years ago | (#40667099)

Most of this info is just a comment in the settings.php file and sites.php files.

The only useful info is the multisite *configuration* info. Since all the sites run on separate databases, you need to go around to each website & configure modules, change the same settings over & over again, etc.

It's supposedly possible with get/set in drush - but good luck figuring out which variables to copy. And god forbid you fuck them up.

Re:And these instructions can't be found on the we (1)

Rhaban (987410) | more than 2 years ago | (#40673313)

Since all the sites run on separate databases, you need to go around to each website & configure modules, change the same settings over & over again, etc.

That's what features [drupal.org] is for

Re:And these instructions can't be found on the we (1)

hazah (807503) | more than 2 years ago | (#40687633)

Not to mention that they don't have to use different databases to begin with, as was asserted.

Drupal (-1)

Anonymous Coward | more than 2 years ago | (#40666715)

the thing I dont get about drupal is why is it necessary when websites are just html codes because i dont need any cms to write html codes and so i think its just a scam to try to get people to pay good money for things when they could just write their own html codes

Re:Drupal (1)

hawguy (1600213) | more than 2 years ago | (#40666843)

the thing I dont get about drupal is why is it necessary when websites are just html codes because i dont need any cms to write html codes and so i think its just a scam to try to get people to pay good money for things when they could just write their own html codes

If you think that's bad, wait until you find out how much money Microsoft makes from Excel, when a spreadsheet is really no different than a paper tabular worksheet. Anything you can do with spreadsheet software can easily be duplicated on paper (sometimes with a little cutting and pasting with scissors and glue).

I can't wait until this whole digital sham blows over and we can stop trying to force everything into some lame digital form.

Re:Drupal (0)

Anonymous Coward | more than 2 years ago | (#40666919)

Yeah if you pay good money for drupal it really is a scam !

Re:Drupal (2)

Tarlus (1000874) | more than 2 years ago | (#40667411)

Yo dawg, we heard you like to write html codes so we wrote some php codes for you to write your html codes.

Re:Drupal (1)

Algae_94 (2017070) | more than 2 years ago | (#40667879)

Drupal is without cost, so I fail to see how it is a scam to get people to pay money.

The intention of a CMS is not so developers who can write HTML code don't have to write them. It's for non technical writers, artists, etc., so that they can create nice content oriented web sites without learning HTML.

Re:Drupal (0)

Anonymous Coward | more than 2 years ago | (#40668455)

C'mon lighten up and give that guy a +1 funny. "HTML codes"...I smell a meme cooking...

Bring back Packt! (0)

Anonymous Coward | more than 2 years ago | (#40666741)

Wow it's been a while since Michael J Ross shilled for a Packt book about Drupal. And they still get at least 8/10 scores still, too, despite numerous flaws.

Re:Bring back Packt! (1)

hackula (2596247) | more than 2 years ago | (#40672537)

Every book reviewed on /. gets 8/10.

Re:Bring back Packt! (1)

rubikscubejunkie (2664793) | more than 2 years ago | (#40703747)

is the policy to only review good books? or u can ask...why waste time to review a bad book?

Re:Bring back Packt! (1)

rubikscubejunkie (2664793) | more than 2 years ago | (#40703707)

sorry, can u let me know what a packt book is?

CTRL-F opcode (5, Informative)

Anonymous Coward | more than 2 years ago | (#40666933)

If the book is anything like the description, it entirely misses the point of a multisite configuration.

I can use drush and with one command update multiple sites at the same time. I regularly update 20 sites with just "drush @all up" and it takes about 2 minutes. This would work multisite or not. Hell they wouldn't even need to be on the same server. If you're updating your site without drush, you're probably doing it wrong.

Since I can rule out updating the site as a motivation, what *is* the motivation?

Simply, efficiency for the opcode cache. You can *easily* feed APC (or xcache etc.) enough memory to completely cache all PHP on all the sites in a multisite. I'm doing so with 20 sites right now. If those 20 sites were not in a multisite config, each site would have its own copies of the same file, which is horribly wasteful when you're allocating ~64MB per site. When people make the mistake of thinking "oh, I have the php cache thingy", the biggest problem is that the default memory allocated to APC is 16MB, and for Xcache its also 16MB. This means that once the opcode cache runs out of memory, every file not currently stuffed into the insufficient space available is going to compile every time its used.

Maybe they avoided mentioning Drush and the Opcode cache, assuming that readers would not understand what they were. Sadly, if you don't know what an opcode cache is and how to appropriately tune it, you are probably not the target audience for a book that focuses on Vagrant and VirtualBox.

For anonymous sites, Nginx + php-fpm + APC + Memcache + Boost is an incredibly efficient way of setting up sites. Combine that with a multisite and you can host many sites on a budget VPS (I'm using Linode) and still get great pageload times because its all coming from cache, and if it needs to regenerate the cache it has plenty of power available with idle php-fpm workers + APC.

For this reason, I find the focus on apache to be a bit sad. If the book does a "sudo tasksel" lamp stack install and uses mod_php, thats complete fail because of all of the additional overhead in the apache processes that are going to spend most of their time serving statically cached pages.

Re:CTRL-F opcode (1)

SpzToid (869795) | more than 2 years ago | (#40667007)

"drush @all up"

Awesome. Thanks! I've been doing 'drush up' for each site 'cuz I never figured this out. Still, even doing 'drush up' for each site is miles ahead of anything else AFAIK.

Re:CTRL-F opcode (2)

cultiv8 (1660093) | more than 2 years ago | (#40668687)

For anonymous sites, Nginx + php-fpm + APC + Memcache + Boost is an incredibly efficient way of setting up sites. Combine that with a multisite and you can host many sites on a budget VPS (I'm using Linode) and still get great pageload times because its all coming from cache, and if it needs to regenerate the cache it has plenty of power available with idle php-fpm workers + APC.

memcache is a memory object caching daemon, mainly aiming to lower *database* load. it does so by caching the result of repeating queries in memory. If you're running an anonymous site on Drupal (ie. no user login) AND using boost, memcache is not necessary because you're not making (or shouldn't be making) any database queries. Boost caches it all.

I recommend using Varnish [wikipedia.org] over Boost.

Re:CTRL-F opcode (0)

Anonymous Coward | more than 2 years ago | (#40673161)

Honestly replying to that post you think the person making it doesn't understand what memcache is?

I run memcache because it + APC makes sites more pleasant to work on when I actually do need to log into them and add content etc. Even if 99% of the traffic is anonymous, that doesn't mean I won't see any benefit from memcache, and its not like it eats a lot of memory. If someone touches several pages in a row that are not yet cached, memcache still applies as well. Granted, it would be the first thing to go if I had a memory issue.

Benchmarks for Varnish vs Boost havent convinced me that for my use case I'd want Varnish. Boost integrates with Drupal and is capable of clearing caches and dealing with Drupal in ways that Varnish can't as far as I'm aware.

Re:CTRL-F opcode (1)

Rhaban (987410) | more than 2 years ago | (#40673407)

varnish + expire [drupal.org] on drupal 7 (or pressflow 6) integrates with drupal as well as boost does.

Re:CTRL-F opcode (1)

Rhaban (987410) | more than 2 years ago | (#40673345)

Boost is overrated. Just put a well configured varnish in front of your site, and you don't need boost.

Re:CTRL-F opcode (1)

Compaqt (1758360) | more than 2 years ago | (#40673791)

Good to see fpm working for you. I've been running into the "incomplete headers" problem, which also aborts Drupal installs. Had to revert to bog-standard prefork mod_php. Any hints?

Install:
    59 sudo aptitude install mysql mysql-server
      60 sudo aptitude install apache2-mpm-worker
      63 sudo ufw allow http/tcp
      64 sudo ufw allow https/tcp
      65 sudo ufw status
      66 apt-get install libapache2-mod-fastcgi php5-fpm php5
      67 sudo aptitude install libapache2-mod-fastcgi php5-fpm php5
      68 sudo a2enmod actions fastcgi alias

Error log:
[Mon Jul 09 00:12:17 2012] [error] [client 10.0.0.4] FastCGI: comm with server "/usr/lib/cgi-bin/php5-fcgi" aborted: idle timeout (30 sec), referer: http://10.0.0.6/d7b/install.php?profile=standard&locale=en [10.0.0.6]
[Mon Jul 09 00:12:17 2012] [error] [client 10.0.0.4] FastCGI: incomplete headers (0 bytes) received from server "/usr/lib/cgi-bin/php5-fcgi", referer: http://10.0.0.6/d7b/install.php?profile=standard&locale=en [10.0.0.6]

Just another review ... (2)

Anonymous Coward | more than 2 years ago | (#40666959)

... from this Michael Ross guy, who apparently has read all the Drupal books out there, by now.

Sorry, but I can't take those submissions seriously anymore; it kind of looks like some sort of astroturfing to me.

Re:Just another review ... (0)

Anonymous Coward | more than 2 years ago | (#40668721)

lol 17 Drupal books [slashdot.org] and counting.

Multitenancy (2)

pettos21 (2685641) | more than 2 years ago | (#40667011)

This is called multitenancy, and is supported by all CMS I know of. http://en.wikipedia.org/wiki/Multitenancy [wikipedia.org] Also supported by most webcommerse platforms of any worth.

Drupal Logo (1)

Evelas (1531407) | more than 2 years ago | (#40667133)

The Drupal logo is made of the tears of those forced to develop sites with it.

Re:Drupal Logo (1)

Tarlus (1000874) | more than 2 years ago | (#40667439)

Yeah, Drupal became such a buzzword with employers that I forced myself sit down and develop a couple of sites with it.

It hurts me inside.

Drupal experience (1)

manu0601 (2221348) | more than 2 years ago | (#40668901)

My experience with Drupal is that it is fast and easy to setup a web 2.0 site with all the community stuff. However things are getting much more troublesome when one want to customize things. And once you have it done, you fear to upgrade to new versions because it may break everything. Your mileage may vary, and perhaps I did not have a look to the right documentation, but this is how it went for me.

I am now a happy SPIP [spip.net] user.

Easily found information?!?! (1)

theNAM666 (179776) | more than 2 years ago | (#40667185)

Okay, buccccckwheat...

All of this info is fairly easily found on the web. Sure, a lot of Drupal documentation is spread here and there in forums, but this is a basic feature of Drupal and there are handbook pages.

Regardless, I used to find myself answering basic multisite questions on IRC every few days (usually from people who barely understood Apache), so maybe there's some point to this. At least, I'll be able to refer people to a book :P

Otherwise, as someonbe else has said, I'm not sure what the point of such a book is. Or perhaps I need to write a book on basic mouse manipulation: lowest common denominator == best market ?

Drupal 7 == Perl 6? (2)

Maow (620678) | more than 2 years ago | (#40667983)

I find Drupal is nice to set up for basic functionality provided by plugins, and I like the forms development, but frankly *hate* digging in further than that.

Maybe I should've made more use of a debugger to understand the code I was trying to modify, but I've sworn off Drupal.

I guess what I came here to say was, Drupal 7?!? NEVER. Too many modules require too much updating to be compatible. Drupal 7 will have the uptake of Perl 6, IMHO. And now there on to Drupal 8, I cannot fathom it.

Re:Drupal 7 == Perl 6? (1)

Anonymous Coward | more than 2 years ago | (#40669403)

Drupal 7 is already more popular than Drupal 6, your personal opinion notwithstanding. http://drupal.org/project/usage/drupal

Re:Drupal 7 == Perl 6? (1)

Maow (620678) | more than 2 years ago | (#40669891)

Drupal 7 is already more popular than Drupal 6, your personal opinion notwithstanding. http://drupal.org/project/usage/drupal [drupal.org]

Well, so it is.

Personally, I mostly rely on Photo Album, which is now abandoned, so cannot upgrade my multi-site installation. I've considered moving to ZenPhoto instead but frankly can't be bothered.

Most of my sites also rely on Misery, which may finally move to D7.

Finally, "And now they're on to Drupal 8".

Re:Drupal 7 == Perl 6? (1)

ameen.ross (2498000) | more than 2 years ago | (#40670699)

If you're not making your photo gallery with Views, you're doing it wrong. And it's been done with Views for a long time [lullabot.com] . And Misery? You can't seriously be using a module that has only 123 users (at time of posting) and complain about lack of support!

Finally, Drupal 8 isn't there yet at all, and may be released in August next year [buytaert.net] .

Re:Drupal 7 == Perl 6? (1)

Maow (620678) | more than 2 years ago | (#40670997)

If you're not making your photo gallery with Views, you're doing it wrong. And it's been done with Views for a long time [lullabot.com] .

That looks interesting but incomplete: galleries? access control? only displays single column? Also, it's written for D4, so likely in need of revision.

Create an image gallery using CCK and Views [drupal.org] is more promising.

However, I have no interest in converting a couple dozen photo albums to some other format, hence I'm stuck at D6, and may well move to ZenPhoto if I must migrate. The photo site hasn't had new albums created in at least a year, and probably no photos added since last summer; it's gone mostly inactive.

And Misery? You can't seriously be using a module that has only 123 users (at time of posting) and complain about lack of support!

Note that I wasn't complaining. I also probably shouldn't have used "rely" -- they were hobby projects that, once found by spammers, became honey pots -- I make them suffer Misery so they don't spam everyone else.

Finally, Drupal 8 isn't there yet at all, and may be released in August next year [buytaert.net] .

I'm curious if there will be any API changes between D7 & D8?

Drupal interest waning on slashdot (1)

stridebird (594984) | more than 2 years ago | (#40671645)

I am a developer who has already gone too deep into D6 and D7 and ended up walking away from the thing. I am happy, when asked why, to just say I don't get it. Privately, I actually think it's totally fucked as a project. Its only tenuous merit is as a platform to allow non-techs to build a site. Which they do, and then hang themselves from the sheer amount of string it produces. I am kind of waiting for its demise now, although I frankly don't care much as it is already apparent that it will have little long-term bearing on web development and practices. So I note with some schadenfreude that this piece is getting almost totally ignored on slashdot.

A sign, perhaps, that we are at the end of the era of slashdot Drupal Book reviews. TF for that anyway.

Check for New Comments
Slashdot Login

Need an Account?

Forgot your password?

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>