Five Reasons to Upgrade to Nette 2.2.3

10 years ago by David Grudl  

I am thrilled with the newly released version Nette 2.2.3 because it has successfully addressed numerous small issues, starting with smarter error detection in native functions, more descriptive error messages from the DI container, and various new features (see release notes).

I'd like to highlight three useful new features. The first one pertains to Latte and involves the invokeFilter() function, which allows you to call a filter (previously known as a helper) outside the template:

$latte = new Latte\Engine;
$latte->addFilter('upper', 'strtoupper');
$upper = $latte->invokeFilter('upper', array('abc'));
// equivalent to {'abc'|upper} in the template

The second new feature concerns Tracy. It can now log errors like E_NOTICE in full detail (i.e., with an HTML file), just as it logs exceptions. You can specify which errors to log in this way by setting the $logSeverity variable:

Tracy\Debugger::$logSeverity = E_NOTICE | E_WARNING;

The third new feature is related to security. The Configurator class has a setDebugMode() method, which you use to specify whether the application will run in production or development mode. Never pass the argument true to this method, as you might accidentally deploy it on a live server, creating a security hole. Instead, provide the IP addresses for which you want to enable development mode on the live server:

$configurator->setDebugMode('23.75.345.200');

However, IP addresses can change, and someone else might get them. Therefore, it is now possible to add an additional safeguard in the form of a cookie. Store a secret string in a cookie named nette-debug (either using the setcookie function or a browser's developer tool, but don't forget the httpOnly flag), for example, mysecret, and let the Configurator validate it as well. Development mode will only be activated if both the IP address and the cookie value match:

$configurator->setDebugMode('mysecret@23.75.345.200');

The fourth new feature is related to the DI container and is well hidden. It allows you to specify which classes to exclude from autowiring. A typical candidate is Nette\Application\UI\Control, which the DI container might otherwise inject into the constructor of a form. You can provide a list of excluded classes to the ContainerBuilder::addExcludedClasses() method, which you can access, for example, in bootstrap.php:

$configurator->onCompile[] = function($configurator, $compiler) {
	$compiler->getContainerBuilder()->addExcludedClasses(array(
		'stdClass',
		'Nette\Application\UI\Control',
	));
};

And finally, the fifth feature: during development, you might encounter the warning Possible problem: you are sending a HTTP header while already having some data in output buffer. Try OutputDebugger or start session earlier. This appears when you try to send HTTP headers, and although it is still possible, the application has already sent some output, which has been captured by the output buffer. In such a situation, it is best to start the OutputDebugger to find out where the output was sent and prevent it. From version 2.2.3, you also have the option to suppress this well-intentioned warning using the Nette\Http\Response::$warnOnBuffer variable. For example, again from bootstrap:

$container->getByType('Nette\Http\Response')->warnOnBuffer = false;