Auto installer for Drupal 4.6 multi-site and modules -- how do I share it?

The problem was not with the installer, but the fact that several of the Amazon modules are not self-contained.

They require that their .inc files be copied to the includes directory before they will work.

I would have loved to, but I am not permitted because I would not make it GPL. I have released it under LGPL, because I do not want to be party to usurping anyones IP rights.

In fact, I have received a threatening email for attempting to release my code under LGPL. LGPL protects the code like GPL, ensuring that it and all derivatives are free and protected, but allows you to determine what you want to do with YOUR code.

Under GPL, any module or theme created for Drupal is forced to be GPL. While I accept this as a requirement for using Drupal, I do not want to be party to it. Because Drupal is GPL and not LGPL, no Drupal sites which I create using proprietary code can ever leave my server, including providing clients with backup copies, because doing so will commit such code to GPL.

Thanks, glad that I can give something back to the community.

Glad I could contribute something back to the Drupal community.

1. FILES appears to be an issue for multisite installations, and having TMP point to a directory visible to the web server appears to be a security risk. I have not yet received a response to http://drupal.org/node/38774 so while the capability is there, the options are currently turned off (see that post for details).

2. It is essential due to spam filters that your email come from a valid domain for your server (see: http://drupal.org/node/38510#comment-71180) If the default for your system is constantly different, simply change this line (about line 116):

$site_mail = "system@".preg_replace('/^(www|dev|new)\.(.*)/i','$2',
trim(strtolower($_SERVER['HTTP_HOST']),'/'));

Sorry... running around today, so I will answer these points as I have time and a hotspot...

3. ServerAlias is a directive in your httpd.conf file (Apache -- see: http://httpd.apache.org/docs/1.3/mod/core.html#serveralias)

If you have direct access to httpd.conf then add a serveralias for each host name you want to use such as:

ServerAlias host1.mydomain.com host2.mydomain.co domain2.com www.domain2.com

or a catch-all like:

ServerAlias *.mydomain.com

As your LAST DEFINITION IN httpd.conf you can even put:

ServerAlias *

Which will make ANYTHING NOT CAUGHT BY ANOTHER HOST DEFINITION go to your Drupal server.

If you don't have direct access to httpd.conf but use an interface like cpanel or hsphere, there will be a Domain Alias and/or a Host Alias setting.

I know that, at least for HSphere, you cannot define a catch-all unless you are on a static IP.

4. The wizard asks for the password to validate that you know the database password for the drupal server. Otherwise anyone could go to your site and mess it up. You might even want to add security above this (SSL, htaccess, etc.). Since there is no admin user at this point, the DB User is all it has to validate against.

As long as you are using the default database user, you don't need to enter the name.

The username is an optional database username in case you have restricted what the drupal database user (as specified in settings.php) has rights to. If you enter a password AND username, then those are the credentials used to access the database server instead of the ones in settings.php.

5. Your original settings.php file (that you sent me) had the database settings in the wrong places. Since you somehow got it to run part way, I suspect that some values were messed up.

Note to avoid confusion, if you had an older version of build_db.php installed in the /database folder please delete it.

also related - 9. and 10.

there should be no settings.php file in the document root folder (although this could be an artifact of clean urls).

settings.php, build_db.php, allcron.php and options.mysql (if used) should all be in the /sites/default folder

9. OOPS!

Thank-you for pointing out the small but significant typo in the documentation. The steps to running the wizard should be:

1) Create the database, with rights to the Drupal user (Not needed if you use the table-prefix method).
2) Add the new domain as a serveralias to the Drupal site (not needed if you use a catch-all domain).
3) Browse to the web address http://{domain}/sites/default/build_db.php (you must know the database user password for security).
4) Enter the password of the Drupal user (in your settings.php file). If the drupal user doesn't have table create rights, then enter the user name and password of a database user who does.
5) You should do a test run first with Show SQL Only checked to see if you have any problematic modules. When you are sure it works on your system, check RUN SQL.
6) Click Start.

6. does it still not support multisite via directories?

Nearest I can tell there is no way to have Drupal function in multi-site mode using a common sites/default/settings.php file. If someone can show me how that can work, I will add support.

Right now, if you manually edit the settings.php file to add a hard coded table prefix, the installer will still handle the rest. If you use the Drupal version of settings.php with all manual settings, it will work fine, install all modules, build all databases, and even build the cron chain properly.

Of course only my settings.php file gives you safe mode and debug mode. Just copy it and set:

  $SETTINGS_AUTO_TABLE_PREFIX = FALSE;   //leave table prefix unchanged
  $SETTINGS_AUTO_DB_NAME = FALSE;       //leave database name unchanged

7. no, it can't be used, so I have to wait

8. settings.php shouldn't be in the root directory. Rememger that you can't "include" a file from another site (well.... if you do, it's output is included, not it's code.

12. The reason file names are not versioned is so the above dowload link will always give you the latest version. I always version the readme file to match the higest version in the file.

The Drupal licence agreement (GPL) requires that all files have the revision number and date.

I would love to but they are blocked on drupal.org.

Even if I put them on my server they are stripped from the post.

I don't know if or when the auto-installer will work with 4.7

I am avoiding looking at 4.7 yet because I am sure it will be a huge amount of work (based on 4.5 to 4.6) to migrate to it and I have no compelling reason to do so, at least until all modules and themes have been migrated.

In the past whenever a minor revision (version + 0.1) occurred all modules and themes were not compatible.

I heard that 4.7 already has an installer so I doubt that this will be either compatible or necessary anyway.

If it is possible to migrate, I will likely need to write some sort of script to migrate an entire installation to 4.7 and I will let people know.

All you need to edit is the regexp that builds the prefix in settings.php.
It is currently:

$db_dompart =  preg_replace('/(_org$|_com$|_ca$|_net$|^dev_|^www_|^new_|-)/i',
  '',
  strtr(trim(strtolower($_SERVER['HTTP_HOST']),'/'),'./','__'));

If you want to ignore the port (ie. the port will not affect the database/table used) then change it to:

$db_dompart =  preg_replace('/(_org$|_com($|:)|_ca($|:)|_net($|:)|^dev_|^www_|^new_|-|:|[0-9]*$)/i',
  '',
  strtr(trim(strtolower($_SERVER['HTTP_HOST']),'/'),'./','__')
);

If you want to have different Drupal site on each port, simply change it to:

$db_dompart =  preg_replace('/(_org$|_com($|:)|_ca($|:)|_net($|:)|^dev_|^www_|^new_|-|:)/i',
  '',
  strtr(trim(strtolower($_SERVER['HTTP_HOST']),'/'),'./','__')
);

Tip: If you are playing with the file and want to debug what settings.php creates, simply edit line 11 to read:

$ALLOW_DEBUG_SETTINGS = TRUE;

then you can access your server with http://www.mydomain.com:8001?DEBUG_SETTINGS
and get debug information about settings.php

I haven't stripped the 4.0 version down for release but will very soon... I think it will be VERY soon.

I have slapped up some temporary screen shots for you, (screen shots are not permitted on Drupal.org).

The screen shots are at:

When you go to /sites/default/build_db.php

When you are done.. This example is when you are initializing a site which had no database created).

When you go to an uninitialized site after the main Drupal database has been created.

You need to enter the path to the installer the first time in Drupal 4.7 because Drupal 4.7 traps the initial database error and never goes to the installer.

Do you mean a 4.6 multi-site installation to 4.7?

There really is no way that I can see to "upgrade" from 4.6 to 4.7. Before that statement get this discussion dragged off-topic, let me clarify:

Modules and themes are not portable from one version of Drupal to another. This is a long-standing core principal of Drupal, it has been covered in other threads.

That means that unless you use only those modules and themes that continue to be maintained AND you rewrite all of your custom modules and themes, you can't directly upgrade from 4.6 to 4.7. You are best to just build a parallel system and migrate one at a time as functionality is ported or replaced in 4.7.

This installer can make it a bit easier, however. You can do like I am doing: run a parallel server and migrate one site at a time by simply moving the serveralias from the drupal 4.6 installation to the 4.7 installation. If there are options you want to set, you should be able to use the options.mysql file to help set them on all sites.

Migrating content and user databases is another BIG challenge, way beyond the scope of this, because the autoincrement indexes and cross references tend to get messed up.

Maybe it's a job for Ethan in "MI:4.7", or perhaps just a topic for a different forum thread...