Book Review: Drupal 7 Multi Sites Configuration 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.
| Drupal 7 Multi Sites Configuration | |
| author | Matt Butcher |
| pages | 100 pages |
| publisher | Packt Publishing |
| rating | 8/10 |
| reviewer | Michael J. Ross |
| ISBN | 978-1849518000 |
| summary | A tutorial on how to run multiple Drupal 7 web sites from a single installation. |
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.
Re: (Score:1)
Re: (Score:1)
Re: (Score:2)
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: (Score:2)
Re: (Score:2)
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: (Score:3)
Yo dawg, we heard you like to write html codes so we wrote some php codes for you to write your html codes.
Re: (Score:2)
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: (Score:2)
Re: (Score:1)
Re: (Score:1)
CTRL-F opcode (Score:5, Informative)
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: (Score:2)
"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: (Score:3)
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: (Score:2)
varnish + expire [drupal.org] on drupal 7 (or pressflow 6) integrates with drupal as well as boost does.
Re: (Score:2)
Boost is overrated. Just put a well configured varnish in front of your site, and you don't need boost.
Re: (Score:2)
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-
Just another review ... (Score:2)
... 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.
Multitenancy (Score:2)
Drupal Logo (Score:1)
Re: (Score:2)
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 (Score:2)
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?!?! (Score:2)
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 t
Drupal 7 == Perl 6? (Score:3)
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: (Score:1)
Drupal 7 is already more popular than Drupal 6, your personal opinion notwithstanding. http://drupal.org/project/usage/drupal
Re: (Score:2)
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: (Score:1)
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: (Score:2)
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 ina
Drupal interest waning on slashdot (Score:1)
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 lo