Not sure where the best forum is for this, I apologize if this is the wrong place.
On a few occasions, I have upgraded a module only to find that a dependency had not yet been upgraded or was not fully documented. media_entity, file_entity, and entity for example. This breaks my site, and in order to get past it, I remove the offending module from the modules directory. Later on, I restore the module, go to uninstall the module and that breaks. Maybe I need to re-install a module and a configuration item is already there…. so I delete the configuration item from the database. and the install works.
Other times I may have deleted the wrong entry, resulting in not being able to uninstall the module later, and because other entries are still there from that module not being able to re-install it either.
What is the best way to handle this (other than restore from backup, which is super annoying with my set up). Obviously restore from backup is always the last resort, and backups should always be taken and available, but it seems there are better approaches.
So my questions and suggestions are:
Q1. If a module fails and I can’t load admin or main pages, how can I disable a module in Drupal 8 without hashing through yml files or something. According to documentation this used to be possible with the system table in Drupal 7 and earlier.
Q2. If a config row is not present when a module tries to uninstall, why should that cause a failure. Couldn’t the code check to see if the row exists, and only delete it if it does exist?
Q3. If a module is trying to install, but some of its config rows exists couldn’t it either replace all the existing rows or only add the rows that need to be there? (Perhaps it could prompt, perhaps it could be a config item)
As mentioned throughout, I know I should have had a backup, I don’t need to be told. Comments telling me how I should have backed up will be ignored.