On D8.9-beta2 and PHP 7.4, scanning of modules results in errors like this:
Server error: `POST http://website.test/admin/reports/upgrade-status/analyze/module/admin_to...` resulted in a `500 500 Service unavailable (with message)`
In case it's related, Drush updatedb throws the following error:
TypeError: Argument 1 passed to Drupal\upgrade_status\ThemeFunctionDeprecationAnalyzer::__construct() must be an instance of Drupal\Core\DependencyInjection\Container, instance of Drupal\Core\DependencyInjection\ContainerBuilder given in Drupal\upgrade_status\ThemeFunctionDeprecationAnalyzer->__construct() (line 39 of /var/www/drupalvm/drupal/web/modules/contrib/upgrade_status/src/ThemeFunctionDeprecationAnalyzer.php) #0 [internal function]: Drupal\upgrade_status\ThemeFunctionDeprecationAnalyzer->__construct(Object(Drupal\Core\DependencyInjection\ContainerBuilder))
| Comment | File | Size | Author |
|---|---|---|---|
| #14 | 3126600-14.patch | 6.22 KB | gábor hojtsy |
| #7 | 3126600-7.patch | 2.84 KB | gábor hojtsy |
| #2 | 3126600.patch | 1.41 KB | gábor hojtsy |
Comments
Comment #2
gábor hojtsySo this is how we define the
ThemeFunctionDeprecationAnalyzerinupgrade_status.services.ymlDon't know when would the service container be different base classes, but either way best practice would be to typehint on the interface we need. Let's try this. Can you test with this?
Comment #3
extect commentedThank you!! This successfully fixes the issue with ThemeFunctionDeprecationAnalyzer.
The scanning exception with an error 500 on every test still exists though.
Comment #4
gábor hojtsyAny other error in your logs? Can you isolate the error to scanning a specific module or happens with all modules?
Comment #5
extect commentedThe error occurs no matter which module I try to scan.
Two entries in the log:
a) PHP-Error @ http://website.test/admin/reports/upgrade-status/analyze/module/admin_to...
Symfony\Component\Routing\Exception\MethodNotAllowedException: in Drupal\Core\Routing\MethodFilter->filter() (line 46 of /var/www/drupalvm/drupal/web/core/lib/Drupal/Core/Routing/MethodFilter.php).
b) Notice @ http://website.test/admin/reports/upgrade-status:
Processing projects without HTTP sandboxing because the built-in PHP webserver does not allow for that.
Comment #6
gábor hojtsyThanks, I will commit the above fix in #3126770: Argument 1 passed to ThemeFunctionDeprecationAnalyzer::__construct() must be an instance of Container and credit you there, so we can continue resolving your actual 500 error. Moving this back to Active for that.
Comment #7
gábor hojtsyNow that I committed that, I went to see what happens to route processing in case PHP built-in webservers, because that should not happen. Noticed that in that case we are still trying to do the HTTP request anyway. While we catch any exception, we should not even try to do that as we already decided at that point that we should not do it. Not sure this will fix anything for you yet, but you should get a distinct log message now about which method is being used (as in which of the three cases do you fall into). Looks like the PHP webserver notice was printed for all cases, which is a problem. It does not help us debug issues if it is printed even for non PHP webserver case. Duh.
This is the kind of thing that cannot be automatically tested much at least in our test setup.
On top of testing feedback for this patch, I would be really interested in any other data about your Symfony filter error. Paths like
http://website.test/admin/reports/upgrade-status/analyze/module/admin_toolbaronly allow POST requests (seeupgrade_status.routing.yml). Did you try to manually invoke that path? Normally it is accessed fromUpgradeStatusForm::parseProject()via a POST HTTP request.Comment #9
gábor hojtsyCommitted #7 even though that will not resolve your problem, but it eliminates one confusing bug on the way. Now awaiting answers to questions in #7 :)
Comment #10
extect commentedThanks for you help!! I applied patch from #7. Not getting any different/additional error messages though. When I try to manually access
http://website.test/admin/reports/upgrade-status/analyze/module/admin_toolbar, I at least get some more backtrace information:Hope that helps?
Comment #11
extect commentedComment #12
gábor hojtsyWell it is not meant to be accessible with the GET method (see the routing.yml) so this error is expected when manually loading it. But upgrade status requests it as a POST request. And that method is allowed on it.
Comment #13
extect commentedMakes sense. However, it throws the very same error when I try to trigger a scan for any of my module via the admin interface without manually accessing the URL.
Comment #14
gábor hojtsySlept on this and had a thought. We can use the same admin endpoint to test the HTTP request capability that will eventually be used, which way we also test the whole session pass-through, etc. If that works, there must be a high likeliness that the eventual HTTP sandboxing will work. If that does not work, then it makes most sense to fall back on not using that sandbox and going with the potential consequences of the inline parser.
Here is the patch for that. This may also be a suitable workaround at least for #3127210: Scanning contributed projects fails with a cURL error when scanning through the UI over HTTP and #3126997: 403 error because Upgrade Status does not send proper authentication to https URL.
Comment #15
extect commentedExcellent!! Thank you! That got it working for most of the modules (like admin_toolbar). There are a few exceptions though (like advagg or honeypot module), where scanning throws the error below:
Comment #16
gábor hojtsyThat new notice and UnexpectedValueException is because of #3126949-14: Missing requirement in composer.json should not generate a warning, attempting to fix it there now. Thanks for testing.
Comment #17
gábor hojtsyComment #19
gábor hojtsyOk based on your feedback I committed the above two issues. This should resolve your problems in my understanding by avoiding HTTP sandboxing at least when it would fail.