Permalink
Commits on Jan 11, 2013
  1. merged branch LawnGnome/PHP-5.5-compat (PR #6647)

    This PR was merged into the 2.1 branch.
    
    Commits
    -------
    
    4991607 Fix version_compare() calls for PHP 5.5.
    34def9f Handle the deprecation of IntlDateFormatter::setTimeZoneId() in PHP 5.5.
    
    Discussion
    ----------
    
    [Form] [Locale] PHP 5.5 compatibility fixes
    
    Bug fix: yes
    Feature addition: no
    Backwards compatibility break: no
    Symfony2 tests pass: yes
    Fixes the following tickets: N/A
    Todo: None
    License of the code: MIT
    Documentation PR: N/A
    
    IntlDateFormatter::setTimeZoneId() is deprecated in PHP 5.5, which results in E_DEPRECATED errors when using the date form type. This PR works around that.
    
    Furthermore, the version_compare() tests used in locale to detect PHP 5.5 are broken with snapshot and Git builds of PHP. I've also committed a fix for those tests in this PR.
    
    ---------------------------------------------------------------------------
    
    by stof at 2013-01-10T08:24:15Z
    
    shouldn't it even be done in 2.0 as it is a bugfix ?
    
    ---------------------------------------------------------------------------
    
    by LawnGnome at 2013-01-11T00:49:11Z
    
    Possibly — I don't know enough about Symfony's release management to know whether this is appropriate for 2.0, and I was mostly scratching my own itch, honestly.
    
    ---------------------------------------------------------------------------
    
    by stof at 2013-01-11T01:51:35Z
    
    well, it is a bugfix and 2.0 is also impacted, so it should be done in it.
    
    ---------------------------------------------------------------------------
    
    by LawnGnome at 2013-01-11T02:52:21Z
    
    The diff for 2.0 looks like it'll be just the StubIntlDateFormatter.php changes — the deprecated method isn't called in DateType on that branch, and there aren't any StubIntlDateFormatter tests on 2.0. How do you want that submitted — as a separate PR against 2.0?
    
    ---------------------------------------------------------------------------
    
    by fabpot at 2013-01-11T07:20:18Z
    
    @LawnGnome A separate pull request would be good. Thanks.
    
    ---------------------------------------------------------------------------
    
    by LawnGnome at 2013-01-11T08:29:48Z
    
    2.0 PR added as #6699.
    fabpot committed Jan 11, 2013
  2. Removed underscores from test method names to be consistent with othe…

    …r components.
    
    It is more common to use fully camel-cased names for test methods. Only some of the test methods are called with underscore notation. To avoid confusion it is better to be consistent.
    jakzal committed Jan 11, 2013
Commits on Jan 10, 2013
  1. Fix version_compare() calls for PHP 5.5.

    Until PHP 5.5 hits beta, the version number for Git builds is still 5.5.0-dev,
    which is less than 5.5.0alpha1 according to version_compare(). This means that
    the branches for 5.5 aren't being executed on 5.5 snapshots at present.
    LawnGnome committed Jan 10, 2013
  2. Handle the deprecation of IntlDateFormatter::setTimeZoneId() in PHP 5.5.

    Optionally use the new IntlDateFormatter::setTimeZone() method if it exists.
    LawnGnome committed Jan 10, 2013
Commits on Jan 9, 2013
Commits on Jan 7, 2013
Commits on Jan 5, 2013
Commits on Jan 4, 2013
  1. Merge branch '2.0' into 2.1

    * 2.0:
      updated license year
      Update src/Symfony/Component/HttpFoundation/Response.php
      [Console] fixed unitialized properties (closes #5935)
      [Bundle] [FrameworkBundle] fixed typo in phpdoc of the SessionListener.
      bumped Symfony version to 2.0.21-DEV
      updated VERSION for 2.0.21
      updated CHANGELOG for 2.0.21
    
    Conflicts:
    	src/Symfony/Bundle/SwiftmailerBundle/LICENSE
    	src/Symfony/Component/Filesystem/LICENSE
    	src/Symfony/Component/HttpFoundation/Response.php
    	src/Symfony/Component/HttpKernel/Kernel.php
    fabpot committed Jan 4, 2013
  2. updated license year

    fabpot committed Jan 4, 2013
Commits on Jan 3, 2013
  1. merged branch jakzal/date-type-fix (PR #6543)

    This PR was merged into the 2.1 branch.
    
    Commits
    -------
    
    6c5e615 [Form] Fixed DateType when used with the intl extension disabled.
    
    Discussion
    ----------
    
    [Form] Fixed DateType when used with the intl extension disabled
    
    DateType's month select box returns timestamps when used with intl extension disabled (see #6485).
    
    The reason for this is that stubbed formats use *L* instead of *M* for month representation. My fix is simply taking this into account when building array for the select box.
    
    I didn't provide unit tests since they're disabled when intl extension is not enabled. I've only manually verified if the months array contains correct data.
    
    Bug fix: yes
    Feature addition: no
    Backwards compatibility break: no
    Symfony2 tests pass: yes
    Fixes the following tickets: #6485
    Todo: -
    License of the code: MIT
    Documentation PR: -
    
    ---------------------------------------------------------------------------
    
    by bschussek at 2013-01-03T17:41:47Z
    
    Doesn't this call for fixing the stub instead of changing the Form component?
    
    ---------------------------------------------------------------------------
    
    by stof at 2013-01-03T17:50:49Z
    
    @bschussek L and M are both valid for the month in Intl
    
    ---------------------------------------------------------------------------
    
    by jakzal at 2013-01-03T17:52:41Z
    
    [StubIntlDateFormatter uses FullTransformer](https://github.com/symfony/symfony/blob/2.1/src/Symfony/Component/Locale/Stub/StubIntlDateFormatter.php#L206) to format the date. [FullTransformer supports both *L* and *M*](https://github.com/symfony/symfony/blob/2.1/src/Symfony/Component/Locale/Stub/DateFormat/FullTransformer.php#L50) formats. Both formats are treated interchangeably.
    fabpot committed Jan 3, 2013
Commits on Dec 29, 2012
  1. [Form] Fixed failing tests for DateTimeToStringTransformer.

    Tests were only failing at the end of the month. PHP uses current day if it is not passed. Since February was used in the test cases, date was being moved to the next month (February has less days than other months).
    jakzal committed Dec 29, 2012
Commits on Dec 28, 2012
Commits on Dec 20, 2012
Commits on Dec 15, 2012
  1. Fixed failing test

    webmozart committed with fabpot Dec 15, 2012
Commits on Dec 14, 2012
Commits on Dec 13, 2012
  1. [Form] Fixed reverse transformation of values in DateTimeToStringTran…

    …sformer
    
    The parts not given in the format are reset to the corresponding values of
    the UNIX base timestamp. For example, when parsing with the format "Y-m-d",
    parsing
    
        "2012-05-18"
    
    now results in the date
    
        "2012-05-18 00:00:00 UTC"
    
    instead of
    
        "2012-05-18 12:58:27 UTC"
    
    as before, where the time part corresponded to the local server time.
    
    Another example: When parsing with the format "H:i:s", parsing
    
        "12:58:27"
    
    now results in
    
        "1970-01-01 12:58:27 UTC"
    
    instead of
    
        "2012-12-13 12:58:27 UTC"
    
    as before, where again the date part corresponded to the local server time.
    
    This behavior is now consistent with DateTimeToArrayTransformer and
    DateTimeToLocalizedStringTransformer.
    webmozart committed Dec 13, 2012
Commits on Dec 11, 2012
  1. fixed CS

    fabpot committed Dec 11, 2012
  2. fixed CS

    fabpot committed Dec 11, 2012
  3. removed unneeded comment

    fabpot committed Dec 11, 2012
Commits on Dec 9, 2012
Commits on Dec 7, 2012
  1. merged branch bschussek/issue6141_2 (PR #6217)

    This PR was merged into the 2.1 branch.
    
    Commits
    -------
    
    6e7e08f [Form] Fixed the default value of "format" in DateType to DateType::DEFAULT_FORMAT if "widget" is not "single_text"
    
    Discussion
    ----------
    
    [Form] Fixed the "format" option in DateType
    
    Bug fix: yes
    Feature addition: no
    Backwards compatibility break: no
    Symfony2 tests pass: yes
    Fixes the following tickets: #6141
    Todo: -
    License of the code: MIT
    Documentation PR: -
    
    This PR fixes a regression introduced in #4839. To quote that PR:
    
    > This PR changes DateType and DateTimeType to support HTML5 by default when setting the option "widget" to "single_text".
    
    In reality, the "format" option now defaults to the HTML5 format always, not just when "widget" is "single_text". This is fixed here.
    
    The second commit in this PR removes special characters between select/text fields. What, with German locale, was
    
    ```
    <day input>.<month input>.<year input>
    ```
    
    before is now
    
    ```
    <day input><month input><year input>
    ```
    
    This is the way date fields are represented on the majority of websites. If you *need* separators, you can have them by setting the "format" option to a custom value:
    
    ```php
    $builder->add('myDate', 'date', array(
        'format' => 'dd.MM.yyyy',
    ));
    ```
    
    ---------------------------------------------------------------------------
    
    by fabpot at 2012-12-07T08:52:21Z
    
    The second commit should probably be done on master and it changes the behavior.
    
    ---------------------------------------------------------------------------
    
    by bschussek at 2012-12-07T12:23:22Z
    
    Ok, I removed the second commit now and removed the entries from the CHANGELOG.
    fabpot committed Dec 7, 2012
  2. [Form] Fixed the default value of "format" in DateType to DateType::D…

    …EFAULT_FORMAT if "widget" is not "single_text"
    webmozart committed Dec 6, 2012
Commits on Dec 6, 2012
Commits on Nov 29, 2012
  1. Merge branch '2.0' into 2.1

    * 2.0:
      [DependencyInjection] fixed composer.json
      [Form] Updated checks for the ICU version from 4.5+ to 4.7+ due to test failures with ICU 4.6
      fixed CS
      small fix of #5984 when the container param is not set
      fixed CS
      Use better default ports in urlRedirectAction
      Add tests for urlRedirectAction
      Update src/Symfony/Component/DomCrawler/Tests/FormTest.php
      Update src/Symfony/Component/DomCrawler/Form.php
      [Security] remove escape charters from username provided by Digest DigestAuthenticationListener
      [Security] added test extra for digest authentication
      fixed CS
      [Security] Fixed digest authentication
      [Security] Fixed digest authentication
      [SecurityBundle] Convert Http method to uppercase in the config
      Use Norm Data instead of Data
    
    Conflicts:
    	src/Symfony/Bridge/Doctrine/Form/EventListener/MergeCollectionListener.php
    	src/Symfony/Bundle/FrameworkBundle/Controller/RedirectController.php
    	src/Symfony/Component/DependencyInjection/composer.json
    fabpot committed Nov 29, 2012
Commits on Nov 25, 2012
  1. merged branch bicpi/add_hasser_hint (PR #6110)

    This PR was merged into the 2.1 branch.
    
    Commits
    -------
    
    06ee53b [Form] improve error message with a "hasser" hint for PropertyAccessDeniedException
    
    Discussion
    ----------
    
    [Form] improve error msg w/ a "hasser" hint for PropertyAccessDeniedException
    
    "Hasser" support was added under the 2.1 branch of the Form component
    
    Bug fix: no
    Feature addition: no
    Backwards compatibility break: no
    Symfony2 tests pass: no, but fails exactly the same as without this fix
    Fixes the following tickets: -
    Todo: -
    License of the code: MIT
    Documentation PR: symfony/symfony-docs#1958
    fabpot committed Nov 25, 2012
Commits on Nov 24, 2012
  1. Updated Bulgarian translation

    Added Bulgarian translation for form component.
    Updated Bulgarian translation for validator messages.
    RoumenDamianoff committed Nov 24, 2012
  2. [Form] improve error message with a "hasser" hint for PropertyAccessD…

    …eniedException
    
    Bug fix: no
    Feature addition: no
    Backwards compatibility break: no
    Symfony2 tests pass: no, but fails exactly the same as without this fix
    Fixes the following tickets: -
    Todo: -
    License of the code: MIT
    Documentation PR: symfony/symfony-docs#1958
    bicpi committed Nov 24, 2012
  3. merged branch bamarni/preloaded-extension (PR #5479)

    This PR was merged into the 2.1 branch.
    
    Commits
    -------
    
    84635bd [Form] allowed no type guesser to be registered
    
    Discussion
    ----------
    
    [Form] made the factory builder pass null when no type guesser registered
    
    reopened #5422 against 2.1 as it's a bug fix
    
    ---------------------------------------------------------------------------
    
    by stof at 2012-10-13T21:23:34Z
    
    @fabpot anything left for this PR ?
    
    ---------------------------------------------------------------------------
    
    by fabpot at 2012-10-14T09:41:29Z
    
    @bamarni Can you add some unit tests and also update the FormExtensionInterface interface phpdoc as `getTypeGuesser` can now return `null`? Thanks. ping @bschussek
    
    ---------------------------------------------------------------------------
    
    by bamarni at 2012-10-14T17:10:27Z
    
    I've added a few tests covering this.
    
    @fabpot : the phpdoc is already correct, it currently can return null, this only occurs with this convenient class.
    
    ---------------------------------------------------------------------------
    
    by bschussek at 2012-10-16T07:43:41Z
    
    This PR breaks FormFactory::createBuilderForProperty(), which expects a guesser to be present. Can you check the component for other uses of the guesser and add a null-check there?
    
    ---------------------------------------------------------------------------
    
    by bamarni at 2012-10-16T10:57:54Z
    
    I cannot find other places than the factory (searching for 'getTypeGuesser').
    
    ---------------------------------------------------------------------------
    
    by bschussek at 2012-11-08T16:58:37Z
    
    You should also adapt `FormRegistry::getTypeGuesser()` not to build a `FormTypeGuesserChain` if the array of guessers is empty. In that case it will return now `null` (adapt the doc block). We also need a different was of checking if the type guessers have already been parsed in FormRegistry. Otherwise the first if condition in `FormRegistry::getTypeGuesser()` will never become false. You could for example initialize the property `$guesser` to `false` and only set it to `null` after the first run of `getTypeGuesser()`.
    
    ---------------------------------------------------------------------------
    
    by bamarni at 2012-11-08T18:40:00Z
    
    good catch I had missed it! I've applied your suggestion in the latest commit. Do you see anything else before I squash?
    
    ---------------------------------------------------------------------------
    
    by bschussek at 2012-11-08T18:45:15Z
    
    A test for `FormRegistry::getTypeGuesser()` would of course be awesome.
    
    ---------------------------------------------------------------------------
    
    by bamarni at 2012-11-08T18:52:13Z
    
    Then it was already awesome! (see https://github.com/symfony/symfony/blob/master/src/Symfony/Component/Form/Tests/FormRegistryTest.php#L252)
    
    I've also added one for the null case if it's what you meant.
    fabpot committed Nov 24, 2012