Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
By sam452 on
I have an existing Drupal 7 app that would be a suitable candidate for setting up Multisites.
In my sites/default folder is my fall back settings.php file which works fine.
Following this guide:
https://www.drupal.org/docs/7/multisite-drupal/multi-site-sharing-the-sa...
I created subfolders in the sites/ folder. As an instance I created sites/p1 and copied my settings.php file from sites/default and changed the $databases() array to the new database. Since the new site will be largely the same as the default I duplicated the db and renamed it p1.
I have successfully created a new site in Apache virtual hosts and named the sites/p1 folder to sites/myapachehostname.biz so that it matches up with what Apache is expecting. This part is working.
It's just that when it attempts to load Drupal, I get this Drupal error. Reading about other posts, I can easily login to mysql server from the server where this Drupal app is hosted using the credentials in the new sites/myapachehostname.biz/settings.php so the obvious answer is not applicable here. In the drupal page linked above, it suggests that there may be records in the system table that are looking for a different path, but all records in system filenames point to sites/all/*
I attempted to let it install its new database. Attempting to do that reverts to the settings.php in sites/default. I've changed the mysql user and ensured that this user has all access but that seemed to make no difference. The settings.php file is pretty lean and I cannot see anything that would prevent connection to mysql. Is there a missing step I'm overlooking? thx, sam
Comments
The modules which are shared
The modules which are shared between the sites will still be in sites/all/modules after switching to multi-site so there is no reason the system table would need updating for those records.
If you look through the documentation you linked, which assumes starting with a fresh site, it should become clear that after the process there is no sites/default/settings.php. As I read your post you still have a sites/default/settings.php. You may need to remove this. If you want your old site to still work, you will need a new directory and settings file at sites/my-old-apachehostname.biz/settings.php (for example).
I belong to the school of though, quite widespread in the Drupal world, that multi-site setups are usually more trouble than they are worth and that it is easier to run two sites.
Digit Professionals specialising in Drupal, WordPress & CiviCRM support for publishers in non-profit and related sectors
Clue I needed
Yes, moving the sites/default/settings.php into another site helped me isolate what was different from my other settings files. But once that was done, it was better to put this back into default.
I'm curious as to your school of thought. I saw the discussion linked to from DrupalCon Austin about multi sites. I think for the use I have: single code base, school with multiple groups wanting their own variation seems like a good fit. I don't know what I don't know and given this customer demand I'm curious as to how much difficult this will be to maintain if they choose to go to multi site. Right now, I'm hacking away using taxonomy and workbench to try to isolate them from each other. It's certainly not bullet proof
multisite means single point
multisite means single point of failure for 2 or more sites. It means running code on both sites which may only be required for one. It means bigger db which takes longer to import when you need to resore or copy a site. When an update of a single site with drush takes seconds, it leaves the question, what benefits do you gain from having a single codebase?
Digit Professionals specialising in Drupal, WordPress & CiviCRM support for publishers in non-profit and related sectors
one codebase
Your experience is helping here. What benefits do we expect to gain? If the modules are the same, core is the same but they want themes, complete separation of custom menus, content then based on what I'm seeing the main negative is multiple databases and having to manage updating these databases during a core upgrade, among other things. IF, a big if, they do not deviate from this model then the benefit should outweigh the negatives?
what I'm seeing the main
How long does it take to type 'drush updb'? That is how long the database upgrade takes. Assuming you use drush for updates.
Actualy it takes less. If you type 'drush up' in a recent version of drush, after the code update it runs drush updb automatically. Yes, you are waiting for 10 seconds per site while this command executes so multi-site can start making sense for people who are running suites of dozens or even hundres of sites (and some are). That is just the way I see it.
Digit Professionals specialising in Drupal, WordPress & CiviCRM support for publishers in non-profit and related sectors