Trying to install the Database Search Defaults module results in WSOD.
With WebProfiler installed it seen that it is TypeError - HTTP 500 Internal Server Error.
Drupal\Component\Utility\Html::escape(): Argument #1 ($text) must be of type string, null given, called in /var/www/html/web/core/lib/Drupal/Component/Render/FormattableMarkup.php on line 238
Install Drupal CMS
Goto the Extend UI and try to install it, by selecting it and click install.
The WSOD is related to the absence of the Comment module which it depends on.
If the Comment module is installed before hand the error doesn't occur.
The module also depends on the non-existent Article type which was probably present in earlier versions of Drupal
If it depends on a specific Article type then that specific Article type should be installed by default, or it should depend on a module that creates that Article type.
The Basic page article type seems too spartan in any case.
The resolution is to track down why a WSOD is triggered if the Comment module is not enabled and fix it, and also to install the Article type by default.
Comments
Comment #2
penyaskitoThere's no recipe where we install the module
search_api_db_defaultsdirectly, so I guess we can't do nothing about it.This is something that should be fixed in
search_api. I've found #3009624: Can not install "Database Search Defaults" because the field comment is missing.You mentioned that you had to install the
commentmodule, but I can see they have the dependency already?Comment #7
vfclists commentedAlthough the
commentmodule is listed as a dependency of Database Search Defaults the WSOD occurs if it is not installed beforehand. It needs to be installed if the WSOD is not to occur.The module also requires an Article content type to be present before it works in any case, so its inclusion in Drupal CMS is questionable.
The point here is Drupal CMS is supposed to be a curated set of modules which are expected to work together without causing WSODs.
If Search API is something added to the Drupal CMS distribution rather than something which comes with core, then the Database Search Defaults should be disabled if it is automatically pulled in by the Search API until it is fixed upstream.
Comment #8
phenaproximaThis is true, but we can't account for every possible combination of every possible module that other modules depend on (or include as submodules). We have no control over that, nor would it be feasible for us to maintain Drupal CMS that way.
What we do have control over, and what we do stand behind, is that the modules we install as part of our recipes -- "install" meaning it's actually activated in Drupal, rather just sitting inert in the codebase -- should work together without WSODs. If we find a bug caused by the interaction of modules we actually install in our recipes, then we are responsible for fixing that. That's what @penyaskito alluded to in his comment.
So if we are not enabling Search API DB Defaults, despite it being shipped with Search API (which, again, we cannot control) -- and there's a bug in its interaction with some other module, that would make it squarely Search API's responsibility to fix.
Comment #9
phenaproximaAs @penyaskito and I have clarified, Drupal CMS is not, as a matter of practicality, responsible for guaranteeing that every conceivable module pair works properly. We can only stand behind what we proactively enable at install time (and what our recipes actually do).
This would need to reproduced, and fixed, in Search API. I'm moving this issue over there.
Comment #10
mrogers commentedPutting a notice of system requirements in the sub module's readme would go a long way.