[META] Track and resolve examples of brittleness

#2007248: When CKEditor module is uninstalled, the right text editor config entities are affected but their labels are missing

#1881630: [meta] Determine how to respond to invalid plugins (plugin dependencies)

While it's not a runtime issue, re-installing a site has a lot more steps than Drupal 7 did, and when it breaks the error handling often doesn't tell you what the problem is.

For memory I've run into trouble doing the following:

- touch settings.php instead of copying default.settings.php

- not deleting config directories.

- not removing settings.php from a previous install (especially if it has config directories in it that aren't there any more).

- not removing the compiled container from PHP storage

I'm seeing an interesting fail now after I tried to hand-truncate the cache tables.

Drupal\Component\Plugin\Exception\PluginException: The plugin (system_menu_block:menu-footer) did not specify an instance class. in Drupal\Component\Plugin\Factory\DefaultFactory::getPluginClass() (line 62 of drupal-8/core/lib/Drupal/Component/Plugin/Factory/DefaultFactory.php).

I've cleared the PHP storage and re-truncated all the cache tables. Is there some other cache? Or something in a cache_* table that needs to be persisted?

As best I can tell I'll need to re-install now.

That would have been handled by an upgrade path if it was later in the cycle. I knowingly broke everyones installs by not writing a hook_update_N

oh, ok - well if that was expected, fine.

Possibly related #2084521: Improve error handling of \Drupal class

If you define the same route name 2x, e.g. in different yml files, core throws a fatal SQL error during the route dumping.

Not sure if this crosses the line into baby-sitting to catch it and show an message instead, but seems like the sort of thing you might hit often during development?

Appears to be a meta-issue not documentation though.

#2076411: Remove the request scope from the current user service / #2004086: The Request service must be synthetic.

The change from route name "menu_menu_edit" to "menu.menu_edit" is potentially forcing a re-install. A menu link or something in the DB is looking up the old name and causing an uncaught exception:

Symfony\Component\Routing\Exception\RouteNotFoundException: Route "menu_menu_edit" does not exist.

I think we debated this before - doesn't seem like this should be fatal?

I believe we discussed removing the route_name column from the {menu_link} table. @dawehner would know.

That would seem a bit odd to remove it - then you'd have to run a more expensive matching operation every time you want to check access?

This needs someone else to reproduce who ideally isn't sleep-deprived, but the following seemed to happen to me:

1) Copy/paste your D7 module (such as https://drupal.org/project/pants) into your D8 modules directory in order to start porting.
2) Change your .info file to a .info.yml file without changing any of the text inside.
3) Go to the modules page.
4) Boom: YAML parse error.
5) Fix the YAML parse error.
6) Reload the modules page.
7) Your module still doesn't show up.

I tried clearing the caches with Drush, with the "Performance" button and no dice. No idea how to proceed without a reinstall. Any ideas?

EDIT: Ugh, missing type: module. Ignore me. Or maybe don't. :P This screwed me up a lot.

That bit me once too, in my case I needed to add 'type: module' to the yml

oh, just saw the edit :) ignore me

Simpletest.
Running the same test twice locally can net different results with errors about mtimefilestorage.
#1567500: [meta] Pave the way to replace the testing framework with PHPUnit and possibly rewrite Simpletest

</endrant>

#2097189: Add a rebuild script has a rebuild script.

#1962876: Misleading error message: Symfony ServiceNotFoundException: You have requested a non-existent service
#2095155: Fatal error does not cause the site to break if it happens outside of the main content (Kind of the opposite, actually)

Also, our error handling in Twig is pretty bad. Often it gets something that it can't handle, e.g. a FieldItemList object (node.nid instead of node.id) it dies with a fatal error as it tries to call a method called printed(), or if you're lucky, you get an exception that doesn't really tell you anything. We *need* to improve that to give you the template and problematic placeholder.

#2113913: "The plugin did not specify an instance class" when the plugin does not exist is confusing

#1908310: Drupal without DB but with site config throws uninformative error is also an example of brittleness - if the db is not available the maintenance theme just does not work.

Updated issue summary.

I was pointed to this meta issue, but the (lack of an) issue summary as well as all existing comments didn't really help to clarify on the context and scope of this meta issue...

@timplunkett's more sane interpretation in IRC was:

things that usually force you to reinstall

So retitling accordingly.

That said, given that interpretation, #2155701: Installer starts with fatal error/exception "table 'semaphore' not found" if settings.php contains $databases already does not really fall into this bucket, as it's a bug at the exact opposite end: Once you run into one of the issues covered by this meta here, you want to re-install, but ugh, sad panda.

@chx asked me to revert the issue title (without stating a reason). Sorry.

Updated with issues from comments added as related issues.

> (without stating a reason).

[18:32] sun: please undo / change the retitling, since we have the rebuild script, you dont need to reinstall
[18:34] chx: That was one of my first thoughts as well... but it appears that folks want to track some further "brittleness" beyond stuff that is mitigated by the rebuild script. (In other words, I still didn't really understand the exact scope and goal of this meta ;) )
[18:34] sun: then please dont retitle it
[18:34] sun: express your concerns but leave the title

Stop lying about what happens in IRC. That got both of us into deep trouble 1.5 years ago and I was very reluctant to talk to you again on IRC and I now put you on ignore and won't talk to you again.

I'm updating the issue summary to try to add a little more clarity around the nature of this issue.

There does appear to be some legitimate confusion about the nature of this meta issue and what it relates to - and as far as I can tell, that confusion was resolved with further conversation in IRC after the snippet shared in the previous comment.

I hope that by updating the issue queue to clarify it's scope, that others may better understand the broad "catch-all" purpose of this meta issue.

Tagging per #34.

Untagging, not being used for tracking either at this point.

Going to go ahead and close this.

We still have plenty of examples of brittleness, but all the child issues here are closed.