Commits
-------
24a0d0a [DependencyInjection] Support Yaml calls without arguments
Discussion
----------
[DependencyInjection] Support Yaml calls without arguments
Commits
-------
e4f3fd9 Fixed example code.
Discussion
----------
[Translation] example code did not work.
The example code for Translation did not compile. And the trans() result was void.
Commits
-------
15dd17e Simplified CONTENT_ headers retrieval
Discussion
----------
Header bag
Bug fix: yes
Feature addition: no
Backwards compatibility break: no
Symfony2 tests pass: yes (actually no but I think this has nothing to do with this PR...)
Fixes the following tickets: -
Todo: -
Commits
-------
86a3512 [FrameworkBundle] Add support for full URLs to redirect controller
Discussion
----------
[FrameworkBundle] Add support for full URLs to redirect controller
I'd consider this a bugfix since at the moment using an URL just redirects to `/current/pathhttp://example.org`.
Commits
-------
0c9b2d4 use SecurityContextInterface instead of SecurityContext
Discussion
----------
[2.0][Security] use SecurityContextInterface instead of SecurityContext
see https://github.com/symfony/symfony/pull/3522 (this is a fix for the 2.0 branch)
---------------------------------------------------------------------------
by pminnieur at 2012-03-21T13:25:59Z
*ping* it still missed the 2.0.12 release ...
---------------------------------------------------------------------------
by stof at 2012-03-21T16:41:28Z
@pminnieur you PR has been merged into master, not into 2.0, so it will only be in 2.1
---------------------------------------------------------------------------
by pminnieur at 2012-03-21T16:43:02Z
I know, and this is a second PR for 2.0 branch.
Commits
-------
068e859 [TwigBundle] Changed getAndCleanOutputBuffering() handling of systems where ob_get_level() never returns 0
Discussion
----------
[TwigBundle] Changed getAndCleanOutputBuffering() handling of systems where ob_get_level() never returns 0
Bug fix: yes
Feature addition: no
Backwards compatibility break: no
Symfony2 tests pass: [](http://travis-ci.org/lencioni/symfony)
Fixes the following tickets: -
Todo: -
Relying on decrementing a counter has two problems. First, and most importantly, if the output buffering nesting level is greater than the counter, the function does not perform the expected task. Secondly, on systems where the counter is needed, a lot of unnecessary extra loops would potentially occur.
This approach checks to see if the level has stayed the same from the previous iteration and if it has it stops looping.
---------------------------------------------------------------------------
by fabpot at 2012-03-21T21:29:50Z
Have you encounter this problem to confirm that your approach works?
---------------------------------------------------------------------------
by vicb at 2012-03-21T21:35:39Z
@lencioni could you also provide an answer from my question in the former version of this PR ?
---------------------------------------------------------------------------
by lencioni at 2012-03-21T21:56:06Z
@fabpot I have not encountered this problem personally, but the code I submitted is [similar to an approach I use in SLIR](https://github.com/lencioni/SLIR/blob/master/core/slir.class.php#L462), which has been successful for people who have encountered it.
@vicb You are referring to [this question](https://github.com/symfony/symfony/pull/3666#issuecomment-4626105), right?
>It was possible than the body of the while loop was never executed before, it is no more. Is this expected ?
I think you may have misinterpreted the change I submitted. In the original code, there were two conditions being checked in the while loop. The first condition has not changed in my code and could still prevent the body of the while loop from being never executed. The second condition in the original code would always evaluate to 99 on the first iteration, which would not prevent the loop from running.
---------------------------------------------------------------------------
by vicb at 2012-03-21T22:00:01Z
oops my mistake, sorry.
Bug fix: yes
Feature addition: no
Backwards compatibility break: no
Symfony2 tests pass: [](http://travis-ci.org/lencioni/symfony)
Fixes the following tickets: -
Todo: -
Relying on decrementing a counter has two problems. First, and most importantly, if the output buffering nesting level is greater than the counter, the function does not perform the expected task. Secondly, on systems where the counter is needed, a lot of unnecessary extra loops would potentially occur.
This approach checks to see if the level has stayed the same from the previous iteration and if it has it stops looping.
Commits
-------
c1206c3 [FrameworkBundle] Subrequests should always use GET method
Discussion
----------
[FrameworkBundle] Subrequests should always use GET method
Bug fix: yes
Feature addition: no
Backwards compatibility break: maybe?
Symfony2 tests pass: [](http://travis-ci.org/asm89/symfony)
Fixes the following tickets: -
Todo: -
When generating a subrequest using the bundle/controller notation instead of a url, the method of the duplicated subrequest isn't set to GET, while this does happen in the other case (see [here](https://github.com/symfony/symfony/blob/master/src/Symfony/Bundle/FrameworkBundle/HttpKernel.php#L143)). This causes weird behavior when embedding actions with forms on a page that is already reached through a POST request (since most forms check if POST was the request method before binding to the request).
Commits
-------
8642473 Changed instances of \DateTimeZone::UTC to 'UTC' as the constant is not valid a produces this error when DateTimeZone is instantiated: DateTimeZone::__construct() [<a href='datetimezone.--construct'>datetimezone.--construct</a>]: Unknown or bad timezone (1024)
Discussion
----------
[Locale] DateTimeZone called incorrectly by default
Bug fix: yes
Feature addition: no
Backwards compatibility break: no
Symfony2 tests pass: no (there were two tests that were failing previously, that still fail)
Fixes the following tickets: none
Todo: none
While running, a warning throws every single time when the code
```php
new \DateTimeZone(\DateTimeZone::UTC);
```
is encountered. It is normally caught as a thrown exception and then corrected here:
```php
// src/Symfony/Component/Locale/Stub/StubIntlDateFormatter.php:442
try {
$this->dateTimeZone = new \DateTimeZone($timeZoneId);
} catch (\Exception $e) {
$this->dateTimeZone = new \DateTimeZone('UTC');
}
```
However in my particular infrastructure, for whatever reason in production only, it causes an error to appear on shutdown in the logs. As ultimately the constant can NEVER pass, it should not be attempted with the constant. Instead, the correct 'UTC' should be passed in (as done in the catch statement).
Commits
-------
fbed9ff Update src/Symfony/Component/HttpKernel/HttpCache/HttpCache.php
Discussion
----------
Branch 2.0 - Correct bad HttpCache behaviour when waiting for unlock.
I read the class Symfony\Component\HttpKernel\HttpCache\HttpCache and I found something which looks like a bug lines 518-520 (in lock method) :
$wait = 0;
while (is_file($lock) && $wait < 5000000) {
usleep($wait += 50000);
}
This code can wait at maximum 50000+100000+150000+.... 4950000 µs = more than 250 seconds !
I corrected like that :
$wait = 0;
while (is_file($lock) && $wait < 5000000) {
usleep(50000);
$wait += 50000
}
This code will wait 5 sec maximum.
This is more coherent if we read the following lines of this method.
---------------------------------------------------------------------------
by arnapou at 2012-03-15T20:09:13Z
Hope I succeded to do a correct PR.
One hour of manipulation in Github for 2 lines of code let me a bitter taste on the tongue...
I was closed to tell you "Do It Yourself" ... what a waste of time...
This interface is not obvious, even if we had already worked on svn/git on *nix.
Commits
-------
eee5065 [TwigBundle] Workaround a flaw in the design of the configuration (normalization)
Discussion
----------
[TwigBundle] Workaround a flaw in the design of the configuration (norma...
...lization)
see #2823
@Seldaek please comment.
---------------------------------------------------------------------------
by Seldaek at 2012-03-09T20:52:47Z
It seems fine at first glance. I don't have time to look at it in detail right now sorry.
Commits
-------
1b395f5 Revert "Throw exception when "date_widget" option is not equal to "time_widget""
Discussion
----------
Reverts commit 3c2539 to remove exception when DateTypeType has differents date and time widgets
see https://github.com/symfony/symfony/pull/1419
Commits
-------
ed218bb Fixed an "Array to string conversion" warning when using PHP 5.4. Also affects Symfony2 master.
Discussion
----------
[Config] Fixed an "Array to string conversion" warning when using PHP 5.4
This also affects Symfony2 master
Commits
-------
17c3482 fixed timezone bug in DateTimeToTimestampTransformer
Discussion
----------
[FIX]fixed timezone bug in DateTimeToTimestampTransformer
After several trials, I found out that the original code
```php
$dateTime = new \DateTime(sprintf("@%s %s", $value, $this->outputTimezone));
```
would create a DateTime object with timezone being '0000', even though $this->outputTimezone is set to my local timezone.
so I expanded the code a bit and it's working now.
PHP Test code,
```PHP
$d = new DateTime("@1234567890 Asia/Tokyo");
echo date_format($d, 'Y/m/d H:i:s')."\n";
echo $d->getTimezone()->getName()."\n";
$d = new DateTime("now Asia/Hong_Kong");
echo date_format($d, 'Y/m/d H:i:s')."\n";
echo $d->getTimezone()->getName()."\n";
```
The output is as followed:
2009/02/13 23:31:30
+00:00
2012/03/13 03:35:55
Asia/Hong_Kong
This could be a bug of PHP,
---------------------------------------------------------------------------
by stealth35 at 2012-03-13T15:54:31Z
👍
Commits
-------
50cb486 Fixed proxy generation in the DoctrineBundle when using Doctrine >= 2.2.0
Discussion
----------
[DoctrineBundle] Fixed proxy generation with Doctrine >= 2.2.0
Bug fix: yes
Feature addition: no
Backwards compatibility break: no
Symfony2 tests pass: yes
The issue here was, that the name of the generated Proxy files have changed in Doctrine 2.2.0, thus the autoloader in the DoctrineBundle stoped working.
This PR fixes this issue by applying different string manipulations to the given class name depending on the currently used Doctrine version.
---------------------------------------------------------------------------
by fabpot at 2012-03-14T07:13:23Z
Can you squash your commits before I merge? Thanks.
---------------------------------------------------------------------------
by Spea at 2012-03-14T09:33:10Z
Should I open a new PR when squashed the commits? Because I don't know what happens when I force the remote repository to push my squashed commits.
---------------------------------------------------------------------------
by stloyd at 2012-03-14T09:48:05Z
First you should rebase (normally), then squash and push with `--force`, then GH will automaticaly update this PR (if you push into same branch on which bases this PR).
---------------------------------------------------------------------------
by Spea at 2012-03-14T10:04:30Z
Yeah I knew about the ```--force``` option. I just wasn't sure what happens when I do it. Thank you!
---------------------------------------------------------------------------
by Spea at 2012-03-14T10:14:23Z
Squashed commits.
Commits
-------
93cc9ef [Validator] Remove a race condition in the ClassMetaDataFactory (fix#3217)
Discussion
----------
[Validator] Remove a race condition (fix#3217)
#3581 for 2.0
Commits
-------
878c239 Fixed autoloader leakage in tests
Discussion
----------
Doctrine autoload
The autoloader for proxies is now unregistered on shutdown to avoid
having several instances registered at the same time in tests.
Commits
-------
aa53b88 Sets _format attribute only if it wasn't set previously by the user
Discussion
----------
Sets _format attribute only if it wasn't set previously by the user.
Fixes#2653
Commits
-------
705e460 provided unmerged definition for correct help generation
45bbb5b added getNativeDefinition() to allow specifying an alternate InputDefinition for help generation
Discussion
----------
[Console] Xml output fix
Bug fix: yes
Feature addition: no
Backwards compatibility break: no
Symfony2 tests pass: yes
Fixes the following tickets: #2667
Todo: add specific test
As per my comment [here](https://github.com/symfony/symfony/issues/2667#issuecomment-4431944), added the ability to provide an InputDefinition that will not be changed by merging with the Application InputDefinition..
Commits
-------
f26c1ce Fixed constraint requirements for Doctrine Common
011791d [Form] Moved the Validator component to the suggest section
Discussion
----------
Composer deps
There is no hard dependency to the Validator component in the Form, as said on Twitter when @harikt tried to use it. I kept the Locale component as a requirement as it is used by the LanguageTyep, CountryType and LocaleType which will be registered when using the CoreExtension.
The constraints for Doctrine deps are fixed too: adding an upper bound everywhere as we don't know the future to guarantee the compatibility (and for instance, 2.0.9 and lower were not compatible with ORM 2.2 as we had to fix the bundle), and the bridge is compatible with Common 2.2 too, not only with 2.1.
I found 2 other places where the dependencies should be discussed:
- the Validator component marks a hard dependency to Doctrine Common for its annotation reader. There is a dependency only when using annotation so it should not be a hard requirement IMO but a suggestion. the issue is that the [ValidatorFactory](https://github.com/symfony/symfony/blob/master/src/Symfony/Component/Validator/ValidatorFactory.php) (not used by the framework itself) will add an annotation loader when relying on the default value of the arguments, which means that people that don't take care will need Common. Would it make sense to change the default so that Common is needed only when the user explicitly asks to use annotations ? Moving Common from require to suggest would make it easier for people using the Validator component standalone if they don't use annotations
- the Security component suggests the Finder and ClassLoader components. But these ones are only used by the [dev script](https://github.com/symfony/symfony/blob/master/src/Symfony/Component/Security/Acl/Resources/bin/generateSql.php) used to generate the SQL schema shipped in the component. Does it really make sense to list them as people cloning the component should probably never use this script (which alters the files in the component) ?
---------------------------------------------------------------------------
by fabpot at 2012-03-11T08:14:46Z
+1 for removing Doctrine Common as a required dependency for the Validator component.
+1 for removing ClassLoader and Finder from the Security suggestions.
