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).
Commits
-------
7a85b43 [TwigBundle] Fixed the path to templates when using composer
Discussion
----------
[TwigBundle] Composer install
When installing the bundle and the bridge from the standalone repositories
the relative path between them is different. This simply backports the
change done in symfony 2.1 to allow using subtree repositories with 2.0.x
too.
---------------------------------------------------------------------------
by travisbot at 2012-05-22T20:54:38Z
This pull request [fails](http://travis-ci.org/symfony/symfony/builds/1404225) (merged 8784dc49 into 836443d6).
---------------------------------------------------------------------------
by travisbot at 2012-05-22T21:01:40Z
This pull request [passes](http://travis-ci.org/symfony/symfony/builds/1404321) (merged 7a85b434 into 836443d6).
When installing the bundle and the bridge from the standalone repositories
the relative path between them is different. This simply backports the
change done in symfony 2.1 to allow using subtree repositories with 2.0.x
too.
Commits
-------
40fd99e [FrameworkBundle] Added another missing dependency to Config
Discussion
----------
Yet another composer missing dep
Config is only suggested by DI, not required. So it not installed currently.
Commits
-------
03183b5 [Templating] added missing @return PHPDoc for LoaderInterface::isFresh method.
Discussion
----------
Template loader phpdoc
Bug fix: no
Feature addition: no
Backwards compatibility break: no
Symfony2 tests pass: yes
Fixes the following tickets: ~
Todo: -
License of the code: MIT
Documentation PR: ~
---------------------------------------------------------------------------
by travisbot at 2012-05-22T17:39:15Z
This pull request [passes](http://travis-ci.org/symfony/symfony/builds/1402200) (merged 03183b5b into 55faa546).
Commits
-------
47a6a29 [FrameworkBundle] Added a missing dependency to DI
Discussion
----------
Composer missing dep
The bundle class extends ContainerAware so the DI component is a required
dependency of the bundle.
---------------------------------------------------------------------------
by travisbot at 2012-05-22T20:27:14Z
This pull request [passes](http://travis-ci.org/symfony/symfony/builds/1403877) (merged 47a6a298 into 55faa546).
Commits
-------
f883953 TypeGuess fixed for Date/Time constraints
41bed29 [Form] fixed invalid 'type' option in ValidatorTypeGuesser for Date/TimeFields
Discussion
----------
[Form] fixed invalid 'type' option in ValidatorTypeGuesser for Date/TimeFields
Automatic field type guessing breaks, if you use any of the Date/Time
constraints (i.e. Symfony\Component\Validator\Constraints\DateTime), since these field types have no 'type' option defined.
(See getDefaultOptions() in DateTimeType.php)
---------------------------------------------------------------------------
by travisbot at 2012-05-10T15:25:16Z
This pull request [passes](http://travis-ci.org/symfony/symfony/builds/1296309) (merged 005bdbb0 into 68eca0f9).
---------------------------------------------------------------------------
by travisbot at 2012-05-18T15:50:39Z
This pull request [passes](http://travis-ci.org/symfony/symfony/builds/1367774) (merged f8839532 into a04acc89).
---------------------------------------------------------------------------
by TonyMalz at 2012-05-18T15:58:57Z
@bschussek Ok, changed it to 'input'
---------------------------------------------------------------------------
by bschussek at 2012-05-22T08:18:27Z
👍
Commits
-------
a450d00 [HttpFoundation] HTTP Basic authentication is broken with PHP as cgi/fastCGI under Apache
Discussion
----------
[HttpFoundation] HTTP Basic authentication is broken with php-cgi under Apache
Bug fix: yes
Feature addition: no
Backwards compatibility break: no
Symfony2 tests pass: yes
Fixes the following tickets: #1813
Todo: -
In order to work, add this to the .htaccess:
RewriteEngine on
RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule ^(.*)$ app.php [QSA,L]
---------------------------------------------------------------------------
by stof at 2012-03-10T17:34:26Z
you should also add a unit test for this
---------------------------------------------------------------------------
by kepten at 2012-03-11T15:34:04Z
Thanks for the feedback, I committed the changes.
---------------------------------------------------------------------------
by stof at 2012-04-04T01:59:53Z
@fabpot could you review it ?
---------------------------------------------------------------------------
by fabpot at 2012-04-04T07:15:34Z
My comments:
* `ServerBag` represents what we have in the `$_SERVER` global variables. As such, the code should be moved to the `getHeaders()` method instead like the other tweaks we do for the HTTP headers.
* A comment must be added explaining why this is needed and the configuration the user must have to make it work (then remove the Github URLs).
* The code should only be executed when `PHP_AUTH_USER` is not available (to not have any overhead when not needed).
---------------------------------------------------------------------------
by danielholmes at 2012-04-14T13:27:09Z
A quick note on that .htaccess/apache configuration required, if adding to the Symfony SE htaccess file, then it will need to look like this:
```
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule ^(.*)$ app.php [QSA,L]
</IfModule>
```
NOTE: No **,L** in the Authorization Rewrite as in the original example - it prevents the front controller rewrite from happening
---------------------------------------------------------------------------
by towards at 2012-04-20T16:12:49Z
@kepten you were faster than me applying @fabpot's comments :) nevertheless part of the bug hunt day I also modified the ServerBag class and tested them on a productive LAMP hosting server using Apache and FastCGI
---------------------------------------------------------------------------
by kepten at 2012-04-20T16:15:57Z
ok, so is my PR is useless or should I still fix problems?
---------------------------------------------------------------------------
by towards at 2012-04-20T16:20:26Z
your PR is fine for sure and I don't want to interfere, just wanted to mention that part of the bug hunt day of Symfony I had a go at this PR as an "exercise" but just saw later on that you already fixed the problem, so you can ignore my pushes
---------------------------------------------------------------------------
by vicb at 2012-04-20T16:20:36Z
I have been working with @towards: your PR is useful, please implement his comments and squash your PR.
---------------------------------------------------------------------------
by kepten at 2012-04-20T16:59:07Z
never squashed before, is it okay now? :)
---------------------------------------------------------------------------
by stof at 2012-04-20T17:21:07Z
it is
---------------------------------------------------------------------------
by vicb at 2012-05-20T19:57:51Z
@fabpot this should be ready to be merged
Commits
-------
fff7221 Fixed the proxy autoloading for Doctrine 2.2
Discussion
----------
Doctrine autoloading
This fixes the autoloading of proxies for Doctrine 2.2
---------------------------------------------------------------------------
by travisbot at 2012-05-17T22:36:11Z
This pull request [passes](http://travis-ci.org/symfony/symfony/builds/1361173) (merged fff72217 into b3799680).
Commits
-------
d1f0c25 Fixed the composer constraint for Doctrine Common
Discussion
----------
Common deps
This allows using Doctrine 2.2 when using the full repo as it is compatible. The workaround previously was to use the individual components as the deps was less strict in them.
Closes#4289
---------------------------------------------------------------------------
by travisbot at 2012-05-17T22:36:03Z
This pull request [passes](http://travis-ci.org/symfony/symfony/builds/1361187) (merged d1f0c254 into b3799680).