Steps to recreate:

1) Setup a template file and corresponding hook_theme() entry.
2) View a page that uses that template. It works!
3) Edit your code to rename the template file (both the file name and the hook_theme entry)
4) Reload the page.
5) See this useless error message:

Twig_Error_Loader: Unable to find template "modules/drupalgotchi/templates/drupalgotchi-status-block.html.twig" (looked into: /stor/sandboxes/garfield/wscci/www/wscci) in "core/modules/block/templates/block.html.twig" at line 52. in Twig_Loader_Filesystem->findTemplate() (line 197 of /stor/sandboxes/garfield/wscci/www/wscci/core/vendor/twig/twig/lib/Twig/Loader/Filesystem.php).

Proposed solution:

Catch that exception (I assume it's an exception...), log it, and have the theme call simply return an empty string. We did that back in Drupal 7 (after we fixed the silent, undetectable fail of Drupal 6), and we should keep doing it.

Comments

Damien Tournoud’s picture

It's not like there is a fail-safe that could make sense. Returning an empty string is just wrong. In addition, templates being missing is fatal in every framework that I know of (it's one of the big cause of 500 errors of Rails apps).

This can only happen during development and the error message is self explanatory. I would recommend not doing anything.

Crell’s picture

Returning an empty string (or rather, null) is what we did in Drupals 5, 6, and 7. Only in 7 did we add any logging at all.

Damien Tournoud’s picture

Status: Active » Closed (won't fix)

Because having done something in the past is not an argument for doing it in the future, let's not do that. Ignoring an error when we don't have a proper resolution for it (and returning an empty string where a template should have been is *not* a proper resolution) is an anti-pattern that we have been moving away from every release of Drupal.

Crell’s picture

Status: Closed (won't fix) » Active
Issue tags: +DX (Developer Experience)

Reopening, because once you find yourself in this situation there's no way to force a clear in some cases.

At this very moment, I'm staring at the performance page (where you'd click cache) with a stale theme cache for a block that shows up on that page. I *cannot load that page* in order to clear the cache to resolve the problem.

If logging an error and failing gracefully is not a better solution than a dead site, please suggest something else because this is not an acceptable situation to leave developers in. Replace the output of the missing theme element with some standard message, perhaps?

I'm not suggesting "silently return empty string and otherwise hide the fact that there's a problem" as a solution. I'm suggesting the same solution we had in Drupal 7: Log the error and fail gracefully.

(And sure, "manually clear the cache by deleting the DB tables". If you have to do that, you're hacking around a limitation of Drupal. Let's not pretend that such limitations are OK.)

Damien Tournoud’s picture

It is simply not ok in my book to let the page finish rendering ignoring an exception in the middle. This is the exact contrary of fail-fast.

So yes, if your admin area depends on a template that doesn't exist, you are screwed. This is by design.

Damien Tournoud’s picture

Ignoring an exception and letting the process continue is always the wrong answer, because it results in undefined behavior. Rendering is absolutely not different. There are many bad things (security and otherwise) that can happen by serving a half-rendered page.

Crell’s picture

Issue tags: +regression

And leaving a site in an unrecoverable state is also always the wrong answer.

Continuing after an exception is absolutely the right course of action in many cases. Exceptions are designed the way they are precisely because you DO want to be able to fail gracefully from them if possible. If not, everything would just be a fatal error.

This is currently a regression from Drupal 7. I don't know what security issues you're talking about, but this is an issue that presumably affects primarily development, not production, so I can't imagine it's a major security issue.

Damien Tournoud’s picture

Continuing after an exception is absolutely the right course of action in many cases. Exceptions are designed the way they are precisely because you DO want to be able to fail gracefully from them if possible. If not, everything would just be a fatal error.

Continuing is fine if you have a way to fail safe, blanket ignoring is not. If I'm not mistaken, you are suggesting the later, which is a programming anti-pattern. Triggering a warning doesn't change the fact that you are letting the process continue with undefined results.

joelpittet’s picture

Issue summary: View changes
Issue tags: +Twig

Tagging with Twig so we can find it a bit better.

joelpittet’s picture

Issue summary: View changes
FileSize
172.83 KB

Here is what happens when a template is missing from D7.

Crell’s picture

Oh good, so this is a bug that needs a backport fix, too. :)

joelpittet’s picture

Not logged but here is D8 currently.

joelpittet’s picture

Status: Active » Closed (won't fix)
Issue tags: -regression

So screenshots show there is no fatal for missing template just warnings. Also hiding the error when the template missing and storing it in the log makes it much harder to catch.

And there is no regression as pointed out in #10