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.
* 2.2: (22 commits)
[Process] Fix regression introduced in #6620 / 880da01c49, fixes#7082
[HttpKernel] added a unit for the previous commit (closes#7025)
[HttpFoundation] fixed, overwritten CONTENT_TYPE
[BrowserKit] fixed test added in the previous merge (refs #7059)
[FrameworkBundle] tweaked reference dumper command (see #7093)
Remove unnecessary comment and change test name
[Config] tweaked dumper to indent multi-line info
[HttpKernel] added some tests for previous merge
Fix REMOTE_ADDR for cached subrequests
[FrameworkBundle] CSRF should be on by default
[WebProfilerBundle] removed dependency on FrameworkBundle (closes#6949)
[HttpKernel] added error display suppression when using the ErrorHandler (if not, errors are displayed twice, refs #6254)
[HttpFoundation] tweaked previous merge
[HttpFoundation] Added getter for httpMethodParameterOverride state
Create validators.lv.xlf
[Process] Warn user with a useful message when tmpfile() failed
[BrowserKit] added a test to make sure HTTP authentication is preserved when submitting a form
Remove array type hint from GetResponseForControllerResultEvent::setControllerResult()
bumped Symfony version to 2.2.0-DEV
Revert "merged branch povilas/issue_6101 (PR #6708)"
...
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
👍
* 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
* 2.2:
Fixed XmlFileLoaderTest::testLoadThrowsExceptionWithInvalidFileEvenWithoutSchemaValidation
moved file hash calculation to own method
[Validator] Add check for existing metadata on property
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)
replaced usage of the deprecated pattern routing key (replaced with path)
Add dot character `.` to legal mime subtype regular expression
[HttpFoundation] fixed the creation of sub-requests under some circumstancies (closes#6923, closes#6936)
* 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)
* 2.2: (30 commits)
[HttpFoundation] Added support for partial ranges in the BinaryFileResponse.
[HttpFoundation] Fixed byte ranges in the BinaryFileResponse.
updated required versions when depending on the HttpFoundation component
updated required versions when depending on the HttpKernel component
updated required versions when depending on the Config component
updated required versions when depending on the Form component
updated required versions when depending on the DependencyInjection component
updated required versions when depending on the Validator component
updated required versions when depending on the Translation component
updated required versions when depending on the Routing component
updated required versions when depending on the EventDispatcher component
updated required versions when depending on the OptionsResolver component
updated required versions when depending on the PropertyAccess component
updated required versions when depending on the Security component
updated required versions when depending on the Templating component
updated required versions when depending on the Stopwatch component
updated required versions when depending on the Process component
updated required versions when depending on the Finder component
updated required versions when depending on the Dom Crawler component
use ~2.0 when depending on the Dom Crawler component
...
* 2.2:
[HttpFoundation] fixed Request::create() method
[HttpKernel] fixed the creation of the Profiler directory
[HttpKernel] fixed the hinclude fragment renderer when the template is empty
bumped Symfony version to 2.2.0-RC2-DEV
[DependencyInjection] enhanced some error messages
[FrameworkBundle] fixed typo
fixed typo
tweaked previous merge
[Security] fixed interface implementation (closes#6974)
Add "'property_path' => false" deprecation message for forms
fixed CS
Added BCrypt password encoder.
updated VERSION for 2.2.0-RC1
Removed underscores from test method names to be consistent with other components.
[Security] fixed session creation when none is needed (closes#6917)
[FrameworkBundle] removed obsolete comment (see 2e356c1)
Micro-optimization
[FrameworkBundle] removed extra whitespaces
[Security] renamed Constraint namespace to Constraints for validator classes in order to be consistent with the whole current validator API.
[FrameworkBundle] fixed wrong indentation on route debug output
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.
* 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)
* 2.2:
fixed regression in the Finder component (it was possible to use it without using exec before, closes#6357)
fixed a circular call (closes#6864)
typo
[Security] [Tests] added unit tests for the UserPasswordValidator class and made the validator service for the UserPassword constraint configurable.
fixed wrong indentation
tweaked previous commit
[HttpKernel] Fix the URI signer (closes#6801)
Add Arabic translations.
[HttpKernel] fixed regression when rendering an inline controller and passing some objects (closes#6822)
[FrameworkBundle] fixed typo
renamed some classes and Twig functions to more descriptive names (refs #6871)
Classcollectionloader: fix traits + enhancements
Fix a deprecated method call in the tests
Update `composer.json` files: - to allow versions ~2.2 (>=2.2,<3.0) of Doctrine DBAL, ORM & Common - fixed Propel1 versions difference between main and bridge files - fixed Twig versions difference between main and bridge files - to allow versions ~1.11 (>=1.11,<2.0) of Twig - fixed Locale ext-intl version to accept all, not non-existing version
Correct comment in NativeSessionStorage regarding session.save_handler
[Security] Add PHPDoc to AuthenticationEvents
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
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.
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.
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
👍
* 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
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.
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.
* 2.0:
updated license year
Update src/Symfony/Component/HttpFoundation/Response.php
[Console] fixed unitialized properties (closes#5935)
[Bundle] [FrameworkBundle] fixed typo in phpdoc of the SessionListener.
bumped Symfony version to 2.0.21-DEV
updated VERSION for 2.0.21
updated CHANGELOG for 2.0.21
Conflicts:
src/Symfony/Bundle/SwiftmailerBundle/LICENSE
src/Symfony/Component/Filesystem/LICENSE
src/Symfony/Component/HttpFoundation/Response.php
src/Symfony/Component/HttpKernel/Kernel.php
This PR was merged into the master branch.
Commits
-------
d5948f1 Use KernelEvents constants in TraceableEventDispatcher
Discussion
----------
[HttpKernel] Use KernelEvents constants in TraceableEventDispatcher
Can't see any reason why we're not using constants here.
This allows to have a meaningful information in the WDT when the route
in the Request is not the route name but the route object (like in
Drupal for instance).
* 2.1:
[FrameworkBundle] fixed broken tests
[FrameworkBundle] Fixed logic under test environment.
[Session] Added exception to save method
[Session] Fixed a bug with the TestListener
Added comment
[FrameworkBundle] Added tests for trusted_proxies configuration.
[FrameworkBundle] Added a check on file mime type for CodeHelper::fileExcerpt()
checked for a potentially missing key
[FrameworkBundle] used the new method for trusted proxies
remove realpath call
Conflicts:
src/Symfony/Bundle/FrameworkBundle/DependencyInjection/Configuration.php
* 2.0:
Added comment
[FrameworkBundle] Added tests for trusted_proxies configuration.
[FrameworkBundle] Added a check on file mime type for CodeHelper::fileExcerpt()
checked for a potentially missing key
[FrameworkBundle] used the new method for trusted proxies
remove realpath call
Conflicts:
src/Symfony/Bundle/FrameworkBundle/DependencyInjection/Configuration.php
MongoClient defaults its write concern to w=1 (i.e. "safe" writes), which means update() may return an array instead of boolean true. Check for this before returning from write().
This PR was merged into the master branch.
Commits
-------
aab60e3 [HttpKernel] fix public Kernel::stripComments()
Discussion
----------
[HttpKernel] fix public Kernel::stripComments()
Needs fix as the method is public.
---------------------------------------------------------------------------
by fabpot at 2012-12-13T17:01:52Z
Can you explain what you mean by "Needs fix as the method is public."?
---------------------------------------------------------------------------
by vicb at 2012-12-13T17:15:05Z
@fabpot One can argue that the fix could not be reached if the method was private.
* 2.1:
fixed CS
fixed CS
[Security] fixed path info encoding (closes#6040, closes#5695)
[HttpFoundation] added some tests for the previous merge and removed dead code (closes#6037)
Improved Cache-Control header when no-cache is sent
removed unneeded comment
Fix to allow null values in labels array
fix date in changelog
removed the Travis icon (as this is not stable enough -- many false positive, closes#6186)
Revert "merged branch gajdaw/finder_splfileinfo_fpassthu (PR #4751)" (closes#6224)
Fixed a typo
Fixed: HeaderBag::parseCacheControl() not parsing quoted zero correctly
[Form] Fix const inside an anonymous function
[Config] Loader::import must return imported data
[DoctrineBridge] Fixed caching in DoctrineType when "choices" or "preferred_choices" is passed
[Form] Fixed the default value of "format" in DateType to DateType::DEFAULT_FORMAT if "widget" is not "single_text"
[HttpFoundation] fixed a small regression
Conflicts:
src/Symfony/Component/HttpFoundation/Tests/Session/Storage/Handler/MongoDbSessionHandlerTest.php
I'm trying to create an executable phar archive from a Symfony application, but when I run the phar, it fails to find any commands because of this php bug/feature:
https://bugs.php.net/bug.php?id=52769
After this change, my archive works just like a normal app/console call
This PR was squashed before being merged into the master branch (closes#6232).
Commits
-------
7428bf9 [WebProfilerBundle] Some eye candy for deprecated calls
Discussion
----------
[WebProfilerBundle] Some eye candy for deprecated calls
.
@fabpot is [`|raw`](https://github.com/symfony/symfony/pull/new/deprecated#L0R117) a twig defect ?
---------------------------------------------------------------------------
by Baachi at 2012-12-08T09:12:12Z
Really nice 👍
---------------------------------------------------------------------------
by vicb at 2012-12-11T10:00:24Z
should be ready now
Since even fatal errors are catched and turned into exceptions by
ErrorHandler, all PHP errors can nicely be displayed by
ExceptionHandler. There is no need to set display_errors to true
anymore then.
Partially fixes#6254 on github.
This PR was merged into the master branch.
Commits
-------
d7a1154 make it possible for bundles extensions to prepend settings into the application configuration of any Bundle
Discussion
----------
[2.2] add possibility for bundles extensions to prepend the app configs
Bug fix: #4652
Feature addition: yes
Backwards compatibility break: no
Symfony2 tests pass: yes
License of the code: MIT
As can be seen in the patch the extensions that should prepend the configuration are enabled automatically if they implement ``PrependExtensionInterface``.
Just as an example, here an extension, which checks if SonataAdminBundle is available and if not disables integration with it in several Bundles. It also sets some default settings for ``document_class`` and ``default_document_manager_name``:
```
diff --git a/DependencyInjection/SymfonyCmfCoreExtension.php b/DependencyInjection/SymfonyCmfCoreExtension.php
index 9f92410..c0a8dbb 100644
--- a/DependencyInjection/SymfonyCmfCoreExtension.php
+++ b/DependencyInjection/SymfonyCmfCoreExtension.php
@@ -3,11 +3,12 @@
namespace Symfony\Cmf\Bundle\CoreBundle\DependencyInjection;
use Symfony\Component\HttpKernel\DependencyInjection\Extension;
+use Symfony\Component\\DependencyInjection\PrependExtensionInterface;
use Symfony\Component\DependencyInjection\ContainerBuilder;
use Symfony\Component\DependencyInjection\Loader\XmlFileLoader;
use Symfony\Component\Config\FileLocator;
-class SymfonyCmfCoreExtension extends Extension
+class SymfonyCmfCoreExtension extends Extension implements PrependExtensionInterface
{
public function load(array $configs, ContainerBuilder $container)
{
@@ -15,4 +16,45 @@ class SymfonyCmfCoreExtension extends Extension
$loader->load('config.xml');
$loader->load('services.xml');
}
+
+ public function prepend(ContainerBuilder $container)
+ {
+ $bundles = $container->getParameter('kernel.bundles');
+ if (!isset($bundles['SonataDoctrinePHPCRAdminBundle'])) {
+ // disable SonataDoctrinePHPCRAdminBundle admin support in Bundles
+ $config = array('use_sonata_admin' => false);
+ foreach ($container->getExtensions() as $name => $extension) {
+ switch ($name) {
+ case 'symfony_cmf_menu':
+ case 'symfony_cmf_routing_extra':
+ case 'symfony_cmf_simple_cms':
+ $container->prependExtensionConfig($name, $config);
+ break;
+ }
+ }
+ }
+
+ // process the configuration of SymfonyCmfCoreExtension
+ $configs = $container->getExtensionConfig($this->getAlias());
+ $config = $this->processConfiguration(new Configuration(), $configs);
+ // add the default configs to various Bundles
+ foreach ($container->getExtensions() as $name => $extension) {
+ switch ($name) {
+ case 'symfony_cmf_content':
+ case 'symfony_cmf_simple_cms':
+ $container->prependExtensionConfig($name, $config);
+ break;
+ }
+ }
+ }
}
```
---------------------------------------------------------------------------
by stof at 2012-09-21T21:10:00Z
I think you are giving too much power to bundles here: a bundle becomes able to modify all the config defined explicitly by the user if it wants to do it.
I think it would be safer to give them the possibility to load an additional config file which would be prepended (so that user-defined config would still win). Giving the ability to load files means passing the loader used by the kernel, and it should then be called before calling the load method on the kernel itself (to respect the order of loaded files)
---------------------------------------------------------------------------
by lsmith77 at 2012-09-22T05:50:08Z
Not sure how a config file helps solve anything. I mean they can load as many config files as they want already. The key is being able to automatically apply configuration to multiple Bundles as well as enabling/disabling features based on if certain Bundles are registered.
BTW the end result in my examples is also prepended, so that user config wins. However yes this would be up to the person implementing the Bundle. We could however provide a dedicated method for prepending in addition to or instead of ``setExtensionConfig``.
---------------------------------------------------------------------------
by stof at 2012-09-22T11:40:29Z
@lsmith77 If you can load a file with the main loader, this file can provide some app-level configuration (be it for your own bundle or others).
And your code example is indeed prepending. But imagine what would occur when someone uses this feature without knowing well how the component works: he will likely call ``setExtensionConfig`` in a first implementation, thus dropping all userland config for the bundle. Your setup does not only allow to make a file win over the userland config but makes it even easier to remove the userland config.
---------------------------------------------------------------------------
by lsmith77 at 2012-09-22T18:11:29Z
but i dont get how that would help. the point is to be able for one bundle to configure other bundles before the load as this is obviously alot cleaner than trying to do the same via a compiler pass. so imho this is what is needed to encourage decoupled bundles. otherwise for example CMS or other reuseable and extensible apps will be forced to always put everything in one bundle.
---------------------------------------------------------------------------
by stof at 2012-09-22T19:23:45Z
@lsmith77 I agree about the feature, not about the way to implement it. If you allow bundles to load a file as it it were some app-level config, they would become able to provide some config for other bundles (and you could load several files depending of which bundles are enabled), but without allowing bundles to remove the userland config.
---------------------------------------------------------------------------
by lsmith77 at 2012-09-22T19:50:19Z
sorry but i dont understand what you suggest. more over i dont see the problem. its already possible to seriously break stuff with compiler passes which cannot be easily enabled/disabled. this is just convenience. if it doesnt work because of some obscure combo then simply dont use it for the app since it needs to be explicitly enabled in the kernel.
---------------------------------------------------------------------------
by lsmith77 at 2012-09-24T09:25:10Z
@stof thought about your comments, are you suggesting for a Bundle to be able to generate a config file that is prepended? in that case the current behavior would already be that if we change ``setExtensionConfig`` to just be a ``prependExtensionConfig`` .. however i am not sure if we really need this limitation since as i point out this would still by far be less dangerous than compiler passes and also i expect this to be used mainly by open source applications on top of Symfony2 rather than standard bundles.
---------------------------------------------------------------------------
by lsmith77 at 2012-10-13T13:28:29Z
@lolautruche i also think this is relevant for you guys. this way you could start preconfiguring 3rd party bundles as part of your main ezPublish bundle.
---------------------------------------------------------------------------
by lolautruche at 2012-10-13T13:57:09Z
While I suspect a nice feature, the implementation looks obscure to me...
---------------------------------------------------------------------------
by lsmith77 at 2012-10-13T17:43:02Z
The implementation of the example extension or the implementation of the actual changes proposed in this PR?
---------------------------------------------------------------------------
by lolautruche at 2012-10-13T17:46:57Z
The example, sorry 😃
---------------------------------------------------------------------------
by lsmith77 at 2012-10-13T17:50:38Z
The example was fairly quickly hacked together. The basic thing you need to do is fetch the config for the bundle you want to change, manipulate the config (usually by appending an array to the array of configs so that you dont affect explicit configuration) and then set it again.
As I explained to @stof it would alternative/additionally be possible to support a method that pushes a config array to the top of the array of config stack. Such a method might make the necessary code simpler.
---------------------------------------------------------------------------
by stof at 2012-10-13T21:39:07Z
@fabpot what do you think about it ?
---------------------------------------------------------------------------
by jrobeson at 2012-10-20T15:45:18Z
I've been porting much of an existing framework over to use more symfony components and bundles. I think that this might help some of the problems i've been having. I would really appreciate some better examples as how to one would use it (same for the cmf router, but that's another story).
---------------------------------------------------------------------------
by lsmith77 at 2012-10-21T07:28:52Z
not really sure what other examples i could give. the process is quite simple:
1) determine what configuration options to add to other Bundles
for example with the following code I determine that SonataAdmin for PHPCR is not installed (which means i should disable using it in other Bundles):
```
$bundles = $container->getParameter('kernel.bundles');
if (!isset($bundles['SonataDoctrinePHPCRAdminBundle'])) {
```
alternatively I could simply already process the configuration and then pick all or some of these configuration options:
```
$configs = $container->getExtensionConfig($this->getAlias());
$config = $this->processConfiguration(new Configuration(), $configs);
```
2) then add these configuration to what other Bundles I feel should get these options
usually I will add these to the top of the config array stack. this means that if the user would manually set the same setting in most cases the user setting will override what the pre-processor set.
```
$container->unshiftExtensionConfig($name, array('use_sonata_admin' => false));
```
---------------------------------------------------------------------------
by lsmith77 at 2012-10-24T12:52:38Z
added ``ContainerBuilder::unshiftExtensionConfig`` since this is the usual use case. with this method added it could be discussed if ``ContainerBuilder::setExtensionConfig`` is still needed or not.
---------------------------------------------------------------------------
by lsmith77 at 2012-11-24T14:48:44Z
I spoke to @fabpot today and he said that since this patch just allows you to set defaults and not really "process" the actual configuration I shouldn't call it "preProcess" so I renamed it to "prepend".
Furthermore as its just prepending @fabpot said there isnt really a need to require manually enabling it, so here is a patch to auto-enable the prepending logic:
```
diff --git a/src/Symfony/Component/HttpKernel/Kernel.php b/src/Symfony/Component/HttpKernel/Kernel.php
index b890fbf..7374b87 100644
--- a/src/Symfony/Component/HttpKernel/Kernel.php
+++ b/src/Symfony/Component/HttpKernel/Kernel.php
@@ -701,8 +701,8 @@ abstract class Kernel implements KernelInterface, TerminableInterface
*/
protected function prependExtensionConfigs(ContainerBuilder $container)
{
- foreach ($this->getPrependingExtensions() as $name) {
- $extension = $container->getExtension($name);
+ foreach ($this->bundles as $bundle) {
+ $extension = $bundle->getContainerExtension();
if ($extension instanceof PrependExtensionInterface) {
$extension->prepend($container);
}
@@ -710,16 +710,6 @@ abstract class Kernel implements KernelInterface, TerminableInterface
}
/**
- * Returns the ordered list of extensions that may prepend extension configurations.
- *
- * @return array
- */
- protected function getPrependingExtensions()
- {
- return array();
- }
-
- /**
* Gets a new ContainerBuilder instance used to build the service container.
*
* @return ContainerBuilder
```
---------------------------------------------------------------------------
by lsmith77 at 2012-11-25T19:31:01Z
ok .. i pondered the code some more and now i have enabled registering of the prepending extensions by default, since its now quite easy to just override the ``prependExtensionConfigs()`` method since there is almost no logic in there anymore.
@fabpot i am not 100% sure with the naming yet ..
---------------------------------------------------------------------------
by lsmith77 at 2012-12-05T14:03:43Z
@fabpot if you are ok with the PR as it is now, i can do the rebase so you can merge this?
---------------------------------------------------------------------------
by lsmith77 at 2012-12-05T18:30:29Z
@fabpot all good now? then i will squash the commits ..
---------------------------------------------------------------------------
by lsmith77 at 2012-12-05T18:34:50Z
actually looking at the full change set again i am no longer sure if it makes sense to have ``PrependExtensionInterface`` in the DI rather than the HttpKernel.
---------------------------------------------------------------------------
by lsmith77 at 2012-12-07T09:21:14Z
@fabpot all good now?
---------------------------------------------------------------------------
by fabpot at 2012-12-07T09:37:52Z
The code looks good to me now. There are two remaining task before merging:
* Is it something we need to add somewhere in the documentation?
* Can you add a note in the DI component CHANGELOG?
Thanks.
---------------------------------------------------------------------------
by lsmith77 at 2012-12-07T09:49:17Z
i have added a changelog entry and squashed the commits.
i will also work on a documentation entry, i guess i will make it a cookbook entry. not sure if it should be included in http://symfony.com/doc/2.0/cookbook/bundles/extension.html .. but imho it would better be a separate entry.
This PR was merged into the master branch.
Commits
-------
7f16c1f [HttpKernel] Add DI extension configs as ressources when possible
Discussion
----------
[HttpKernel] Add DI extension configs as ressources when possible
/cc @rdohms @richardmiller
---------------------------------------------------------------------------
by vicb at 2012-11-30T11:57:48Z
btw @fabpot what about having a base class for `Extension` in the DI ? Would make it easier to re-use it when using standalone components, Di and (the suggested) Config as the greatest part of the class is not HttpKernel specific.
---------------------------------------------------------------------------
by fabpot at 2012-12-06T08:47:28Z
@vicb your suggestion makes sense.
Can you also explain the goal of this PR?
---------------------------------------------------------------------------
by vicb at 2012-12-06T09:01:58Z
The goal of this PR is to avoid having to sfcc when you modify a DI extension configuration. I think @rdohms got trapped.
---------------------------------------------------------------------------
by vicb at 2012-12-06T09:08:08Z
see https://twitter.com/rdohms/status/274059267428978688
---------------------------------------------------------------------------
by stof at 2012-12-06T09:20:54Z
I thought about it several times but never took time to implement it. It is annoying to have to clear the cache when you modify a default value in the Configuration class. So +1
This PR was squashed before being merged into the master branch (closes#6173).
Commits
-------
4878ec0 [HttpKernel] [WebProfilerBundle] Better handling of deprecated methods
Discussion
----------
[HttpKernel] [WebProfilerBundle] Better handling of deprecated methods
Bug fix: no
Feature addition: yes
Backwards compatibility break: yes, if you were expecting E_USER_DEPRECATED or E_DEPRECATED to throw an exception
Symfony2 tests pass: yes
Fixes the following tickets: #6139 partly, I'd go through and add the actual trigger_error() calls in another (or possibly one per component) PR
Todo: call trigger_error()
License of the code: MIT
Documentation PR: -
I added the deprecation count with the Exception icon in the Profiler Toolbar, and changed the color of it to be yellow for deprecations and red for exceptions (was yellow for exceptions).
---------------------------------------------------------------------------
by fabpot at 2012-12-03T09:43:09Z
Adding trigger_error calls should be done in one PR to ease the merging. thanks.
This PR was merged into the master branch.
Commits
-------
acfc750#2042 initial implementation of fatal error handler
Discussion
----------
Display traces for fatal errors
Bug fix: no
Feature addition: yes
Backwards compatibility break: no
Symfony2 tests pass: looks like yes
Fixes the following tickets: #2042 (partly)
License of the code: MIT
Output looks like on screen http://easycaptures.com/fs/uploaded/737/1191436899.png . I've added one line to css to prevent displaying standard xdebug trace http://easycaptures.com/fs/uploaded/737/5939488074.png
---------------------------------------------------------------------------
by Koc at 2012-11-08T21:55:41Z
So, community please advice me, how can I trigger `KernelEvents::EXCEPTION` event in `ErrorHandler` or `ExceptionHandler`? Or should I provide other event for this?
---------------------------------------------------------------------------
by stof at 2012-11-08T22:03:23Z
@Koc Don't. the exception handler is there to be the safe guard when developing, and does not depend on the kernel (which would be required to trigger the event). If you were triggering the listener again, it would mean that any exception thrown in a listener would lead to a loop.
And if it is for the fatal error handling, you simply cannot be sure the kernel is still available (and even less in a wokring state) at this point.
---------------------------------------------------------------------------
by Koc at 2012-11-08T22:06:31Z
But how can I notify logger (which will send me mail or just log this situation)?
---------------------------------------------------------------------------
by fabpot at 2012-11-09T07:33:41Z
The error handler is only registered when in debug mode in the Kernel and can be triggered very early in the handling of a request (even before we have access to the dispatcher or anything else). So, the current PR looks fine to me (apart from the typo and the lack of unit tests).
---------------------------------------------------------------------------
by Koc at 2012-11-09T09:13:03Z
> The error handler is only registered when in debug mode
Ooh! I haven't see that before. But the goal - be notified about errors by email or log-file. Like now exceptions with traces from site emails to me.
---------------------------------------------------------------------------
by fabpot at 2012-11-09T09:20:54Z
I think there are two goals. The first one being to have nice pages in the development environment when a fatal error occurs. And this PR addresses that feature quite nicely. The second can be addressed in another PR.
---------------------------------------------------------------------------
by henrikbjorn at 2012-11-14T11:50:22Z
I have some questions about the ErrorHandler. Is there a reason for it only to be registered in an debug environment (which prod is not). Would assume that if i enable the ErrorHandler in productions aswell Monolog would log thoose instead of them just vanishing?
---------------------------------------------------------------------------
by Koc at 2012-11-14T12:01:50Z
I am thinking about it too. But as Fabien says it will another PR
---------------------------------------------------------------------------
by GromNaN at 2012-11-18T10:38:09Z
You should add a memory reserve to be able to handle "Out of memory" errors.
An example is here :
513d628966/lib/Raven/ErrorHandler.php (L91)513d628966/lib/Raven/ErrorHandler.php (L62)
---------------------------------------------------------------------------
by fabpot at 2012-11-28T11:35:21Z
@Koc can you finish this PR (probably by integrating the memory reserve as explained by @GromNaN)?
---------------------------------------------------------------------------
by Koc at 2012-11-28T11:46:12Z
of course, on this weekend
---------------------------------------------------------------------------
by Koc at 2012-12-02T17:44:44Z
@fabpot done
