Five Reasons to Upgrade to Nette 2.2.3
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;
Sign in to submit a comment