"Oops, an error occurred! Code: 201601301501048.." in TYPO3 7.6

Question

I installed the TYPO3 version 7.6 and after adding extension to my page I got the error:

"Oops, an error occurred! Code: 201512031647523f4d731f"

I am not getting meaning of this error and I also enable 'displayErrors' => 1, in local configuration but still not get meaningful error.

Lannie

Answer 1

You need to switch off the "Content Object Exception Handler", which is an exception handler in new versions. If a content element/plugin throws an exception, it does no longer take down the whole site, but only itself. To disable it, set

config.contentObjectExceptionHandler = 0

Reference

Don't forget to re-enable the exception handler when going live, and in your live system, you can find the exception trace in your log files. Basically what Viktor Livakivskyi says in the other answer.

Closestool

Whatafa! Why is it not a debug setting in the LocalConfiguration.php? For this kind of stuff, I have a love/hate relationship with TYPO3. Ok, I am hangry, so now I will get something to eat.. – Forepaw

In production you should not enable debug output and in most cases it is not necessary - you will have the error message and stack trace in the log. So only do it the way it is described here on development systems (see logging framework) and other answer https://mcmap.net/q/956528/-quot-oops-an-error-occurred-code-201601301501048-quot-in-typo3-7-6 – Adamite

Answer 2

Basically it is date + hash, which makes each of such errors unique.

For development environment you may turn it off, as @Jost suggested.

But for production this is crucial to let it be turned on, so if some of your plugins or TS libs fails, it will not break the complete output and show "Oops an error occurred" without any info, but the message, you see now with a code.

The real user of a website can then report this code to you, and you can search for this code in your TYPO3 error log, which is by default located under typo3temp/logs/, unless you configured it different.

So, this feature really easies your life to find out user-generated errors.

Ninanincompoop

On newer non-Composer TYPO3 systems this would be typo3temp/var/logs by default. On Composer-based systems the log messages are elsewhere var ... – Adamite

Answer 3

You can open the file ./typo3/sysext/frontend/Classes/ContentObject/Exception/ProductionExceptionHandler.php

Search for the string Oops, an error occurred!. Add a debug line directly after the function declaration.

    /**
 * Handles exceptions thrown during rendering of content objects
 * The handler can decide whether to re-throw the exception or
 * return a nice error message for production context.
 *
 * @param \Exception $exception
 * @param AbstractContentObject $contentObject
 * @param array $contentObjectConfiguration
 * @return string
 * @throws \Exception
 */
public function handle(\Exception $exception, AbstractContentObject $contentObject = null, $contentObjectConfiguration = array())
{
debug ($exception, 'handle $exception');

Then you use a debug extension, e.g. fh_debug. This will give you an output like this. It shows you the backtrace of the call which lead to this error. The backtraces are shown in 2 formats. You can add more debug lines at the positions before the places from the backtraces, in order to have more information about the error.

<table><tbody><tr><td>index.php</td><td>34</td><td>call_user_func</td></tr><tr><td>index.php</td><td>33</td><td>run</td></tr><tr><td>Application.php</td><td>78</td><td>handleRequest</td></tr><tr><td>Bootstrap.php</td><td>302</td><td>handleRequest</td></tr><tr><td>RequestHandler.php</td><td>232</td><td>INTincScript</td></tr><tr><td>TypoScriptFrontendController.php</td><td>3478</td><td>recursivelyReplaceIntPlaceholdersInContent</td></tr><tr><td>TypoScriptFrontendController.php</td><td>3512</td><td>INTincScript_process</td></tr><tr><td>TypoScriptFrontendController.php</td><td>3564</td><td>cObjGetSingle</td></tr><tr><td>ContentObjectRenderer.php</td><td>859</td><td>render</td></tr><tr><td>ContentObjectRenderer.php</td><td>943</td><td>render</td></tr><tr><td>ContentObjectArrayContentObject.php</td><td>41</td><td>cObjGet</td></tr><tr><td>ContentObjectRenderer.php</td><td>805</td><td>cObjGetSingle</td></tr><tr><td>ContentObjectRenderer.php</td><td>859</td><td>render</td></tr><tr><td>ContentObjectRenderer.php</td><td>953</td><td>handle</td></tr><tr><td>ProductionExceptionHandler.php</td><td>53</td><td>debug</td></tr></tbody></table><br><table><tbody><tr><th>Object TYPO3\CMS\Core\Error\Exception</th></tr><tr><td>message</td><td class="el">PHP Catchable Fatal Error: Argument 1 passed to TYPO3\CMS\Frontend\ContentObject\ContentObjectRenderer::render() must be an instance of TYPO3\CMS\Frontend\ContentObject\AbstractContentObject, null given, called in /home/myuser/public_html/neu/typo3_src-7.6.10/typo3/sysext/frontend/Classes/ContentObject/ContentObjectRenderer.php on line 1359 and defined in /home/myuser/public_html/neu/typo3_src-7.6.10/typo3/sysext/frontend/Classes/ContentObject/ContentObjectRenderer.php line 927</td></tr>
<tr><td>code</td><td class="el"><table><tbody><tr><th>Integer</th></tr><tr><td>1</td></tr></tbody></table></td></tr>
<tr><td>file</td><td class="el">/home/myuser/public_html/neu/typo3_src-7.6.10/typo3/sysext/core/Classes/Error/ErrorHandler.php</td></tr>
<tr><td>line</td><td class="el"><table><tbody><tr><th>Integer</th></tr><tr><td>111</td></tr></tbody></table></td></tr>
</tbody></table>

<h3>handle $exception</h3><hr>

---

Text, added later: In the meantime it is not necessary any more to edit the PHP file ProductionExceptionHandler.php of TYPO3. You just install and configure the extension fh_debug which now does the necessary step automatically.

Trappist

Don't disclose debug information in productive enviroments, and, for gods sake don't effing mess with core code. – Bron

@j4k3: You comment does not make any sense. The output of the debug information is controlled by the debug settings of the Install Tool. Don't call my code mess any more! – Trappist

First of all I didn't. Second of all why wouldn't I. Third of all, what is so hard to understand about this being to generous with debugging information? The innards of your code is something you don't generally want your possble attackers to know about. Fourth of all. Dont. Mess. With. The. Core. – Bron

Yes, of course you are free to develop a TYPO3 extension which does a similar thing. This is a quick solution. There might even be a case when the customer is the only person which is able to provide the debug information. All the debug information is given in my example. Of course this shall be removed from TYPO3 Core again immediately after the reason of the exception has been discovered. It can easily be disabled by setting of DevIpMask in the Install Tool. – Trappist