Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
While debugging another issue this Undefined index distracted me.
(I've split this issue from #1102620: provision-deploy fails silently on unavailable database )
Undefined index: profiles deploy.provision.inc:84 [1.52 sec, 5.88 MB] [notice]
array_keys() expects parameter 1 to be array, null given deploy.provision.inc:84 [1.52 sec, 5.88 MB] [warning]
In the original issue I've already posted a proposal patch (http://drupal.org/files/issues/provision-check_package_list_0.patch)
anarcat commented that the patch might conflict in situations where there are no site specific packages.
Bottom line is that if we're not 100% sure that the array index $site_packages['profiles'] exists we should test it.
Comment | File | Size | Author |
---|---|---|---|
#6 | provision-1111572-6.patch | 1.55 KB | helmo |
#6 | provision-1111572-6b.patch | 3.54 KB | helmo |
Comments
Comment #1
anarcat CreditAttribution: anarcat commentedas I said over there, this needs to be tested against sites that have no site-specific packages, which i think is a perfectly valid situation that shouldn't abort. please reroll the patch to focus on making sure that we silence the warning. in fact, i wonder why we try to look for profiles in site-specific packages, that's rather weird...
Comment #2
stella CreditAttribution: stella commentedsubscribe
Comment #3
Anonymous (not verified) CreditAttribution: Anonymous commentedI think this is a legacy bit of code from when we used to care about site-specific packages. We made a decision to stop doing that eventually.
I think the code is obsolete because it tries to handle incompatible target platforms. We now handle that directly in the frontend (the package comparison stuff, disabling incompatible platforms from being selected). but we should also give thought to how migrations/clones from the commandline could be possible in future, in provision directly..
Comment #4
helmo CreditAttribution: helmo commentedThanks, for the attention.
I'm a bit confused as to what is the best solution, hope you can come up with an appropriate fix.
Comment #5
anarcat CreditAttribution: anarcat commentedWhat needs to happen here is that a patch gets uploaded in this issue that doesn't crash the verify when there's no site-specific packages. It can just do a warning, that's fine.
Comment #6
helmo CreditAttribution: helmo commentedI've tried refactoring this. The Unfortunately the diff doesn't look pretty since I've wrapped the foreach in an if. I have for that reason first included a partial patch.
But what about #3... could whole piece of code this be safely removed?
Comment #7
anarcat CreditAttribution: anarcat commentedThat's true... maybe we need to just ditch that code. Sorry I missed that part there... That would need thorough testing though.
Comment #8
izmeez CreditAttribution: izmeez commentedsubscribing
Comment #9
Steven Jones CreditAttribution: Steven Jones commentedYeah, so I've always seen this error since using Aegir, and given the errors that occur, this usually means the code has never run for me, I've never noticed anything bad happen. I guess we need to test the case where this code executes and make sure it still works?
Or maybe we should remove the code if it does nothing anyway, as suggested in #3.
Comment #10
crea CreditAttribution: crea commentedSubscribing
Comment #11
jacobson CreditAttribution: jacobson commentedThis bug still exists. I get this error trying to migrate a drupal 7.0 site to drupal 7.4:
Comment #12
3rdLOF CreditAttribution: 3rdLOF commentedI have the identical issue migrating a site from D6 site to D6 platforms.
Comment #13
Yura CreditAttribution: Yura commentedSince upgrading Aegir from 1.1 to 1.2, site specific modules (site/example.com/modules/) has been moved but modules under /sites/all/modules/ directory doesn't. I suppose it has related with this issue!
Comment #14
lukusI'm experiencing the same problem, trying to clone a site from Drupal 7.x.
Comment #15
Steven Jones CreditAttribution: Steven Jones commentedSo, we call
provision_save_site_data()
before we do any of this, which basically means that we wipe out any record of the site specific packages anyway, so in reality we never check them, at all.I'm not sure what the proper fix for this code is, but for now I'm going to commit a fix for the notice we're getting, it just doesn't look good.
So I guess the question is, should we bother checking packages in the backend at all, or should we just remove this code completely?
Comment #16
Lowell CreditAttribution: Lowell commentedsubscribing
same issue migrating one site, my other 9 sites migrated perfectly.
And I am only changing the domain name, leaving db server and platform unchanged
Comment #17
anarcat CreditAttribution: anarcat commentedI support the idea of the backend being dumb and trying to do stupid stuff, while the frontend being there to keep people from shooting themselves in the foot. However, here there's the possibility of the frontend being not up to date when the task is called... Hum...
Comment #18
Anonymous (not verified) CreditAttribution: Anonymous commentedThe method for 'updating' the frontend to reflect changes made in the backend can be done by using 'hosting-import' - I *think* that includes refreshing the package info in the frontend but I'm unsure. But I use this method to automate migrations of sites from backend only, and use hosting-import to update the site node to be 'on' the new platform.
Edit: Actually this may not help the situation here.. maybe just ignore me :)
Comment #19
ergonlogicIs this still an issue on the dev branch (7.x-3.x)?