ICANN using Drupal

ICANN (Internet Committee for Assigned Names and Numbers), the non-profit organization that oversees the use of Internet domains is using Drupal at http://public.icann.org. They are using Mollom too!

Setup of /sites directory for multi-site

Drupal's multi-site hosting capability is built in with any installation. This is great news for users who run numerous web sites from a single hosting account. A single Drupal installation can be used to run multiple domains, which makes it much easier to manage and maintain the code base. Even if you are dealing with only one domain, the multi-site capability may be valuable by providing the ability to run a separate domain or sub-domain for a development version.

This page describes the set-up of the /sites directory for multi-sites.
With version 5.x, the intended location for all non-core elements of a Drupal installation is in a separate /sites directory inside the Drupal installation.

Directory	Contents
/drupal/sites/all (used by all sites)	/modules /themes
/drupal/sites/default (used when there is no /sites/example.com directory)	/files settings.php
/drupal/sites/example1.com	/files /modules /themes /tmp settings.php
/drupal/sites/example2.com	/files /modules /themes /tmp settings.php

The intended best practice configuration is to create a /sites/example.com directory for each domain. It should contain a site-specific settings.php file and /files directory. Configure Drupal site settings to specify 'File System Directory' of 'sites/example.com/files' instead of the default 'files'. It's possible to do this with an existing web site, but moving file uploads around can cause a lot of confusion if there are already URLs pointing to the old locations.
Domain specific modules and themes should also be placed in /sites/example.com/modules and /sites/example.com/themes respectively.
Contributed modules and additional themes which are for use by all domains in a multi-site installation should be placed in /sites/all/modules and /sites/all/themes. Note that there shouldn't be a /sites/all/files or /sites/all/settings.php.
The /sites/default directory should contain /files and settings.php, for use if the /sites/example.com directory doesn't exist for a domain.
In addition to multiple sites, such as example1.com and example2.com, sub domains are also easily set up. Adding sub3.example2.com and sub3.example2.com/site4, the directory structure for these four sites would be:

/drupal/sites/all/modules
/drupal/sites/all/themes
/drupal/sites/default/files
/drupal/sites/default/settings.php
/drupal/sites/example1.com/files
/drupal/sites/example1.com/modules
/drupal/sites/example1.com/settings.php
/drupal/sites/example1.com/themes
/drupal/sites/example1.com/tmp
/drupal/sites/example2.com/files
/drupal/sites/example2.com/modules
/drupal/sites/example2.com/themes
/drupal/sites/example2.com/tmp
/drupal/sites/example2.com/settings.php
/drupal/sites/sub3.example2.com/files
/drupal/sites/sub3.example2.com/modules
/drupal/sites/sub3.example2.com/settings.php
/drupal/sites/sub3.example2.com/themes
/drupal/sites/sub3.example2.com/tmp
/drupal/sites/sub3.example2.com.site4/files
/drupal/sites/sub3.example2.com.site4/modules
/drupal/sites/sub3.example2.com.site4/settings.php
/drupal/sites/sub3.example2.com.site4/themes
/drupal/sites/sub3.example2.com.site4/tmp

Note that Drupal reconizes www.example.com as a sub-domain of example.com.

If you wish to point both of them to the same site, use /drupal/sites/example.com/ as your directory, and uncomment the corresponding option in your .htaccess
Once you've done this, the file structure of your site will be cleanly organized:

• The main Drupal directory will contain only the standard 'core' files.
• Themes and modules that are shared among all sites are properly placed in /sites/all
• Site-specific themes, modules, and files are compartmentalized and properly placed in /sites/example.com, /sites/example1.com, /sites/sub3.example2.com and /sites/sub3.example2.com.site4 .
• /sites/default/settings.php and /sites/default/files will be used if /sites/example.com directory does not exist.
• Backing up the /sites directory and your Drupal database will give you everything you need to restore the site in the event of a crash, or to move to a new server.
• Adding a domain is easy: just copy the /sites/default directory to /sites/example5.com

To help keep files organized you may choose to use shortcuts to point relevant files and directories that are stored elsewhere in your Drupal installation. These short-cuts (like a desktop "alias") are referred to as "symbolic links" on a Web server. Symbolic links can be used for several purposes:

• Even if using default settings, a good option is to use links from /sites/example.com directory to point to the /sites/default directory. That way, if the settings and /files are ever changed from the default and actually placed in /sites/example.com, their location does not 'move' and no links are broken.
• Links could also be used to point the /sites/default directory to your primary site.
• A /files directory could easily be shared across two domains without being shared across the remaining domains.
• A non-domain-name path for /files can be setup. If it is possible that the domain name might change (say, from a development name), then you can set up a link from /drupal/sites/moniker to /drupal/sites/example.com, where 'moniker' is a short version of the site name that will remain constant even if /example.com changes.

If you are working from the command line on a Linux, Unix or OSX server you can create a symbolic link using the following command:

$ ln -s /path/to/actual/file/or/directory name_of_shortcut
Although the /sites/default directory could contain a /modules and /themes directory, these elements should usually be placed in /sites/all or /sites/example.com. Similarly, although contributed modules could be placed in /drupal/modules as was the practice in version 4.7, this is not recommended.
Multi-site directory setup for sub-domains, including non-standard ports, is described in the installation instructions found in INSTALL.txt.
See multidomain for a contributed module that allows spanning one site across multiple domains, so that specific content types appear on specific domains or sub-domains.
Version 4.6 and 4.7: Best practice for multi-site set-up under version 4.6 and 4.7 is similar to 5.x. The primary difference is that there is no /sites/all directory. Instead, /modules and /themes that are available for all domains are kept in /drupal/modules and /drupal/themes.
Files Directory

The following user-submitted code may be useful in redirecting URLs for the /files directory to the /sites/example.com/files directory. The following code is added to the [drupal_root]/files/.htaccess file:

<IfModule mod_rewrite.c>
  RewriteEngine on

  # Note: this will redirect to the /sites subfolder which is identical to
  # the domain accessed by the browser.  If you use partial domain names as
  # the /sites subfolder (e.g. /sites/domain.com vs /sites/www.domain.com)
  # you will need to modify the Drupal root .htaccess to remove the leading www
  # or modify the following to use the protion of %{HTTP_HOST} that mirrors
  # your /sites subfolders

  RewriteCond %{REQUEST_FILENAME} !-f
  RewriteCond %{REQUEST_FILENAME} !-d
  RewriteCond %{REQUEST_FILENAME} ^(.*)\/files\/
  RewriteCond %1/sites/%{HTTP_HOST}/files -d
  # To redirect the URI to the actual location of the file /sites/<domain>/files/<filesname>
  # change the [L] to [L,R]
  RewriteRule ^(.*)$ /sites/%{HTTP_HOST}/files/$1 [L]

  # If the domain does not have a dedicated /sites/<domain>/files folder allow the
  # default folder to catch it.
  RewriteCond %{REQUEST_FILENAME} !-f
  RewriteCond %{REQUEST_FILENAME} !-d
  # To redirect the URI to the actual location of the file /sites/default/files/<filename>
  # change the [L] to [L,R]
  RewriteRule ^(.*)$ /sites/default/files/$1 [L]

</IfModule>

If the .htaccess method doesn't work, try this user-contributed code for use in settings.php, instead of .htaccess.
In settings.php, put this code:

<?php
$conf['file_directory_temp'] = 'sites/' .substr(strrchr(dirname(__FILE__), '/'), 1) .'tmp';$conf['file_directory_path'] = 'sites/' .substr(strrchr(dirname(__FILE__), '/'), 1) .'/files';?>

Running multi site

Run multiple sites from the same code base (multi-site)

If you are running more than one Drupal site, you can simplify management and upgrading of your sites by using the multi-site feature. Multi-site allows you to share a single Drupal installation (including core code, contributed modules, and themes) among several sites.

This is particularly useful for managing the code since each upgrade only needs to be done once. Each site will have its own database and its own configuration settings, so each site will have its own content, settings, enabled modules, and enabled theme. However, the sites are sharing a code base and web document root, so there may be security concerns (see section below for more information).

Overview of the Process

To create a new site using a shared Drupal code base you must complete the following steps:

1. Create a new database for the site.
2. Create a new subdirectory of the 'sites' directory with the name of your new site (see below for information on how to name the subdirectory).
3. Copy the file sites/default/default.settings.php into the subdirectory you created in the previous step. Rename the new file to settings.php.
4. Adjust the permissions of the new site directory, and grant write permissions on the configuration file
5. Make symbolic links if you are using a subdirectory such as example.com/subdir and not a subdomain such as subd.example.com (see the subdirectory multi-site section below for details).
6. In a Web browser, navigate to the URL of the new site and continue with the standard Drupal installation procedure.

It may also be necessary to modify your Web server's configuration file (often named httpd.conf for Apache) to allow Drupal to override Apache's settings. This is true for all installations of Drupal and is not specific to the multi-site install. Additional information is available in the Best Practices: Configuring Apache and PHP for Drupal in a Shared Environment section of the Install Guide.

Details of the Process

Domains, URLs, and sites subdirectory name

The new subdirectory of the sites directory has a name that is constructed from the site's URL. For example, the configuration for www.example.com would be in sites/example.com/settings.php. You do not need to include 'www' as part of the directory name.

Drupal will use the same sites/example.com directory for any subdomain of example.com, including www, unless there is an alternative, matching subdomain sites subdirectory. For instance, URL http://sub.example.com would be served from sites/sub.example.com, if it exists.

For a subdirectory URL, such as http://example.com/subdir, name the sites subdirectory as follows: sites/example.com.subdir -- and read the section below on getting subdirectory multi-site working.

If you are installing on a non-standard port, the port number is treated as the first part of the subdomain. For example, http://www.example.com:8080 could be loaded from sites/8080.example.com. If that directory doesn't exist, Drupal would then look for sites/example.com, just like a real subdomain.

Site-specific modules and themes

Each site configuration can have its own site-specific modules and themes in addition to those installed in the standard 'modules' and 'themes' directories. To use site-specific modules or themes, simply create a 'modules' or 'themes' directory within the site configuration directory. For example, if sub.example.com has a custom theme and a custom module that should not be accessible to other sites, the setup would look like this:

sites/sub.example.com/settings.php 
sites/sub.example.com/themes/custom_theme 
sites/sub.example.com/modules/custom_module

Document root

One area of frequent confusion is that in a Drupal multisite installation the webserver document root is the same for all sites. For example with the following three sites: example.com, sub.example.com and example.com/site3 there will be a single Drupal directory and all sites will be calling the same index.php file.

Some webhosts automatically create a new directory (i.e. example.com) when creating a new domain or subdomain. In this case it is necessary to make it into a symbolic link to the main Drupal directory, or better yet when creating the domain or subdomain, set it to use the same document root as the site where you have Drupal installed.

Subdirectory multi-site

If you are attempting to get Drupal multi-site working using subdirectory URLs rather than subdomain or different domain URLs, you may encounter problems. You'll start out by making a directory such as sites/example.com.subdir, and putting a settings.php file there. If this works for you, great! But it probably will not, until you make a symbolic link that tells your web server that the document root for http://example.com/subdir is the same as the document root for http://example.com. To do this, go to the example.com document root and type:

ln -s . subdir

If your codebase itself is in a subdirectory, then link your new site to the directory:

ln -s drupaldir subdir

This symbolic link is enough to resolve issues with subdirectory multi-site installations on at least some web hosts. If you still encounter problems with clean URLs and have access to edit the .htaccess file, try adding the following stanza immediately before the existing rewrite rule (for Drupal 7):

RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteCond %{REQUEST_URI} !=/favicon.ico
RewriteCond %{REQUEST_URI} ^/subdir
RewriteRule ^ subdir/index.php [L]

That block should go right after the RewriteBase / line, and before the other RewriteCond lines. What that does is catch incoming URLs that contain the subdir prefix and route them to the symlinked file so that they find the right database. Note that if you have multiple subdirectory-based multi-sites, each one will need its own block as above. (Based on this forum thread: http://drupal.org/node/239583#comment-786932)

Note that these problems do not usually occur for multi-site installations using a subdomain, so you might want to try that if you cannot get subdirectory multi-site to work. (However, subdomains are not good for search engine rankings!)

Localhost alias for local workstation

On many systems it is possible to create entries in a "hosts" file to create aliases for the localhost name for a local workstation. By creating aliases for localhost it is possible to create names such as localdev1.example.com and localdev2.example.com, both for the local computer.

If on the other hand you use subdirectories in your local web root, create a symbolic link like this:

ln -s drupaldir subdir

and name your site folder localhost.subdir.

Domain name changes

Once a site is in production in a particular subdirectory under the sites directory, the subdirectory should not be renamed, even if the Web site URL changes. This is because several database tables (for example: system and files) include references to "sites/www.mydomain.com." Instead of renaming the sites directory, you can create a symlink to the new URL from the old one. Navigate to the sites directory and then use the following command:

$ ln -s /path/to/drupal/sites/old.domainname.com new.domainname.com

Security Concerns

You might want to reconsider using Drupal's multi-site configuration, in situations where the administrators for all of the sites being run from the same code base are not either the same person or a small group with a high level of mutual trust. The reason is that anyone with full administrative privileges on a Drupal site can execute arbitrary PHP code on that site through various means (even without FTP access to the site), and that arbitrary PHP code could be used from one site to affect another site, if the two sites are in the same HTTP document root and sharing the same Drupal code.

So, unless you completely trust all of the administrators of the sites you are considering running from the same Drupal code base to be knowledgeable, careful, and not malicious, you might want to consider installing their Drupal sites in completely separate areas of the web server that are not able to affect each other via PHP scripting.

drupal target _blank not working

A target="_blank" alternative for Drupal, or saving users' content by overriding the filter tips link
With a few lines of code in template.php and a small jQuery script, you can fix that by opening a new window when that link is clicked - without losing XHTML compliance (which you'd lose if you used target="_blank"). Additionally, you can re-use that trick elsewhere by adding a special class attribute to your anchor tags.

The first thing you need to do is add the following lines to your Drupal theme's template.php (replacing YOURTHEMENAME with your theme's name):

// Theming the filter tips more info link so users don't lose
// their stuff when visiting another page.
function phptemplate_filter_tips_more_info() {
  return '<p>'. l(t('More information about formatting options'), 'filter/tips', array('class' => 'target_blank')) .'</p>';
}

drupal_add_js(drupal_get_path('theme', 'YOURTHEMENAME') .'/target-blank.js', 'theme');


What that does is first override the theme function for the filter tips "more link" and add the "target_blank" class to that link. Our jQuery will use that class. Secondly, it tells Drupal to add a Javascript file called target-blank.js to every page. It's a really small script, and because of the potential for re-use, we might as well load it on every page, so we don't put any conditions on when we add it.
Next, create a file named target-blank.js in your theme's folder and add the following jQuery Javascript to it:

$(document).ready(function(){
  $("a.target_blank").click(function(){
    window.open(this.href);
    return false;
  });
});


This jQuery script waits until the document is ready, then on the click of any anchor tag with the class "target_blank" it opens that link in a new window.
That's it.
If you want to use this jQuery with any other anchor tags in your site, add class="target_blank" and you've got a link opening in a new window without compromising your XHTML compliance.
Hat tip to ejhildreth for the tip on using jQuery to maintain XHTML compliance.
Additionally, you can read about why this isn't in Drupal already. In short, opening new windows is considered bad UI. And I agree. My personal conviction, though, is losing users' data is worse.

Git GUI tools

Git can be integrated with your development environment using command-line tools, several 'front-ends' or GUIs, and integrated tools in some IDEs.

This section includes documentation to configure tools for use with Drupal.org and, where available, detailed directions for best-practice workflows using those tools.

Refer to Git interfaces, frontends, and tools for a comprehensive list maintained in the official Git Wiki, including graphical user interfaces (GUIs).

SmartGit

1. Click "Edit" » "Preferences" » "Git" and choose "User Information"
2. Enter your Full Name and E-mail address

EGit

1. Click "Window" » "Preferences" » "Team" » "Git" » and choose "Configuration"
2. Add your Full Name and E-mail address

Git Gui

1. Click "Window" » "Edit" » "Options..."
2. Add your Full Name and Email address

Giggle

Linux (gtk+/GNOME)

1. Install giggle-personal-details-plugin from your distribution's repository
2. Click "Edit" » "Personal Details"
3. Add your Full Name and Email address

gitg

Linux (gtk+/GNOME)

1. Click on "Edit" » "Preferences" and choose "Configuration"
2. Add your Full Name and Email address

Installing Git

Unlike traditional version control systems like CVS or SVN, a Git repository can be a completely local undertaking. Consequently, to work with Git, you first install it on your local machine.

Wikipedia holds a list of available Git clients and (IDE) plugins.

Mac / Linux

• Installing Git on Linux and OSX.
• Installing Git on Mac using Macports tutorial.
• Brief video tutorial on how to install Git and a Git GUI on a Mac

Windows

• Starting by installing msysgit is a good idea. Don't select the git-cheetah Windows Explorer extension in the installer, it's not actively developed.
• An illustrated guide to Git on Windows (2009) might be helpful to read.
• Brief video tutorial on how to install Git and a Git GUI on Windows

Git graphical user interface (GUI) tools

Visit the Git GUI tools page for a list of Git tools with graphical user interfaces, if you prefer using those rather than working on the command line.

Design for Drupal 8

Attracting more designers to Drupal is an important goal in our quest to create a well-rounded ecosystem and to attract more users to Drupal. While we made some great improvements in Drupal 7, we need to do more of the same with Drupal 8, and then some. After conversations with various Drupal designers and front-end developers, I decided that adding a new theme to Drupal 8 core is a great way to attract more designers, both as end-users of Drupal but hopefully also as contributors to the project.

I wanted to kick this off early in the Drupal 8 development cycle, and have asked Jeff Burnz to be the Initiative Owner for the Drupal 8 Design Initiative. This is the third official Drupal 8 initiative after the Configuration Management Initiative and the Web Services Initiative.

Jeff will guide the community through a design process with the goal of producing a beautiful theme that can be added to Drupal 8. The emphasis of this theme will be on design to show the world that Drupal can be used to create delightful experiences.

As important as a new theme for Drupal 8 is, so is the process of selecting the design and building the theme itself. Another goal of the the Design Initiative is to define and execute a new process for the selection and development of new core themes. Jeff has gathered a small team of Drupal UX-ers, designers and front-end developers to drive this process forward. You will be hearing a lot more about this in the coming weeks and months and your input will be sought -- this will be an entirely open process, with full community collaboration an important part of the process.

Last but not least, hopefully we can continue to improve Drupal's mark-up, CSS and theming capabilities along the way, as well as further educate the Drupal community about the importance of design.

Long story short, this should be a great initiative for Drupal 8. If all goes well, not only will we get a new theme for Drupal 8, but hopefully we'll raise the bar for design for Drupal in a significant way. If you want to learn more about this initiative, you can find additional information in Jeff's announcement blog post.

If you want to get involved please see this discussion on drupal.org.