Using a drupal environment supporting multiple sites, with a shared TinyMCE module (ie sites/all/modules/tinymce), linktocontent_node and linktocontent_menu refuse to install on more than one site (attempts to activate the module fail with a "Module Already Installed" message).
I think the problem is that the installation process checks TinyMCE's plugin_reg.php file, finds the plugin already registered and fails out instead of continuing. Since the module is considered inactive, it doesn't then show up in the Linktocontent configuration page.
This seems to be the section doing the dirty, line 77 in linktocontent_util.inc:
// check whether plugin already exists in plugin_reg.php
if (strpos($content, '// linktocontent.module: '.$plugin) !== FALSE) {
drupal_set_message(t('The plugin %plugin has been already installed.',
array('%plugin' => $plugin)));
drupal_goto('admin/build/modules');
}
$insert_pos = strpos($content, 'return $plugins;');
if ($insert_pos !== FALSE) {
$content = substr($content, 0, $insert_pos - 1) . $insert . substr($content, $insert_pos);
_linktocontent_install_write($plugin_reg, $content);
}
I'd propose changing the !== to a ===, moving the file writing code inside the 'if' statement, and dumping the failure code altogether:
// check whether plugin already exists in plugin_reg.php
if (strpos($content, '// linktocontent.module: '.$plugin) === FALSE) {
$insert_pos = strpos($content, 'return $plugins;');
if ($insert_pos !== FALSE) {
$content = substr($content, 0, $insert_pos - 1) . $insert . substr($content, $insert_pos);
_linktocontent_install_write($plugin_reg, $content);
}
}
Or words to that effect. So it writes to the file if it doesn't already have the reg code, ignores it if it doesn't, and in either case proceeds to the module activation code.
For the time being a workaround is to take the plugin registration code out of plugin_reg.php and activating the module through admin/build/modules; this adds the reg code back in, so all the other hosted sites should proceed.
| Comment | File | Size | Author |
|---|---|---|---|
| #2 | linktocontent_util.patch | 1.22 KB | stborchert |
Comments
Comment #1
kingandy... I'd just like to apologise for the general incoherence of that last paragraph. Bleah.
Comment #2
stborchertHi.
Hm, I never thought about using it in a multisite install.
Could you please test the attached patch (simply modified linktocontent_util.inc based on your info).
Thanks for your feedback.
greetings,,
Stefan
Comment #3
kingandyThat seems to work fine!
One more thing - I've spotted that the uninstall process removes the code from the plugin_reg.php file, which would cause further complications for a multi-site arrangement. This might not be a large concern for now though, since I'm not sure when that gets fired - switching the module off through administration seems to deactivate it without running the uninstall function. This suits me just fine :)
I'm not sure how you'd go about keeping track of how many times a module is being used across sites anyway - maybe add a comment to the plugin_reg?
Comment #4
stborchertAnother thing I never thought about :-{
Uninstalling is for completely removing any module-specific data (variables, tables, strings in plugin_reg.php ;-) ).
Perhaps adding a site-information string to the plugin comment (in plugin_reg.php) would fix this?
Comment #5
kingandySounds like a good idea to me. I think the main danger here is that (for some reason) somebody may have several per-site installs of linktocontent, and a single global TinyMCE module, so we want to know which sites have it installed and check if they still have the module active. I don't know how you'd do that though.
Would it be an option to just leave the reg code in? The uninstall doesn't remove the actual plugin files, so TinyMCE wouldn't complain...
Comment #6
scafmac commentedA couple of things. First leaving the settings in plugin_reg.php in spite of the fact that all sub-sites might have un-installed it is the safest (and only) option. Especially since more than a couple other TinyMce buttons do not work, yet remain visible in the admin settings page.
Second, on a similar note, I do not believe that failing to write to plugin_reg.php should prevent the modules from installing to begin with. A warning makes sense, but not failing to turn on the module. I use a customized plugin_reg.php file for my multisite. I've already added the Linktocontent section and don't want to continually have to make it server writeable & then fix it afterwards. This is a pain in the behind.
Luckily the module rocks besides that. :)
Comment #7
stborchertYou're right.
I thought it only would throw a message and don't break the installation but it does indeed. Hm, I couldn't remember what I was writing a few weeks ago. Uh ...
True. I'm thinking about a concept how to do the auto-installation whithout breaking the whole process if plugin_reg.php isn't writeable or the modules are installed multiple times.
Thanks
Comment #8
vikingew commentedThis doesn't apply only to multisites, in a clean sense. Imagine this sceenario, you have a site setup with tiny and linktocontent working. Then you decide to build another site, not as multisite BUT you reuse the folders under sites/all/modules and copy the ones you need for the new site, so you copy the tiny folder and the linktocontent folder. Then Enable tiny and then linktocontent. Now in next step when you want to enable any of the submodules as above you get same message end the checkboxes on Modules page never gets ticked so it looks as disabled. This patch seem to solve this as well though, not sure if there are any other complications with it.
Comment #9
ray007 commentedsubscribing
Comment #10
stborchertHi to all.
Unfortunately I'm out of time at the moment. If someone is willing to write a patch that handles
please do :-)
If you need help understanding my code (or the concept behind), please contact me.
greetings,
Stefan
Comment #11
ray007 commentedBit short on time myself, but the 2 ways I'd see are:
1.) create an entry in the system table
2.) manage registered plugins in a structured variable
or is there a reason to not use 1 of those 2 approaches?
Comment #12
stborchertIn which database do you want to store the info?
Guess you have 3 sub-sites and don't share any table. Do you store the info in db#1? Or in all databases?
I thought about managing this in plugin_reg.php but if it isn't writeable it would fail, too.
It's really tricky :-)
This is already done for each installation:
SELECT * FROM variable WHERE name = 'linktocontent_registered_plugins';.You get an array with all sub-modules registered to "linktocontent" ("global") and an array where the modules registered itself to a special category (for example "linktocontent_node").
For example linktocontent_category is registered to the category "linktocontent_node" because it modifies the data called by linktocontent_node.
Comment #13
ray007 commentedPlease correct me if I'm wrong, but I thought the whole problem with multisite was, that the registration for 1 site makes it impossible to register the plugins for the other sites. And that we therefore should have independent registrations for all sites?
Comment #14
stborchertWith "registration" I did not mean the registration as a tinymce-plugin but the registration of the contrib modules (linktocontent_node, linktocontent_menu, ...) to linktocontent.module. This is working on multisite installations because its done in the variable-table (should not be shared across sites).
Comment #15
stborchertHi all.
The latest development snapshot doesn't abort the installation if plugin_reg.php isn't writable or the plugin text is already there. It only throws a message and continues installation.
Note: You'll have to wait a few hours before the archive is updated so its best to download and test this tommorow (I think it will be refreshed in about 4 hours).
greetings,
Stefan
Comment #16
stborchertShouldn't be active anymore...