Commits
-------
854daa8 [Form] Fixed errors not to be added onto non-synchronized forms
Discussion
----------
[Form] Fixed errors not to be added onto non-synchronized forms
Bug fix: yes
Feature addition: no
Backwards compatibility break: no
Symfony2 tests pass: yes
Fixes the following tickets: #4686
Todo: -
Commits
-------
28f002d [Locale] fixed bug on the parsing of TYPE_INT64 integers in 32 bit and 64 bit environments, caused by PHP bug fix :) (closes#4718)
Discussion
----------
[Locale] fixed bug on the parsing of TYPE_INT64 integers in 32 bit and 64 bit environments, caused by PHP bug fix
Bug fix: yes
Feature addition: no
Backwards compatibility break: no
Symfony2 tests pass: yes
Fixes the following tickets: #4718
License of the code: MIT
[](http://travis-ci.org/eriksencosta/symfony)
Tests pass on PHP 5.3.3, 5.3.14 and 5.4.4 with ICU 4.2, 4.4 and 4.6 on 32 and 64 bit environments.
Commits
-------
a609d55 [Locale] fixed StubIntlDateFormatter to behave like the ext/intl implementation
Discussion
----------
[2.0][WIP][Locale] StubIntlDateFormatter should use the TZ environment variable instead of the PHP's date.timezone setting
Bug fix: yes
Feature addition: no
Backwards compatibility break: yes
Symfony2 tests pass: yes
Fixes the following tickets: #3841
Todo: Check ext/intl changes for the next PHP 5.4 release
License of the code: MIT
There were changes that need to be investigated for the next PHP 5.4 release:
- [php-src @ eb346ef](eb346ef0f4)
- [php-src @ 888e77f](888e77ff73)
A strong evidence of bug in ext/intl was found while testing `StubIntlDateFormatter`. See the comment available at the docblock of `StubIntlDateFormatterTest`'s `testFormatWithDefaultTimezoneIntlShouldUseTheTzEnvironmentVariableWhenAvailable()` method and the following Gist for test scripts: https://gist.github.com/2946342
Maybe the upcoming PHP 5.4 release fix this bug since it will use the PHP's `date.timezone` when no time zone is provided. If confirmed the bug, it will need to be reported to the ext/intl maintainers.
---------------------------------------------------------------------------
by travisbot at 2012-06-18T05:02:05Z
This pull request [passes](http://travis-ci.org/symfony/symfony/builds/1644431) (merged a609d55c into cd0aa378).
---------------------------------------------------------------------------
by fabpot at 2012-06-28T14:09:08Z
@eriksencosta Now that PHP 5.4.4 is out, our tests for the Locale components are broken. Is this PR ready to be merged?
---------------------------------------------------------------------------
by eriksencosta at 2012-06-28T14:53:14Z
@fabpot the failed test case seems unrelated to this issue. I will debug it.
Failed test: `Locale\Tests\Stub\StubNumberFormatterTest::testParseTypeInt64IntlWith32BitIntegerInPhp32Bit`
Recent build job: http://travis-ci.org/#!/symfony/symfony/jobs/1729618
I just need to confirm mine todo note. If you want, merge it, I'll track this and make a new PR if needed (possibly only to remove the TODO note.)
Commits
-------
2c12ed3 Added a missing provide for the swiftmailer bridge
Discussion
----------
Composer provide
Currently, the standalone bridge will be installed when a library requires it, even if you have the full framework, thus leading to weird issues if the versions missmatch (which is possible as the bridge does not have any hard requirement to a component in the composer.json which would enforce ``self.version``)
Commits
-------
3ce8227 [Security] Only redirect to urls called with http method GET
Discussion
----------
[Security] Only redirect to urls called with http method GET
Bug fix: [yes]
Feature addition: [no]
Backwards compatibility break: [no]
Symfony2 tests pass: [yes]
License of the code: MIT
---------------------------------------------------------------------------
by travisbot at 2012-06-14T12:01:32Z
This pull request [passes](http://travis-ci.org/symfony/symfony/builds/1619029) (merged 3ce8227a into 4e1e08ef).
Commits
-------
0d67b9f Removed useless use statements
a3c1299 [Form] Added a missing use statement and fix a phpdoc
Discussion
----------
Use statements
This adds a missing use statements in the Form component (which would cause a fatal error if the exception was thrown) and removes useless use statements in the BrowserKit component (the use statement for the current class confuses the IDEs)
---------------------------------------------------------------------------
by travisbot at 2012-06-14T08:05:41Z
This pull request [passes](http://travis-ci.org/symfony/symfony/builds/1617154) (merged 0d67b9f2 into 41f48b7e).
Commits
-------
5d88255 Authorization header should only be rebuild when Basic Auth scheme is used
Discussion
----------
[Regression fix] Authorization header should only be rebuild when Basic Auth scheme is used
Bug fix: yes
Feature addition: no
Backwards compatibility break: no
Symfony2 tests pass: yes
Fixes the following tickets: fixes regression introduced by #1813
Todo: N/A
License of the code: MIT
---------------------------------------------------------------------------
by travisbot at 2012-06-11T14:40:28Z
This pull request [passes](http://travis-ci.org/symfony/symfony/builds/1592604) (merged cf5ee26a into 27100ba4).
---------------------------------------------------------------------------
by mvrhov at 2012-06-12T06:13:01Z
fixed
---------------------------------------------------------------------------
by travisbot at 2012-06-12T06:14:55Z
This pull request [passes](http://travis-ci.org/symfony/symfony/builds/1598555) (merged 5d88255d into 27100ba4).
Commits
-------
b631073 [Yaml] Fixed double quotes escaping in Dumper.
Discussion
----------
[Yaml] Fixed double quotes escaping in Dumper
Issue #4308 is caused by Dumper::escapeWithDoubleQuotes() which uses [str_replace()](http://php.net/str_replace).
From the php docs:
> Because str_replace() replaces left to right, it might replace a previously inserted value when doing multiple replacements.
We should be very careful in deciding about the order of elements in $escapees array. I'd really appreciate if someone reviewed my fix. Tests say I didn't break anything but I'm not sure what percentage of Yaml specification is covered by tests.
Bug fix: yes
Feature addition: no
Backwards compatibility break: not that I know
Symfony2 tests pass: [](http://travis-ci.org/jakzal/symfony)
Fixes the following tickets: #4308
---------------------------------------------------------------------------
by travisbot at 2012-05-18T08:53:51Z
This pull request [passes](http://travis-ci.org/symfony/symfony/builds/1364279) (merged 5192722c into a04acc89).
---------------------------------------------------------------------------
by travisbot at 2012-05-18T23:19:49Z
This pull request [fails](http://travis-ci.org/symfony/symfony/builds/1371539) (merged ecaa1aab into fc3c609b).
---------------------------------------------------------------------------
by dinamic at 2012-05-19T07:35:21Z
Something is really wrong with this method. You can see clearly that multiple characters would fail proper escaping.
Here's an example:
```
$value = '\\\\"some value\n \"some quoted string\" and \'some single quotes one\'"';
var_dump(Escaper::escapeWithDoubleQuotes($value));
string(72) ""\\\"some value\n \\some quoted string\\ and 'some single quotes one'\"""
```
To begin with the backslash - in the initial value you have 2 (escaped ones), that after escaping should result in 4, not in 1 (escaped). I guess this behavior has to be verified with the importer, but imho it does not seem right.
Does anyone know why this escaping wasn't done using a regular expression in first place?
---------------------------------------------------------------------------
by clemens-tolboom at 2012-05-19T10:18:58Z
Searching for https://duckduckgo.com/?q=what+is+\xc2\x85 the table on http://stackoverflow.com/questions/6609895/efficiently-replace-bad-characters is interesting enough to decide we need way more documentation on this file.
\xc2\x85 seems to be triple dot (ellipses)
\xe2\x80\xa9 seems to be paragraph separator see http://drupal.org/node/914360#comment-3468550
Commits
-------
4938080 MethodNotImplementedException -> MethodArgumentValueNotImplementedException
789fc14 Accept calling setLenient(false)
Discussion
----------
GH-4491 - Move patch from master to 2.0
A patch in PR-4469 fixed an issue with setLenient() and not having intl. This was only merged into master, although the original issue was created in the 2.0 branch. This PR cherry-picked the patches against 2.0 again.
---------------------------------------------------------------------------
by travisbot at 2012-06-06T15:29:19Z
This pull request [passes](http://travis-ci.org/symfony/symfony/builds/1527145) (merged 49380804 into 9a5e6c90).
---------------------------------------------------------------------------
by kbond at 2012-06-06T17:42:40Z
fixes#4491
Commits
-------
20b556d [Form] fixed a bug that caused input date validation not to be strict when using the single_text widget with a datetime field
7e3213c [Form] fixed a bug that caused input date validation not to be strict when using the single_text widget with a date field
Discussion
----------
[Form] fixed a bug that caused input date validation not to be strict when using the single_text widget with a date/datetime field
Bug fix: yes
Feature addition: no
Backwards compatibility break: no
Symfony2 tests pass: yes
Fixes the following tickets: -
Todo: -
License of the code: MIT
Documentation PR: -
Currently, input date validation is not strict when using the single_text widget with a date or datetime field. This will cause unexpected transformation of input date value as follows:
* 2012-04-31 => 2012-05-01
* 2012-04-31 03:04:00 => 2012-05-01 03:04:00
Additionally this is not same as other transformation logic for date/datetime fields because they use the checkdate() function to validate input date values. The checkdate() function validates a date strictly.
```php
<?php
var_dump(checkdate(4, 31, 2012)); // bool(false)
```
BTW, the documentation of [IntlDateFormatter::setLenient()](http://php.net/manual/en/intldateformatter.setlenient.php) and [IntlDateFormatter::isLenient()](http://php.net/manual/en/intldateformatter.islenient.php) have been fixed recently. Please see https://bugs.php.net/bug.php?id=61896 **The default parser is lenient, not strict**.
---------------------------------------------------------------------------
by travisbot at 2012-05-28T07:35:11Z
This pull request [fails](http://travis-ci.org/symfony/symfony/builds/1453681) (merged 20b556da into 167779e5).
---------------------------------------------------------------------------
by bschussek at 2012-05-28T09:25:23Z
Quote on strict parsing:
> Extra space, unrecognized tokens, or invalid values ("February 30th") are not accepted.
Disabling lenient parsing makes entering dates in text boxes even harder than it is right now.
---------------------------------------------------------------------------
by iteman at 2012-05-29T09:31:49Z
In my opinion, in most applications, in particular enterprise applications, date/time handling is very important. Unexpected transformation of date/time may sometimes lead unexpected outcomes. In such applications, accepting invalid values is not important than avoiding unexpected transformation. **As specifications, "strict" should be the default, or at least, the "strict" option should be provided if the default is "lenient".**
Moving on to the current behavior.
If "lenient" is intended behavior, is there any way to know it? At least, there is nothing to be found in the tests and documentation for the date/datetime field.
http://php.net/manual/en/intldateformatter.setlenient.php:
> Extra space, unrecognized tokens, or invalid values ("February 30th") are not accepted.
This is only applicable to *DateTimeToLocalizedStringTransformer* (using *IntlDateFormatter*) that is used by *DateType*, not applicable to *DateTimeToStringTransformer* (using *DateTime*) that is used by *DateTimeType*. Why is defferent between these implementation in the first place?
On the one hand, strict validation by *checkdate()* has been adopted in the widgets except the single_text widget. Does this conflict with the single_text widget? Isn't there any problem to be determined "lenient" or "strict" by the widget type mainly from the point of view of the separation of concerns?
Additionally, is there any way to avoid unexpected transformation in the current behavior without changing the specification of a domain object, or writing a new transfer object, or not using the single_text widget?
Finally, I think that the current behavior is bad, but if the current behavior is not a bug, I think that the "strict" option should be provided in *DateType* and *DateTimeType*.
Thanks.
---------------------------------------------------------------------------
by tanakahisateru at 2012-05-29T13:45:12Z
Simply, potentially some users can't find represented their own posts if "4" changed to "5" silently. I think, for regular users to understand why converted so is harder than to understand why blocked his date text.
---------------------------------------------------------------------------
by fabpot at 2012-05-30T05:19:44Z
I'm +1 for this change, but only on master. @bschussek?
---------------------------------------------------------------------------
by sstok at 2012-05-30T07:44:04Z
Date parsing with 'only' the Locale component is hard, especially the extra space or using / when only - is excepted.
And there also a locale that uses dd. mm. yyyy. (dot + space).
So to overcome this I have created a little helper class https://github.com/rollerworks/Locale.
It works as follow.
1. First it searches all the numeric-script characters, and converts those to ASCII decimals
2. Then matches the converted input against an pre-compiled regex that accepts extra spaces or using '/' instead of '-', and omitting leading zero's, etc...
3. Validate the matched parts using checkdate().
I'm not suggesting to only use my Component, but making an it an option would be something to consider, no?
Like an option mode: lenient/strict/match (match is the Rollerworks Locale Component or a-like).
The only thing currently missing is Timezone parsing support, but that is not to hard.
I only have not implemented this because there was no direct need for it at the time.
---------------------------------------------------------------------------
by bschussek at 2012-05-30T07:49:11Z
@fabpot Ok. In the long run we need to find a better solution anyway.
Commits
-------
face1f1 Add 5.3.3 to Travis, now is available.
Discussion
----------
Add 5.3.3 to Travis, now is available.
---------------------------------------------------------------------------
by travisbot at 2012-05-28T12:41:45Z
This pull request [passes](http://travis-ci.org/symfony/symfony/builds/1455374) (merged face1f1b into cc42a187).
---------------------------------------------------------------------------
by fabpot at 2012-05-28T14:03:29Z
The minimum PHP version has been changed for Symfony 2.1, not for 2.0.
---------------------------------------------------------------------------
by vicb at 2012-05-28T14:29:37Z
but 5.3.2 is not available on travis, @Maks3w right ?
---------------------------------------------------------------------------
by Maks3w at 2012-05-28T14:33:05Z
@vicb 5.3.2 is not available on Travis.
@fabpot Then you can merge #4439, it's the same but for master
---------------------------------------------------------------------------
by vicb at 2012-05-28T14:43:33Z
why not keep 5.3.3 for 2.0 also (closer to 5.3.2 than just 5.3 which is 5.3.13 - best we can do).
Commits
-------
35b458f fix kernel root, linux dir separator on windows, to fix cache:clear issue
Discussion
----------
Fix cache clear windows 2.0
Hi,
This fix the issue #3453 for the 2.0 branch.
---------------------------------------------------------------------------
by travisbot at 2012-05-25T07:43:47Z
This pull request [fails](http://travis-ci.org/symfony/symfony/builds/1430935) (merged 35b458f6 into f9044e44).
Commits
-------
8da880c Fixed notice in AddCacheWarmerPass if there is no cache warmer defined.
8c6c86c Added unit tests for AddCacheWarmerPass class.
Discussion
----------
[FrameworkBundle] Fix for notice in AddCacheWarmerPass
Bug fix: yes
Feature addition: no
Backwards compatibility break: no
Symfony2 tests pass: yes
Fixes the following tickets: #4391
---------------------------------------------------------------------------
by travisbot at 2012-05-24T23:08:48Z
This pull request [fails](http://travis-ci.org/symfony/symfony/builds/1428180) (merged 8da880c3 into 7f93bf1f).
Fabien Potencier
Bernhard Schussek
Eriksen Costa
Marc Abramowitz
Victor Berchet
Maks
Christophe Coevoet
Uwe Jäger
Miha Vrhovnik
Raul Fraile
Francesc Rosàs
KUBO Atsuhiro
jaugustin
Jakub Zalas
