This PR was merged into the master branch.

Discussion
----------

Fix JSON parse error in Twig docs

Commits
-------

a7efc8f4 Fix JSON parse error in Twig docs

This PR was merged into the master branch.

Discussion
----------

Only register one of each authentication provider

Fixes #655

Commits
-------

657bf5f6 Only register one of each authentication provider

Fixes #655

This PR was merged into the master branch.

Discussion
----------

added exception in the Monolog context when appropriate (closes #613, closes #614)

Added support for PSR-3 logging and the special exception key.

Commits
-------

973ee703 added exception in the Monolog context when appropriate (closes #613, closes #614)

This PR was merged into the master branch.

Discussion
----------

fixed use statement

fixes bolt/bolt#322

and addresses #663

Commits
-------

081a05b2 use request context from silex

This PR was merged into the master branch.

Discussion
----------

Multiple Monolog Loggers Cookbook

First Draft, comments appreciated. I tried to make it more of a cookbook than just the example in #567

Commits
-------

3247b740 Clarify the described convention
71312015 Use statements
08669b72 Typos
2153e86d Multiple Monolog Loggers Cookbook

This PR was squashed before being merged into the master branch (closes #648).

Discussion
----------

Added support for URL host from Routing Component

Hi everyone,

Firstly, I wanted to thank you all for Silex. It's fabulous.

I needed URL host support in Silex to manage different subdomains of my small application and came up with an idea of introducing `->host($host)` chained method to `Silex\Route` class. This way users can apply host resolution to controllers in Silex.

This PR includes above functionality + one unit test to check if everything works as expected.

URL host support is of course available in Routing Component from version `>=2.2`, but Silex relies on 2.2 anyway.

Example:
```php
<?php

// ...

$app->match('/', function() {
    // app-specific action
})->host('example.com');

$app->match('/', function ($user) {
    // user-specific action
})->host('{user}.example.com');

// ...
```

I am open for comments.

Commits
-------

f0124c7f Added support for URL host from Routing Component

This PR was merged into the master branch.

Discussion
----------

note that `mod_rewrite` needs to be enabled

If `mod_rewrite` isn't enabled - like in default Apache installs and WAMP - it will result in 404's. I had this issue with the hello world zip distribution (SO question: http://stackoverflow.com/questions/15498419/why-am-i-getting-these-silex-404s) and it was quite difficult to track down. Almost made me give up on Silex, although this is of course not a Silex issue - but it can be challenging for beginners, and if you can't get the hello world to run it kinda takes the wind out of your sails.

Commits
-------

091b99cb note that `mod_rewrite` needs to be enabled

This PR was merged into the master branch.

Discussion
----------

Add example of JsonUserPersister being managed

Reintroducing the example used at the beginning will make things clearer, I think.

Commits
-------

96574213 Add example of JsonUserPersister being managed

This PR was merged into the master branch.

Discussion
----------

fixed request dependency on the URL matcher

Alternative fix for #662

Commits
-------

5dc7c27f fixed request dependency on the URL matcher

This PR was merged into the master branch.

Discussion
----------

Change visibility of `providers` and `booted` to protected

This changes `$providers` and `$booted` in `Application` to protected, which makes it easier to extend.

Commits
-------

e6902d10 Change visibility of `providers` and `booted` to protected

This PR was squashed before being merged into the master branch (closes #623).

Discussion
----------

Include querystring parameters when issuing a redirect from RedirectableUrlMatcher

When a route has a scheme requirement (HTTP or HTTPS) and the current request's scheme does not match it, it issues a redirect to the required scheme. Prior to this change, the new URL being redirected to left off the querystring parameters.

It would be cleaner to set the QUERY_STRING parameter as part of RequestContext->fromRequest() but that's part of the Symfony core. Including it inside the $this['url_matcher'] closure keeps the change localized to Silex.

Commits
-------

09034777 Include querystring parameters when issuing a redirect from RedirectableUrlMatcher

If `mod_rewrite` isn't enabled - like in default Apache installs and WAMP - it will result in 404's. I had this issue with the hello world zip distribution (SQ question: http://stackoverflow.com/questions/15498419/why-am-i-getting-these-silex-404s) and it was quite difficult to track down. Almost made me give up on Silex, although this is of course not a Silex issue - but it can be challenging for beginners, and if you can't get the hello world to run it kinda takes the wind out of your sails.

This PR was merged into the master branch.

Commits
-------

6a4fffeb Added a note about writing documentation

Discussion
----------

Added a note about writing documentation

---------------------------------------------------------------------------

by igorw at 2013-03-08T15:52:03Z

👍

This PR was squashed before being merged into the master branch (closes #553).

Commits
-------

7c38c9a8 Add services allowing for form type extensions and guessers

Discussion
----------

Add services allowing for form type extensions and guessers

I don't like the empty `FormTypeGuesserChain`, but `PreloadedExtension` requires one to be passed until symfony/symfony#5479 gets merged.

---------------------------------------------------------------------------

by fabpot at 2012-11-24T11:54:08Z

symfony/symfony#5479 has been merged now.

---------------------------------------------------------------------------

by davedevelopment at 2012-11-25T19:59:41Z

So, do we want this documenting at this point? I'm glad to have removed the dummy TypeGuesser, but without it, people who don't have a 'dev' version of symfony/form, will need the workaround in their userland code, which may cause headaches.

---------------------------------------------------------------------------

by fabpot at 2013-01-10T07:34:15Z

I think we need to switch to Symfony 2.2 in Silex now. What others think? @igorw

---------------------------------------------------------------------------

by davedevelopment at 2013-01-10T07:54:20Z

👍 from me, though while we're on the topic, are there any plans to tag a 1.0?

---------------------------------------------------------------------------

by igorw at 2013-01-10T13:52:38Z

@fabpot Is there any reason why you would want to enforce users to use an unstable version?

I am against it for the following reasons:

* Users should be able to get stable versions if the stable versions work correctly.
* Silex already allows you to get 2.2, simply by lowering the `minimum-stability` to `beta`.
* Our current recommended way to install silex is `1.0.*@dev` (except on the download page, because it was not updated correctly when we changed it). This means that once they update it will blow up (due to `minimum-stability`), which will result in a lot of frustration, and a lot of support requests.

IMO we should encourage our users to try 2.2 by lowering their `minimum-stability`, but not enforce it.

---------------------------------------------------------------------------

by stof at 2013-01-10T13:55:34Z

another solution would be to bump the requirement to 2.2 only after releasing Silex.

---------------------------------------------------------------------------

by fabpot at 2013-01-11T07:51:36Z

Silex has not reached 1.0 yet. So, switching to 2.2 seems logical to me. That being said, we can wait for 2.2 stable to be out if this is what you suggest.

---------------------------------------------------------------------------

by igorw at 2013-01-11T16:23:06Z

Bumping to 2.2 after it is stable sounds acceptable to me, but unless there is a specific change in 2.2 that silex *needs*, I still don't really see the point. Supporting 2.1+ is easy enough to do.

---------------------------------------------------------------------------

by davedevelopment at 2013-03-06T13:28:19Z

So the current status with this PR, is that adding a TypeExtension with anything less than 2.1.4 of the symfony components will break, unless the user also adds an FormTypeGuesserChain to the guessers array. That is, the test `testFormServiceProviderWillLoadTypeExtensions` will fail with symfony/form < 2.1.4.

If we want to merge this in I guess we can:

* Document the whole feature, with a note/gotcha for Symfony <2.1.4
* Bump the minimum Symfony component versions to 2.1.4
* Just merge it anyway

---------------------------------------------------------------------------

by stof at 2013-03-06T14:13:38Z

bumping to 2.1.4 as minimum is fine IMO. I don't see why someone would want to use 2.1.0 explicitly instead of using the bufix releases for 2.1

---------------------------------------------------------------------------

by fabpot at 2013-03-06T21:39:29Z

👍 for bumping to 2.1.4+

---------------------------------------------------------------------------

by igorw at 2013-03-06T22:08:37Z

In this particular case I'd say it's acceptable to bump to `2.1.4`.

In the future these kind of changes will need more consideration though, as they can cause BC issues when multiple branches of symfony are supported by silex.

---------------------------------------------------------------------------

by fabpot at 2013-03-08T12:05:04Z

When we said bumping to 2.1.4, I thought we were talking about bumping for just the component that has problems with earlier Symfony version, not all of them.

---------------------------------------------------------------------------

by davedevelopment at 2013-03-08T12:14:06Z

I did that because I wasn't sure how to approach it, I'll have a think about it, but I'll probably need some guidance.

I guess we may have to fall back on documenting that we have a dependency on 2.1.4 version of the Form Component, because it's not actually required? Maybe that should be in `suggest`? I don't think suggest enforces version requirements, so it either needs to be in the suggest message, or in the docs?

---------------------------------------------------------------------------

by igorw at 2013-03-08T12:22:59Z

It should be in both. Specifically, the form service provider docs.

---------------------------------------------------------------------------

by davedevelopment at 2013-03-08T13:01:26Z

Changed the requirements bump and documented, do we need to have something more specific/wordy in the docs?

Squashed a little as well, can squash further if it's desirable.

This PR was squashed before being merged into the master branch (closes #645).

Commits
-------

adc172b3 Add support for remember-me with RememberMeServiceProvider

Discussion
----------

Add support for remember-me with RememberMeServiceProvider

This is a refactoring of #464.

I made a separate service provider to avoid adding more complexity to the SecurityServiceProvider.

This PR was merged into the master branch.

Commits
-------

eb941a8f proper prefixes for cookie options

Discussion
----------

All cookie-related options of NativeSessionStorage should be prefixed with `cookie_`

---------------------------------------------------------------------------

by indeyets at 2013-02-16T09:25:59Z

Separate issue is, that there are, actually, much more options available. Listing all of those wouldn't be useful for this doc, so I skipped it for now.

---------------------------------------------------------------------------

by igorw at 2013-02-16T15:33:22Z

The doc should probably link to http://php.net/session.configuration

---------------------------------------------------------------------------

by igorw at 2013-03-05T02:30:32Z

@indeyets what's the status on this? can you update your patch with the link?

This PR was merged into the master branch.

Commits
-------

e11b93e3 Force travis to use 2.1.*

Discussion
----------

Force travis to use 2.1.* now 2.2 has a stable release

This PR was merged into the master branch.

Commits
-------

36b879b3 Use addPrefix to avoid deprecated calls in >2.2.0

Discussion
----------

Use addPrefix to avoid deprecated calls in >2.2.0

I think this should take care of #642