Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with
or
.
Download ZIP
Commits on Jan 10, 2013
  1. @fabpot

    merged branch vincentaubert/master (PR #6660)

    fabpot authored
    This PR was squashed before being merged into the master branch (closes #6660).
    
    Commits
    -------
    
    45c8682 [Security][Translation]Created fr translation for Security
    
    Discussion
    ----------
    
    [Security][Translation]Created fr translation for Security
    
    adds french translations for the security component
  2. @vincentaubert @fabpot
  3. @fabpot

    merged branch 1ed/patch-5 (PR #6658)

    fabpot authored
    This PR was merged into the master branch.
    
    Commits
    -------
    
    c3a6659 [Security] added Hungarian translations for exception messages
    
    Discussion
    ----------
    
    [Security] added Hungarian translations for exception messages
  4. @fabpot

    merged branch dmecke/patch-1 (PR #6657)

    fabpot authored
    This PR was merged into the master branch.
    
    Commits
    -------
    
    2f51961 Created de translation for Security
    
    Discussion
    ----------
    
    [Security][Translation]Created de translation for Security
  5. @fabpot

    merged branch dlsniper/ro-trans (PR #6654)

    fabpot authored
    This PR was merged into the master branch.
    
    Commits
    -------
    
    e35998f Translated to Romanian
    
    Discussion
    ----------
    
    [Security] Translated to Romanian
    
    Added Romanian version for Security messages.
    
    Thanks!
  6. @fabpot

    merged branch AV4TAr/spanish-translation (PR #6655)

    fabpot authored
    This PR was merged into the master branch.
    
    Commits
    -------
    
    b194607 spanish translation
    
    Discussion
    ----------
    
    Security / spanish translation
    
    Spanish Translation.
  7. @1ed
  8. @dmecke
  9. @AV4TAr

    spanish translation

    AV4TAr authored AV4TAr committed
  10. @dlsniper

    Translated to Romanian

    dlsniper authored
  11. @fabpot

    merged branch rdohms/patch-7 (PR #6653)

    fabpot authored
    This PR was merged into the master branch.
    
    Commits
    -------
    
    ff5ba38 Created PT_BR translation for Security
    
    Discussion
    ----------
    
    [Security][Translation]Created PT_BR translation for Security
    
    Added the PT_BR strings for Security strings.
  12. @rdohms

    Created PT_BR translation for Security

    rdohms authored
    Added the PT_BR strings for Security strings.
  13. @fabpot

    merged branch stof/enhance_deprecation (PR #6646)

    fabpot authored
    This PR was merged into the master branch.
    
    Commits
    -------
    
    68257d3 Enhanced the triggering of E_USER_DEPRECATED errors
    
    Discussion
    ----------
    
    Enhanced the triggering of E_USER_DEPRECATED errors
    
    Bug fix: no
    Feature addition: no
    Backwards compatibility break: no
    Deprecations: no
    Symfony2 tests pass: yes
    Fixes the following tickets: none
    
    - Removed useless error handlers around FormEvent as the triggering has
      been fixed in it.
    - Enhanced the triggering of deprecation errors for places where the BC
      method provide some user logic needing to be converted to a new way.
      For instance, AbstractType should trigger the error when the type extending it overwrites the deprecated methods instead of ``setDefaultOptions``, which was not the case previously.
    - Enhanced the deprecation messages to mention the replacement whenever
      possible.
    
    ---------------------------------------------------------------------------
    
    by stof at 2013-01-10T01:23:49Z
    
    @fabpot should I remove ``Symfony\Component\Form\Test\DeprecationErrorHandler::getFormEvent`` ? It is not used anymore in the testsuite and is not needed anymore as the constructor of FormEvent does not trigger the deprecation erronously.
    
    ---------------------------------------------------------------------------
    
    by fabpot at 2013-01-10T07:24:02Z
    
    @stof: yes, remove it then. Thanks.
    
    ---------------------------------------------------------------------------
    
    by stof at 2013-01-10T08:23:14Z
    
    done
  14. @fabpot

    merged branch asm89/issue-837 (PR #4935)

    fabpot authored
    This PR was merged into the master branch.
    
    Commits
    -------
    
    73db84f [Security] Move translations file to 'security' domain
    324703a [Security] Switch to English messages as message keys
    aa74769 [Security] Fix CS + unreachable code
    2d7a7ba [Security] Fix `AuthenticationException` serialization
    50d5724 [Security] Introduced `UsernameNotFoundException#get/setUsername`
    39da27a [Security] Removed `get/setExtraInformation`, added `get/set(Token|User)`
    837ae15 [Security] Add note about changed constructor to changelog
    d6c57cf [FrameworkBundle] Register security exception translations
    d7129b9 [Security] Fix exception constructors called in `UserChecker`
    0038fbb [Security] Add initial translations for AccountStatusException childs
    50e2cfc [Security] Add custom `getMessageKey` AccountStatusException childs
    1147977 [Security] Fix InsufficientAuthenticationException constructor calls
    79430b8 [Security] Fix AuthenticationServiceException constructor calls
    42cced4 [Security] Fix AuthenticationException constructor calls
    963a1d7 [Security] Add initial translations for the exceptions
    ed6eed4 [Security] Add `getMessageKey` and `getMessageData` to auth exceptions
    694c47c [Security] Change signature of `AuthenticationException` to match `\Exception`
    
    Discussion
    ----------
    
    [2.2][Security] AuthenticationException enhancements
    
    Bug fix: semi
    Feature addition: yes
    Backwards compatibility break: yes
    Symfony2 tests pass: [![Build Status](https://secure.travis-ci.org/asm89/symfony.png?branch=issue-837)](http://travis-ci.org/asm89/symfony)
    Fixes the following tickets: #837
    License of the code: MIT
    
    This PR adds the functionality discussed in #837 and changes the constructor of the `AuthenticationException` to match that of `\Exception`. This PR will allow developers to show a translated (save) authentication exception message to the user. :)
    
    *Todo:*
    - Add some functional test to check that the exceptions can indeed be translated?
    - Get feedback on the current English messages
    
    ---------------------------------------------------------------------------
    
    by asm89 at 2012-07-15T14:04:11Z
    
    ping @schmittjoh
    
    ---------------------------------------------------------------------------
    
    by schmittjoh at 2012-07-15T14:57:32Z
    
    Looks good to me.
    
    While you are at the exceptions, I think we can also get rid of the "extra information" thing and replace it by explicit getters/setters. Mostly that will mean adding set/getToken, set/getUser, set/getUsername. Bundles might add custom exceptions which have other data. This will make it a bit more useful and predictable.
    
    ---------------------------------------------------------------------------
    
    by asm89 at 2012-07-15T15:40:45Z
    
    @schmittjoh I removed the `get/setExtraInformation` and added the more explicit getters/setters as you suggested.
    
    ---------------------------------------------------------------------------
    
    by asm89 at 2012-07-15T19:33:15Z
    
    @fabpot Did you reschedule this for 2.2? Why? It was originally a 2.1 ticket. I think it is an important one because at the moment there is no reliable way to show users the cause of an `AuthenticationException` without the threat of exposing sensitive information. This issue has been around for a while, see the original issue this PR refers to, or for example [this TODO comment in FOSUB](https://github.com/FriendsOfSymfony/FOSUserBundle/blob/master/Controller/SecurityController.php#L37).
    
    The PR itself is ready to merge now. My only question that remains is about whether the actual translations should be functional tested?
    
    ---------------------------------------------------------------------------
    
    by fabpot at 2012-07-15T19:43:19Z
    
    We need to stop at some point. If not, we never release anything. beta3 was scheduled for today and I don't plan any other one before the first RC and I won't have time to review this PR next week. So, if you, @schmittjoh, @vicb, @stof, and a few other core devs "validate" this PR, I might consider merging it before 2.1.
    
    ---------------------------------------------------------------------------
    
    by asm89 at 2012-07-15T19:46:09Z
    
    @fabpot I totally agree with your point of view. I just have been trying to pickup some security issues that were still open. :)
    
    ---------------------------------------------------------------------------
    
    by stof at 2012-07-15T19:50:29Z
    
    This looks good to me
    
    ---------------------------------------------------------------------------
    
    by asm89 at 2012-08-12T09:06:24Z
    
    Since the beta period is over I assume the window was missed to get this security related PR in 2.1. If I have feedback from @fabpot I'll still try to make it mergeable asap though.
    
    ---------------------------------------------------------------------------
    
    by fabpot at 2012-08-13T10:10:32Z
    
    @asm89 This would indeed be considered for merging in 2.2.
    
    ---------------------------------------------------------------------------
    
    by Antek88 at 2012-10-03T10:30:46Z
    
    +1
    
    ---------------------------------------------------------------------------
    
    by stof at 2012-10-04T21:27:15Z
    
    @asm89 could you rebase this PR ? It conflicts with master
    
    ---------------------------------------------------------------------------
    
    by fabpot at 2012-10-05T17:16:44Z
    
    What's the status of this PR? @asm89 Have you taken all the feedback into account?
    
    ---------------------------------------------------------------------------
    
    by stof at 2012-10-13T17:48:48Z
    
    @asm89 ping
    
    ---------------------------------------------------------------------------
    
    by fabpot at 2012-10-29T09:48:40Z
    
    @asm89 If you don't have time, I can finish the work on this PR, but can you just tell me what's left?
    
    ---------------------------------------------------------------------------
    
    by asm89 at 2012-10-29T10:02:22Z
    
    I can pick this up, but I have two outstanding questions:
    - One about adding `::create()`? symfony#4935 (comment)
    - And what is the final verdict on the messages? symfony#4935 (comment) The initial idea was that the exception itself have an exception message which is plain english and informative for the developer. If you want to display the 'safe' user messages you have the optional dependency on the translator. There is a comparison made with the Validator component, but in my opinion that's a different case because the violations always contain the message directed at the user and have no plain english message for the developer. Apart from that the Validator component contains it's own code for replacing `{{ }}` variables in messages (duplication? not as flexible as the translator). Concluding I'd opt for: optional dependency on translator component if you want to show 'safe' user messages + message keys.
    
    @schmittjoh Any things to add?
    
    ---------------------------------------------------------------------------
    
    by schmittjoh at 2012-10-29T10:14:09Z
    
    Message keys sound good to me. I wouldn't add the ``create`` method for now.
    
    On Mon, Oct 29, 2012 at 11:02 AM, Alexander <notifications@github.com>wrote:
    
    > I can pick this up, but I have two outstanding questions:
    >
    >    - One about adding ::create()? symfony/symfony#4935<symfony#4935 (comment)>
    >    - And what is the final verdict on the messages? symfony/symfony#4935<symfony#4935 (comment) initial idea was that the exception itself have an exception message
    >    which is plain english and informative for the developer. If you want to
    >    display the 'safe' user messages you have the optional dependency on the
    >    translator. There is a comparison made with the Validator component, but in
    >    my opinion that's a different case because the violations always contain
    >    the message directed at the user and have no plain english message for the
    >    developer. Apart from that the Validator component contains it's own code
    >    for replacing {{ }} variables in messages (duplication? not as
    >    flexible as the translator). Concluding I'd opt for: optional dependency on
    >    translator component if you want to show 'safe' user messages + message
    >    keys.
    >
    > @schmittjoh <https://github.com/schmittjoh> Any things to add?
    >
    > —
    > Reply to this email directly or view it on GitHub<symfony#4935 (comment)>.
    >
    >
    
    ---------------------------------------------------------------------------
    
    by fabpot at 2012-10-29T10:27:37Z
    
    As I said in the discussion about the translations, I'm -1 for the message keys to be consistent with how we manage translations everywhere else in the framework.
    
    ---------------------------------------------------------------------------
    
    by stof at 2012-10-29T10:30:50Z
    
    @fabpot When we changed the English translation for the validation errors in 2.1, we had to tag the commit as a BC rbeak as it was changing the source for all other translations. And if you look at the state of the files now, you will see that we are *not* using the English as source anymore in some places as some validation errors have a pluralized translation but the source has not been changed.
    So I think using a key is more future-proof.
    
    ---------------------------------------------------------------------------
    
    by asm89 at 2012-10-30T19:44:49Z
    
    Any final decision on this? On one hand I have @stof and @schmittjoh +1 on message keys, on the other @fabpot -1. I guess it's your call @fabpot.
    
    Edit: also @vicb seemed to be +1 on message keys earlier on.
    
    ---------------------------------------------------------------------------
    
    by drak at 2012-11-01T20:19:00Z
    
    I am also -1, I agree with @fabpot
    
    ---------------------------------------------------------------------------
    
    by asm89 at 2012-11-12T09:38:51Z
    
    @fabpot Can you please give a definite answer on this? I personally think @stof and @vicb have good points to do message keys, but with all these different people +1 and -1'ing the PR I'm lost on what it should actually do.
    
    ---------------------------------------------------------------------------
    
    by asm89 at 2012-11-14T09:59:06Z
    
    ping @fabpot
    
    ---------------------------------------------------------------------------
    
    by asm89 at 2012-11-26T10:01:27Z
    
    ping @fabpot We talked about this in Berlin. Any final thoughts on the PR? :) One idea was to do message keys + opt depend on the translator component if you want to use them, or use your own implementation.
    
    ---------------------------------------------------------------------------
    
    by fabpot at 2012-11-26T14:01:37Z
    
    The conclusion is: keep using plain English.
    
    On Mon, Nov 26, 2012 at 11:01 AM, Alexander <notifications@github.com>wrote:
    
    > ping @fabpot <https://github.com/fabpot> We talked about this in Berlin.
    > Any final thoughts on the PR? :) One idea was to do message keys + opt
    > depend on the translator component if you want to use them, or use your own
    > implementation.
    >
    > —
    > Reply to this email directly or view it on GitHub<symfony#4935 (comment)>.
    >
    >
    
    ---------------------------------------------------------------------------
    
    by Inori at 2012-11-26T15:00:22Z
    
    is this final? if not, then +1 for message keys
    
    ---------------------------------------------------------------------------
    
    by vicb at 2012-11-27T22:33:47Z
    
    @fabpot I can't understand why we keep discussing this for months as this implementation use *both* keys and plain Englis, ie using  keys  is optional ( if it was not it would not be an issue according to #6129)
    
    ---------------------------------------------------------------------------
    
    by asm89 at 2013-01-02T21:43:46Z
    
    @fabpot @vicb I'll rebase this PR, fix the comments and refactor the message keys to use plain English + {{ }} syntax for the placeholders.
    
    ---------------------------------------------------------------------------
    
    by asm89 at 2013-01-07T15:00:58Z
    
    @fabpot If I fix this tonight, will it make the beta?
    
    ---------------------------------------------------------------------------
    
    by fabpot at 2013-01-07T15:53:00Z
    
    yes, definitely.
    
    ---------------------------------------------------------------------------
    
    by asm89 at 2013-01-07T20:13:38Z
    
    @fabpot I switched the implementation to English messages instead of message keys and fixed the final comments + rebased. Anything you want me to do after this?
    
    Still happy with `getMessageKey()`?
  15. @stof

    Enhanced the triggering of E_USER_DEPRECATED errors

    stof authored
    - Removed useless error handlers around FormEvent as the triggering has
      been fixed in it.
    - Enhanced the triggering of deprecation errors for places where the BC
      method provide some user logic needing to be converted to a new way.
    - Enhanced the deprecation messages to mention the replacement whenever
      possible.
Commits on Jan 9, 2013
  1. @fabpot

    merged branch bschussek/bugfix (PR #6630)

    fabpot authored
    This PR was merged into the master branch.
    
    Commits
    -------
    
    c1aff96 [Form] Fixed regression introduced when merging 2.1 into master
    
    Discussion
    ----------
    
    [Form] Fixed regression introduced when merging 2.1 into master
    
    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: -
  2. @webmozart
  3. @fabpot

    merged branch Tobion/relative-path (PR #3958)

    fabpot authored
    This PR was merged into the master branch.
    
    Commits
    -------
    
    6703fb5 added changelog entries
    1997e2e fix phpdoc of UrlGeneratorInterface that missed some exceptions and improve language of exception message
    f0415ed [Routing] made reference type fully BC and improved phpdoc considerably
    7db07d9 [Routing] added tests for generating relative paths and network paths
    75f59eb [Routing] add support for path-relative and scheme-relative URL generation
    
    Discussion
    ----------
    
    [2.2] [Routing] add support for path-relative URL generation
    
    Tests pass: yes
    Feature addition: yes
    BC break: <del>tiny (see below)</del> NO
    deprecations: NO
    
    At the moment the Routing component only supports absolute and domain-relative URLs, e.g.
    `http://example.org/user-slug/article-slug/comments` and
    `/user-slug/article-slug/comments`.
    
    But there are two link types missing: schema-relative URLs and path-relative URLs.
    schema-relative: e.g. `//example.org/user-slug/article-slug/comments`
    path-relative: e.g. `comments`.
    
    Both of them would now be possible with this PR. I think it closes a huge gap in the Routing component.
    Use cases are pretty common. Schema-relative URLs are for example used when you want to include assets (scripts, images etc) in a secured website with HTTPS. Path-relative URLs are the only option when you want to generate static files (e.g. documentation) that can be downloaded as an HTML archive. Such use-cases are currently not possible with symfony.
    
    The calculation of the relative path based on the request path and target path is hightly unit tested. So it is really equivalent. I found several implemenations on the internet but none of them worked in all cases. Mine is pretty short and works.
    
    I also added an optional parameter to the twig `path` function, so this feature can also be used in twig templates.
    
    Ref: This implements path-relative URLs as suggested in #3908.
    
    <del>[BC BREAK] The signature of UrlGeneratorInterface::generate changed to support scheme-relative and path-relative URLs. The core UrlGenerator is BC and does not break anything, but users who implemented their own UrlGenerator need to be aware of this change. See UrlGenerator::convertReferenceType.</del>
    
    ---------------------------------------------------------------------------
    
    by jalliot at 2012-04-16T09:56:56Z
    
    @Tobion For completeness, you should add the option to the `url` and `asset` twig functions/template helpers.
    
    ---------------------------------------------------------------------------
    
    by stof at 2012-04-16T10:46:06Z
    
    @jalliot adding the option to ``url`` does not make any sense. The difference between ``path`` and ``url`` is that ``path`` generates a path and ``url`` generates an absolute url (thus including the scheme and the hostname)
    
    ---------------------------------------------------------------------------
    
    by Tobion at 2012-04-16T12:27:49Z
    
    @stof I guess jalliot meant we could then generate scheme-relative URLs with `url`. Otherwise this would have no equivalent in twig.
    
    ---------------------------------------------------------------------------
    
    by jalliot at 2012-04-16T12:34:08Z
    
    @stof Yep I meant what @Tobion said :)
    
    ---------------------------------------------------------------------------
    
    by Tobion at 2012-04-18T11:57:04Z
    
    The $relative parameter I added besides the existing $absolute parameter of the `->generate` method was not clear enough. So I merged those into a different parameter `referenceType`. I adjusted all parts of symfony to use the new signature. And also made the default `UrlGenerator` implementation BC with the old style. So almost nobody will recognize a change. The only BC break would be for somebody who implemented his own `UrlGenerator` and did not call the parent default generator.
    Using `referenceType` instead of a simple Boolean is much more flexible. It will for example allow a custom generator to support a new reference type like http://en.wikipedia.org/wiki/CURIE
    
    ---------------------------------------------------------------------------
    
    by Tobion at 2012-04-18T13:34:58Z
    
    ping @schmittjoh considering your https://github.com/schmittjoh/JMSI18nRoutingBundle/blob/master/Router/I18nRouter.php would need a tiny change
    
    ---------------------------------------------------------------------------
    
    by schmittjoh at 2012-04-18T13:37:39Z
    
    Can you elaborate the necessary change?
    
    ---------------------------------------------------------------------------
    
    by Tobion at 2012-04-18T13:51:10Z
    
    This PR changes the signature of `generate` to be able to generate path-relative and scheme-relative URLs. So it needs to be
    `public function generate($name, $parameters = array(), $referenceType = self::ABSOLUTE_PATH)` and your implementation would need to change `if ($absolute && $this->hostMap) {` to `if (self::ABSOLUTE_URL === $referenceType && $this->hostMap) {`
    I can do a PR if this gets merged.
    
    ---------------------------------------------------------------------------
    
    by schmittjoh at 2012-04-18T13:52:14Z
    
    If I understand correctly, the old parameter still works, no?
    
    edit: Ah, ok I see what you mean now.
    
    ---------------------------------------------------------------------------
    
    by Tobion at 2012-04-18T13:56:33Z
    
    Yeah the old parameter still works but $absolute would also evaluate to true (a string) in your case for non-absolute URLs, i.e. paths.
    
    ---------------------------------------------------------------------------
    
    by Tobion at 2012-04-19T21:09:46Z
    
    ping @fabpot
    
    ---------------------------------------------------------------------------
    
    by fabpot at 2012-04-20T04:30:18Z
    
    Let's discuss that feature for 2.2.
    
    ---------------------------------------------------------------------------
    
    by Tobion at 2012-04-20T10:40:59Z
    
    What are your objections against it? It's already implemented, it works and it adds support for things that are part of a web standard. The BC break is tiny at the moment (almost nobody is affected) because the core UrlGenerator works as before. But if we waited for 2.2 it will be much harder to make the transition because 2.1 is LTS. So I think is makes sense to add it now. Furthermore it makes it much more future-proof as custom generators can more easiliy add support for other link types like CURIE. At the moment a Boolean for absolute URLs is simply too limited and also somehow inconsistent because $absolute = false stands for an absolute path. You see the awkwardness in this naming.
    
    Btw, I added a note in the changelog. And I will add documentation of this feature in symfony-docs once this is merged.
    
    ---------------------------------------------------------------------------
    
    by fabpot at 2012-04-20T12:14:32Z
    
    nobody has ever said that 2.1 would be LTS. Actually, I think we are going to wait for 2.3 for LTS.
    
    ---------------------------------------------------------------------------
    
    by Tobion at 2012-04-20T12:27:18Z
    
    Well what I meant is, the longer we wait with this, the harder to apply it.
    In 04ac1fd you modified `generate` signature for better extensibility that is not even made use of. I think changing `$abolute` param goes in the same direction and has direct use.
    
    I'd like to know your reason to wait for 2.2. Not enough time to review it, or afraid of breaking something, or marketing for 2.2?
    
    ---------------------------------------------------------------------------
    
    by stof at 2012-04-20T16:28:27Z
    
    @Tobion the issue is that merging new features forces to postpone the release so that it is tested by enough devs first to be sure there is no blocking bug in it. Big changes cannot be merged when we are hunting the remaining bugs to be able to release.
    
    ---------------------------------------------------------------------------
    
    by schmittjoh at 2012-04-20T16:42:11Z
    
    Considering the changes that have been made to the Form component, and are still being made, I think this is in comparison to that a fairly minor change.
    
    Maybe a clearer guideline on the release process, or the direction would help, and avoid confusion, or wrong expectations on contributors' part.
    
    ---------------------------------------------------------------------------
    
    by Tobion at 2012-10-05T13:52:11Z
    
    @fabpot this is ready. So if you agree with it, I would create a documentation PR.
    
    ---------------------------------------------------------------------------
    
    by stof at 2012-10-13T16:09:47Z
    
    @fabpot what do you think about this PR ?
    
    ---------------------------------------------------------------------------
    
    by Crell at 2012-11-01T16:05:01Z
    
    This feels like it's overloading the generate() method to do double duty: One, make a URl based on a route.  Two, make a  URI based on a URI snippet.  Those are two separate operations.  Why not just add a second method that does the second operation and avoid the conditionals?  (We're likely to do that in Drupal for our own generator as well.)
    
    ---------------------------------------------------------------------------
    
    by Tobion at 2012-11-01T16:38:39Z
    
    @crell: No, you must have misunderstood something. The generate method still only generates a URI based on a route. The returned URI reference can now also be a relative path and a network path. Thats all.
    
    ---------------------------------------------------------------------------
    
    by Tobion at 2012-12-13T18:30:28Z
    
    @fabpot this is ready. It is fully BC! I also improved phpdoc considerably.
    
    ---------------------------------------------------------------------------
    
    by Tobion at 2012-12-14T20:51:38Z
    
    @fabpot Do you want me to write documentation for it? I would also be interested to write about the new features of the routing component in general. I wanted to do that anyway and it would probably be a good fit for your "new in symfony" articles.
    
    ---------------------------------------------------------------------------
    
    by fabpot at 2012-12-14T20:58:16Z
    
    Im' going to review this PR in the next coming days. And to answer your second question, more documentation or better documentation is always a good thing, so go for it.
    
    ---------------------------------------------------------------------------
    
    by Tobion at 2013-01-02T21:50:20Z
    
    @fabpot ping. I added changelog entries.
  4. @fabpot

    merged branch pborreli/typo-2013 (PR #6625)

    fabpot authored
    This PR was merged into the master branch.
    
    Commits
    -------
    
    36197dc Fixed typos
    
    Discussion
    ----------
    
    Fixed typos
    
    Bug fix: no
    Feature addition: no
    Backwards compatibility break: no
    Fixes the following tickets: -
    Todo: -
    License of the code: MIT
  5. @pborreli

    Fixed typos

    pborreli authored
  6. @fabpot

    merged branch bschussek/issue5844 (PR #6137)

    fabpot authored
    This PR was merged into the master branch.
    
    Commits
    -------
    
    586a16e [Validator] Changed DefaultTranslator::getLocale() to always return 'en'
    58bfd60 [Validator] Improved the inline documentation of DefaultTranslator
    cd662cc [Validator] Added ExceptionInterface, BadMethodCallException and InvalidArgumentException
    e00e5ec [Validator] Fixed failing test
    cc0df0a [Validator] Changed validator to support pluralized messages by default
    56d61eb [Form][Validator] Added BC breaks in unstable code to the CHANGELOG
    1e34e91 [Form] Added upgrade instructions to the UPGRADE file
    b94a256 [DoctrineBridge] Adapted DoctrineBridge to translator integration in the validator
    c96a051 [FrameworkBundle] Adapted FrameworkBundle to translator integration in the validator
    92a3b27 [TwigBridge] Adapted TwigBridge to translator integration in the validator
    e7eb5b0 [Form] Adapted Form component to translator integration in the validator
    46f751c [Validator] Extracted message interpolation logic of ConstraintViolation and used the Translation component for that
    
    Discussion
    ----------
    
    [Validator] Integrated the Translator in the Validator component
    
    Bug fix: no
    Feature addition: no
    Backwards compatibility break: yes
    Symfony2 tests pass: yes
    Fixes the following tickets: #5844, #6117
    Todo: -
    License of the code: MIT
    Documentation PR: -
    
    This PR allows to replace the default message substitution strategy in the validator (`strtr()`) by passing an implementation of `Symfony\Component\Translation\TranslatorInterface`. The motivation for this are both #5844 and the need to replace the translation strategy in Drupal's integration of the Validator.
    
    In the stand-alone usage of the validator, both the translator and the default translation domain can now be passed to `ValidatorBuilderInterface`:
    
    ```php
    $validator = Validation::createValidatorBuilder()
        ->setTranslator(new MyTranslator())
        ->setTranslationDomain('validators')
        ->getValidator();
    ```
    
    References:
    
    * #5844
    * #6117
    * #6129
    * [Add a validation framework to Drupal 8](http://drupal.org/node/1845546)
    * [Add the symfony validator component to core despite Symfony potentially releasing BC-breaking updates after 2.3.](http://drupal.org/node/1849564)
    
    ---------------------------------------------------------------------------
    
    by Tobion at 2012-11-28T08:53:25Z
    
    no BC break? Looking at ValidatorBuilderInterface there is definitely one.
    
    ---------------------------------------------------------------------------
    
    by bschussek at 2012-11-28T08:55:01Z
    
    ValidatorBuilderInterface is not part of the stable API. You are not supposed to implement this interface.
    
    ---------------------------------------------------------------------------
    
    by Tobion at 2012-11-28T09:01:07Z
    
    We're not only documenting bc breaks for stable API, otherwise we could remove 90% of the upgrade file since few methods are tagged with API.
    An interface that nobody should implement?
    
    ---------------------------------------------------------------------------
    
    by bschussek at 2012-11-28T09:30:02Z
    
    The question is what to consider a BC break. Something will always break for someone. Should we consequently mark everything as BC break? I don't think so.
    
    For example, since 2.1, you are supposed to use `Validation::createValidator*()` for creating a validator. Because of that, I won't consider changing the constructor signature of `Validator` a BC break anymore from 2.1 on.
    
    The same for the unstable interfaces. These are currently meant to be used only, that is, type hint against them and call their methods. But we don't guarantee that we won't add methods to them.
    
    ---------------------------------------------------------------------------
    
    by Tobion at 2012-11-28T09:38:19Z
    
    I agree that almost any change could be considered a BC break. So we probably need to better define what a BC break is and what not. Otherwise Symfony will stop evolving after 2.3 because from then on Fabien wanted to prevent BC breaks which is almost impossible in a strict definition of bc break.
    
    ---------------------------------------------------------------------------
    
    by fabpot at 2012-11-28T11:37:22Z
    
    BC breaks should always be documented, and we guarantee BC only for things tagged with @api. I'm going to update the docs to make things clearer.
    
    ---------------------------------------------------------------------------
    
    by bschussek at 2012-11-28T13:09:57Z
    
    @fabpot I documented these changes now in the CHANGELOG: af99ebb1206ac92889b7193ba1ecc12bf2617e85
    
    Are we sure we want to document *all* BC breaks from now on, even in non-@api code? This could rather scare people looking at our changelogs (lots of BC BREAKS there).
    
    ---------------------------------------------------------------------------
    
    by fago at 2012-11-28T17:29:58Z
    
    Unfortunately, it turns out the symfony translator interface does not mach the Drupal translation system as well as we initally thought, see http://drupal.org/node/1852106. Given that, this would integrating the validator component into Drupal even harder, because it introduces the dependency on the (unwanted) translation component. :(
    
    ---------------------------------------------------------------------------
    
    by stof at 2012-11-28T18:19:36Z
    
    If this does not help Drupal anyway, maybe #5844 is a better way to manage translations for people using the validator outside forms ?
    and the Drupal guys would simply follow a similar approach, but based on their own translator instead of the symfony one.
    
    ---------------------------------------------------------------------------
    
    by fago at 2012-11-28T18:50:12Z
    
    Yeah. The only problem I see with the approach of #5844 is that *after* validation only the translated messages are available. We'd need to have access to the untranslated messages also.
    
    ---------------------------------------------------------------------------
    
    by fago at 2012-11-29T09:49:47Z
    
    As our translation system handles translating pluralized messages differently, the current ExecutionContextInterface::addViolation() method poses a problem also. We need to pass on - both the single and plural - message, as the message gets chosen during translation, see http://api.drupal.org/api/drupal/core!includes!common.inc/function/format_plural/8
    So maybe, we could allow adding an already created ConstraintViolation object also? Then, we could implement a "PluralConstraintViolation" class that takes both message templates.
    
    ---------------------------------------------------------------------------
    
    by bschussek at 2012-12-03T15:52:36Z
    
    I updated this PR to support pluralized messages by default in the validator. This should solve the problem of the Drupal guys, because their implementation of `TranslatorInterface::transChoice($id, $number, ...)` can now simply split the $id by pipes (`|`) and pass the parts to their own `format_plural($count, $singular, $plural, ...)` function.
    
    For us, it breaks BC because translation catalog sources had to be adapted.
    
    ---------------------------------------------------------------------------
    
    by fabpot at 2012-12-03T16:25:52Z
    
    Most of the XLF files are broken (the end is missing now).
    
    IIUC, we now have a hard dependency on the Translation component, which is something we wanted to avoid.
    
    ---------------------------------------------------------------------------
    
    by fabpot at 2012-12-03T16:27:56Z
    
    Oops, clicked on the "comment" button too fast.
    
    So, the dependency is hard (you need to install the dep) but light as we only rely on the translation interface from the component (when using the default translator). It looks acceptable to me, especially because we now use Composer to manage dependencies.
    
    ---------------------------------------------------------------------------
    
    by bschussek at 2012-12-03T16:54:10Z
    
    @fabpot Thanks for the hint. Going to fix this.
    
    ---------------------------------------------------------------------------
    
    by bschussek at 2012-12-04T11:34:43Z
    
    @fabpot Fixed.
    
    ---------------------------------------------------------------------------
    
    by bschussek at 2012-12-07T12:40:24Z
    
    Is there anything missing for this PR to be merged?
Commits on Jan 8, 2013
  1. @fabpot
  2. @fabpot
  3. @fabpot

    Merge branch '2.1'

    fabpot authored
    * 2.1:
      [Console] Fix style escaping parsing
      [Console] Make style formatter matching less greedy to avoid having to escape when not needed
      [Bundle] [FrameworkBundle] fixed indentation in esi.xml services file.
      [Component] [Security] fixed PSR-2 coding violation in ClassUtilsTest class.
      [Form] Fixed EntityChoiceList when loading objects with negative integer IDs
      [TwigBundle] There is no CSS visibility of display, should be visible instead
      [Form] corrected source node for a Danish translation
      [DependencyInjection] fixed a bug where the strict flag on references were lost (closes #6607)
      [HttpFoundation] Check if required shell functions for `FileBinaryMimeTypeGuesser` are not disabled
      [CssSelector] added css selector with empty string
      [HttpFoundation] Docblock for Request::isXmlHttpRequest() now points to Wikipedia
      [DependencyInjection] refactored code to avoid logic duplication
      [Form] Deleted references in FormBuilder::getFormConfig() to improve performance
      [HttpFoundation] Update docblock for non-working method
    
    Conflicts:
    	src/Symfony/Bundle/TwigBundle/Resources/views/Exception/trace.html.twig
    	src/Symfony/Bundle/TwigBundle/Resources/views/Exception/traces.html.twig
  4. @fabpot

    Merge branch '2.0' into 2.1

    fabpot authored
    * 2.0:
      [Bundle] [FrameworkBundle] fixed indentation in esi.xml services file.
      [TwigBundle] There is no CSS visibility of display, should be visible instead
      [DependencyInjection] fixed a bug where the strict flag on references were lost (closes #6607)
      [HttpFoundation] Check if required shell functions for `FileBinaryMimeTypeGuesser` are not disabled
      [CssSelector] added css selector with empty string
      [HttpFoundation] Docblock for Request::isXmlHttpRequest() now points to Wikipedia
      [DependencyInjection] refactored code to avoid logic duplication
    
    Conflicts:
    	src/Symfony/Bundle/FrameworkBundle/Resources/config/esi.xml
    	src/Symfony/Component/DependencyInjection/Dumper/PhpDumper.php
    	src/Symfony/Component/HttpFoundation/File/MimeType/FileBinaryMimeTypeGuesser.php
  5. @fabpot

    merged branch hhamon/cs_fix (PR #6621)

    fabpot authored
    This PR was merged into the 2.1 branch.
    
    Commits
    -------
    
    2155719 [Component] [Security] fixed PSR-2 coding violation in ClassUtilsTest class.
    
    Discussion
    ----------
    
    [2.1] [Component] [Security] fixed PSR-2 coding violation in ClassUtilsTest class
    
    Bug fix: no
    Feature addition: no
    Backwards compatibility break: no
    Fixes the following tickets: -
    Todo: -
    License of the code: MIT
  6. @fabpot

    merged branch hhamon/indentation_fix_esi_services_file (PR #6622)

    fabpot authored
    This PR was merged into the 2.0 branch.
    
    Commits
    -------
    
    113271c [Bundle] [FrameworkBundle] fixed indentation in esi.xml services file.
    
    Discussion
    ----------
    
    [2.x] [Bundle] [FrameworkBundle] fixed indentation in esi.xml services file.
    
    Bug fix: no
    Feature addition: no
    Backwards compatibility break: no
    Fixes the following tickets: -
    Todo: -
    License of the code: MIT
  7. @fabpot

    merged branch Seldaek/stylefix (PR #6623)

    fabpot authored
    This PR was merged into the 2.1 branch.
    
    Commits
    -------
    
    eb93e66 [Console] Fix style escaping parsing
    8ca1b80 [Console] Make style formatter matching less greedy to avoid having to escape when not needed
    
    Discussion
    ----------
    
    [Console] Fix output formatting issues
    
    Bug fix: yes
    Feature addition: no
    Backwards compatibility break: no
    Symfony2 tests pass: yes
    License of the code: MIT
  8. @Seldaek
  9. @Seldaek
  10. @hhamon
  11. @webmozart
  12. @webmozart
  13. @hhamon
  14. @webmozart
Something went wrong with that request. Please try again.