* 2.1:
Options small typo
[Console] fixed unparsed StringInput tokens
[TwigBridge] fixed trans twig extractor
[DomCrawler] fix handling of schemes by Link::getUri()
[Console] Fixed comment
[TwigBridge] fixed the translator extractor that were not trimming the text in trans tags (closes#7056)
Fixed handling absent href attribute in base tag
added a DebuClassLoader::findFile() method to make the wrapping less invasive
fixed CHANGELOG
bumped Symfony version to 2.1.9-DEV
updated VERSION for 2.1.8
updated CHANGELOG for 2.1.8
StringInput resets the given options.
Conflicts:
src/Symfony/Component/HttpKernel/Kernel.php
This PR was merged into the 2.1 branch.
Commits
-------
5b19c89 [Console] fixed unparsed StringInput tokens
635b1fc StringInput resets the given options.
Discussion
----------
[Console] fixes unparsed StringInput tokens
`StringInput` instances call `setToken` after constructor, `parse` method is called in constructor, so `StringInput` tokens where never parsed.
| Q | A
| ------------- | ---
| Bug fix? | yes
| New feature? | no
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | #6749
This PR was merged into the 2.2 branch.
Commits
-------
da22926 [Validator] gracefully handle transChoice errors
Discussion
----------
[Validator] gracefully handle transChoice errors
This validator annotation was throwing an error for me:
```
/** @Assert\Length(min=6, minMessage="Must be 6 characters") */
```
To avoid this error in the current code I would need to provide a message template that accommodates the minimum length being 1, even though that's not the case.
| Q | A
| ------------- | ---
| Bug fix? | yes
| New feature? | no
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | ~
| License | MIT
| Doc PR | ~
---------------------------------------------------------------------------
by kriswallsmith at 2013-02-25T19:41:51Z
ping @fabpot
Any thoughts on this change? Having to provide a transChoice template when you know what the pluralization is going to be is a pain in the neck.
---------------------------------------------------------------------------
by kriswallsmith at 2013-02-25T19:42:11Z
ping @bschussek too :)
---------------------------------------------------------------------------
by fabpot at 2013-02-25T19:57:08Z
I'm +1 for this change. What do you think @bschussek?
---------------------------------------------------------------------------
by vicb at 2013-02-26T10:44:33Z
Would this be a common enough use case to be pushed to the translator ?
A link (anchor tag with an href attr) in crawled by the Crawler
can contain any valid URI, including mailto: links.
Currently this is not correctly supported by Link::getUri.
Schemes that do not start with 'http' are treated as relative URIs
and appenden to the base URI. This leads to strange URIs like this:
http://foo.com/mailto:foo@bar.com
Fixed Link::getUri to treat any URI with a schema part as an
absolute URL. Updated the unit tests to test for this.
This PR was merged into the 2.1 branch.
Commits
-------
0690709 added a DebuClassLoader::findFile() method to make the wrapping less invasive
Discussion
----------
added a DebuClassLoader::findFile() method to make the wrapping less invasive
| Q | A
| ------------- | ---
| Bug fix? | yes
| New feature? | no
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | -
| License | MIT
i have classified it as a bug fix, since due to the wrapping it can break assumptions about the loaded class loader, so implementing this method at least doesnt break the assumption that ``findFile()`` is available.
actually i think we should also introduced a loader interface to reduce the duct typing
---------------------------------------------------------------------------
by stof at 2013-02-24T16:39:46Z
👎 for the interface:
- it would make the use of the autoloader more difficult (you would have to require the interface before requiring the loader)
- it would forbid using these wrappers with the composer ClassLoader
---------------------------------------------------------------------------
by digitalkaoz at 2013-02-24T19:16:36Z
mh, i think all autoloaders should follow a common interface, maybe its worth to think about a PSR?
---------------------------------------------------------------------------
by lsmith77 at 2013-02-24T19:27:27Z
ah I see
---------------------------------------------------------------------------
by stof at 2013-02-24T20:33:07Z
@digitalkaoz Such an interface would have to be in PHP itself, otherwise, you would have to require it first each time (as it cannot be autoloaded before registering the autoloader). And an autoloader in PHP is just a callable.
---------------------------------------------------------------------------
by digitalkaoz at 2013-02-24T20:47:10Z
Yes @stof, i know, but it would be nice if all autoloaders follows a common pattern , call it a convention ;)
* 2.1:
Defined stable version point of Doctrine.
[HttpFoundation] Remove Cache-Control when using https download via IE<9 (fixes#6750)
Update composer.json
[Form] Fixed TimeType not to render a "size" attribute in select tags
[Form] Added test for "label" option to accept the value "0"
Expanded fault-tolerance for unusual cookie dates
Fix docblock type
[Form] Fixed "label" option to accept the value "0"
merged branch jfcixmedia/2.1 (PR #5838)
[DomCrawler] lowered parsed protocol string (fixes#6986)
Conflicts:
composer.json
src/Symfony/Bridge/Twig/Resources/views/Form/form_div_layout.html.twig
src/Symfony/Bundle/FrameworkBundle/Resources/views/Form/time_widget.html.php
src/Symfony/Bundle/FrameworkBundle/composer.json
src/Symfony/Component/Form/Tests/Extension/Csrf/EventListener/CsrfValidationListenerTest.php
src/Symfony/Component/Routing/composer.json
src/Symfony/Component/Security/composer.json
src/Symfony/Component/Validator/composer.json
This PR was squashed before being merged into the 2.1 branch (closes#7153).
Commits
-------
b2080c4 [HttpFoundation] Remove Cache-Control when using https download via IE<9 (fixes#6750)
Discussion
----------
[HttpFoundation] Remove Cache-Control when using https download via IE<9 (fixes#6750)
| Q | A
| ------------- | ---
| Bug fix? | yes
| New feature? | no
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | #6750
| License | MIT
| Doc PR |
This PR was merged into the 2.1 branch.
Commits
-------
b7bd630 [Form] Fixed TimeType not to render a "size" attribute in select tags
Discussion
----------
[Form] Fixed TimeType not to render a "size" attribute in select tags
| Q | A
| ------------- | ---
| Bug fix? | yes
| New feature? | no
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | #6153
| License | MIT
| Doc PR | -
This PR was merged into the 2.2 branch.
Commits
-------
54d7d25 [HttpKernel] hinclude fragment renderer must escape URIs properly to return valid html
Discussion
----------
[HttpKernel] hinclude fragment renderer must escape URIs properly to return valid html
| Q | A
| ------------- | ---
| Bug fix? | [yes]
| New feature? | [no]
| BC breaks? | [no]
| Deprecations? | [no]
| Tests pass? | [yes]
| Fixed tickets | [-]
| License | MIT
| Doc PR | [-]
Since rendering of hinclude fragments returns html/xml, it is marked as safe. So it's not auto-escaped of course. But that means it must properly escape it's input (the URI) when outputting in html context.
Btw, this does not need to be done for esi because esi tags are processed in middleware which do not go to the client/browser.
---------------------------------------------------------------------------
by Koc at 2013-02-15T22:59:05Z
Will it works correct when `arg_separator.output="&"`?
---------------------------------------------------------------------------
by stof at 2013-02-15T23:04:01Z
if your url comes form the routing, yes. It [does not rely on the default separator](https://github.com/symfony/Routing/blob/master/Generator/UrlGenerator.php#L265) to avoid issues when the separator is configured to ``&`` as it would have been escaped again in Twig templates for instance.
---------------------------------------------------------------------------
by fabpot at 2013-02-16T07:26:19Z
Can you include the proper PR header in the description? Thanks.
---------------------------------------------------------------------------
by Tobion at 2013-02-16T12:28:18Z
Added.
This PR was squashed before being merged into the master branch (closes#5838).
Commits
-------
201f3e6 [Form] Fixed cannot unset string offsets in CsrfValidationListener
Discussion
----------
[Form] Fixed cannot unset string offsets in CsrfValidationListener
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: -
A php fatal error is happening when someone rewrite the entire form data for an object with a single input.
```
Fatal error: Cannot unset string offsets in vendor/symfony/symfony/src/Symfony/Component/Form/Extension/Csrf/EventListener/CsrfValidationListener.php on line 72
```
Example:
```html
<form action="/app_dev.php/post/create" method="post" >
<div id="posttype">
<div>
<label for="posttype_name" class="required">Name</label>
<input type="text" id="posttype_name" name="posttype[name]" required="required" maxlength="255" />
</div>
<div>
<label for="posttype_text" class="required">Text</label>
<textarea id="posttype_text" name="posttype[text]" required="required"></textarea>
</div>
<input type="hidden" id="posttype__token" name="posttype[_token]" value="83a1617c694fbdea43c2527f1a55c7419ce82a42" /></div>
<p>
<button type="submit">Create</button>
</p>
</form>
```
If someone alters the html to add a simple input at the bottom of the form like this one:
```html
<input type="text" id="posttype" name="posttype" value="test123" />
```
The result will be a php fatal error.
---------------------------------------------------------------------------
by bschussek at 2012-10-26T09:49:05Z
Thank you for the pull request! Could you please reference the pull request in the test?
```php
// https://github.com/symfony/symfony/pull/5838
public function testStringFormData()
{
...
```
---------------------------------------------------------------------------
by jfcixmedia at 2012-10-26T10:21:29Z
@bschussek Added, thanks.
This PR was merged into the 2.1 branch.
Commits
-------
3e40c17 [HttpKernel] fixed locale management when exiting sub-requests
Discussion
----------
[HttpKernel] fixed locale management when exiting sub-requests
| Q | A
| ------------- | ---
| Bug fix? | yes
| New feature? | no
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | #7063
| License | MIT
| Doc PR | n/a
This fix is temporary as #7007 will fix it properly in Symfony 2.3.
---------------------------------------------------------------------------
by vicb at 2013-02-17T20:17:44Z
changelog ?
---------------------------------------------------------------------------
by fabpot at 2013-02-17T20:27:22Z
The changelogs are updated when we release a new version only.
---------------------------------------------------------------------------
by stof at 2013-02-17T20:41:00Z
@fabpot the intl locale should be reset to the right value too
---------------------------------------------------------------------------
by stof at 2013-02-17T20:42:31Z
hmm sorry, I missed the fact that you are changing the locale in the Request again, which will set the intl one
This PR was merged into the 2.2 branch.
Commits
-------
a313188 added a proper setter for the templating servicein HInclude
Discussion
----------
added a proper setter for the templating servicein HInclude
| Q | A
| ------------- | ---
| Bug fix? | yes
| New feature? | no
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | n/a
| License | MIT
| Doc PR | n/a
---------------------------------------------------------------------------
by stof at 2013-02-17T12:44:40Z
👍
This PR was merged into the 2.2 branch.
Commits
-------
738de9a [HttpKernel] added a unit for the previous commit (closes#7025)
d0e4b76 [HttpFoundation] fixed, overwritten CONTENT_TYPE
Discussion
----------
Fixed content type when passed as a server value
| Q | A
| ------------- | ---
| Bug fix? | yes
| New feature? | no
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | #7025
| License | MIT
| Doc PR | n/a
---------------------------------------------------------------------------
by stof at 2013-02-17T14:51:35Z
👍
* 2.1:
[FrameworkBundle] tweaked reference dumper command (see #7093)
[HttpKernel] added some tests for previous merge
Fix REMOTE_ADDR for cached subrequests
[Process] Warn user with a useful message when tmpfile() failed
Conflicts:
src/Symfony/Bundle/FrameworkBundle/Command/ConfigDumpReferenceCommand.php
This PR was merged into the 2.2 branch.
Commits
-------
b240d1f [BrowserKit] added a test to make sure HTTP authentication is preserved when submitting a form
Discussion
----------
[WIP]BrowserKit] added a test to make sure HTTP authentication is preserved
| Q | A
| ------------- | ---
| Bug fix? | no
| New feature? | no
| BC breaks? | no
| Deprecations? | no
| Tests pass? | no
| Fixed tickets |
| License | MIT
| Doc PR |
Since #6995 BrowseKit no longer seems to preserve the HTTP authentication when submitting a form. This PR adds a test to demonstrate the failure.
---------------------------------------------------------------------------
by vicb at 2013-02-13T12:49:16Z
Thanks. Could you add a "[WIP]" prefix to the PR tittle and set "bug fix" to "no" for now ?
---------------------------------------------------------------------------
by sstok at 2013-02-13T13:59:42Z
done 👍
---------------------------------------------------------------------------
by fabpot at 2013-02-17T12:49:35Z
This cannot be related to #6995 as your test does not involve any HttpFoundation classes.
This PR was merged into the 2.2 branch.
Commits
-------
cb319ac [HttpKernel] added error display suppression when using the ErrorHandler (if not, errors are displayed twice, refs #6254)
Discussion
----------
[HttpKernel] added error display suppression when using the ErrorHandler (if not, errors are displayed twice, refs #6254)
| Q | A
| ------------- | ---
| Bug fix? | yes
| New feature? | no
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | n/a
| License | MIT
| Doc PR | n/a
---------------------------------------------------------------------------
by bamarni at 2013-02-15T10:15:29Z
Are you sure this fixes the twice displaying issue? This is already done here : https://github.com/symfony/symfony/blob/master/src/Symfony/Component/HttpKernel/Kernel.php#L99
Fatal errors are displayed twice in some situations because this handler gets registered twice, and it registers 2 times the same shutdown callback, a few lines below your change.
---------------------------------------------------------------------------
by fabpot at 2013-02-15T10:21:39Z
No, I've closed this #6254 as this is an Assetic issue, not a Symfony one.
This PR was squashed before being merged into the 2.2 branch (closes#6999).
Commits
-------
de0f7b7 [HttpFoundation] Added getter for httpMethodParameterOverride state
Discussion
----------
[HttpFoundation] Added getter for httpMethodParameterOverride state
| Q | A
| ------------- | ---
| Bug fix? | no
| New feature? | yes
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | #6984
| License | MIT
| Doc PR | ~
* 2.1:
added support for the X-Forwarded-For header (closes#6982, closes#7000)
fixed the IP address in HttpCache when calling the backend
[EventDispatcher] Added assertion.
[EventDispathcer] Fix removeListener
[DependencyInjection] Add clone for resources which were introduced in 2.1
[DependencyInjection] Allow frozen containers to be dumped to graphviz
Fix 'undefined index' error, when entering scope recursively
[Security] fixed session creation on login (closes#7011)
Add dot character `.` to legal mime subtype regular expression
[HttpFoundation] fixed the creation of sub-requests under some circumstancies (closes#6923, closes#6936)
This PR was squashed before being merged into the 2.2 branch (closes#6972).
Commits
-------
4cbdbcb [Validator] Add check for existing metadata on property
Discussion
----------
[Validator] Add check for existing metadata on property
| Q | A
| ------------- | ---
| Bug fix? | no (sort of)
| New feature? | no
| BC breaks? | no (I don't think so)
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | ~
| License | MIT
| Doc PR | ~
Todo:
- [x] Check if the new method should be added to the interface as well.
This adds a check for metadata existence before usage else the code will emit a warning.
This should not be a BC break or a bug fix as the patched code is 2.2 specific.
@bschussek let me know if I should add the method in the interface as well. Thank you.
---------------------------------------------------------------------------
by vicb at 2013-02-05T10:40:56Z
Strictly speaking this is a BC break (you are adding a public method). But I guess we should better defined what should be describe as BC break - I have asked myself the same question more than one time /cc @fabpot
Please also add a UT and a note in the changelog.
---------------------------------------------------------------------------
by dlsniper at 2013-02-05T11:26:30Z
@vicb thanks for input. In this case I guess I should add the method to the interface as well.
As for unit tests I'll add them soon as well.
---------------------------------------------------------------------------
by fabpot at 2013-02-05T14:19:14Z
Can you add a test?
---------------------------------------------------------------------------
by dlsniper at 2013-02-05T15:57:12Z
I'll do it tonight as I've bumped into some work related issues.
---------------------------------------------------------------------------
by fabpot at 2013-02-11T11:11:12Z
Just for the record, this is not a BC break as the interface was added in 2.2.
This PR was merged into the 2.2 branch.
Commits
-------
73aa7d1 replaced usage of the deprecated pattern routing key (replaced with path)
Discussion
----------
replaced usage of the deprecated pattern routing key (replaced with path)
| Q | A
| ------------- | ---
| Bug fix? | no
| New feature? | no
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | n/a
| License | MIT
| Doc PR | n/a
---------------------------------------------------------------------------
by lsmith77 at 2013-02-07T13:35:54Z
do we have tests to cover the BC behavior?
---------------------------------------------------------------------------
by fabpot at 2013-02-07T16:30:31Z
I've just added some tests for the legacy way.
This PR was merged into the 2.2 branch.
Commits
-------
0e4a1fe updated required versions when depending on the HttpFoundation component
2704705 updated required versions when depending on the HttpKernel component
0a70fe7 updated required versions when depending on the Config component
2f1939b updated required versions when depending on the Form component
719628a updated required versions when depending on the DependencyInjection component
3db311a updated required versions when depending on the Validator component
a671313 updated required versions when depending on the Translation component
289ccfc updated required versions when depending on the Routing component
a742f0a updated required versions when depending on the EventDispatcher component
51857fe updated required versions when depending on the OptionsResolver component
20dfc15 updated required versions when depending on the PropertyAccess component
f971ccf updated required versions when depending on the Security component
da06817 updated required versions when depending on the Templating component
108a8c0 updated required versions when depending on the Stopwatch component
155cccb updated required versions when depending on the Process component
b95184b updated required versions when depending on the Finder component
a5da4a1 updated required versions when depending on the Dom Crawler component
0d74948 use ~2.0 when depending on the Dom Crawler component
d2d4c0a use ~2.1 when depending on the ClassLoader component
4def221 use ~2.0 when depending on the CSS selector component
9b64be2 use ~2.0 when depending on the locale component
c3906a4 updated required versions when depending on the Yaml component
Discussion
----------
Update Composer deps
| Q | A
| ------------- | ---
| Bug fix? | no
| New feature? | no
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | n/a
| License | MIT
| Doc PR | n/a
Since we adopted Composer in Symfony, we limit the Symfony Components deps for any Symfony Component to the current version of Symfony. That's very limited as for instance, any version of Yaml can be used as a dependency for any other Symfony Component. So, this PR changes the version constraints for dependencies to the largest range possible.
The idea is also to open the range even more when new versions of Symfony comes.
---------------------------------------------------------------------------
by bamarni at 2013-02-08T17:40:41Z
👍closes#5891
---------------------------------------------------------------------------
by canni at 2013-02-08T23:42:04Z
👍
---------------------------------------------------------------------------
by simensen at 2013-02-09T05:35:41Z
👍
I think this is a great idea but it opens up the potential for internal version conflicts between components. The increased maintenance is probably worth it, though. :)
Several packages on Packagist are currently broken (see #6983) and I think this would fix that. A number of my projects have been forced back to 2.2@RC in favor of staying on 2.3@dev so I'm excited to see this resolved one way or another.
---------------------------------------------------------------------------
by vicb at 2013-02-09T10:06:36Z
Would the right way to fix this issue be semantic versioning ?
According to rfc2616 (http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.35.1)
byte positions are inclusive:
The first-byte-pos value in a byte-range-spec gives the byte-offset of
the first byte in a range. The last-byte-pos value gives the byte-offset
of the last byte in the range; that is, the byte positions specified are
inclusive. Byte offsets start at zero.
* 2.0:
[DependencyInjection] Allow frozen containers to be dumped to graphviz
Add dot character `.` to legal mime subtype regular expression
[HttpFoundation] fixed the creation of sub-requests under some circumstancies (closes#6923, closes#6936)
This PR was merged into the 2.0 branch.
Commits
-------
a12744e Add dot character `.` to legal mime subtype regular expression
Discussion
----------
[HttpFoundation][2.0] Add dot character `.` to legal mime subtype regular expression
| Q | A
| ------------- | ---
| Bug fix? | yes
| New feature? | no
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| License | MIT
For example, the following mimetype (used for Microsoft powerpoints) is not recognized given the current regexp : `application/vnd.ms-powerpoint; charset=binary`
This PR was merged into the 2.2 branch.
Commits
-------
5a2caa5 [HttpKernel] fixed the hinclude fragment renderer when the template is empty
Discussion
----------
[HttpKernel] fixed the hinclude fragment renderer when the template is empty
| Q | A
| ------------- | ---
| Bug fix? | yes
| New feature? | no
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | n/a
| License | MIT
| Doc PR | n/a
---------------------------------------------------------------------------
by lsmith77 at 2013-02-07T13:36:58Z
does it make sense to allow the template to be empty? i mean isnt this instead an error condition?
---------------------------------------------------------------------------
by fabpot at 2013-02-07T16:16:04Z
Why not? An empty template means and empty content, which you might want as this is just the fallback content displayed when the real content is not loaded yet.
This PR was merged into the 2.2 branch.
Commits
-------
bc4a0e7 [HttpFoundation] fixed Request::create() method
Discussion
----------
[HttpFoundation] fixed Request::create() method
| Q | A
| ------------- | ---
| Bug fix? | yes
| New feature? | no
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | n/a
| License | MIT
| Doc PR | n/a
When creating a Request with Request::create(), some information can
come from the URI and the server variable. Until now, it was not clear
which information had precedence over the other and as a matter of fact,
this method was not consistent.
Now, information contained in the URI always take precedence over
information coming from the server array. That makes sense as the server
array is often copied from another existing Request object.
---------------------------------------------------------------------------
by vicb at 2013-02-07T14:42:15Z
You should add a note in the changelog
When creating a Request with Request::create(), some information can
come from the URI and the server variable. Until now, it was not clear
which information had precedence over the other and as a matter of fact,
this method was not consistent.
Now, information contained in the URI always take precedence over
information coming from the server array. That makes sense as the server
array is often copied from another existing Request object.
This PR was merged into the 2.2 branch.
Commits
-------
3053194 [DependencyInjection] enhanced some error messages
Discussion
----------
[DependencyInjection] enhanced some error messages
| Q | A
| ------------- | ---
| Bug fix? | no
| New feature? | no
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | n/a
| License | MIT
| Doc PR | n/a
* 2.1:
[HttpKernel] fixed the creation of the Profiler directory
[Security] fixed session creation when none is needed (closes#6917)
[FrameworkBundle] removed obsolete comment (see 2e356c1)
This PR was merged into the 2.2 branch.
Commits
-------
badb2b9 Add "'property_path' => false" deprecation message for forms
Discussion
----------
Add "'property_path' => false" deprecation message for forms
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.
This PR was merged into the 2.2 branch.
Commits
-------
35b62ac [Security] renamed Constraint namespace to Constraints for validator classes in order to be consistent with the whole current validator API.
Discussion
----------
[Security] renamed Constraint namespace to Constraints for validator classes in order to be consistent with the whole current validator API.
| Q | A
| ------------- | ---
| Bug fix? | no
| New feature? | no
| BC breaks? | yes (for people already using the ``UserPassword`` constraint class in their code)
| Deprecations? | yes
| Tests pass? | yes
| Fixed tickets | -
| License | MIT
| Doc PR | -
This PR was merged into the 2.2 branch.
Commits
-------
a433ba2 [Security] [Tests] added unit tests for the UserPasswordValidator class and made the validator service for the UserPassword constraint configurable.
Discussion
----------
[Security] [Tests] added unit tests for the UserPasswordValidator class ...
...and made the validator service for the UserPassword constraint configurable.
| Q | A
| ------------- | ---
| Bug fix? | no
| New feature? | no
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | -
| License | MIT
| Doc PR | -
This PR was merged into the 2.2 branch.
Commits
-------
8f8d6cf [HttpKernel] fixed regression when rendering an inline controller and passing some objects (closes#6822)
Discussion
----------
[HttpKernel] fixed regression when rendering an inline controller and passing some objects (closes#6822)
| Q | A
| ------------- | ---
| Bug fix? | yes
| New feature? | no
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | #6822
| License | MIT
| Doc PR | n/a
This PR was merged into the 2.1 branch.
Commits
-------
e7624b6 [Security] Add PHPDoc to AuthenticationEvents
Discussion
----------
[Security] Added PHPDoc to AuthenticationEvents
| Q | A
| ------------- | ---
| Bug fix? | no
| New feature? | no
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets |
| License | MIT
| Doc PR |
HttpContentRenderer has been renamed to FragmentHandler.
The RendererStrategy subnamespace has been renamed to Fragment.
The strategy classes now have Fragment in their names.
ProxyRouterListener has been renamed to FragmentListener
The router_proxy configuration entry has been renamed to fragments.
This PR was merged into the master branch.
Commits
-------
b1d1168 Fixed the NullLogger to implement the HttpKernel interface again
Discussion
----------
Fixed the NullLogger to implement the HttpKernel interface again
| Q | A
| ------------- | ---
| Bug fix? | yes
| New feature? | no
| BC breaks? | no (reverting one introduced by mistake)
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets |
| License | MIT
| Doc PR | n/a
This BC breaking mistake has been reported in https://github.com/schmittjoh/JMSSecurityExtraBundle/pull/105#issuecomment-12908659
This PR was squashed before being merged into the master branch (closes#6852).
Commits
-------
fde7585 [DIC] Better handling of enableable configurations
Discussion
----------
[DIC] Better handling of enableable configurations
| Q | A
| ------------- | ---
| Bug fix? | yes
| New feature? | no
| BC breaks? | no, this feature has not been released yet
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | -
| License | MIT
| Doc PR | -
My definition of bug fix might be discussable. The thing which I think is not discussable is that this PR fixes the semantic - and I think it is important for a "semantic configuration": before this PR, some nodes had `->canBeDisabled` for nodes that were actually disabled by default. Those nodes now have `->canBeEnabled` which sounds right.
**Edit: Jan 28, 2013** - history:
See [the related comments](https://github.com/symfony/symfony/pull/6829#discussion_r2727742).
I think Symfony **must** get the configuration right as we can expect of lot of devs to use this as a template when writting their own configuration.
@schmittjoh could you please give me your feedback on [this change](https://github.com/symfony/symfony/pull/6852/files#L4R224) considering [the rationale](https://github.com/symfony/symfony/pull/6852/files#L3R7).
---------------------------------------------------------------------------
by stof at 2013-01-23T16:10:33Z
@vicb your links are broken as they are pointing to the PR creation page
---------------------------------------------------------------------------
by stof at 2013-01-23T16:10:55Z
and to create a TODO list, it has to be a list first
---------------------------------------------------------------------------
by vicb at 2013-01-23T16:31:10Z
@stof thanks for reporting the broken links, they are fixed /cc @schmittjoh
---------------------------------------------------------------------------
by vicb at 2013-01-23T16:31:50Z
@Tobion please submit a PR to my repo, I don't have much time to work on this. Thanks !
---------------------------------------------------------------------------
by vicb at 2013-01-25T15:14:47Z
@fabpot @schmittjoh I'd like your feedback on the latest commit, rationale is in the method phpDoc. It better matches what we do now and seem the most sensible thing to do.
edit: with this you can no more disable the node explicitly, I have to find a better solution
---------------------------------------------------------------------------
by schmittjoh at 2013-01-25T15:20:13Z
Looks good.
On Fri, Jan 25, 2013 at 4:15 PM, Victor Berchet <notifications@github.com>wrote:
> @fabpot <https://github.com/fabpot> @schmittjoh<https://github.com/schmittjoh>I'd like your feedback on the latest commit, rationale is in the method
> phpDoc. It better matches what we do now and seem the most sensible thing
> to do.
>
> —
> Reply to this email directly or view it on GitHub<https://github.com/symfony/symfony/pull/6852#issuecomment-12704585>.
>
>
---------------------------------------------------------------------------
by vicb at 2013-01-28T14:37:57Z
@fabpot I know I keep insisting on this one and I am sorry for that but I think this should be considered as a bug fix (see the PR header for details) and should be merged in 2.2. I think the Symfony core should be exemplary as it is used by many developers as a template when creating their own bundle. *This PR is no more a WIP and can be merged right now*.
In addition to fixing the enableable nodes, this PR contain new UTs and some fixes to the code / tests.
---------------------------------------------------------------------------
by fabpot at 2013-01-28T16:43:42Z
@vicb As explained in a comment, this is not a BC break as this feature does not exist in 2.1. So, I can make the change to the CHANGELOG if you want after merging, or I can let you make the change.
---------------------------------------------------------------------------
by vicb at 2013-01-28T16:46:33Z
I am going to change it right now !
---------------------------------------------------------------------------
by vicb at 2013-01-28T16:46:56Z
(and thanks for having checked this)
---------------------------------------------------------------------------
by vicb at 2013-01-28T16:54:37Z
@fabpot I have updated the changelog and the PR header.
I am not sure if the commits should be squashed or not. On one side the multiple commits can help understand the changes but on the other side that's a lot of small commits which could pollute history. I let you choose what to do.
This PR was merged into the master branch.
Commits
-------
e3086cc [Console] added some missing information in the phpdoc (closes#6464)
Discussion
----------
[Console] added some missing information in the phpdoc (closes#6464)
| Q | A
| ------------- | ---
| Bug fix? | no
| New feature? | no
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | #6464
| License | MIT
| Doc PR | n/a
This PR was merged into the master branch.
Commits
-------
ed64413 removed deprecated message in FieldType
Discussion
----------
removed deprecated messages coming for internal calls
| Q | A
| ------------- | ---
| Bug fix? | no
| New feature? | no
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | #6407
| License | MIT
| Doc PR | n/a
It's probably not the cleanest code possible, but I don't see any other way to keep the type for BC and avoid the deprecated message when called internally.
That should fix the deprecated messages thrown by the Form and Validator components.
---------------------------------------------------------------------------
by stof at 2013-01-24T15:41:26Z
The cases where you should actually be warned about the deprecation of FieldType is when using ``field`` to create a field with the factory (which would not trigger the constructor)
---------------------------------------------------------------------------
by fabpot at 2013-01-24T15:46:23Z
@stof: what do you mean? That we can remove the `trigger_error()` call altogether?
---------------------------------------------------------------------------
by stof at 2013-01-24T15:49:31Z
Nobody will ever instantiate the FieldType directly as the framework is registering it (btw, you are missing the FrameworkBundle lazy registration here).
The constructor of a form type is not the right place to deprecate it as registering it does not mean it will be used in the app.
---------------------------------------------------------------------------
by fabpot at 2013-01-24T15:51:26Z
@stof: I've updated the PR to remove the `trigger_error` call.
This PR was merged into the master branch.
Commits
-------
8bfd7a7 Remove custom error handler for deprecations
efbff0c Change deprecated Min and Max constraint
c47f027 [Validator][Constraints] Update AllValidator using new Validator API
Discussion
----------
[Validator][Constraints] Update AllValidator using new Validator API
Bug fix: yes
Feature addition: no
Backwards compatibility break: no
Symfony2 tests pass: yes
Fixes the following tickets:
License of the code: MIT
This PR was merged into the master branch.
Commits
-------
9264431 Remove custom error handler for deprecations
c80c17e Change deprecated Min constraint to Range constraint
a39fdd8 Remove getPropertyPath in the tests
ffa4c6f [Validator][Constraints] CollectionValidator
Discussion
----------
[Validator][Constraints] Update CollectionValidator using new Validator API
Bug fix: yes
Feature addition: no
Backwards compatibility break: no
Symfony2 tests pass: yes
Fixes the following tickets: #6648
License of the code: MIT
In the tests `$i = 1` is because in `validate` the first call to `$this->context` is `$this->context->getGroup();`, should I write this in a comment before each declaration?
---------------------------------------------------------------------------
by stof at 2013-01-15T21:50:41Z
You should also modify the CollectionValidator tests to use a different constraint than ``Min`` which is deprecated. Once it is done, these tests should not need to register a custom error handler catching deprecations anymore
---------------------------------------------------------------------------
by franmomu at 2013-01-15T22:33:43Z
Perfect, I'm going to do the same in #6743
This PR was merged into the master branch.
Commits
-------
2061cc0 Update src/Symfony/Component/Validator/Mapping/ClassMetadata.php
Discussion
----------
[Validator] ClassMetadata use deprecated methods
Bug fix: yes
Feature addition: no
Backwards compatibility break: maybe yes (I don't have the knowlegde)
Symfony2 tests pass: yes
Fixes the following tickets: ?
Todo: Nothing
License of the code: MIT
Documentation PR: Nothing
getValue() is deprecated since version 2.2 and will be removed in 2.3. Use getPropertyValue() instead.
ClassMetadata is still using the deprecated method, changed it to getPropertyValue to prevent a trigger error.
---------------------------------------------------------------------------
by fabpot at 2013-01-14T15:35:28Z
ping @bschussek
* 2.1:
[DependencyInjection] fixed the creation of synthetic services in ContainerBuilder
[Security] PHPDoc in SecurityEvents
Fix typos in README
Added an error message in the DebugClassLoader when using / instead of \.
KNOWN_ISSUES with php 5.3.16
[FrameworkBundle] fixed Client::doRequest that must call its parent method (closes#6737)
[Yaml] fixed ignored text when parsing an inlined mapping or sequence (closes#6786)
[Yaml] fixed#6773
[Yaml] fixed#6770
bumped Symfony version to 2.1.8-DEV
bumped Symfony version to 2.0.23-DEV
Conflicts:
src/Symfony/Bundle/FrameworkBundle/Client.php
src/Symfony/Component/HttpKernel/Kernel.php
This PR was squashed before being merged into the master branch (closes#6734).
Commits
-------
4d51ec0 Fix for hardcode (#6384) in choice widget
Discussion
----------
Fix for hardcode (#6384) in choice widget
empty_value should not be disabled if field is not required!
#6384
---------------------------------------------------------------------------
by sstok at 2013-01-15T15:51:08Z
You need to revert the file mode changes (100644 → 100755)
---------------------------------------------------------------------------
by MaksSlesarenko at 2013-01-18T16:44:42Z
fixed tests
---------------------------------------------------------------------------
by MaksSlesarenko at 2013-01-21T15:36:59Z
ping @fabpot
---------------------------------------------------------------------------
by fabpot at 2013-01-21T15:58:26Z
ping @bschussek
---------------------------------------------------------------------------
by MaksSlesarenko at 2013-01-23T11:15:37Z
ping @fabpot @bschussek
---------------------------------------------------------------------------
by Tobion at 2013-01-23T12:08:19Z
I think it's good to squash and merge.
---------------------------------------------------------------------------
by fabpot at 2013-01-23T12:16:37Z
Can you rebase and squash before I merge? Thanks.
---------------------------------------------------------------------------
by MaksSlesarenko at 2013-01-23T19:51:36Z
@fabpot done
This PR was merged into the master branch.
Commits
-------
7944860 [DIC] Move PrependExtensionInterface to the Extension namespace
Discussion
----------
[DIC] Move PrependExtensionInterface to the Extension namespace
@fabpot Please merge before 2.2 (no BC break) /cc @lsmith77
The previous code allowed to pass null as a Request but that does not
really make sense as rendering a sub-request can only happen from a
master request. This was done to ease testing but that was a mistake.
* 2.0:
[DependencyInjection] fixed the creation of synthetic services in ContainerBuilder
[Security] PHPDoc in SecurityEvents
[FrameworkBundle] fixed Client::doRequest that must call its parent method (closes#6737)
[Yaml] fixed ignored text when parsing an inlined mapping or sequence (closes#6786)
[Yaml] fixed#6773
[Yaml] fixed#6770
bumped Symfony version to 2.0.23-DEV
Conflicts:
src/Symfony/Component/DependencyInjection/ContainerBuilder.php
src/Symfony/Component/HttpKernel/Kernel.php
src/Symfony/Component/Yaml/Inline.php
src/Symfony/Component/Yaml/Tests/InlineTest.php
As explained in #6775, this has been done for the following reasons:
1. It's also Request::getHost()
2. The term hostname has been obsoleted in
http://tools.ietf.org/html/rfc3986#appendix-D.2 and uses the host only
3. hostname in the RFC was defined as the registered domain name, but we
probably also want to match IP-Adresses with the pattern which is the
host = IP-literal / IPv4address / reg-name for.
This PR was squashed before being merged into the 2.0 branch (closes#6818).
Commits
-------
598ae9d [Security] PHPDoc in SecurityEvents
Discussion
----------
[Security] PHPDoc in SecurityEvents
| Q | A
| ------------- | ---
| Bug fix? | no
| New feature? | no
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets |
| License | MIT
| Doc PR |
I'm not sure about the description given.
This PR was merged into the master branch.
Commits
-------
aadefd3 [HttpKernel] refactored the HTTP content renderer to make it easier to extend
Discussion
----------
[HttpKernel] refactored the HTTP content renderer to make it easier to extend
| Q | A
| ------------- | ---
| Bug fix? | no
| New feature? | kinda
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | n/a
| License | MIT
| Doc PR | n/a
This makes the StreamedResponse logic reusable for other strategies and it also makes the RenderingStrategy interface less fuzzy about its contract.
That also makes features like #4470 easier to implement from the outside.
---------------------------------------------------------------------------
by stof at 2013-01-20T11:01:29Z
👍
This PR was merged into the master branch.
Commits
-------
fcabadf Fix JsonDecode to work on PHP 5.3, update the CHANGELOG.md
b6bdb45 Completly refactor the Serializer Options Pull Request to push context information directly and avoid state and dependencies between SerializerInterface and encoders/normalizers.
ef652e2 Added context to JsonEncoder
eacb7e2 Rename $options to $context, as it makes the intent much more clear.
8854b85 Fix CS issues, removed global options
9c54a4b [Serializer] Allow options to be passed to SerialiizerInterface#serialize and #unserialize. Thsee options are available to all encoders/decoders/normalizers that implement SerializerAwareInterface.
Discussion
----------
[2.2] [Serializer] Configurable Serializer
Bug fix: no
Feature addition: yes
Backwards compatibility break: yes
Symfony2 tests pass: yes
Fixes the following tickets: #4907, #4938
License of the code: MIT
Todo:
This is an extension of GH-6574 that removes the context state in favor of passing this information around.
---------------------------------------------------------------------------
by beberlei at 2013-01-18T13:12:39Z
@fabpot @lsmith I think this is how it should work from an OOP/OOD perpesctive, avoiding the context state. This makes for a much cleaner code and dependency graph.
---------------------------------------------------------------------------
by lsmith77 at 2013-01-18T14:14:37Z
makes sense. anything fancier would lose this components simplicity which IMHO is the main benefit versus JMS serializer.
---------------------------------------------------------------------------
by fabpot at 2013-01-18T14:26:25Z
Looks very good. 👍
---------------------------------------------------------------------------
by beberlei at 2013-01-18T14:37:32Z
I need to fix the failures with the JsonEncoder and then this is good to merge
---------------------------------------------------------------------------
by stof at 2013-01-18T14:40:21Z
you also need to update the CHANGELOG of the component
---------------------------------------------------------------------------
by beberlei at 2013-01-18T23:17:57Z
Fixed, only the Redis Profiler problem still failing the Travis builds. Also I updated the CHANGELOG.md.
@fabpot Good to merge from my POV
---------------------------------------------------------------------------
by stof at 2013-01-18T23:27:59Z
@beberlei see #6804 for the Redis profiler issue
This PR was squashed before being merged into the master branch (closes#6789).
Commits
-------
917f473 [Console] Removing unnecessary sprintf in Application->getHelp
Discussion
----------
[Console] Removing unnecessary sprintf in Application->getHelp
Minor change of the `Symfony\Component\Console\Application->getHelp()` method.
I have spotted:
1. an unnecessary `sprintf` call (no `args` arguments);
2. two ways of adding a new line in the help (an empty string as new entry of the array and a `\n` at the end of the string).
It seems to be there since the begining and it looks like a forgoten change to me, so I fixed them by removing the `sprintf` call and using a new array entry (empty string) instead of the `\n`.
| Q | A
| ------------- | ---
| License | MIT
This PR was merged into the 2.0 branch.
Commits
-------
fea20b7 [Yaml] fixed#6770
Discussion
----------
[Yaml] fixed parsing of negative integers (2.0 branch)
| Q | A
| ------------- | ---
| Bug fix? | yes
| New feature? | no
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | #6770
| License | MIT
| Doc PR | n/a
Note that an unrelated test fixture for large integers had to be changed to work on systems with 64-bit integer support because of the change from `assertEquals()` to `assertSame()`. Please see the diff for clarification.
* 2.1:
[Yaml] fixed unneeded BC break
[DependencyInjection] fixed a bug in the YAML dumper where references where not converted to the @ notation
[Yaml] fixed typo
updated VERSION for 2.1.7
updated CHANGELOG for 2.1.7
updated VERSION for 2.0.22
update CONTRIBUTORS for 2.0.22
updated CHANGELOG for 2.0.22
Conflicts:
src/Symfony/Component/HttpKernel/Kernel.php
* 2.0:
[Yaml] fixed unneeded BC break
[DependencyInjection] fixed a bug in the YAML dumper where references where not converted to the @ notation
[Yaml] fixed typo
updated VERSION for 2.0.22
update CONTRIBUTORS for 2.0.22
updated CHANGELOG for 2.0.22
Conflicts:
src/Symfony/Component/HttpKernel/Kernel.php
* 2.1:
[Yaml] fixed default value
Added Yaml\Dumper::setIndentation() method to allow a custom indentation level of nested nodes.
added a way to enable/disable object support when parsing/dumping
added a way to enable/disable PHP support when parsing a YAML input via Yaml::parse()
fixed CS
[Process] Fix docblocks, remove `return` from `PhpProcess#start()` as parent returns nothing, cleaned up `ExecutableFinder`
fixes a bug when output/error output contains a % character
[Console] fixed input bug when the value of an option is empty (closes#6649, closes#6689)
[Profiler] [Redis] Fix sort of profiler rows.
Fix version_compare() calls for PHP 5.5.
Removed underscores from test method names to be consistent with other components.
[Process] In edge cases `getcwd()` can return `false`, then `proc_open()` should get `null` to use default value (the working dir of the current PHP process)
Fix version_compare() calls for PHP 5.5.
Handle the deprecation of IntlDateFormatter::setTimeZoneId() in PHP 5.5.
removed the .gitattributes files (closes#6605, reverts #5674)
[HttpKernel] Clarify misleading comment in ExceptionListener
Conflicts:
src/Symfony/Bundle/WebProfilerBundle/Resources/views/Profiler/toolbar_style.html.twig
src/Symfony/Component/Form/Tests/Extension/Core/Type/DateTimeTypeTest.php
src/Symfony/Component/Form/Tests/Extension/Core/Type/TimeTypeTest.php
src/Symfony/Component/Form/Tests/Util/PropertyPathTest.php
src/Symfony/Component/HttpKernel/Profiler/RedisProfilerStorage.php
src/Symfony/Component/Process/Process.php
* 2.0:
[Yaml] fixed default value
Added Yaml\Dumper::setIndentation() method to allow a custom indentation level of nested nodes.
added a way to enable/disable object support when parsing/dumping
added a way to enable/disable PHP support when parsing a YAML input via Yaml::parse()
[Console] fixed input bug when the value of an option is empty (closes#6649, closes#6689)
Conflicts:
src/Symfony/Component/Yaml/Dumper.php
src/Symfony/Component/Yaml/Parser.php
src/Symfony/Component/Yaml/Tests/DumperTest.php
src/Symfony/Component/Yaml/Tests/ParserTest.php
src/Symfony/Component/Yaml/Yaml.php
YAML does not specify an absolute indentation level, but a consistent indentation of nested nodes only: http://www.yaml.org/spec/1.2/spec.html#space/indentation/
Projects that are generally using 2 spaces for indentation should be able to retain consistency with their coding standards by supplying a custom value for the new $indent parameter added to Yaml::dump(), or the new Dumper::setIndentation() method.
The new parameter is a backwards-compatible API addition and defaults to the previous default of 4 (which was changed from 2 via PR #2242 only recently).
Conflicts:
src/Symfony/Component/Yaml/Dumper.php
src/Symfony/Component/Yaml/Yaml.php
By default, object support is disabled, and instead of throwing an
exception when an object is handled, null is returned.
If you do need object support, enable it via:
Yaml::dump($data, false, true);
If you want an exception to be thrown in case an invalid type is handled
(a PHP resource or a PHP object), pass true as the second argument:
Yaml::dump($data, true, true);
The same can be done when parsing:
Yaml::parse($data, 2, false, true);
PHP support when parsing a file has been disabled by default.
If you do need PHP support when parsing a YAML file, enable it via:
Yaml::setPhpParsing(true);
As of Symfony 2.1, PHP support is disabled by default, and support will
be removed in Symfony 2.3.
This PR was merged into the master branch.
Commits
-------
1c5d74c Fixed coding standards issues in invalid-xml-resources.xlf file.
552a806 Fixed coding standards issues.
293991d [Translation] Added some tests to QtFileLoader.
Discussion
----------
[Translation] Added some tests to QtFileLoader.
Added one test for testing exception is thrown if resource is not local.
Added one test for testing exception is thrown if xml resource is invalid.
QtFileLoader has now 100% code coverage.
Bug fix: no
Feature addition: no
Backwards compatibility break: no
Symfony2 tests pass: yes
License of the code: MIT
This PR was merged into the master branch.
Commits
-------
68ac23f [Security] Added Danish translation
Discussion
----------
[Security] Added Danish translation
Bug fix: no
Feature addition: no
Backwards compatibility break: no
Deprecations: no
Symfony2 tests pass: yes
Fixes the following tickets: -
Todo: -
License of the code: MIT
Documentation PR: -
This PR was merged into the 2.1 branch.
Commits
-------
a62e04f [Process] Fix docblocks, remove `return` from `PhpProcess#start()` as parent returns nothing, cleaned up `ExecutableFinder`
Discussion
----------
[2.1][Process] Fix docblocks, remove `return` from `PhpProcess#start()`
This PR was merged into the master branch.
Commits
-------
9fc7def added the UPGRADE file for Symfony 3.0
e84cad2 [Routing] updated CHANGELOG
65eca8a [Routing] added new schemes and methods options to the annotation loader
5082994 [Routing] renamed pattern to path
b357caf [Routing] renamed hostname pattern to just hostname
e803f46 made schemes and methods available in XmlFileLoader
d374e70 made schemes and methods available in YamlFileLoader
2834e7e added scheme and method setter in RouteCollection
10183de make scheme and method requirements first-class citizen in Route
Discussion
----------
Routing options
| Q | A
| ------------- | ---
| Bug fix? | no
| New feature? | no
| BC breaks? | no
| Deprecations? | yes
| Tests pass? | yes
| Fixed tickets | #5989, #5990, #6049
| License | MIT
In #5989, it has unanimously been decided to renamed `hostname_pattern` to `hostname` and `pattern` to `path`. That makes a lot of sense and I would like to do the renaming now as `hostname_pattern` is new in Symfony 2.2, so I'd like to avoid breaking BC just after the release. As we are modifying the route options, I've also included changes introduced by @Tobion in #6049 which were discussed in #5990.
As everything is BC, I think it's wise to include that in 2.2. What do you think?
---------------------------------------------------------------------------
by Tobion at 2013-01-14T18:25:53Z
I agree it should be done in 2.2. Thanks for working on it.
---------------------------------------------------------------------------
by vicb at 2013-01-14T23:11:12Z
@fabpot "Everything is BC" until it breaks BC in 3.0, that's why I'd like to see [deprecations in PR summary](https://github.com/symfony/symfony-docs/pull/2116) what do you think ?
---------------------------------------------------------------------------
by vicb at 2013-01-14T23:16:40Z
it would also be great to update the CHANGELOG with deprecations (it could also help people answering your question)
---------------------------------------------------------------------------
by fabpot at 2013-01-15T07:07:03Z
@vicb: I've just updated the CHANGELOG and created the UPGRADE file for 3.0.
---------------------------------------------------------------------------
by vicb at 2013-01-15T07:15:32Z
@fabpot thanks.
getValue() is deprecated since version 2.2 and will be removed in 2.3. Use getPropertyValue() instead.
ClassMetadata is still using the deprecated method, changed it to getPropertyValue to prevent a trigger error.
This PR was merged into the master branch.
Commits
-------
c1d5f16 Update src/Symfony/Component/HttpKernel/Tests/EventListener/RouterProxyListenerTest.php
Discussion
----------
Typo fix
Just a typo fix
This PR was merged into the master branch.
Commits
-------
fb52d94 Update src/Symfony/Component/Security/Resources/translations/security.es_CA.xlf
Discussion
----------
Update src/Symfony/Component/Security/Resources/translations/security.es...
..._CA.xlf
This PR was merged into the master branch.
Commits
-------
0a060ca Fix Russian and Ukrainian translations for Security component
Discussion
----------
[Security] Fix Russian and Ukrainian translations
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.
* 2.0:
Fix version_compare() calls for PHP 5.5.
[Process] In edge cases `getcwd()` can return `false`, then `proc_open()` should get `null` to use default value (the working dir of the current PHP process)
Conflicts:
src/Symfony/Component/Form/Extension/Core/ChoiceList/MonthChoiceList.php
This PR was merged into the master branch.
Commits
-------
6b669fb Update src/Symfony/Component/Security/Resources/translations/security.nl.xlf
Discussion
----------
Update src/Symfony/Component/Security/Resources/translations/security.nl.xlf
see #6668
Some more minor tweaks
This PR was merged into the master branch.
Commits
-------
83d0469 Create security.no.xlf
Discussion
----------
Norwegian Translation for Security
Norwegian Translation
This PR was merged into the master branch.
Commits
-------
2617cf6 Added Turkish translation for security component
Discussion
----------
Added Turkish translation for security component
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.
This PR was merged into the master branch.
Commits
-------
d027f45 [PROFILER][REDIS] Support database, auth on redis connection
Discussion
----------
[PROFILER][REDIS] Support database, auth on redis connection
Bug fix: no
Feature addition: yes
Backwards compatibility break: no
Symfony2 tests pass: yes
Allow database and password on dsn:
```yml
framework:
profiler:
dsn: redis://127.0.0.1:6379
dsn: redis://127.0.0.1:6379/3
dsn: redis://user:password@127.0.0.1:6379/3
```
Since redis uses only password for authentification, user will not be used ...
---------------------------------------------------------------------------
by shouze at 2013-01-10T16:58:02Z
👍 db selection is a must have
This PR was merged into the master branch.
Commits
-------
76fefe3 updated CHANGELOG and UPGRADE files
f7da1f0 added some unit tests (and fixed some bugs)
f17f586 moved the container aware HTTP kernel to the HttpKernel component
2eea768 moved the deprecation logic calls outside the new HttpContentRenderer class
bd102c5 made the content renderer work even when ESI is disabled or when no templating engine is available (the latter being mostly useful when testing)
a8ea4e4 [FrameworkBundle] deprecated HttpKernel::forward() (it is only used once now and not part of any interface anyway)
1240690 [HttpKernel] made the strategy a regular parameter in HttpContentRenderer::render()
adc067e [FrameworkBundle] made some services private
1f1392d [HttpKernel] simplified and enhanced code managing the hinclude strategy
403bb06 [HttpKernel] added missing phpdoc and tweaked existing ones
892f00f [HttpKernel] added a URL signer mechanism for hincludes
a0c49c3 [TwigBridge] added a render_* function to ease usage of custom rendering strategies
9aaceb1 moved the logic from HttpKernel in FrameworkBundle to the HttpKernel component
Discussion
----------
[WIP] Kernel refactor
Currently, the handling of sub-requests (including ESI and hinclude) is mostly done in FrameworkBundle. It makes these important features harder to implement for people using only HttpKernel (like Drupal and Silex for instance).
This PR moves the code to HttpKernel instead. The code has also been refactored to allow easier integration of other rendering strategies (refs #6108).
The internal route has been re-introduced but it can only be used for trusted IPs (so for the internal rendering which is managed by Symfony itself, or by a trusted reverse proxy like Varnish for ESI handling). For the hinclude strategy, when using a controller, the URL is automatically signed (see #6463).
The usage of a listener instead of a controller to handle internal sub-requests speeds up things quite a lot as it saves one sub-request handling. In Symfony 2.0 and 2.1, the handling of a sub-request actually creates two sub-requests.
Rendering a sub-request from a controller can be done with the following code:
```jinja
{# default strategy #}
{{ render(path("partial")) }}
{{ render(controller("SomeBundle:Controller:partial")) }}
{# ESI strategy #}
{{ render(path("partial"), { strategy: 'esi' }) }}
{{ render(controller("SomeBundle:Controller:partial"), { strategy: 'esi' }) }}
{# hinclude strategy #}
{{ render(path("default1"), { strategy: 'hinclude' }) }}
```
The second commit allows to simplify the calls a little bit thanks to some nice syntactic sugar:
```jinja
{# default strategy #}
{{ render(path("partial")) }}
{{ render(controller("SomeBundle:Controller:partial")) }}
{# ESI strategy #}
{{ render_esi(path("partial")) }}
{{ render_esi(controller("SomeBundle:Controller:partial")) }}
{# hinclude strategy #}
{{ render_hinclude(path("default1")) }}
```
---------------------------------------------------------------------------
by fabpot at 2013-01-03T17:58:49Z
I've just pushed a new version of the code that actually works in my browser (but I've not yet written any unit tests). I've updated the PR description accordingly.
All comments welcome!
---------------------------------------------------------------------------
by Koc at 2013-01-03T20:11:43Z
what about `render(controller="SomeBundle:Controller:partial", strategy="esi")`?
---------------------------------------------------------------------------
by stof at 2013-01-04T09:01:01Z
shouldn't we have interfaces for the UriSigner and the HttpContentRenderer ?
---------------------------------------------------------------------------
by lsmith77 at 2013-01-04T19:28:09Z
btw .. as mentioned in #6213 i think it would make sense to refactor the HttpCache to use a cache layer to allow more flexibility in where to cache the data (including clustering) and better invalidation. as such if you are refactoring HttpKernel .. it might also make sense to explore splitting off HttpCache.
---------------------------------------------------------------------------
by fabpot at 2013-01-04T19:30:07Z
@lsmith77 This is a totally different topic. This PR is just about moving things from FrameworkBundle to HttpKernel to make them more reusable outside of the full-stack framework.
---------------------------------------------------------------------------
by fabpot at 2013-01-05T09:39:52Z
I think this PR is almost ready now. I still need to update the docs and add some unit tests. Any other comments on the whole approach? The class names? The `controller` function thingy? The URI signer mechanism? The proxy protection for the internal controller? The proxy to handle internal routes?
---------------------------------------------------------------------------
by sstok at 2013-01-05T10:08:25Z
Looks good to me 👍
---------------------------------------------------------------------------
by sdboyer at 2013-01-07T18:17:08Z
@Crell asked me to weigh in, since i'm one of the Drupal folks who's likely to work most with this.
i think i've grokked about 60% of the big picture here, and i'm generally happy with what i see. the assumption that the HInclude strategy makes about working with templates probably isn't one that we'll be able to use (and so, would need to write our own), but that's not a big deal since the whole goal here is to make strategies pluggable.
so, yeah. +1.
---------------------------------------------------------------------------
by winzou at 2013-01-09T20:21:44Z
Just for my information: will this PR be merged for 2.2 version? Thanks.
---------------------------------------------------------------------------
by stof at 2013-01-09T20:41:04Z
@winzou according to the blog post announcing the beta 1 release, yes. It is explicitly listed as being one of the reason to make it a beta instead of the first RC.
---------------------------------------------------------------------------
by winzou at 2013-01-09T20:49:36Z
OK thanks, I've totally skipped this blog post.
---------------------------------------------------------------------------
by fabpot at 2013-01-10T15:26:15Z
I've just added a bunch of unit tests and fix some bugs I found while writing the tests.
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.
This PR was merged into the master branch.
Commits
-------
6b1652e [PropertyAccess] Property path, small refactoring, read/writeProperty to read/write Property/Index.
1bae7b2 [PropertyAccess] Extracted PropertyAccess component out of Form
Discussion
----------
[PropertyAccess] Extracted PropertyAccess component out of Form
Bug fix: no
Feature addition: no
Backwards compatibility break: yes
Symfony2 tests pass: yes
Fixes the following tickets: -
Todo: -
License of the code: MIT
Documentation PR: -
TODO: adapt DoctrineBundle/PropelBundle to pass the "property_accessor" service to EntityType/ModelType
Usage:
```php
$accessor = PropertyAccess::getPropertyAccessor();
// equivalent to $object->getFoo()->setBar('value')
$accessor->setValue($object, 'foo.bar', 'value');
// equivalent to $object->getFoo()->getBar()
$accessor->getValue($object, 'foo.bar');
// equivalent to $object->getFoo()['bar']
$accessor->getValue($object, 'foo[bar]');
// equivalent to $array['foo']->setBar('value')
$accessor->setValue($array, '[foo].bar', 'value');
// equivalent to $array['foo']['bar']
$accessor->getValue($array, '[foo][bar]');
```
Later on, once we have generation and caching of class-specific accessors, configuration will be something like this (consistent with the Form and Validator component):
```php
$accessor = PropertyAccess::getPropertyAccessorBuilder()
->setCacheDirectory(__DIR__ . '/cache')
->setCacheLifeTime(86400)
->enableMagicGetSet()
->enableMagicCall()
->getPropertyAccessor();
```
or
```php
$accessor = PropertyAccess::getPropertyAccessorBuilder()
->setCache($cache)
->getPropertyAccessor();
```
etc.
---------------------------------------------------------------------------
by Burgov at 2013-01-07T08:48:15Z
+1. I use this feature outside of the Form context a lot
---------------------------------------------------------------------------
by stof at 2013-01-07T08:49:34Z
The classes in the Form component should be kept for BC (and deprecated) for people using the feature
---------------------------------------------------------------------------
by michelsalib at 2013-01-07T10:02:19Z
YES YES YES 👍. Sorry for my enthusiasm, but I already copy pasted the PropertyPath class to some of my libraries to avoid linking to the whole Form component. I thus will be glad to officially use this component into my libraries via composer.
---------------------------------------------------------------------------
by norzechowicz at 2013-01-07T10:17:39Z
Same as @michelsalib to avoid linking full Form component I was using copied parts of code. Can't wait to use this component in my lib. 👍
---------------------------------------------------------------------------
by bschussek at 2013-01-07T10:43:41Z
I split away `getValue()` and `setValue()` from `PropertyPath` into a new class `ReflectionGraph`. The component is also named ReflectionGraph now.
---------------------------------------------------------------------------
by michelsalib at 2013-01-07T10:47:10Z
I am not found of the name. What do you intend to do in the component more than what PropertyPath does ?
---------------------------------------------------------------------------
by bschussek at 2013-01-07T10:58:59Z
@michelsalib A `PropertyPath` is simply a string like `foo.bar[baz]`. `getValue()` and `setValue()` interpret this path. There may be different interpretations for the same path, so these methods were split into a new class.
I chose the name `ReflectionGraph` because the functionality is very similar to `ReflectionProperty`.
```php
$reflProperty = new ReflectionProperty('Vendor/Class', 'property');
$reflProperty->setValue($object, 'foo');
$reflGraph = new ReflectionGraph();
$reflGraph->setValue($object, 'property.path', 'foo');
```
---------------------------------------------------------------------------
by michelsalib at 2013-01-07T11:00:42Z
What about naming it `Reflection`, maybe sometime we will want to add more reflection tools for classes, interfaces... ?
---------------------------------------------------------------------------
by bschussek at 2013-01-07T11:02:32Z
@michelsalib I doubt that we will do that. PHP's implementation is sufficient.
---------------------------------------------------------------------------
by vicb at 2013-01-07T11:03:57Z
> Backwards compatibility break: no
Really ?
---------------------------------------------------------------------------
by michelsalib at 2013-01-07T11:05:07Z
Well, that is just a suggestion. If I am the only one to oppose, I won't complain.
---------------------------------------------------------------------------
by bschussek at 2013-01-07T11:09:08Z
> Really ?
@vicb Would you please refrain from such meanginless comments in the future? I'm getting a bit tired of them. If you think that BC is broken somewhere, tell me where so that I can fix it.
---------------------------------------------------------------------------
by stof at 2013-01-07T11:09:43Z
@vicb There is no BC break as he kept deprecated classes for BC
---------------------------------------------------------------------------
by norzechowicz at 2013-01-07T11:13:12Z
@bschussek what do you think about some kind of factory for Reflection? This will prevent creating new Reflection objects each time you want to access properties values.
---------------------------------------------------------------------------
by vicb at 2013-01-07T11:18:47Z
@bschussek my point is that my comment is no more meaningless than closing #6453 because it will break BC.We could also keep BC by extending the classes in the new ns but in both cases BC will ultimately be broken (when the legacy classes are removed)
---------------------------------------------------------------------------
by vicb at 2013-01-07T12:23:45Z
@bschussek @stof I think that modifying the constructor signatures of `EntityChoiceList`, `FormType` are BC breaks (this is not an exhaustive list)
---------------------------------------------------------------------------
by bschussek at 2013-01-07T12:35:13Z
@vicb You are right. I added corresponding entries to the CHANGELOG and adapted the above description.
---------------------------------------------------------------------------
by vicb at 2013-01-08T13:39:13Z
@bschussek looking at this PR, I was wondering if an alternate syntax would make sense:
```php
<?php
$reflGraph = new ReflectionGraph($object);
// equivalent to $object->getFoo()->setBar('value')
$reflGraph['foo.bar'] = 'value';
// equivalent to $object->getFoo()->getBar()
$reflGraph['foo.bar'];
```
_Sorry for the off topic_
---------------------------------------------------------------------------
by vicb at 2013-01-08T13:49:46Z
The advantage of using such a `ReflectionGraph` factory is that it might be easier to return specialized reflection graphs, ie optimized instances (that would be cached).
---------------------------------------------------------------------------
by Toflar at 2013-01-08T14:49:54Z
I was also puzzled by the fact that there will be many `ReflectionGraph` instances although they don't have to. I'm with @vicb and I'd also vote for using the constructor to set the subject you're working on. Otherwise you'll repeat yourself over and over again by passing the subject - say `$object` - to `getValue()` or `setValue()`. If however you don't like the constructor thing then why do we have to have an instance of `ReflectionGraph` rather than just go for static methods and use `ReflectionGraph::getValue()` and `ReflectionGraph::setValue()`?
In my opinion there are a few methods that could be static anyway (especially some private ones) :)
But probably I misunderstood something as I'm just about to discover the SF components and don't have any experience working with them (so basically I just read the PR because of @bschussek's tweet :D)
Couldn't come up with any intuitive name for the component though :(
Generally when we talk about "getting" and "setting" values we call those things "mutators"...so `GraphMutator` might be more intuitive than the word `Reflection` :)
---------------------------------------------------------------------------
by Taluu at 2013-01-08T14:57:42Z
I like the last proposition made by @vicb (implementing `ArrayAccess` on `ReflectionGraph` - or whatever name will be chosen (`PathMutator` for example :D), and also specify which object should be worked on in the constructor rather than in each method).
Would this also be used in the `Validator` component ?
---------------------------------------------------------------------------
by stof at 2013-01-08T15:16:12Z
@Toflar A static ``ReflectionGraph::getValue()`` means you have a coupling to the implementation (as with any static call). The current implementation allows you to replace it with your own implementation as long as you implement the interface as it follows the DI pattern (as done in other places in Symfony).
@vicb The issue with ``$reflGraph = new ReflectionGraph($object);`` is that you cannot inject the ReflectionGraph anymore, as you need a new one each time. This would mean adding a ``ReflectionGraphFactory`` to be injected (and which could then be replaced by a factory using code generation). Using the constructor directly would not allow using a replacement based on code generation later. So the resulting code would more likely be
```php
$reflGraph = new ReflectionGraph();
$mutator = $reflGraph->getMutator($object);
// equivalent to $object->getFoo()->setBar('value')
$mutator['foo.bar'] = 'value';
// equivalent to $object->getFoo()->getBar()
$mutator['foo.bar'];
```
Btw, writing this, I find the naming Mutator suggested by @Taluu good when it concerns the setter, but quite weird when getting the value.
---------------------------------------------------------------------------
by Taluu at 2013-01-08T15:21:00Z
I was not the one to suggest though, it was @everzet. But then something like `PathAccessor`, as it is both a mutator and a getter ? I also like @stof suggestion, still in the idea of avoiding to have to put the object as an argument and also allowing to use an `ArrayAccess` interface..
---------------------------------------------------------------------------
by vicb at 2013-01-08T15:21:54Z
@stof your remark makes sense.
What about `Accessor`, the benefit being that it might well be the name of a coming PHP feature: https://wiki.php.net/rfc/propertygetsetsyntax-v1.2
---------------------------------------------------------------------------
by everzet at 2013-01-08T15:27:02Z
```php
$manager = new PropertyManager(new PropertyPath());
$num = $manager->getValue($object, 'foo.num');
$manager->setValue($object, 'foo.num', $num + 1);
$objectManager = new ObjectPropertyManager($object[, $manager]);
$num = $objectManager->getValue('foo.num');
$objectManager->setValue('foo.num', $num + 1);
$objectManager['foo.num'] += 1;
```
---------------------------------------------------------------------------
by bschussek at 2013-01-08T15:28:01Z
It might be me, but I don't like `ArrayAccess` to be misused for features like that. If I access a key in an array access structure, I expect it to be something like a collection, an associative array or a key value store. This class is neither.
Putting that aside, an accessor for a specific object might make sense, but I'm not sure about that yet.
```php
$reflObject->setValue('foo.bar', 'value');
$reflObject->getValue('foo.bar');
```
---------------------------------------------------------------------------
by stof at 2013-01-08T15:28:52Z
@vicb I would vote for PathAccessor then, as we are not doing simple accessor but accessors through a path in an object graph.
In my snippet above, we would then have a ReflectionGraph instance and a PathAccessor instance (``$mutator``).
Btw, I would also keep the methods ``setValue`` and ``getValue``. I find it more clear.
---------------------------------------------------------------------------
by bschussek at 2013-01-08T15:32:07Z
@stof But then we're rather left with the question of ReflectionGraph **vs.** PathAccessor. I don't think that the tiny interface difference (one global, one object-based) justifies the big naming difference.
---------------------------------------------------------------------------
by vicb at 2013-01-08T15:33:24Z
> This class is neither.
It might be `$pa['foo.bar[baz]'] = $pa['foo.bar']['baz'];` I don't know if it would help though.
---------------------------------------------------------------------------
by stof at 2013-01-08T15:35:51Z
@bschussek In my suggestion, ``ReflectionGraph`` is a factory for the PathAccessor objects. It is not accessing anymore itself (which would probably continue to cause issues to implement it with code generation). But the naming could indeed be changed to something else.
This PR was merged into the master branch.
Commits
-------
1edf302 Fixed some translation typos
Discussion
----------
Fixed translation typos on the Security componente
Hi,
In my last PR I've introduced some translation typos on the Security component messages for the Spanish translation.
So sorry.
Christian.
This PR was merged into the master branch.
Commits
-------
77545a2 Update src/Symfony/Component/Security/Resources/translations/security.es.xlf
Discussion
----------
Update src/Symfony/Component/Security/Resources/translations/security.es...
....xlf
---------------------------------------------------------------------------
by mweimerskirch at 2013-01-10T17:43:38Z
Duplicate of #6684?
This PR was merged into the master branch.
Commits
-------
a1ef9d8 Fixed 2 typos in French translation
Discussion
----------
Fixed 2 typos in French translation
This PR was merged into the master branch.
Commits
-------
b92973c Fixed German translations for security component
Discussion
----------
Fixed German translations for security component
authentication != authorisation
plus a few other minor things
This PR was merged into the master branch.
Commits
-------
9471a1c Added Luxembourgish translation for security component
Discussion
----------
Added Luxembourgish translation for security component
This PR was merged into the master branch.
Commits
-------
67d7423 Remove use of deprecated HttpKernel LoggerInterface
dca4528 [HttpKernel] Extend psr/log's NullLogger class
1e5a890 [Monolog] Mark old non-PSR3 methods as deprecated
91a86f8 [HttpKernel][Monolog] Add PSR-3 support to the LoggerInterface
Discussion
----------
[HttpKernel][MonologBridge] PSR-3 support
This enables PSR-3 support and monolog 1.3+. The first commit is the main part. The rest deals with deprecation of short-hand methods (warn/err/crit/emerg) that are fully expanded in PSR-3 (warning/error/critical/emergency).
The downside of deprecating them is that for bundles it's a bit harder to support older and newer versions. If that is too much of a hassle you can drop that for now and cherry pick the first commit.
The upside is that it forces people to move towards PSR-3 compatible stuff, which means eventually we could completely drop the LoggerInterface from the framework. In any case I think the documentation should only mention the `Psr\Log\LoggerInterface` and people should start hinting against that. The change should be done in core as well I suppose.
Anyway I wanted to throw this out there as it is to get feedback.
---------------------------------------------------------------------------
by stof at 2013-01-09T09:15:15Z
@Seldaek I also think you should change the typehint to use the PSR LoggerInterface in all classes using the logger
---------------------------------------------------------------------------
by Seldaek at 2013-01-09T09:54:55Z
OK updated according to all the feedback. I tested it in an app and it still seems to work so there shouldn't be any major issues.
---------------------------------------------------------------------------
by Seldaek at 2013-01-09T09:59:55Z
@fabpot if you merge please merge also the bundle PR, otherwise it won't be possible to update without conflict.
---------------------------------------------------------------------------
by frosas at 2013-01-10T14:59:20Z
I'm trying to understand why a `composer update` of a Symfony 2.1.* resulted in a fatal error. Shouldn't a stable version don't break like this?
As @olaurendeau points, why Symfony depends 1.* instead of 1.2.*? Or why Monolog 1.3 breaks its public interface (EDIT: I'm not sure about it)? Or why isn't this PR being merged (into branch 2.1) at the same time Monolog 1.3 is released?
Please, understand I'm not looking for who to blame, it's just I want to know if this situation is unexpected or if otherwise a `composer update` on a stable branch is not as innocent as it seems.
---------------------------------------------------------------------------
by stof at 2013-01-10T15:06:51Z
@frosas it cannot be merged into 2.1 as it is a BC break. The 2.1 branch has been updated to forbid Monolog 1.3 already
---------------------------------------------------------------------------
by Seldaek at 2013-01-10T15:11:58Z
@frosas you can blame me for releasing as 1.3.0 and not 2.0, but technically for monolog this isn't really a BC break, I just added an interface. The problem is due to the way it's used in symfony, it ended up as a fatal error. In any case the situation is now sorted out I think.
---------------------------------------------------------------------------
by frosas at 2013-01-10T15:26:43Z
@stof now I see this `>=1.0,<1.3-dev` change in the 2.1 branch. Now, shouldn't a new (2.1.7) version be released for all of us not in the dev minimum-stability?
@Seldaek then do you see feasible to rely only in X.Y.* versions to avoid this kind of errors?
---------------------------------------------------------------------------
by Seldaek at 2013-01-10T15:45:22Z
@frosas relying on X.Y.* is painful because you always need to wait until someone updates the constraint to get the new version. Of course using ~1.3 like in this PR means if I fuck up and break BC people will update to it, but that's a less likely occurrence than the alternative I think, so I would rather not use X.Y.*
---------------------------------------------------------------------------
by frosas at 2013-01-10T15:50:50Z
@Seldaek you are right about this, but I was thinking more in changing it only for the stable versions. EDIT: I mean, how often do you need a new feature in a branch you only apply fixes to?
---------------------------------------------------------------------------
by stof at 2013-01-10T15:57:32Z
@frosas Monolog and Symfony have separate release cycles. Foorcing Symfony users to use an old version of Monolog until they update to a new version of Symfony whereas the newer Monolog is compatible is a bad idea. Thus, as Monolog keeps BC, it does not maintain bugfix releases for all older versions (just like Twig does too). So it would also forbid you to get the fixes done in newer Monolog versions.
The incompatibility between Symfony 2.1 LoggerInterface and PSR-3 (whereas they expect exactly the same behavior and signature for methods with the same name) is unfortunate and is the reason why we get some issues here.
---------------------------------------------------------------------------
by frosas at 2013-01-10T16:21:06Z
@stof I appreciate you prefer to allow newer versions at the price of having to be constantly monitoring its changes to avoid breaks.
Another similar but safer strategy would be to stick to X.Y.* versions and upgrade to X.Y+1.* once the new version integration is tested, but I understand this is discutible in projects as close to Symfony as Monolog.
Returning to the issue, what do you say to release this 2.1.7 version? Or is it only me who is having issues here?
---------------------------------------------------------------------------
by stof at 2013-01-10T16:26:20Z
@frosas a minor release should not break BC when following smeantic versionning (Symfony warned about the fact it is not strictly followed for the first releases of 2.x). But as far as monolog is concerned, 1.3 is BC with 1.2.
---------------------------------------------------------------------------
by Seldaek at 2013-01-10T16:49:55Z
@frosas sorry I didn't get you still had the problem. I tagged a 2.1.7 of monologbundle which hopefully fixes your issue.
This PR was merged into the master branch.
Commits
-------
0b75f67 Security component Polish message translations
Discussion
----------
[Security] Polish message translations
Security component messages translated from English to Polish.
This PR was merged into the master branch.
Commits
-------
c06e627 Fixed some typos
Discussion
----------
FIxed some typos in the Spainsh translation of the Security component messages
Hi,
In order to show the most clear and less _"robotic"_ messages in Spanish, I've fixed some typos and some incorrect translations in the Spanish translation file of the Security component.
Christian.
This PR was merged into the master branch.
Commits
-------
e84a8d0 fixed some small issues with grammar and used terminology
Discussion
----------
fixed some small issues with grammar and used terminology
This PR was merged into the master branch.
Commits
-------
d5825aa slovenian translations of security component added
Discussion
----------
Slovenian translations of security component added
This PR was merged into the master branch.
Commits
-------
d6f972b Created Slovak translation to Security
Discussion
----------
[security][tranlation] Created Slovak translation to Security
This PR was merged into the master branch.
Commits
-------
6ae8ca8 Update src/Symfony/Component/Security/Resources/translations/security.es.xlf
Discussion
----------
Update src/Symfony/Component/Security/Resources/translations/security.es...
....xlf
This PR was merged into the master branch.
Commits
-------
9b8428d [security][tranlation]Fixed spanish translation
Discussion
----------
[security][tranlation]Fixed spanish translation
This PR was merged into the master branch.
Commits
-------
0b5177b added italian translations
Discussion
----------
added italian translations for the security component
---------------------------------------------------------------------------
by matteosister at 2013-01-10T14:22:54Z
not sure if the file should be named **security.it_IT.xlf** or **security.it.xlf**
---------------------------------------------------------------------------
by fabpot at 2013-01-10T14:25:49Z
security.it.xlf
---------------------------------------------------------------------------
by matteosister at 2013-01-10T14:31:14Z
ok, renamed the files, and squashed the pr to a single commit!
Thanks @fabpot!
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
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
This PR was merged into the master branch.
Commits
-------
2f51961 Created de translation for Security
Discussion
----------
[Security][Translation]Created de translation for Security
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!
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
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: [](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()`? https://github.com/symfony/symfony/pull/4935#discussion_r1358297
- And what is the final verdict on the messages? https://github.com/symfony/symfony/pull/4935#discussion_r1165701 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<https://github.com/symfony/symfony/issues/4935#discussion_r1358297>
> - And what is the final verdict on the messages? symfony/symfony#4935<https://github.com/symfony/symfony/issues/4935#discussion_r1165701>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 <https://github.com/schmittjoh> Any things to add?
>
> —
> Reply to this email directly or view it on GitHub<https://github.com/symfony/symfony/pull/4935#issuecomment-9861016>.
>
>
---------------------------------------------------------------------------
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<https://github.com/symfony/symfony/pull/4935#issuecomment-10709997>.
>
>
---------------------------------------------------------------------------
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()`?
- 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.
