* 2.4:
unified return null usages
[Validator] added Japanese translation
Textarea value should default to empty string instead of null.
Fix doc blocks
[Process] Fix#10681, process are failing on Windows Server 2003
updated doc
[Security] fix DBAL connection typehint
[HttpFoundation] status 201 is allowed to have a body
unified return null usages
Conflicts:
src/Symfony/Component/DependencyInjection/ContainerBuilder.php
src/Symfony/Component/DomCrawler/Crawler.php
src/Symfony/Component/Security/Core/Authentication/Provider/PreAuthenticatedAuthenticationProvider.php
This PR was merged into the 2.3 branch.
Discussion
----------
unified return null usages
| Q | A
| ------------- | ---
| License | MIT
This PR unifies the way we return `null` from a function or method:
* always use `return;` instead of `return null;` (the current code base uses both);
* never use `return;` at the end of a function/method.
Commits
-------
d1d569b unified return null usages
* 2.4:
made types consistent with those defined in Hack
made {@inheritdoc} annotations consistent across the board
made {@inheritdoc} annotations consistent across the board
fixed types in phpdocs
[Debug] Fixed ClassNotFoundFatalErrorHandler on windows.
made phpdoc types consistent with those defined in Hack
Add support Thai translations
[Validator] Add missing czech translations
made types consistent with those defined in Hack
removed extra/unsupported arguments
[HttpKernel] fixed an error message
[TwigBundle] removed undefined argument
[Translation] Make IcuDatFileLoader/IcuResFileLoader::load invalid resource compatible with HHVM.
Conflicts:
src/Symfony/Component/Console/Helper/TableHelper.php
src/Symfony/Component/DependencyInjection/Loader/XmlFileLoader.php
src/Symfony/Component/Form/FormError.php
src/Symfony/Component/HttpKernel/Debug/TraceableEventDispatcher.php
src/Symfony/Component/Process/ProcessPipes.php
src/Symfony/Component/PropertyAccess/PropertyAccessor.php
src/Symfony/Component/Security/Acl/Dbal/MutableAclProvider.php
src/Symfony/Component/Security/Http/RememberMe/TokenBasedRememberMeServices.php
src/Symfony/Component/Translation/Dumper/FileDumper.php
src/Symfony/Component/Validator/ConstraintViolation.php
src/Symfony/Component/Validator/Constraints/EmailValidator.php
src/Symfony/Component/Validator/ExecutionContextInterface.php
src/Symfony/Component/Validator/Mapping/BlackholeMetadataFactory.php
Instead correctly use the array of schemes from the Route.
Also adjusted the dumpers to dump the correct data.
I extended the tests to not only test the deprecated behavior, but also
the new schemes-requirement.
Instead correctly use the array of schemes from the Route.
Also adjusted the dumpers to dump the correct data.
I extended the tests to not only test the deprecated behavior, but also
the new schemes-requirement.
* 2.2:
[Form] fixed INF usage which does not work on Solaris (closes#8246)
Fix grammar
bumped Symfony version to 2.2.4
updated VERSION for 2.2.3
update CONTRIBUTORS for 2.2.3
updated CHANGELOG for 2.2.3
[Process] Disable exception on stream_select timeout
[HttpFoundation] fixed issue with session_regenerate_id (closes#7380)
[DomCrawler] added a note about the default charset
[Console] fixed regression when calling a command foo:bar if there is another one like foo:bar:baz (closes#8245)
force the Content-Type to html in the web profiler controllers
Conflicts:
src/Symfony/Component/HttpKernel/Kernel.php
As explained in #6775, this has been done for the following reasons:
1. It's also Request::getHost()
2. The term hostname has been obsoleted in
http://tools.ietf.org/html/rfc3986#appendix-D.2 and uses the host only
3. hostname in the RFC was defined as the registered domain name, but we
probably also want to match IP-Adresses with the pattern which is the
host = IP-literal / IPv4address / reg-name for.
This PR was merged into the master branch.
Commits
-------
67d7423 Remove use of deprecated HttpKernel LoggerInterface
dca4528 [HttpKernel] Extend psr/log's NullLogger class
1e5a890 [Monolog] Mark old non-PSR3 methods as deprecated
91a86f8 [HttpKernel][Monolog] Add PSR-3 support to the LoggerInterface
Discussion
----------
[HttpKernel][MonologBridge] PSR-3 support
This enables PSR-3 support and monolog 1.3+. The first commit is the main part. The rest deals with deprecation of short-hand methods (warn/err/crit/emerg) that are fully expanded in PSR-3 (warning/error/critical/emergency).
The downside of deprecating them is that for bundles it's a bit harder to support older and newer versions. If that is too much of a hassle you can drop that for now and cherry pick the first commit.
The upside is that it forces people to move towards PSR-3 compatible stuff, which means eventually we could completely drop the LoggerInterface from the framework. In any case I think the documentation should only mention the `Psr\Log\LoggerInterface` and people should start hinting against that. The change should be done in core as well I suppose.
Anyway I wanted to throw this out there as it is to get feedback.
---------------------------------------------------------------------------
by stof at 2013-01-09T09:15:15Z
@Seldaek I also think you should change the typehint to use the PSR LoggerInterface in all classes using the logger
---------------------------------------------------------------------------
by Seldaek at 2013-01-09T09:54:55Z
OK updated according to all the feedback. I tested it in an app and it still seems to work so there shouldn't be any major issues.
---------------------------------------------------------------------------
by Seldaek at 2013-01-09T09:59:55Z
@fabpot if you merge please merge also the bundle PR, otherwise it won't be possible to update without conflict.
---------------------------------------------------------------------------
by frosas at 2013-01-10T14:59:20Z
I'm trying to understand why a `composer update` of a Symfony 2.1.* resulted in a fatal error. Shouldn't a stable version don't break like this?
As @olaurendeau points, why Symfony depends 1.* instead of 1.2.*? Or why Monolog 1.3 breaks its public interface (EDIT: I'm not sure about it)? Or why isn't this PR being merged (into branch 2.1) at the same time Monolog 1.3 is released?
Please, understand I'm not looking for who to blame, it's just I want to know if this situation is unexpected or if otherwise a `composer update` on a stable branch is not as innocent as it seems.
---------------------------------------------------------------------------
by stof at 2013-01-10T15:06:51Z
@frosas it cannot be merged into 2.1 as it is a BC break. The 2.1 branch has been updated to forbid Monolog 1.3 already
---------------------------------------------------------------------------
by Seldaek at 2013-01-10T15:11:58Z
@frosas you can blame me for releasing as 1.3.0 and not 2.0, but technically for monolog this isn't really a BC break, I just added an interface. The problem is due to the way it's used in symfony, it ended up as a fatal error. In any case the situation is now sorted out I think.
---------------------------------------------------------------------------
by frosas at 2013-01-10T15:26:43Z
@stof now I see this `>=1.0,<1.3-dev` change in the 2.1 branch. Now, shouldn't a new (2.1.7) version be released for all of us not in the dev minimum-stability?
@Seldaek then do you see feasible to rely only in X.Y.* versions to avoid this kind of errors?
---------------------------------------------------------------------------
by Seldaek at 2013-01-10T15:45:22Z
@frosas relying on X.Y.* is painful because you always need to wait until someone updates the constraint to get the new version. Of course using ~1.3 like in this PR means if I fuck up and break BC people will update to it, but that's a less likely occurrence than the alternative I think, so I would rather not use X.Y.*
---------------------------------------------------------------------------
by frosas at 2013-01-10T15:50:50Z
@Seldaek you are right about this, but I was thinking more in changing it only for the stable versions. EDIT: I mean, how often do you need a new feature in a branch you only apply fixes to?
---------------------------------------------------------------------------
by stof at 2013-01-10T15:57:32Z
@frosas Monolog and Symfony have separate release cycles. Foorcing Symfony users to use an old version of Monolog until they update to a new version of Symfony whereas the newer Monolog is compatible is a bad idea. Thus, as Monolog keeps BC, it does not maintain bugfix releases for all older versions (just like Twig does too). So it would also forbid you to get the fixes done in newer Monolog versions.
The incompatibility between Symfony 2.1 LoggerInterface and PSR-3 (whereas they expect exactly the same behavior and signature for methods with the same name) is unfortunate and is the reason why we get some issues here.
---------------------------------------------------------------------------
by frosas at 2013-01-10T16:21:06Z
@stof I appreciate you prefer to allow newer versions at the price of having to be constantly monitoring its changes to avoid breaks.
Another similar but safer strategy would be to stick to X.Y.* versions and upgrade to X.Y+1.* once the new version integration is tested, but I understand this is discutible in projects as close to Symfony as Monolog.
Returning to the issue, what do you say to release this 2.1.7 version? Or is it only me who is having issues here?
---------------------------------------------------------------------------
by stof at 2013-01-10T16:26:20Z
@frosas a minor release should not break BC when following smeantic versionning (Symfony warned about the fact it is not strictly followed for the first releases of 2.x). But as far as monolog is concerned, 1.3 is BC with 1.2.
---------------------------------------------------------------------------
by Seldaek at 2013-01-10T16:49:55Z
@frosas sorry I didn't get you still had the problem. I tagged a 2.1.7 of monologbundle which hopefully fixes your issue.
Commits
-------
0706d18 [Routing] fixed 4 bugs in the UrlGenerator
Discussion
----------
[Routing] UrlGenerator: fixed missing query param and some ignored requirements
This was pretty hard to figure out. I could fix 4 bugs and refactor the code to safe 2 variables and several assignments. Sorry for doing this in one commit, but they were highly interdependent.
See the added tests for what was fixed. The most obvious bug was that a query param was ignored if it had by accident the same name as a default param (but wasn't used in the path).
In 3 cases it generated the wrong URL that wouldn't match this route. The generator wrongly ignored either the requirements or the passed parameter. I had to adjust one test that was asserting something wrong (see comments).
---------------------------------------------------------------------------
by Tobion at 2012-08-13T14:22:35Z
ping @fabpot
---------------------------------------------------------------------------
by Tobion at 2012-08-29T17:53:07Z
@fabpot I think it's important to merge this before 2.1 final.
Commits
-------
3466896 [Routing] fix encoding of static static, so UrlGenerator produces valid URLs
Discussion
----------
[Routing] fix encoding of static text
Fixes#4166
As requested by Fabien, I split #4205 into multiple PRs.
---------------------------------------------------------------------------
by stof at 2012-06-09T12:49:32Z
github tells me this PR cannot be merged automatically. Could you rebase it ?
---------------------------------------------------------------------------
by Tobion at 2012-06-09T13:12:55Z
Done
---------------------------------------------------------------------------
by travisbot at 2012-06-09T13:18:18Z
This pull request [passes](http://travis-ci.org/symfony/symfony/builds/1576266) (merged 3466896a into 15b5aa4f).
Commits
-------
31843cf [FrameworkBundle] Add info to config
d5ab4c1 [Routing] Update changelog
bbef65e [Routing] Add strict_parameters option to disable exceptions when a route generation fails due to an invalid parameter
Discussion
----------
[Routing] Add strict_parameters option to disable exceptions on invalid parameters
---------------------------------------------------------------------------
by travisbot at 2012-06-09T15:07:26Z
This pull request [passes](http://travis-ci.org/symfony/symfony/builds/1577025) (merged bbef65e6 into 37678e17).
---------------------------------------------------------------------------
by stof at 2012-06-09T15:43:48Z
Seems good, but you forgot to update the Changelog of the component. Anyway, let's wait for @vicb's review as he knows the Routing component better than me.
---------------------------------------------------------------------------
by Seldaek at 2012-06-09T16:35:56Z
I updated the changelog
---------------------------------------------------------------------------
by travisbot at 2012-06-09T16:38:31Z
This pull request [passes](http://travis-ci.org/symfony/symfony/builds/1577716) (merged d5ab4c1d into 37678e17).
---------------------------------------------------------------------------
by travisbot at 2012-06-11T10:10:37Z
This pull request [passes](http://travis-ci.org/symfony/symfony/builds/1590901) (merged a54e59e4 into 37678e17).
---------------------------------------------------------------------------
by travisbot at 2012-06-11T13:50:21Z
This pull request [passes](http://travis-ci.org/symfony/symfony/builds/1591926) (merged 31843cf0 into 0995b1f2).
Commits
-------
382b083 [Routing] improved generated class by PhpGeneratorDumper
27a05f4 [Routing] small optimization of PhpGeneratorDumper
Discussion
----------
[Routing] improved PhpGeneratorDumper
Test pass: yes
BC break: no
The first commit only replaces arrays with strings and makes some cosmetic changes, so that it's more readable. This makes the `PhpGeneratorDumper` consistent in style with `PhpMatcherDumper` that I fixed recently and should slightly improve performance of the generation of the class.
The second commit changes the output of the `PhpGeneratorDumper->dump` and tries to optimize the resulting class that is used to generate URLs. It's best explained with an example.
Before my changes:
```php
class ProjectUrlGenerator extends Symfony\Component\Routing\Generator\UrlGenerator
{
static private $declaredRouteNames = array(
'Test' => true,
'Test2' => true,
);
/**
* Constructor.
*/
public function __construct(RequestContext $context)
{
$this->context = $context;
}
public function generate($name, $parameters = array(), $absolute = false)
{
if (!isset(self::$declaredRouteNames[$name])) {
throw new RouteNotFoundException(sprintf('Route "%s" does not exist.', $name));
}
$escapedName = str_replace('.', '__', $name);
list($variables, $defaults, $requirements, $tokens) = $this->{'get'.$escapedName.'RouteInfo'}();
return $this->doGenerate($variables, $defaults, $requirements, $tokens, $parameters, $name, $absolute);
}
private function getTestRouteInfo()
{
return array(array ( 0 => 'foo',), array (), array (), array ( 0 => array ( 0 => 'variable', 1 => '/', 2 => '[^/]+?', 3 => 'foo', ), 1 => array ( 0 => 'text', 1 => '/testing', ),));
}
private function getTest2RouteInfo()
{
return array(array (), array (), array (), array ( 0 => array ( 0 => 'text', 1 => '/testing2', ),));
}
}
```
After my changes in second commit:
```php
class ProjectUrlGenerator extends Symfony\Component\Routing\Generator\UrlGenerator
{
static private $declaredRoutes = array(
'Test' => array ( 0 => array ( 0 => 'foo', ), 1 => array ( ), 2 => array ( ), 3 => array ( 0 => array ( 0 => 'variable', 1 => '/', 2 => '[^/]+?', 3 => 'foo', ), 1 => array ( 0 => 'text', 1 => '/testing', ), ),),
'Test2' => array ( 0 => array ( ), 1 => array ( ), 2 => array ( ), 3 => array ( 0 => array ( 0 => 'text', 1 => '/testing2', ), ),),
);
/**
* Constructor.
*/
public function __construct(RequestContext $context)
{
$this->context = $context;
}
public function generate($name, $parameters = array(), $absolute = false)
{
if (!isset(self::$declaredRoutes[$name])) {
throw new RouteNotFoundException(sprintf('Route "%s" does not exist.', $name));
}
list($variables, $defaults, $requirements, $tokens) = self::$declaredRoutes[$name];
return $this->doGenerate($variables, $defaults, $requirements, $tokens, $parameters, $name, $absolute);
}
}
```
As you can see, there is no need to escape the route name and invoke a special method anymore. Instead the route properties are included in the static route array directly, that existed anyway. Is also easier to read as defined routes and their properties are in the same place.
Commits
-------
03c7cfe UrlGenerator no longer appends '?' if query string is empty
Discussion
----------
UrlGenerator no longer appends '?' if query string is empty
If you generate a URL using null parameters (`array('foo' => null, 'bar' => null')`), `http_build_query` returns an empty string, resulting in a trailing `?` at the end of the generated URL.
This fixes that so that, if there are `$extra` params & `http_build_query` is empty, the URL is no longer appended.
---------------------------------------------------------------------------
by fabpot at 2011/07/22 10:15:26 -0700
Can you add unit tests?
---------------------------------------------------------------------------
by ericclemmons at 2011/07/22 10:52:21 -0700
Yes sir, will do.
-Eric Clemmons
Sent from my iPad Nano
On Jul 22, 2011, at 12:15 PM, fabpot<reply@reply.github.com> wrote:
> Can you add unit tests?
>
> --
> Reply to this email directly or view it on GitHub:
> https://github.com/symfony/symfony/pull/1773#issuecomment-1633515
---------------------------------------------------------------------------
by ericclemmons at 2011/07/22 11:55:30 -0700
**Added passing test.**
Currently `master` fails test:
```
1) Symfony\Tests\Component\Routing\Generator\UrlGeneratorTest::testUrlWithNullExtraParameters
Failed asserting that two strings are equal.
--- Expected
+++ Actual
@@ @@
-http://localhost/app.php/testing
+http://localhost/app.php/testing?
//tests/Symfony/Tests/Component/Routing/Generator/UrlGeneratorTest.php:114
```
Only + and % are now encoded in generated routes, since they are the only characters that, if not encoded, could cause problems/conflicts when decoded. Namely + turns into a space, and % followed by numbers could do funky things.
The matcher decodes everything which works since nothing will have %NN without being escaped, and + are escaped as well.
When generating URL, thrown exceptions are InvalidArgumentException and
distinction of errors is quite difficult. This modification brings different
exceptions for different cases
The _scheme requirement can be used to force routes to always match one given scheme
and to always be generated with the given scheme.
So, if _scheme is set to https, URL generation will force an absolute URL if the
current scheme is http. And if you request the URL with http, you will be redirected
to the https URL.
When an object has a "main" many relation with related "things" (objects,
parameters, ...), the method names are normalized:
* get()
* set()
* all()
* replace()
* remove()
* clear()
* isEmpty()
* add()
* register()
* count()
* keys()
The classes below follow this method naming convention:
* BrowserKit\CookieJar -> Cookie
* BrowserKit\History -> Request
* Console\Application -> Command
* Console\Application\Helper\HelperSet -> HelperInterface
* DependencyInjection\Container -> services
* DependencyInjection\ContainerBuilder -> services
* DependencyInjection\ParameterBag\ParameterBag -> parameters
* DependencyInjection\ParameterBag\FrozenParameterBag -> parameters
* DomCrawler\Form -> FormField
* EventDispatcher\Event -> parameters
* Form\FieldGroup -> Field
* HttpFoundation\HeaderBag -> headers
* HttpFoundation\ParameterBag -> parameters
* HttpFoundation\Session -> attributes
* HttpKernel\Profiler\Profiler -> DataCollectorInterface
* Routing\RouteCollection -> Route
* Security\Authentication\AuthenticationProviderManager -> AuthenticationProviderInterface
* Templating\Engine -> HelperInterface
* Translation\MessageCatalogue -> messages
The usage of these methods are only allowed when it is clear that there is a
main relation:
* a CookieJar has many Cookies;
* a Container has many services and many parameters (as services is the main
relation, we use the naming convention for this relation);
* a Console Input has many arguments and many options. There is no "main"
relation, and so the naming convention does not apply.
For many relations where the convention does not apply, the following methods
must be used instead (where XXX is the name of the related thing):
* get() -> getXXX()
* set() -> setXXX()
* all() -> getXXXs()
* replace() -> setXXXs()
* remove() -> removeXXX()
* clear() -> clearXXX()
* isEmpty() -> isEmptyXXX()
* add() -> addXXX()
* register() -> registerXXX()
* count() -> countXXX()
* keys()
