I have a D8 (8.5.6) installation which I have been trying to upgrade to 8.6 since it came out. It is on a shared hosting account which does not allow drush, so FTP it is. During the database update, it fails and I end up with the proverbial white screen of death. Before delving into detail troubleshooting, I want to disable all the third-party modules, and see if this works. If successful, I want to enable the third-party modules, one by one.

Is that a "good practice" type of approach?

The point is to quickly identify whether it is a contrib module which causes problems are the core install. Normal troubleshooting procedures would follow in any case.

  • White screen of death? Before delving into troubleshooting you need the error message. Ask your hosting provider where to find the error log.
    – 4uk4
    Commented Nov 18, 2018 at 10:07
  • 1
    What is failing exactly, do you have a stack trace ? You need to inspect error logs or anything related that could help to understand what is going on, and post it here (edit your question and pay attention to formatting for readability). I don't think it's a bad approach, on the contrary, but it's maybe a bit drastic and it could be very long depending on the number of contributed modules in use. So I would first try to have a clear understanding of the problem just by digging into error reporting. You need to connect to your host via ssh (not ftp) so that you can read logs in real time.
    – user26231
    Commented Nov 18, 2018 at 10:13
  • I was hoping not to go this way. I can restore files and databases, so can always fall back. Commented Nov 18, 2018 at 10:47
  • 2
    In a away, Drupal is more like a PHP framework than a CMS, so yes one's appreciation depends a lot on its skills and its goals.
    – user26231
    Commented Nov 18, 2018 at 11:46
  • 2
    You should check the error logs! Not checking the logs and trying to debug with your uninstall/install contrib modules approach is like missing a phone call and calling every contact to ask if they called and what they want instead of checking the call log or listening to the voicemail. It could've even been someone not in your contacts that called, i.e. not an issue with a contrib module.
    – sonfd
    Commented Nov 18, 2018 at 15:24

1 Answer 1


The one and only way to solve your problem responsibly is the following.

  1. Download all files to your local machine.
  2. Where you have a web development setup. And Drush.
  3. Download the database.
  4. Setup the page on your local machine, import the database and re-do locally what you were currently trying to do on the live server.
  5. Use your local Drush and whatever other tools you can get to check error messages, server logs, debug output etc.
  6. Drop and re-import the local database and repeat every step until you have reproduced the problem often enough to know what went wrong in the first place.
  7. Fix your live page.

And finally:

Never ever again update stuff untested on the live server. And have the database backed up let's say at least once a week. Good luck!

  • thank you for stating the obvious, but my question was something entirely different. Commented Nov 18, 2018 at 19:38
  • @NamSandStorm – Whatever helps you debugging is good practice. Bring your Drupal in an environment where you have all the tools you need for debugging. If you finally get to the root of your issue by uninstalling all modules and switching them back on one by one, then that's cool. Just remember, uninstalling modules triggers their uninstall routine and probably deletes data and/or settings you need to restore (from configuration exports at best).
    – leymannx
    Commented Nov 18, 2018 at 20:03

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.