Fresh install on WAMP 2.5, openatrium-7.x-2.26-core.zip. During installation received a group of 34 warnings:
• Warning in features rebuild of oa_permissions. No module defines permission "administer panelizer node oa_group content".
• Warning in features rebuild of oa_permissions. No module defines permission "administer panelizer node oa_group context".
• Warning in features rebuild of oa_permissions. No module defines permission "administer panelizer node oa_group defaults".
• Warning in features rebuild of oa_permissions. No module defines permission "administer panelizer node oa_group layout".
• Warning in features rebuild of oa_permissions. No module defines permission "administer panelizer node oa_group overview".
• Warning in features rebuild of oa_permissions. No module defines permission "administer panelizer node oa_group settings".
Then 15 Warnings:
• Warning: file_put_contents(temporary://fil8210.tmp): failed to open stream: "DrupalTemporaryStreamWrapper::stream_open" call failed in file_unmanaged_save_data() (line 1936 of D:\wamp\www\dps\includes\file.inc).
• The file could not be created.
• Warning: file_put_contents(temporary://fil8220.tmp): failed to open stream: "DrupalTemporaryStreamWrapper::stream_open" call failed in file_unmanaged_save_data() (line 1936 of D:\wamp\www\dps\includes\file.inc).
Previously, the Open Atrium will just work fine, I could continue accessing OA2 (7.x-2.22), but now, all I see is half a page of blank followed by: please see attached image.
What am I doing wrong?
Comment | File | Size | Author |
---|---|---|---|
OA2-226.jpg | 155.47 KB | cheng.wu@gnb.ca |
Comments
Comment #1
mpotter CreditAttribution: mpotter commentedThose permission warnings have already been fixed in 7.30-rc1.
For the file warnings, be sure to read about installing Drupal on Windows servers to set the permissions correctly for your various directories.
Comment #2
cheng.wu@gnb.ca CreditAttribution: cheng.wu@gnb.ca commentedThank you, Mike, I followed your advice and check the permissions and have it resolved.
Comment #3
omega8cc CreditAttribution: omega8cc commentedThis still happens with 2.30-rc3:
https://gist.github.com/omega8cc/aff17370c249eaa854df
Maybe a regression?
[EDIT] We are experiencing this with non-interactive install, using Drush 7 on Aegir
Comment #4
mpotter CreditAttribution: mpotter commentedTry the -dev version of the open atrium drupal-org-core.make file that includes a patch to the order Drupal does stuff during the install.
Also, our "fix" for this was adding an install_task to rebuild permissions. The cause of the warning is related to caching and batching during the install. It is fixed in the Quick Install option for OA2. Maybe the Aegir system isn't running the install task or isn't using the quick install.
Finally, please check your permissions after install and see if the OG Permissions are set correctly (Admins can do most anything, Members can add content of various types). In the past this error was fixed because the warnings actually prevented permissions from getting set. If in the 2.30 version you are getting the warnings but the permissions are still set properly then I'd consider it a minor issue.
Unfortunately, we don't use Aegir so my ability to debug or help with this is limited.
Comment #5
omega8cc CreditAttribution: omega8cc commentedOK, thank you for this information, we will test the dev version then.
On a side note, Open Atrium was probably the first professionally developed and maintained Drupal distro supported by Aegir, because both were under the same DevSeed team umbrella. Things changed a lot in the meantime, but Open Atrium is still included by default in every Aegir installation maintained as a part of our BOA stack, and there are already 500+ known hosts using it to power thousands of Drupal sites, including those based on Open Atrium. It is a big community and valued developers audience worth considering when testing/releasing new OA versions.
We have made it crazily simple to install and test, if needed: https://gist.github.com/omega8cc/2624110
Thank you for your great work on next OA versions!
Comment #6
mpotter CreditAttribution: mpotter commentedA bit off topic, but I've never really understood then the differences with Aegir and why it always seems to have issues that don't come up when doing normal Drupal installs. As a Drupal distro we have to first support normal Drupal installs and how drupal.org works. Then we added Quick Install so people could do the install in 2 minutes instead of 20 min. Then we try to support Pantheon with it's infrastructure. At the end of the day, time and resources are extremely limited and we can't test on everything. It would be nice to fix whatever Aegir is doing differently from Drupal's normal install that causes issues.
Or, ideally, since this is an open source distribution and others can contribute, it would be nice to get an Aegir champion who has the time and desire to help fix issues and post patches.
Comment #7
omega8cc CreditAttribution: omega8cc commentedAegir doesn't do anything on its own. It is just a wrapper/extension around Drush, so it is not really about anything Aegir specific but very generic Drush based install, which should be supported by every professional Drupal distro, in my opinion. Aegir and BOA simply make testing Drush based installs fast and easy, and we have made it extremely easy, plus, we test new distros releases and submit patches for many distros for years. But at some point we have decided to stop fixing distros to make them work with Drush and thus Aegir. It is distro's maintainer responsibility and area of expertise, and with increasing complexity it is no longer reasonable to expect that we will continue to work on making all distros we support Drush and thus Aegir compatible. We do will continue to debug and report issues, but proposing patches may not be possible, since we can't learn everything about every distro we provide in BOA, of course.
Comment #8
mpotter CreditAttribution: mpotter commentedWell yes, in theory that is all true. So why is it that Aegir installs give different errors and problems that cannot be reproduced in a normal Drupal install? *something* has to be different. This isn't the first time, and it's not just with Open Atrium, but I've seen it in the past in other distros. Other than adding the Quick Install option, the normal Drupal install process in OA2 isn't anything weird or custom. Just seems that Drupal installs are very fragile and when you get a lot of modules, the exact order that the install batching happens can be a problem.
We have automated build testing here too. We run drush site-install nightly for both a full standard drupal install, a quick install, and an upgrade of an existing site. All using regular drush commands. And those also work fine.
In the above case, the warnings for the permissions only happened some of the time, and only on Pantheon. Never got them on local installs, even in 2.26. We had to debug this issue on Pantheon and ended up just adding a post-install task to rebuild permissions since it was nearly impossible to debug why it was happening.
In the -dev version (as I mentioned above) we are actually using a patch to Drupal's install that moves the registry stuff that seems to make installs more stable and less timing and batch dependent, so that's why I'm curious how it might work on Aegir. But that's the first patch to Drupal's install system we've done.
In any case, back to the OP, give the -dev version a try and report back. Would be really interested to know what the Drupal core install patch does to Aegir.
Comment #9
omega8cc CreditAttribution: omega8cc commentedI have just tried it again with 1311820-drupal-registry_update-13.patch applied and it didn't made any difference :/ Still the same warnings. We will try to debug this further and report back.
Comment #10
omega8cc CreditAttribution: omega8cc commentedAs a side note, it could be also Drush version related - we are using Drush 7 already.
Comment #11
mpotter CreditAttribution: mpotter commentedAhh, that might be it.
You see, we are forced to use Drupal 5 because that's the version used on drupal.org to package distributions!
Last time I chatted with the drupal.org guys over a year ago they couldn't update to Drush 6 until the site was on Drupal 7. Since drupal.org updated to Drupal 7 I haven't heard why that haven't updated. Maybe they are concerned about compatibility since Drush 6 parses make files in the reverse order from Drush 5 (something else we've had to deal with).
I'd say if Aegir wants to do "standard Drupal installs" it should probably use the same version of Drush that the drupal.org packager requires. Or maybe a way you can specify which version to run on which distro?
Comment #12
omega8cc CreditAttribution: omega8cc commentedOuch, that could be the culprit, but we can't use Drush 5 for a long time already, and since recently we have introduced Drupal 8 support, we just can't use anything older than Drush 7, so we are effectively comparing apples and oranges here :/
Also, we can't run separate Drush versions per distro, because differences in Drush API force us to make changes also in the Aegir backend, so it is not possible to swap versions on the fly.
Comment #13
druplicate CreditAttribution: druplicate commentedI got this error on rc3 fresh install with Drush 5.3.
Didn't try the patch.
Comment #14
mpotter CreditAttribution: mpotter commenteddruplicate: are you saying you got the error in rc3 with Aegir or with a plain Drupal install? And please definitely use the patch that is in the -dev.
Comment #15
druplicate CreditAttribution: druplicate commentedSorry, that was without Aegir.
Just a plain fresh install on Virtualbox with Ubuntu 12.04, though eventually it will likely be hosted at Omega8.
I'll try the dev version soon.Applied patch: 1311820-drupal-registry_update-13.patch and the install was clean - no warnings.
Comment #16
mpotter CreditAttribution: mpotter commentedOK, marking this as fixed with the patch in -dev. Reopen this if the patch isn't working or if this occurs after the 2.30 stable release.
Comment #17
Argus CreditAttribution: Argus commented^^
Comment #19
populist CreditAttribution: populist commentedI am re-opening this issue as per #16 because I am still seeing these warnings with OA 7.33 running on Pantheon (https://i.embed.ly/1/image?url=http%3A%2F%2Fcontent.screencast.com%2Fuse...).
This might be a Panelizer issue specifically, but figured I would throw it out there for the OA masses.
Comment #20
mpotter CreditAttribution: mpotter commentedHi Matt, can you run a couple of tests to see if this happens all the time or if it's a timing issue. This one has plagued us for a while and I could never reproduce it consistently, and never in any local installs. It always seemed to happen more on Pantheon, but again, not all the time. Makes it a bit of a pain to debug. So any help from the Pantheon side would be greatly appreciated.
Those specific warning messages are generated when a module gets enabled before the permissions are defined. The permissions come in via Features as part of the module. But some kind of caching prevents Drupal from "seeing" the permissions that were already created. So perhaps the way caching works on Pantheon during Drupal installs is different?
Comment #21
DenisVSI use drush to install OA.
Site not work. In main page errors:
Install via browser gives same result.
Comment #22
mpotter CreditAttribution: mpotter commented@DenisVS: Please mention what version you are installing. This was an old issue that was re-opened. I'm tempted to close this issue and let people re-open it with the specific version they are using.
Also, the "MySQL server has gone away" message means your my.cnf MySql configuration is wrong and does not have the settings described in the System Requirements for Open Atrium (namely the max_allowed_packets). Search drupal.org for "MySQL server has gone away" and you will find a lot of topics.
TO BE CLEAR:
This topic has been re-opened ONLY for people using Pantheon Hosting who are getting the spam of "No module defines permission" warnings in the 2.33 release. ANY other install issues need to go to different issue threads. We need to keep this issue clean to help debug this issue.
Comment #23
mpotter CreditAttribution: mpotter commentedComment #24
DenisVSmpotter
I'm test from 7.x-2.26 to 7.x-2.40-rc1, and all versions are given an error.
As for the problem of MySQL connect, with original Drupal installation all works perfectly. Error appear only with OA pack.
Comment #25
mpotter CreditAttribution: mpotter commented@Denisvs: See the System Requirements for Open Atrium on the main project page. They are different from "original Drupal installation". Open Atrium requires more memory and DB resources. Please create a separate issue for your problem if you still get errors after solving the "MySql Server has gone away". That isn't what this thread is about and until you solve those errors everything else doesnt matter.
Comment #26
GuillaumeDuveauStill there on 7.x-2.41
Comment #27
mpotter CreditAttribution: mpotter commented@guix: I assume you are talking about when installing on Pantheon?
Comment #28
GuillaumeDuveau@mpotter: No, I downloaded 7.x-2.41 and installed it on my local VM environment (Ubuntu Trusty 64) customized to meet the OA2 doc :
Anyways, it's "just" a warning and everything seems fine after it, just to let you guys know.
Comment #29
mpotter CreditAttribution: mpotter commented@guix: Was this using the Quick Install?
Would love to figure out what causes this and if it's completely reproduceable. I can't get this to happen on any of our test servers, including Ubuntu, CentOS or my local Macbook via MAMP. But #19 implies Pantheon has this issue also.
It's clearly something different with the hosting configuration somewhere. But since I can't reproduce it this will require help from somebody that sees the issue and knows enough to tweak their MySql or PHP config until it goes away.
Since the quick install is just doing a series of DB imports, I'm guessing it's a MySQL cnf difference, maybe with caching or something.
Anybody game to mess around with this one?
(P.S. Even though everything seems fine, you might want to go into your Drupal permissions and OG permissions to ensure people have the correct permissions. In the past with this spam of warnings it actually did cause a problem)
Comment #30
GuillaumeDuveau@mpotter: Yes, Quick Install. Thank you for the tip in your P.S. !
Comment #31
GuillaumeDuveauComment #32
GuillaumeDuveauedit : deleting a different error message which is related to another issue
Comment #33
mpotter CreditAttribution: mpotter commentedPlease ONLY post to this thread with information about the "No module defined permission..." errors (See #22). For ANY OTHER error please open a new issue. The errors in #32 are completely unrelated to this issue and likely related to some other problem on your server. Will be forced to close this issue if it continue to go off topic.
Comment #34
GuillaumeDuveau@mpotter : sorry for the last report, I edited it.
I tried a new quick install with the same server config (PHP : max_execution_time=60) and this time the install failed because the 60 seconds were reached.
So I tried a new quick install with max_execution_time=300. This time I didn't get the warning message reported in this issue (Warning in features rebuild of oa_permissions. No module defines permission "administer panelizer node oa_team settings").
So for this issue, it could be that max_execution_time should be above 60 sec. The necessary minimum PHP execution time might differ from a server to another (performance varies) so it's difficult to define one. Maybe the best is to advise in the documentation to temporarly increase the PHP exec time during the install, in case of such problems.
Comment #35
hefox CreditAttribution: hefox at Phase2 commentedtry out #1549608: Cannot import exported Panelizer permissions using Features/defaultconfig if handler cache is stale, which has been added to dev of OA but probably can get it applied to whatever version you'll are using
Comment #36
hefox CreditAttribution: hefox at Phase2 commentedComment #37
JohanFeuillet CreditAttribution: JohanFeuillet commentedmy experience having those messages is :
fresh new install with OA 2.42 :
the messages appear if i add some modules in /sites/all/modules
the messages disappear if i remove those modules
Thanks for bringing us OpenAtrium.
Comment #38
mpotter CreditAttribution: mpotter commentedConfirmed that this is still happening with 2.42 on Pantheon.
Comment #39
hefox CreditAttribution: hefox at Phase2 commented:'(
Comment #40
hefox CreditAttribution: hefox at Phase2 commentedI've managed to reproduce this once and then had 3 warnings less installs.... so... Uh...
WTF Pantheon?
edit: Going to wait a day to see if can reproduce it after the site's been sitting a while. Also opened a support ticket with pantheon.
Comment #42
hefox CreditAttribution: hefox at Phase2 commentedhopefullly...