Drupal 10, the latest version of the open-source digital experience platform with even more features, is here.Webform have a policy of keeping their 'old' update hooks in an include file, and they move the update hooks out on every release:
- #2929226: 8.x-5.0-beta25 release
- http://cgit.drupalcode.org/webform/commit/webform.install?h=8.x-5.0-rc1&...
Although they may have started to move them all out into an include now.
This means that provision can't detect the update hooks, because it's simply trying to statically scan the code and file them, and doesn't find the PHP include statement, and include that file, which is quite understandable!
Not sure how to resolve this keeping the static code scanning, which we do need I think. We could scan for include statements, and try and include those files too, or hardcode a special case for webform module.
Hard.











Comments
Comment #2
helmo CreditAttribution: helmo at Initfour websolutions commentedFor reference the code is in platform/provision_drupal.drush.inc
The only thing we get from that is a schema version number.
Maybe we should make it work with an 'unknown' schema version.... I don't like the idea of parsing include statements.
Comment #3
Steven Jones CreditAttribution: Steven Jones at ComputerMinds commentedHere's an ugly workaround for webform, because we know the location of the include file.
Comment #4
Steven Jones CreditAttribution: Steven Jones at ComputerMinds commentedFully expecting this patch to be rejected, but it does work :)
Comment #5
Jon PughWorth speaking to the Webform developer? I know JRockowitz well...
Wondering what other solutions there might be that we aren't thinking of.
Is this how Drupal core checks itself for updates? Maybe we should include the file to read all functions and the include?
Comment #6
jrockowitz CreditAttribution: jrockowitz as a volunteer and at The Big Blue House commentedI really want to keep all the update code in an include.
Core bootstraps each module's install file and does a loop that uses
function_exists('MODULE_NAME_update_N');Comment #7
helmo CreditAttribution: helmo at Initfour websolutions commentedSteven, I'm glad your patch doesn't just follow just any include statement. Eval'ing the .install file would be even nastier ;)
I can imagine more contrib's having the desire to move these hooks ... Could this name be suggested as a 'standard'?
I looked in the core queue and found https://www.drupal.org/project/drupal/issues/633332#comment-5106756 which seems to suggest that webform should move those hooks to e.g. webform.install.api.php
Either this or we need to make our version comparison work with 'unknown' as I suggested in #2.
Comment #8
jrockowitz CreditAttribution: jrockowitz as a volunteer and at The Big Blue House commentedIf anyone else is moving their update hooks into an include file, they are going to use an 'includes' directory. The solution in #3 makes sense but maybe it should just pull in all the include files.
Comment #9
Steven Jones CreditAttribution: Steven Jones at ComputerMinds commented@jrockowitz do you know if this is becoming a convention?
Comment #10
Jon PughCan't we figure out how Drupal loads this information and just use that?
We can't predict where people might put their code, it would be wrong of us to assume everyone would follow the same patterns.
Let's dig in a little here to figure out what function Drupal itself calls the find this information?
Comment #11
Steven Jones CreditAttribution: Steven Jones at ComputerMinds commentedDrupal does a usual PHP include statement.
But we're scanning for these files over all manner of places, so we'll want to include in a very isolated way.
I'm not sure we can make this work in a nice way really, since people could do whatever they want in .install files.
Comment #12
jrockowitz CreditAttribution: jrockowitz as a volunteer and at The Big Blue House commentedThe Webform module is probably the only D8 module 100+ update hooks and it is possibly the only module using an include in the install file.
Comment #13
Chris MaissanHere was our fix, also a little ugly. Uses a regex to locate any include statements in the install file.
Comment #14
Chris MaissanRegex would need some work. The Advanced Aggregation module has the following line which is picked up.
module_load_include("missing.inc", "advagg");
Comment #15
acThis issue is still a pain, any further suggestions on how we can fix this beyond #13?
Comment #16
Jon PughI added this to the META release node so it will get more attention.
I'm still not sure why we need a special function for this. Doesn't drupal core have a way to load these version functions?
Comment #17
Jon PughSee #3007818: [meta] Aegir 3.17 release (bugfix/patches)
Comment #18
millenniumtreeWe've been actively delaying upgrading aegir because I have to take additional steps to re-patch every server.
I don't see a problem with patch #3.
The patch doesn't appear to do any harm, and it solves the most common problem (webform) immediately. No need to wait for webform to change anything, and certainly no need to predict the future of update hook includes for contrib modules. Solve the problem first, and if someone cares to find the 'right' way later, they can submit another patch.
Without the patch, most of the dozens of sites we manage cannot be migrated, and that's a show-stopper.
I vote to get #3 in the next release.
Comment #19
memtkmcc CreditAttribution: memtkmcc at Omega8.cc commentedWe have included both suggested patches in the Provision version used in BOA already.
Comment #20
sean.walker CreditAttribution: sean.walker as a volunteer commentedI was at a blocker migrating sites this morning (even if the webform versions on both platforms were identical), there would still be an error in Aegir when examining platforms because it couldn't display the correct update hook. The patch (#3) got me through for now and I can keep upgrading sites. Thanks for the patch Steven Jones, it was exactly what I was hoping to find. It just adds a few lines as an additional check, so I don't see how this is a bad thing ultimately. I now can migrate all I want, so thank you! :)
Comment #21
Chris MaissanPatch 13 stopped working with Webforms 8.x-5.2. The attached has an improved regex.
Comment #22
acPatch is good.
Comment #23
moss.dev CreditAttribution: moss.dev as a volunteer commentedTested patch #21 against latest provision release successfully.
Comment #24
Chris MaissanUses realpath instead of sprintf to combine path segments.
Comment #25
acCreating a lot of warnings on platform verify:
Comment #26
Chris MaissanTry patch 24.
Comment #27
acGah, sorry. Latest patch works.
Comment #28
npacker CreditAttribution: npacker commentedPatch 24 looks good.
Comment #30
colanThanks!