We have a custom install profile. We have our wysiwyg profiles in a feature.
We found recently that when installing the site with Drush, after the installation is complete, the wysiwyg profiles are not enabled. The wysiwyg table is empty. If we clear the cache, the profiles are restored and it works. This only occurs when installing via Drush, installing via browser works fine.
We tried adding in a features_revert at the end of our hook_install, but it did not fix the issue.
Some things I noted from investigating:
- During the installation I can see that the imported wysiwyg profiles are inserted into the database correctly.
- At some point later, the table is emptied. Also the cache item for wysiwyg_profiles is empty.
- I noted that wysiwyg implements its own static cache and at some point it is returning nothing from entity load. It seems like possibly its returning nothing, this is being written to the database and clearing the profiles.
I was wondering if someone with more knowledge of the module might be able to point us in the right direction. I understand that this could be related to something other than wysiwyg, but if there is something obvious for me to look at please let me know.
Comment | File | Size | Author |
---|---|---|---|
#6 | WYSIWYG-breaking-installation-profile.png | 110.59 KB | jmcoimbra |
#4 | 1954910-wysiwyg-empty-after-installation_fixed.patch | 371 bytes | tim-e |
#3 | 1954910-wysiwyg-empty-after-installation_fix.patch | 399 bytes | tim-e |
#2 | 1954910-wysiwyg-empty-after-installation.patch | 373 bytes | tim-e |
Comments
Comment #1
TwoDI've also had problems if I don't clear the caches after installing modules (several ones, not just Wysiwyg) using Drush. I don't know why and I've not had time to dig through it. (I've dug through Drush several times already, but looking for the cause of other oddities, it's quite complicated and sometimes invokes itself in response to PHP timeouts or to do "threading").
For now, I've just made it a habit to issue
drush cc all
after doing anything critical with Drush.I've not done many installations with existing profiles as features so I can't tell now where this could go wrong.
If you find out more about what happens, I'd be glad to hear it.
Comment #2
tim-e CreditAttribution: tim-e commentedI narrowed this issue down to the fact that when installing via Drush and doing a features_revert, we always got a FALSE return from module_hook for wysiwyg_default_profiles. Specifically in the function_exists condition. It seems that Drush wasnt properly loading the inc files for the feature.
We resolved it by implementing hook_hook_info_alter and adding a group to the hook "wysiwyg_default_profiles". It seems that the Wysiwyg module doesn't implement hook_hook_info so I have attached a patch for it.
Comment #3
tim-e CreditAttribution: tim-e commentedExtra line in that first patch, here's a correct version
Comment #4
tim-e CreditAttribution: tim-e commentedApologies, the last patch I missed a line at the end. Fixing for coding standards. Patch attached.
Comment #5
TwoDUmm, that makes no sense. Wysiwyg does create a hook called
hook_wysiwyg_default_profiles()
, only a callback fromhook_features_api()
namedwysiwyg_default_profiles
.That
hook_hook_info()
implementation would suggest other modules can implementhook_wysiwyg_default_profiles()
by placing their hook implementation functions in $module.features.wysiwyg.inc, again making no sense.Our
wysiwyg_default_profiles()
function is declared in wysiwyg.features.inc, as declared inwysiwyg_features_api()
. If Features doesn't load the file given by the 'file' key before calling the function given by the 'default_hook' key, that's a major bug on their part.Comment #6
jmcoimbra CreditAttribution: jmcoimbra commentedHello.
I am installing a custom profile via drush and I've got this:
I also tried the installation via a browser and the last message before breaking the installation was "Installed Wysiwyg module.", then I get the message in the image attached.
The final result is finding the tables "wysiwyg" and "wysiwyg_user" both empties. And no help for me flushing all caches.
The bad news is that when I comment the line
dependencies[] = wysiwyg
in my profile's .info, it will have no issues.Let me know if you need more tests.
Comment #7
jmcoimbra CreditAttribution: jmcoimbra commentedHello again!
I feel like making a big noise here. My issue is in my own custom profile. I've been studying wysiwyg module and I could not find any issue for its installation.
I agree that features module may have a issue on their part.
Comment #8
TwoDIs your profile complicated with lots of dependencies or could you perhaps attach it here so I can try replicating the exact conditions?
Those SQL errors in user module are a bit worrying, but I'm not sure if/how they are related to this problem.
Comment #9
jmcoimbra CreditAttribution: jmcoimbra commentedIf you don't mind I think it is a good idea to give us your profile, so it can help us understand your issue.
It is complicated to attach my profile here, because we have our own repositories. Basically, we've copied the ideas of Spark and Panopoly.
We don't have modules generated by features being used.
Comment #10
TwoD@tim-e, Can we please have an update on this? How did you arrive at the solution used in your last patch and how does it work?
Is it possible to post your profile here since the one used by jmcoimbra seems too complex to isolate the issue?
EDIT: @jmcoimbra, just to make sure... Does tim-e's patch fix your problem?
Comment #11
jmcoimbra CreditAttribution: jmcoimbra commentedHello.
I didn't use tim-e's patch, so it seems to be an specific fix for his issue.
What I could see is that when something breaks the profile's installation, Wysiwyg will have the state described here.
I've missed a debug, or better Drupal messages when it comes to profiles installation.