Drupal 6.x

You can share tables between Drupal installations by setting table prefixes ($db_prefix) on only some tables but not others. One interesting application for this is to share the taxonomy tables (vocabularies, term_data). Another interesting use is to share users across Drupal installations. To share tables in Drupal, sites must be shared in the same database.

Warnings!

This procedure could result in unexpected results, depending on which tables you choose to share, including broken version updates and/or security holes.

Upgrades to the next version of Drupal are not supported! Be sure you have read EVERYTHING on this page, most especially the issues surrounding a major Drupal upgrade, before considering using shared tables!.

Below the Page Specific Visibility Options options, you will see a large text box. On each line, you can specify which pages that block will appear on -- or not appear on, depending on what you selected above.

The following are some annotated examples. They all assume that you choose the second option above; if you chose the first option, blocks will appear on all pages other than what you specify below. You're welcome to add more than one listing, each separated by lines. (Note that you cannot specify pages on which blocks appear as well as pages on which blocks do not appear. It is either one or the other.)

<front>

Specifies that the block appears on the front page.

node/42

Specifies that the block will appear on the item with the node ID of 42.

aggregator

Specifies that the block appears on just the aggregator.

blog/*

Specifies that all URLs that start with blog/ will show the block. Note: if you want the block(s) to also appear on the main blog page, you need to add blog (that is, without the trailing slash) as well.

Some users have reported they receive the error "warning: Delimiter must not be alphanumeric or backslash in [your drupal install] modules/block.module on line 354." if they do not surround their paths in <> like <node/42>

This seems to be a duplicate (albeit earlier) page

Please see http://drupal.org/node/350634 which is more recent and more accurate.

Description

These snippets allow you to override the default login layout using a custom user_login.tpl.php.

If you want to customize the full page layout, click through to the Customizing the login, registration and request password full page layout handbook page.

Step 1 of 2

In a text editor like notepad.exe, create a file called template.php using the the following snippet. If you already have a template.php file, simply add it to your existing one.

For use with Drupal 4.7.x and Drupal 5.x

<?php
 /**
   * This snippet catches the default login form and looks for an
   * user_login.tpl.php file in the theme folder
   */

function phptemplate_user_login($form) {
    return _phptemplate_callback('user_login', array('form' => $form));
}
?>

For use with Drupal 6.x

_phptemplate_callback is deprecated in Drupal 6 in favor of the theme registry and preprocess functions. See the Drupal 6 theme guide for more information.


<?php
function mytheme_theme(&$existing, $type, $theme, $path) {
$hooks['user_login'] = array(

When migrating a website from any system to Drupal you should be aware of existing inbound links to your site, as well as search engine indexes and ranking. In order to maintain your search engine ranking and also not break inbound links you should plan to redirect inbound requests to old uris to your new drupal nodes.

Instead of offering up 404 Errors, you can direct users to the content they are looking for. In some cases using the path_redirect module may be sufficient. In other cases you may want to write redirect rules in your .htaccess file, and in still other cases, the method described below may work for you. Another step, which will help with search engine indexing is to install and configure xmlsitemap module and submit your sitemap to the major search engines for indexing.

The rest of this article describes an approach that will parse the Search Engine query from the HTTP_REFERER and search the drupal website for what the user was actually looking for.

If you upgrade a site from one version of Drupal to another, you must take specific steps to make your theme compatible with the new version.

Always test the modifications on a separate development server before moving to a production site.

The Ping core module is useful for notifying interested sites that your site has changed. It automatically sends notifications (called "pings") to the pingomatic service to tell it that your site has changed. In turn pingomatic will ping other services such as weblogs.com, Technorati, blo.gs, BlogRolling, Feedster.com, Moreover, etc.

The ping module requires cron or a similar periodic job scheduler to be enabled.

You can: