Drupal-powered websites can be put into an "offline mode." This is much better than most alternatives (such as taking the web server offline), especially for search engines, as the message and HTTP status codes given to users and robots alike will tell them to patiently come back later.
I've found that putting the site into offline mode makes database backups go much faster on heavily trafficked sites (which is obvious). However, for a particular site I was working with, this needed to be done in an automated manner, and on a dedicated database server that did not have access to the Drupal installation.
Most people take their Drupal sites offline through Drupal's web-based administration interface. They can also be put offline through the Drupal Shell. Neither were suitable for me: the former cannot be automated easily, and the latter requires access to the Drupal installation. Fortunately, Drupal sites can easily be taken offline by setting things in the database, which can easily be done via bash scripts and the command-line MySQL client.
Given your database user is my_db_user, password my_password, and database my_drupal_db, the backup script would look something similar to:
#!/bin/bash
# Take site offline
mysql --user my_db_user --password=my_password my_drupal_db << EOF
UPDATE variable SET value='s:1:"1";' WHERE name = 'site_offline';
DELETE FROM cache WHERE CID = 'variables';
EOF
# Do stuff here while the site is offline (e.g. backup)
# Bring site online
mysql --user my_db_user --password=my_password my_drupal_db << EOF
UPDATE variable SET value='s:1:"0";' WHERE name = 'site_offline';
DELETE FROM cache WHERE CID = 'variables';
EOFUpdate: The original version of this article had some problems on some setups with the variables table being cached. I added another SQL statement to make sure this cache is flushed so the site actually reflects its configuration.
Update: This method really doesn't work that well, and the more I think about it, there isn't a way to get around writing something that interacts with Drupal. I'm working on a script that will be more fool-proof.
After over 2 years, I've finally upgraded this website from Drupal 4.7 to 6.5. It's something I've been meaning to do for a long while. Hopefully, with the new Drupal version management scheme I've developed for Rhombic Networks (article coming soon), along with the advancements in update management within Drupal itself, it will be much easier to keep current with updates.
Like I discussed my last upgrade to Drupal 4.7, there are several new features I'm excited about:
Hopefully, I can get my development mojo going and finish porting my Drupal Sands and Sands_CSS themes to Drupal 5.x and 6.x. I'm sorry I took so long!
Recently, I've received a few error 404s on a request for "siteinfo.xml." siteinfo.xml is a file used by Amazon's A9 search engine's browser toolbar SiteInfo, and is automatically fetched for every website a user visits.
This sounds pretty similar to Microsoft's Internet Explorer's infamous favorites icons feature. For every site a user visited with Internet Explorer, the browser would automatically request a file called favicon.ico, to be displayed in the browser's location bar and bookmarks. A lot of people were not happy--all of the sudden web servers would begin to get swamped for requests for this mysterious favicon.ico that did not exist. These requests polluted many web server logs, and were very annoying.
On some sites, especially dynamic ones, 404 errors are very expensive. Unfortunately this is true of most Drupal-powered sites, including mine. When using Drupal's "pretty URLs" which uses Apache's mod_rewrite to, well, make URLs pretty, all requests that the web server does not process (including errors) will go through Drupal. Going through Drupal means a long boot-strapping process to initialize Drupal and load all its modules, and at least one database request to find out a URL does not exist and to return an error 404. Too many requests for a non-existent file can basically become a DoS attack.
It seems Amazon's A9 developers didn't get the memo people don't like tools that request files that don't exist.
Granted, it's not too bad: I don't think this toolbar has much market penetration, so it's not as if millions of people are killing my site. The siteinfo.xml specification page also mentions that the file is fetched through A9 and cached, so the file will not be requested for every user that visits, but only for the first one.
Kudos for Amazon's programmers being a bit brighter than Microsoft's, but eh, I can't say how much more bright for designing a system that is a bit too similar to the favicon.ico debacle.
Over at the Plone Blog is the article Death and Taxonomies; it reviews Drupal's taxonomy (aka category) system.
The author basically comes to the conclusion I have, a conclusion that is shared by many in the Drupal community but not so much outside of it: Drupal's taxonomy system is amazing.
For most people and their uses, it is completely overengineered and complicated to use. This fits into Drupal's marketing stance that it is a content management framework rather than just a CMS. It is very generic, and with some custom programming can be adapted to anything--the possibilities are limitless. With many web development projects (that I don't want to write in PHP) I think about, I wish I had the facility of Drupal's taxonomy system.
Of course, there are problems, which the review goes into: there are too many hierarchal relationships in Drupal, all competing with each other. There is the menu system, the book module, and hierarchal taxonomies. The key to being a Drupal master is know when to use which and how to use them, something I've definitely not mastered. And that is part of the problem--why should you need to?
I've outlined some of the design decisions I made when designing Sands, including why some links are black, the use of a em-relative layout, and why I think they are more usable, in a post on Drupal's forums: Any theme with high usability?
I'm in the process of upgrading this site to Drupal 4.7. Expect a lot to be broken, especially links. Please let me know if you find any problems!
Some changes:
I previously had the "Topics" taxonomy as a hierarchal tree, for example, CentOS would be under Linux. It looked like a good idea before I started to use it, but Drupal and hierarchies don't work as well as I'd like... I converted it to a flat list, and then turned it into a Drupal 4.7 free-tagging taxonomy. Hopefully this will lead to better tagging of my posts.
I don't need to do this, but I want to. It looks nicer, it makes pages easier to save, and it facilitates moving to another CMS if the need ever arises. For many URLs I've used permanent redirects to prevent old links from breaking.
Sands is an attempt to create an all-purpose, drop-in replacement, "generic" theme like Bluemarine. It has design attributes taken from Drupal.org's proprietary Bluebeach theme and friendselectric.
Some features:
In April 2006, I forked Sands into two different themes: Sands and Sands_CSS:
Warning: screenshots are old and have not been updated.
Below are some screenshots of various pages with what they looked like dressed in the Sands theme. Of course, you can see for yourself what they look like by downloading the theme and trying it out yourself!
Screenshots were taken with Mozilla Firefox 1.0.x on Debian Linux, dressed with a modified GTK Clearlooks theme.
Sands is developed and kept in the Drupal contributions CVS repository. It has a project page on Drupal.org where you can download the theme and submit bug reports.
If you're impatient, here are direct-download links to Drupal.org:
All the modern generation ones, including Firefox 1.0, Internet Explorer 6, Safari/Konqueror, and Opera 8. There may be some issues with browsers older than that.
To see any known rendering issues please see Drupal's issue tracker for Sands. If you've a new one, please contact me or preferably, create a new issue at the aforementioned issue tracker.
I'm blind: I use a high contrast theme for my UI windows/widgets that is dark grey/black, so the form controls look the same. On a "normal" machine with a white-ish color scheme (i.e. the defaults) they'll be white, just like you'd expect. Sands doesn't make any attempts to change colors on form controls (and I don't think it should).
Theme-wise, I drew design features I liked from:
The colors of the columns are in both colors.css and columns.css, not just only colors.css, as one would initially think.
Setting the colors of the columns depends on the way the columns are contructed, so their colors are placed in columns.css to allow sharing of the other Sands and Sands_CSS stylesheets.
It is based off of Ruthsarian's skidoo_too layout.
This is due to some extremely odd bug triggered when a page contains the <base href="..."> tag, as Drupal 4.6 does. I gave up trying to find a way around it a long time ago.
If you want to get around it, upgrade to Drupal 4.7, which no longer uses the <base href="..."> tag, or use the Sands (not Sands_CSS) theme, which uses tables for layout.
Internet Explorer 6 does not intuitively work with transparent PNGs, which is why you see grey borders on these images. There are many scripts that will fix this problem, but they do not work with the way Sands has transparent PNGs for both <img> tags and as CSS "background-image"s. I've not had time to look into this, but patches are accepted!
Yes, you may. You are under no obligation to keep it there; I wanted emphasize the things I link to in it (the theme, Drupal, the GNU GPL, and myself), and few people change the defaults.
You can remove the icons by editing style.css, and removing the inclusion of the icons.css style sheet.
If you've renamed your theme from "Sands" or "Sands_CSS" to something else, you need to modify template.php. Sands requires a few custom theming functions contained in this file, and functions will only execute in this file if the function is prefixed with the name of the theme.
For example, if you're using Sands, and you create a new theme "blah", you need to modify function names that begin with "sands_" to "blah_" for them to be called.
Changing column with both Sands and Sands_CSS is easy, though not necessarily easy. In columns.css, simply change all occurences of "14em" with your desired column width (in ems). You can give the left and right columns different widths as well, if you follow the logic of the CSS.
Samat Jain is co-founder of a web services company based in his hometown, Rhombic Networks, LLC, where he currently serves as CTO, system administrator, and programmer.
If you like his site, please leave a comment on your favorite posting, or contact Samat and let him know!