I don't have Windows to check, all I know is that when I installed ddev on my local (Ubuntu) I was able to use Project Browser to install modules through the GUI. My point is people will get used to that -> they'll want to do it on the server too -> they'll change the permissions on the server to be unsafe -> they'll get hacked -> Drupal will get a bad reputation.
For devs, I'm sure ddev works OK. Other groups need a less problematic alternative. As I've stated, the first time I tried to install it, it failed. That's on Ubuntu, so it should have worked out of the box. And, no I didn't file an issue. I have no interest in using it because what I use now (LAMP) works fine and there's no benefit to me in replacing it with ddev or learning to use ddev.
And, Drupal should not be like WP. Drupal should be the more secure, more advanced alternative. It just needs to offer something for those who aren't hardcore devs: a dentist who likes tinkering with things, a plumber who knows a little code, etc.
What I said on that issue still applies. I also started a thread in the security channel in Drupal Slack. The bigwigs are like "Hang on a minute lads, I've got a great idea" on loop.
There are two main problems IMNSHO:
- it's yet another hurdle for newbies to overcome. Like I said, I tried to install it and it didn't work the first time. I didn't spend any time on it but considering I'm running Ubuntu locally, that's not a good sign. I can only imagine what things are like on Windows. XAMPP/MAMP are self-contained and fairly easy to set up. Drupal is presented as something with a laundry list of things to install. See posts like https://www.reddit.com/r/drupal/comments/1iln0vb/things_get_more_complic... and there's some advice here: https://www.reddit.com/r/drupal/comments/18gw05x/is_drupal_docker_compos... Then, go hang out in WordPress forums for a bit. Do you think most of them have the technical expertise to do what Acquia et al expects everyone to do? Given all of the bad decisions made by the Drupal bigwigs, I don't think they're the ones to fix the problems they created.
- it encourages bad habits, like the web server writing to code directories. Newbies will get used to that and then want the same thing on the server, exposing themselves to being hacked.
Both work for me. It might be your version of composer, your shell, or maybe they're smart quotes or backticks.
The first time I tried to install ddev it failed. When I tried again using the one-click CMS installer, it - surprisingly - worked. I have scripts to switch between PHP versions. I don't do that often so it isn't an issue. I really don't need or want ddev, regular ol' LAMP is sufficient.
One reason not to like ddev is the file permissions aren't realistic. It lets the webserver modify code directories. Which is fine on local machines, but on the server that's a huge security risk. Unfortunately, Acquia et al seem to think that's OK (see Project Browser).
If you manually created them and you can't delete them, that probably means something else depends on them. Look up how to export a single config file (through the UI or drush) and post one of the affected menus here.
I have dozens of all kinds of local sites (Drupal, WP, TypeScript, etc) running on Ubuntu + Apache2 + MySQL. (I'm not running Windows, Ubuntu is the OS).
Also, your stack trace *looks* more like a resources issue, although that could indicate some other problem.
The menu items might be coming from a module. I know you can delete items you've created manually, but I don't know if you can do that with ones that are part of config.
What are you trying to do?
Also, you shouldn't be on Drupal 9. Are you also having problems upgrading?
The first link would create an insecure installation, see this reply from that link: https://drupal.stackexchange.com/a/315089
I haven't used CiviCRM for a long time and I'm not keen on installing it. There's a channel for it in Drupal slack but it's barely used. Do they have their own forums?
Why not just switch DNS to the new server? Alternatively, you or your host change the IP the new server listens on to the old server's IP.
Why can't you target the images using the existing CSS classes? Give an example of the HTML, including the containers it's in.
What have you tried so far? I assume you want users to create their own maps, draw on the maps, etc. I'd start by looking at the APIs for various mapping programs, since this isn't really a Drupal-specific question.
I believe the devel module has or had a devel themer module that shows the names. Or, if you can code, add some debug code to find out the names it's looking for.
There's a ton of tooltip libraries available and some have projects here. I don't know if they have a modal option, but you probably don't need that.
For the first, you need to find your php.ini file and set or change the value of session.gc_divisor as it says. You might need root access or to contact your host.
I created this for the second, you can test out the MR:
https://www.drupal.org/project/yoast_seo/issues/3526356 💬 yoast_seo_entity_field_access vs PHP8.4: "explicit nullable type must be used instead" Active
I didn't test whether that works so that's up to you.
I also offer paid support if there are other issues.
tolstoydotcom → created an issue.
Those who've worked with smaller clients will realize what will happen: they'll take the risk. Then, some will get hacked. Then, Drupal will get a bad reputation about being insecure.
There are still lots of sites running D7/8/9, including major sites like large universities and government sites. There are countless thousands of sites running vulnerable versions of WordPress. They're taking a risk or they don't know any better.
Drupal should make it as easy as possible to be as secure as possible. That's a strong selling point. Drupal should not make it easy for people to create insecure environments.
Letting a public web server write to code directories is a huge security risk. It's a hacker's dream. On local environments it's not an issue.
The idea that everyone is going to have a git workflow with a dev site and a developer running ddev on a local machine is a fantasy. If the idea is to appeal to people who aren't going to use the command line, then the only safe alternative is something like https://www.drupal.org/project/sheephole_helper → Since it's open source, what's the objection to using that instead of encouraging an unsafe server environment?
ddev causes problems, you might want to try a plain LAMP stack.
You need to give the correct permissions to the files directory so the web server can create what it needs to. Follow this:
https://www.drupal.org/docs/administering-a-drupal-site/security-in-drup... →
First, I'd suggest you start with an idea for a site. E.g., a site with travel photos. Try to set it up on your own and if you get stuck ask here.
If you want to write code, see the Examples module. And, Daniel Sipos has physical or online books available from Amazon. Choose the latest version.
Bear in mind that some of the Drupal info you'll get online is for D7. While the basic concepts transfer to newer versions, the code might be different.
If you can't figure it out and you have a test site with SSH access or a zip of the full site and the db (sans personally identifiable information), I can take a look for a reasonable fee.
As long as this is just for logged-in users, putting their roles in the DOM seems to be analogous to putting any other user-specific info in the DOM.
However, a site might have a 'shadowbanned' role, and admins might be too cowardly to reveal that to the user. On the justifiable front, a site might have security levels and wouldn't want to reveal to a user which level they're on.
In the specific case of what you have now, did you clear cache? Can the web server read the directory/files? Start with an info.yml file from another module and modify it, your YML might be wrong.
Have you printed out what's in the arrays at steps 6, 5, and 4? I'd imagine somewhere it's using a wrong key, like 'Subject' for 'subject'.
Do you have a stack trace showing what called the minLength method? Look there to see what subject is.
Also, you have '$email_address' above.
I tried her command line and query and they worked. Maybe a copy/paste issue, or something about charset mismatches? Note that the password will be newpasswd.
Deleted fields are or at least were purged at cron. Run that, run update.php, and clear cache. Then, repeat for good measure. The fields should be gone, unless something uses them.
Thankfully, Drupal has tighter standards than WP. Or, at least it should have them.
On a local installation, go hog wild.
However, if you give the web server permission to write to code directories on a publicly-accessible site, it's only a matter of time before you get a nasty surprise from some script kiddie constantly looking for vulnerabilities.
I posted a couple of ideas to the CMS queue a while back. One was to work with cPanel on a way to install & update Drupal, the other was improving the permissions page. Both were shot down unilaterally by someone from Lullabot. I moved the permissions issue here but I'm stuck on getting the tests to pass:
https://www.drupal.org/project/drupal/issues/3495351 ✨ Make the user permissions page less daunting for new users Active
I had a request for the Project Browser project that they let their JS be extensible just like most other Drupal JS is. That too was shot down unilaterally, this time by someone from Acquia.
I don't need a weatherman...
The first time I tried to install ddev it didn't work either, and that's on Ubuntu. The second time I used the script that comes with Drupal CMS and it worked, but I'm not really impressed.
What I prefer is a regular LAMP stack: Linux + Apache2 + PHP + MySQL.
Apparently you can set that up on Windows by installing WSL2. Get Ubuntu 22 or 24, then look up Digital Ocean or similar instructions on how to install LAMP on it. Unless you're constantly switching PHP versions you'll probably like that better.
Maybe AI could give you a better migration, or you can ask on the #migration channel in Drupal Slack (they should be using these forums instead of Slack, but that's a separate issue). Or, I can do it for a reasonable fee.
Creating JSON by hand is problematic, it'd be better to use a built-in method for that (json_encode etc).
If it's not a JSON issue, print_r($myEntity->toArray()) and then mimic what your field looks like in the data you're sending.
IIRC there's an issue or a module that brings back the "key|label" textarea.
What I've found (YMMV) is that "fix it in post" is a lot better than trying to make a migration perfect. I.e., pre-process your data to make the migration YML simpler. Then, if anything didn't transfer over, write some code to fill it in.
In your case that means using the map table the migration created that maps the old entity ID to the new entity ID. For each of those, use the old entity ID to look up the field in the old system, then write it to the entity in the new system using the new entity ID.
You left two messages, you might want to delete the other one.
Their API looks straightforward: https://developer.chase.com/products/aggregation-fdx/specification/
The authentication/fraud prevention side of things might not be so straightforward, but if you can't find such a module (maybe through Drupal Commerce) you can probably find someone (such as yours truly) to write it for you if you have a budget.
I'm having this same issue with the 8.x-1.0-beta12 version of this module and the 4.3.4 version of VBO on D10. The view is a table with a VBO column.
I just looked at the HTML with and without the VBO column and both put a form inside divs with the 'views-content' and 'views-form' classes. So, I assume they're both trying to do the same thing and only one is winning. I haven't tried it but maybe increasing the weight of this module might work as a quick fix. In my case removing the VBO column isn't a problem.
That's just 18 gigs. I have a $10 VPS that has 40 gigs of space. Note that Drupal isn't going to store the files in the db, it's just going to store the paths to where they are on disk. When uploading the files Drupal will move them using built-in PHP functions that have limits (like upload_max_filesize) so you'll need to set those in php.ini. You'll also need to tell the field to accept files up to your max size. If these are private files, Drupal will deliver them to the user, but if they're public that will be handled by the web server. I'm not seeing much of an issue here.
I don't know anything about Sharepoint, but I'd imagine it has an API, or maybe some sort of an export that includes the files and some meta info.
You need to provide examples. If at one point a module worked with both D8 and D9, but they've since removed D8, then you need to upgrade to the earlier version. Then, after upgrading core to D9, upgrade that module to the latest version that uses D9.
A module is either listed on this site, or is custom. If it's listed on this site and it doesn't have a D9 version, then look in the issues queue to see if there's a patch. If it's custom, you can try to increase the version and see if it still works: https://www.drupal.org/docs/develop/creating-modules/let-drupal-know-abo... →
Unless there's some reason why you're using Paragraphs, I'd suggest using https://www.drupal.org/project/address → instead (118k installs). It's not perfect but it's better than making your own.
As for the page, there might be a module that breaks out fields onto a separate editing page, but if not I'd create a custom module to do that. If you need help with that feel free to reach out.
There shouldn't be any problems. 6k really isn't that much, as long as you've got the space for it. You could offload it to S3 or similar if you wanted. If you save them on the server it might be a good idea to store them in subdirectories based on the first initial of the name or date or something.
I'd suggest trying it using fake documents and then seeing if there are any issues.
I really don't know what they're thinking, but when PHP can write to code directories that's an unsafe configuration that hackers can use to take over your site.
One safe way to do this is to log in using SSH and run composer commands as the user who owns the files, not as the web server user.
Discuss this with your hosting company.
tolstoydotcom → created an issue.
tolstoydotcom → created an issue.
It's offered because it works when you use ddev and with ddev permissions are different. Those pulling the strings on PB/CMS seem to support unsafe installations where the web server can write to code directories. In such installations, a hacker could find a bug in Drupal core or a contrib module/theme and exploit it so they could upload a PHP file of their choosing to your server. Then, they could take over your site. And, they might do that in subtle ways that it takes you some time to notice.
If you have SSH, you can run composer commands on the server instead.
Or, if you have SSH and you have Java 17 installed on your local machine, then you can help test out my alternative: https://github.com/TolstoyDotCom/sheephole
Otherwise, I guess the safe way would be to do your work on your local machine, and then after making changes to the files, replace them on the server. You just need to make sure not to replace the sites/default or similar directory.
I'm using 10.4.6 and I have the same problem. I'm trying several themes and I did composer require 'drupal/artisan:^2.0@alpha'. On admin/appearance it says the serialization module was required so I enabled that using drush and then reloaded the page and set the theme as default. When I loaded a webform I got the error message above.
I didn't follow the README instructions, I was just trying a bunch of themes. So you may or may not consider this an issue. However, composer issues are bad enough, npm and similar are far worse. So, while I'd like to check out the theme I think I'll find something else.
I'd personally skip ddev and just install a LAMP stack locally. That works well as long as you don't need to constantly switch PHP versions and it more closely mimics what you'd get on a server. I'd suggest doing that and just run (AFAIK) composer create-project drupal/cms to set it up.
Then, duplicate that on your server and ask your host to switch to serving out of web. If they won't do that, find another host. If you can't do that, can you set up a VPS? If not, maybe this will work:
https://serverfault.com/questions/942417/htaccess-change-document-root-t...
Doubtful. That's a PHP 8.2 issue, meaning you probably need to update Drupal core to a version that doesn't create properties dynamically.
I meant the Slack channels for Drupal: https://www.drupal.org/community/contributor-guide/reference-information... →
Once you set that up, see the #ai channel.
I'd need to look into it, but I'd imagine Webform fires an event when a form is submitted. Or you can at least use a form_alter hook.
I hate to promote it, but try Slack. There's a whole AI channel there where the module's devs hang out.
You might want to suggest they spend more time eating their own dog food right here.
There's already a non-complicated way to do this using the REST API. Or, you can create a custom module with a route that would take parameters and create the node.
Is there any reason why you want to bootstrap Drupal rather than using either of those methods?
I'm not clear on what I need to do to get the tests to pass. Should I just add the new code files and revert user.service.yml, with the idea being to change the yml file once the code files are committed? Or, do I need to add a mock service somewhere?
I already made a change to PermissionsRepositoryHandler::permissionsRepositoryFactory. I was using DI but I temporarily changed it to instead use Drupal::service thinking that would get the tests to pass. It didn't.
I mostly agree. Something like Slack might be OK for evanescent messages ("I'm working on issue 134 today") but tech support, planning, etc should be on this site. Using Slack isn't the only questionable decision unfortunately.
I'm not familiar with the nitty-gritty of Project Browser, but the best place to ask such questions is on Slack.
I assume you're doing automatic updates directly on your server. Any time the web server can modify code files that's a huge security risk. Is that what's going on here? I.e., which user is running rsync?
I'd need to research that, but there is an eca channel in Drupal Slack.
I support using these forums instead of Slack, but needs must.
This isn't really clear, but you can add a filter to views that only shows 'approved' or 'declined' submissions. That filter can also be exposed as a select box.
It's hard to tell without error messages. Did you press F12 to see any messages about where it's looking for the files that are missing? Did you check the server logs for errors? Is mod_rewrite enabled?
If you have a budget for this, someone from here could look into this for you. I can do that as long as you provide working SSH info. It's probably not a major issue.
tolstoydotcom → changed the visibility of the branch 3495351-change-permissions.yml-files to hidden.
For a personal D10 site, I created a new view in my local version that I tried to import into the live site. I got this message: "Configuration block.block.workflowtransitionform depends on the theme that will not be installed after import."
I exported that config and it had this:
...
dependencies:
module:
- workflow
theme:
- null
id: workflowtransitionform
theme: null
...I replaced both instances of "null" with "claro", imported that config on admin/config/development/configuration/single/import, and then I was able to import the view.
I have no idea where "null" came from, but if this is a common problem for a lot of people it might be easiest to create a "config repair" contrib module that would look for and fix such things.
My concerns, as usual, were shot down in the Slack thread.
Maybe recipes have a fundamental flaw in that versions are given. I.e., someone might be using an older version of a module for a specific reason and that older version would work with the recipe if it were flexible. Perhaps a more adaptive system would be better, like something that would try to match what the site has installed currently.
I posted this, please follow up there and then summarize here:
https://drupal.slack.com/archives/C2THUBAVA/p1742485267633119
There's no direct upgrade path from D7 to D8+, you have to do a migration. See "31 days of Drupal migrations" for a lot of background info. Or, if you have a budget for this you can hire someone such as myself to put that together for you.
Another possibility is file permissions. Maybe the web server can't read one of the files.
It'd be great if someone could add debugging code to Doctrine\Common\Annotations\TokenParser that prints out what it's parsing. My rawdebug file can be used for that, or just error_log. Of course, merely adding debugging might change the files in such a way that the problem goes away.
You can try this: https://www.drupal.org/project/redis →
I don't use ddev so what I'd do in this case is switch to a local LAMP install. In any case, you could backup everything, delete the vendor directory, truncate the 'cache_' tables in the db, and then run 'composer install'.
Note that using ddev means you can update code files through the Drupal UI. However, if you try that using LAMP on a server it would require unsafe permissions or ownership: on public sites having the web server being able to write to code files is a huge security risk.
You'd need to scan all of the text fields for all of the content types looking for absolute or relative links. There might be such a module (like a reverse sitemap) but most likely you'd need to code it up. If you aren't a coder and you have a budget for this, feel free to DM me.
See the FileItem.php file. You'd probably need to alter anything where FileItem::validateExtensions is used, to replace it with your own more permissive method.
You'd want to disable caching and add a cache buster to the URL. If that isn't it and there are no error messages on admin/reports/dblog or in your web server error log, then add code to the code that checks access to find out what the problem is. You can also install a debug module that shows that info.
To be clear, my module adds a Javascript file to the PB page. That JS file adds download buttons to eligible modules. That works on the first page, but if I click the pager to go to Page 2, Page 3, etc my Javascript isn't run: the attach method isn't called.
It seems bad design to have something in Drupal that isn't extensible: everything else is. If you add JS to a Views page, the JS's attach method will be called when you go to Page 2 etc.
My workaround is to poll every two seconds and add my buttons if they haven't already been added. That's suboptimal but I can deal with it if necessary.
Like I said, I'm not familiar with Svelte, but is adding in a hook or calling Drupal.attachBehaviors out of the question? Feel free to close again if that isn't going to happen.
What *I* would do is use my rawdebug module to print out the statement involved. Line 113 is $return = $this->clientStatement->execute($args); and it says For a \PDO client connection, this [clientStatement] will be a \PDOStatement object. And, there's a PDOStatement::debugDumpParams . The last one that's printed will be the culprit. I'd then look into indexes, how much data there is, etc.
I'm not familiar with Sharepoint but it looks like a Dropbox alternative, not a way to build web sites. What do you want to do? Is this a one-time export, or an ongoing thing?
Did you grep all of the source for the version with periods?
jsonapi.search_page
If you can't find it there, can you export your config files (either through the UI or drush) and look for it there? If that still doesn't work, see if it's in your config or key_value tables. Those might require queries that cast binary to char.
Once you find it, do a db backup and then delete it.
Assuming $databases in settings.php isn't commented out or being overwritten by something else later in the file or in an include file, do you see the expected info when you add this to Database.php at the start of the getConnection method?
echo '<pre>';print_r(self::$databaseInfo);exit;
Also here: https://www.drupal.org/project/drupal/issues/3508236 💬 Parameter "entity" for route "jsonapi.block--block.individual" must match "[^/]++" ("" given) Active
If you search the source code, where is jsonapi.search_page mentioned?
+1 on adding the link to /forum back. The Stack sites are a great resource, but it's best to have help on this site. The Slack channel should be more for ephemera.
tolstoydotcom → created an issue.
Whatever the status of https://www.drupal.org/project/drupal/issues/3372939 🐛 Use AccountProxyInterface instead of AccountInterface Needs work , the only method this module calls on AccountProxy is hasPermission and that's in AccountInterface. So, in the issue fork I changed AccountProxy to AccountInterface. There appears to be crosstalk with the other issue fork I created so I can do this again if needed.
tolstoydotcom → created an issue.
It's probably a problem with the subdomain not being set up properly. I suspect Drupal thinks it's installed under some other domain. I'd press F12 and try to figure out where Drupal is trying to load things from. If you can, test it without a subdomain.
tolstoydotcom → created an issue.
I'd be very surprised if CMS won't run on Wampserver, XAMPP etc as long as you have the correct versions of MySQL, PHP, and Apache. Drupal is just a (very large) PHP application, it doesn't embed itself into your system or anything.
Why not try it out and see? Just make sure you've got composer installed and the root of the site contains a 'vendor' and a 'web' directory, serving Drupal out of 'web' should work.
I reopened this because it still seems to be an issue: https://drupal.slack.com/archives/C1BB308HH/p1737753467044569
In the current version of the flag module, there's FlagLinkBuilderInterface::build($entity_type_id, $entity_id, $flag_id, $view_mode = NULL); defined in https://git.drupalcode.org/project/flag/-/blob/8.x-4.x/src/FlagLinkBuild...
However, the current version of this module's FlagAnonLinkBuilder::build is missing the last argument. I'll add a MR.
I've run D7 on wampserver and XAMPP. As posted above, I've also run it on plain apache2+MySQL. I hesitate to say composer isn't even a strict requirement because the reality is that you're going to have lots of problems if you can't use it. Opening a terminal & typing in two commands (one of which is provided for you) shouldn't be too onerous for most people.
marcus_johansson → credited tolstoydotcom → .
Look up the Drupal Slack channels. You want the project-browser channel.
IMNSHO, Project Browser encourages an unsafe installation. I'm working on a safe alternative and I'll announce it there and on Reddit. It'll take some time.
They haven't made it clear enough, but "Drupal Core" and "Drupal CMS" are basically the same thing. CMS just has pre-installed modules and recipes.
Not to further confuse things, but see the "dangerous" part: https://wisdomtree.dev/drupal-cms-review
Someone else had the same problem recently:
https://drupal.slack.com/archives/C1BB308HH/p1737368679086469
Before I knew about this issue, I suggested this:
It would help if you could edit drupal_check_module(). Just before the "addError" line, add this:
echo '<pre>';print_r($requirements);exit;
Then, post what it prints. It might warrant a bug report somewhere.
Even if the module is missing dependencies, it doesn't seem like drupal_check_module() should be doing this.
Drupal runs fine if you just install MySQL (or even Postgres) and a web server (Apache2 is easier; if you use nginx you'll need to find a config file).
It doesn't really require that, it just doesn't highlight alternatives.
I'm on Ubuntu and instead of ddev etc, I just use apache2 + MySQL. Apparently Ubuntu can be installed on Windows so that's an option.
I'm currently working on a way to make dealing with composer easier for non-devs.
If you use section names like "admin >> editing" and "admin >> deleting", it will look like a hierarchy.
Or, sections can be nested (the client would have to be aware of that of course):
sections:
- title: users
weight: 1
extended_help: 'permissions for regular users'
- title: admin
weight: 2
extended_help: 'permissions for admins'
sections:
- title: editing
weight: 1
extended_help: 'permissions for admins editing items'
- title: deleting
weight: 2
extended_help: 'permissions for admins deleting items'
I don't have an answer for that, but I didn't mean for you to make my change permanently. "Don't hack core" is an old maxim around here. What's $plugin_id?
I pushed the changes/additions if anyone wants to review them. I made a minor change to the existing file core/modules/user/src/PermissionHandler.php and a few changes to core/modules/user/user.services.yml (I added comments for those).
There are now three ways to get permissions:
- the 'user.legacy_permissions' service. This is the current way.
- the 'user.permissions' service. This is a replacement for the former way.
- the 'user_permissions_parser.repository_factory' service. This is what new code should use, it returns an object with all of the permissions.
There are differences in the sorting between the first two services above. If that's an issue I can change it. However, both get the same permissions.
I can add tests if this looks OK.
The code in question:
if (isset($definitions[$plugin_id])) {
return $definitions[$plugin_id];
}
What I'd do is use my rawdebug module and print out what's in $plugin_id and get a stack trace. At least add echo (string) $plugin_id;exit; and let us know what it says. A quick fix is probably to replace $plugin_id with (string) $plugin_id in both places but I'd only do that if I thought it was just a matter of having to clear the cache or similar.
You could write a script to run composer commands over the web, but that would be very unsafe: you'd basically be installing a tool (a shell) that hackers try to install on your site.
cPanel has a shell but that depends on your host.
Drupal could work with cPanel and similar to help people like you, but my suggestion to do that has been unilaterally ruled out: https://www.drupal.org/project/drupal_cms/issues/3491208 ✨ Create installation recipes that cPanel & hosting providers can use Active
The alternative is to work on your site locally and then upload it to your hosting. ddev is one option, but I just use local apache2 and mysql installations. I'm on Ubuntu so this is a lot smoother than Windows.
I might be and probably am wrong, but that trace doesn't offer a good clue. Are you able to export the config files using either the UI or drush? Is that route in those files somewhere?
If you can answer that and post this to the core issues queue they might be able to spot something.
An idea I have is some sort of "safe mode" for Drupal that would provide replacement versions for files that, instead of throwing exceptions, return anodyne data where possible (as with the help route in my previous suggestion).
Can you help find out the reason?
- make a backup of RouteProvider.php
- change line 211 to echo '<pre>';debug_print_backtrace();exit;
- post the result (use a storage service since it'll be a huge file)
Then, undo those changes and change line 211 to return $this->getRouteByName('help.main');
Then, clear caches/run update.php/run cron a couple times to see if that solves it.
Note: If you can avoid doing the last until later it might be helpful since there might be other things you can do to figure out the problem.
Every contrib module has the necessary composer command. The other main one you need is 'composer update'. If something goes wrong, there's a composer forum here.
If you can find the cause of the WSOD that would help. What does it say on admin/reports/dblog?