Taxonomy/Book wrapper installation unsuitable for multisite environment
robertDouglass - June 2, 2006 - 14:38
| Project: | Category |
| Version: | 4.7.x-1.x-dev |
| Component: | User interface |
| Category: | feature request |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | closed |
Jump to:
Description
The way the wrappers are installed is unsuitable for multisite environments. The correct behavior (and one that is far less invasive overall) would be to copy the wrapper module into sites/mysite/modules/. This makes it multisite safe and allows for slightly better security settings (webserver shouldn't be able to write to the main modules directory one way or another).

#1
The wrappers get installed to wherever the taxonomy and book modules are installed on your site. So if your taxonomy module is in the 'sites/mysite/modules' directory, then that's where the wrapper will get installed.
Correct me if I'm wrong, but isn't it forbidden to have a module with the same name in the 'modules' directory and in the 'sites/mysite/modules' directory? Wouldn't the two modules conflict with each other? Or does one cleanly override the other? I recall once advising a user that the former (less desirable) behaviour is the one that Drupal has - see http://drupal.org/node/55144.
Also, bear in mind that the wrapper installation script is designed to cover the 'standard' installation of the wrappers. Installing them in a multi-site environment is IMO beyond the scope of what the installation script should be responsible for. In cases like this, the wrappers can always be installed manually.
#2
The whole point of the sites/modules dir is to allow clean overrides. I'm of the firm conviction that the default behavior of the category module should be to try to put the module there. I can't see any argument for having a feature that can change the behavior of a whole different website (which is the way it is now). I admit that there are some implementation challenges (and no perfect solution), but it should at least try to be a good multisite citizen.
#3
Robert is right, Drupal allows site-specific modules to override any site-wide module, including taxonomy. In other words, you can leave the default taxonomy module where it is - and just make a site-specific copy for any site that wishes to use the category module. The category module will overwrite the site-specific copy instead. There is no need to have any unnecessary duplicate modules.
It's all about the order in which you do things. Because of the way Drupal caches modules, if you create a site-specific module override, it won't be recognized until you actually visit the admin/modules page. So if you activate the category wrapper before Drupal officially recognizes the site-specific override, it will install the wrapper into system-wide modules directory, which of course completely borks all other sites sharing the install.
Here are the steps to correctly implement category module on a multi-site install (manually). I don't see any reason why the category module shouldn't be able to do all of this automatically, if instead of replacing the active taxonomy/book modules, it just installed the wrapper modules into the site-specific modules directory, creating it if it doesn't already exist.
Install category module in the main (shared) modules directory.
Now, for each domain that you want to use the category module follow these steps *in order*
1. If one does not already exist, create a site-specific 'modules' directory (i.e. /sites/example.com/modules/) and *make sure it is writeable by drupal*.
2. Copy the main taxonomy module from 'drupal/modules/taxonomy.module' to the site-specific modules directory so that you have '/sites/example.com/modules/taxonomy.module)'. (Do this BEFORE you activate the category modules)
3. Do the same for book.module *if applicable.
4. Go to the admin/modules page (This will force Drupal to recognize the site-specific taxonomy.module override).
5. Activate the category modules.
4. Proceed to the category settings (admin/settings/category) and use the script to install the taxonomy wrapper. This should replace the site-specific taxonomy.module, leaving the site-wide taxonomy.module (and therefore all your other websites) unaffected.
I don't see any reason why the category module shouldn't be able to do all of this automatically, if instead of replacing the active taxonomy/book modules, it just installed the wrapper modules into the site-specific modules directory, creating it if it doesn't already exist.
#4
I've just got all my taxonomy-using test sites on the installation wrecked. This is very important information and it's buried on the bugs page. Please insert a multisite warning into the README or INSTALL files. Thank you.
#5
Oops. Sorry I've overwritten the original post title. I try to re-set.
#6
It is true that a module in sites can override a core module. However, if a core module is already enabled, placing a copy in sites and then visiting admin/modules will cause "attempt to redeclare function" errors.
The core version is loaded because it has an entry in the system table, but drupal_get_path('module', $modname) returns the sites version, which is then include_once'ed, causing the conflict. The resolution is to temporarily remove the sites version, disable the core version in admin/modules, and then copy the sites version back into place.
The online help for category module indicates that the core versions of book and taxonomy should be enabled before replacing them (and I assume also before overriding them via sites). Jaza, why is this necessary?
#7
Seems like the 6.x version works better (overrides from Category directory, not replacing the original module). Also this is a long-dead issue, 4.7.x no more supported, and there's a newer one about the problem of multisites: #367686: Taxonomy Wrapper enabled on one site breaks other sites that don't use Category module. Closing.