Legacy wrapper and multi-site
| Project: | Category |
| Version: | HEAD |
| Component: | Code |
| Category: | bug report |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | closed |
Jump to:
Just ran into this one. I have a multi-site installation that shares a code base. As soon as I installed the legacy wrappers I bombed all my other sites and had to convert them all to category right away. I probably would have done so anyway, but would have preferred not having to do them all at once. In my case, all the sites are under my control and I am the only decision-maker, so I can just go ahead and upgrade them, but I can imagine lots of scenarios where people with multi-site installations cannot convert all sites to categories at once, or maybe even at all.
Maybe you already have a plan for this, but it looks to me like there needs to be some way for the legacy wrappers to live in harmony with sites that are not using category. My first thought would be to keep the original book and taxonomy modules on the site (renamed to book.inc and taxonomy.inc), then alter any code that depends on category so that it checks whether category is installed. If not, it executes the legacy function from the .inc file.
This would also get away from the need to copy and rename the files everytime you install category (like on a multi-site installation, or in my current development environment where I keep adding and removing things.) That manual process is annoying and potentially a source of errors, anyway.
#1
Thanks for your suggestion, Karen. I too find the process of installing the wrapper modules to be a pain (and when I'm doing development and testing, I sometimes need to install and uninstall them a lot). However, the wrapper modules do (IMHO) succeed very well in achieving quite a difficult task, and I can't really think of an alternative method.
For mult-sites, obviously, the situation is more complicated. If you have your taxonomy data shared between multiple sites, and you only want to use the category module on some of them, then I gues one solution would be to run category and the taxonomy wrapper on some sites, and to just run plain ol' taxonomy on other sites. This would mean that if you change your terms and vocabularies on one of the non-category sites, the change would not run through to the category system. But if you removed the 'administer taxonomy' permission from all roles on your non-category sites (and didn't log in as user #1 too often), this would not be an issue.
Another option would be to develop a 'category wrapper' (nooo - not another wrapper! I hear you say). This would update category data for sites running only taxonomy and/or book. Not sure exactly how it would work - but it is a possibility.
As for the difficulty in installing and uninstalling the wrappers, I'm thinking of writing a script to make this easier. Perhaps simply embed the script within the 'admin/settings/category' page, and make it a series of '[un]install x wrapper' buttons.
#2
First of all, I don't have shared databases, just a shared codebase, so this isn't as complicated as it will be for some people.
Second, how can I have one site using legacy taxonomy and another using the wrapper? If they are sharing a codebase and I replaced the legacy module with the wrapper, the legacy module is no longer available (which is why they were throwing off errors).
#3
I see. In your case, the best option would be to make use of Drupal's "site-specific modules and themes within a shared codebase" feature. Instead of installing the taxonomy wrapper in the default '/modules' directory, you will have to install it in various '/sites/sitex/modules' directories. E.g.:
1. /sites/sitex/modules/taxonomy.module (where this is the taxonomy wrapper, being used with the category module)
2. sites/sitey/modules/taxonomy.module (where this is the original taxonomy module, on one of your sub-sites that is not using category)
Make sure that if you do this, you do NOT install the original or the wrapper version of taxonomy in your regular '/modules' directory, or in your '/sites/default/modules' directory, as this will cause a conflict in that two modules with the same name will be available to one site. Each site must have access to only one file called 'taxonomy.module'.
You can leave the category module (and co.) installed in your '/modules' directory (or your '/sites/default/modules' directory) - it will be available to all sites, but only enabled on some. This is better, as there will only be one copy of the category module in your code base. Unfortunately, if you have more than one sub-site that's using original taxonomy, you will need to have a copy of the taxonomy wrapper for each such sub-site, and all the copies will need to be maintained. This is unfortunate, but as far as I can see, it's unavoidable for your desired setup.
#4
I had no idea you could do something like that! I had been researching the various things I can do with multi-site but never came across the possibility of keeping separate modules. I have no problem with keeping separate copies of the taxonomy module, it's better than being rushed into upgrading a site that isn't ready for it yet. It actually may help solve another problem -- I have many modules being used by only one site and the modules page is becoming unwieldy for everyone, so I can move some of the seldom used modules out to just be available to the sites that need them and cut down on the clutter for everyone else.
Thanks!
#5
Leaving this issue active for now, as this multi-site wrapper module technique is really something that needs to be documented on the category module site.
#6
This technique has now been documented on the new multi-site installation tips page on the category module site.
#7