Maintenance fixes only

The shared email module allows multiple users to use the same email address for different accounts. The module works for both registration and account updates.

Compatible with with Email Registration, Subuser, User Import and LoginToboggan modules.

Other features

Shared email password reset
http://drupal.org/project/sharedemail_pass_reset

How can you get involved?

• Help translate this module at localize.drupal.org
• Help writing documentation. Please, open a project issue if you wish to help writing documentation for this module.

How it works

Shared email overrides the 'user' module's validation that prevents the same email address being used by more than one user. Displays a warning to the user that they are using a shared email.

Based on http://drupal.org/node/15578#comment-249157

This module modifies the email address before it is validated by the user module.
Because it only changes the edit value rather than the form value, the validation will pass but the original unchanged email is still stored properly.

Make sure to enable the 'show warning text' permission for the users role that can see the warning message.

I'm looking for a new maintainer! Please contact me or file an issue in the theme's issue queue asking for commit access.

About Hiroshige

Hiroshige is a fixed-width (960-pixel) theme with a flexible layout whose CSS grid layout classes are applied programatically based on region content. The theme includes a default favicon, default logo, default user picture, and a custom maintenance page. The layout supports primary links but not secondary links.

This module helps to export and/or import menus. Using it you can easily transfer menus from one Drupal site to another. The module can be used in ensemble with Node export (node content migration). In this case, it allows to batch-arrange existing content into a given menu structure, using a very simple text file.

Here is an example of the JSON-like file format understandable by the module (starting from versions 7.x-1.3):

Important: please use Unicode (UTF-8) as file encoding, one-byte national charsets will not work. Also, JSON's name and value must be enclosed in double quotes, single quotes are not valid. Trailing commas are not allowed.

D6 users:
The export feature is now implemented! You can export menus and import them in D7 installations (and D8 when relevant version will be ready)

The autoload module is a utility module. It allows other modules to leverage PHP 5's class autoloading capabilities in a unified fashion. It does, naturally, require PHP 5.1.2 or later.

You do not need this module unless you are developing a module that makes use of classes or you are installing a module that depends on this one.

The 1.x branch uses a manual info-hook. The 2.x branch includes a backport of the Drupal 7 self-learning registry as well as the info hook for backward compatibility.

Because this functionality is already in Drupal 7 core, there will never be (or need to be) a Drupal 7 version of this module. Leveraging this module for Drupal 6 class-using modules, however, will make moving to Drupal 7 easier.

See the included README.txt file for information on how to use this module in your own modules.

NOTE: Remember to clear all caches in your module's hook_enable() if your module relies on autoload. Autoload information is cached and your class may not be found if the autoload cache is not cleared.

The Post Block module allows you to create blocks that display a list of links to the various content types on your site. The benefit of using Post Block is that you can specify exactly which content types are listed.

Disable being able to re-use CCK fields (prevents splitting fields into separate tables when new fields are added to a content type). This is useful when custom modules have hard-coded SQL queries to CCK field tables where re-using a field would break the queries.

Current options are disable the submit button, remove the form, or prank the user to move the button around the screen on mouseover.

Drupal 7+

From what I've seen, Drupal 7 fully normalizes content type fields by default, therefore this module couldn't prevent it. Unless someone can demonstrate otherwise, there is no point in using this module in Drupal 7, even as a gag.