merged branch SamsonIT/fixedMessedUpHeaders (PR #7189)

This PR was squashed before being merged into the 2.2 branch (closes #7189).

Commits
-------

850bd5a [HttpFoundation] Fixed messed up headers

Discussion
----------

[HttpFoundation] Fixed messed up headers

| 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

I ran into this when somewhere in our code the Response object was cast into a string. After that, when send()'ing the Response, the headers would be all mixed up. This is because the __toString in HeaderBag ksorts the headers, while the __toString in ResponseHeaderBag doesn't ksort the corresponding headerNames. This patch ksorts that one as well.

allPreserveCase() is new to 2.2, so this bug doesn't seem to affect earlier versions.

To be exact, this is where it got introduced: https://github.com/symfony/symfony/commit/63a228c45613bb

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

by Burgov at 2013-02-26T09:27:20Z

B.t.w. another option was to ksort a copy of the headers array in the ResponseBag and leaving the actual thing as-is. Not sure which one would be the best option?
[Finder] Adds expandable globs support to shell adapters
merged branch jfsimon/issue-6586 (PR #7190)

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

Commits
-------

6e0d93e [Finder] Adds expandable globs support to shell adapters

Discussion
----------

[Finder] Adds expandable globs support to shell adapters

As expandable globs, i mean glob following `*.{a,b}` syntax.

| Q             | A
| ------------- | ---
| Bug fix?      | yes
| New feature?  | no
| BC breaks?    | no
| Deprecations? | no
| Tests pass?   | yes
| Fixed tickets | #6586
Adds expandable globs support to shell adapters
merged branch jfsimon/issue-6586 (PR #7190)

This PR was submitted for the master branch but it was merged into the 2.2 branch instead (closes #7190).

Commits
-------

b2e9bdb [Finder] Adds expandable globs support to shell adapters

Discussion
----------

[Finder] Adds expandable globs support to shell adapters

As expandable globs, i mean glob following `*.{a,b}` syntax.

| Q             | A
| ------------- | ---
| Bug fix?      | yes
| New feature?  | no
| BC breaks?    | no
| Deprecations? | no
| Tests pass?   | yes
| Fixed tickets | #6586
fix issue 4911
fixed paths/notPaths regex for shell adapters
merged branch jfsimon/issue-4911 (PR #7188)

This PR was submitted for the master branch but it was merged into the 2.2 branch instead (closes #7188).

Commits
-------

3b2cb79 [Finder] fixed paths/notPaths regex for shell adapters
45b84c5 [Finder] fix issue 4911

Discussion
----------

[Finder] Fixes paths/notPaths issue with shell adapters

This PR is built upon #5128 from @gajdaw.
It fixes wrong handling of regex in `paths` and `notPaths` criteria by shell adapters.

| Q             | A
| ------------- | ---
| Bug fix?      | yes
| New feature?  | no
| BC breaks?    | no
| Deprecations? | no
| Tests pass?   | yes
| Fixed tickets | #4911, #5128
Routing issue with installation in a sub-directory
ref: https://github.com/symfony/symfony/issues/7129
Fixed handling absent href attribute in base tag

The HTML5 spec states that the href attribute is optional for the
base tag. Fixed the DomCrawler::addHtmlContent() method to support this

See here and here:
http://www.w3.org/TR/html-markup/base.html#base.attrs.href
http://www.whatwg.org/specs/web-apps/current-work/multipage/semantics.html#the-base-element
merged branch matthijsvandenbos/matthijsvandenbos/basetag-href-fix (PR #7178)

This PR was submitted for the master branch but it was merged into the 2.1 branch instead (closes #7178).

Commits
-------

c41f640 [DomCrawler] Fixed handling absent href attribute in base tag

Discussion
----------

[DomCrawler] Fixed handling absent href attribute in base tag

| Q             | A
| ------------- | ---
| Bug fix?      | yes
| New feature?  | no
| BC breaks?    | no
| Deprecations? | no
| Tests pass?   | yes
| Fixed tickets |
| License       | MIT
| Doc PR        |

# Description
The HTML5 spec states that the href attribute is optional for the
base tag. The current code causes an exception on conforming HTML.
Fixed the DomCrawler::addHtmlContent() method to support this.
Added Unit Test to check for this situation.

# Explanantion
Currently, if the base tag doesn't have an href attribute, the uri for the DomCrawler gets set to an empty string. This is incorrect behaviour, especially because it breaks DomCrawler::links(). The Symfony\Component\DomCrawler\Link objects it creates, expect a non-empty string in their constructor arguments and throw an InvalidArgumentException.

# References
http://www.w3.org/TR/html-markup/base.html#base.attrs.href
http://www.whatwg.org/specs/web-apps/current-work/multipage/semantics.html#the-base-element
merged branch lsmith77/debugclassloader_findfile_2_1 (PR #7168)

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

:-1: 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 ;)
[TwigBridge] fixed the translator extractor that were not trimming the text in trans tags (closes #7056)

Trimming was not done by the extractor but it was the default behavior
of the TransNode class. Now, things are consistent between the two.
[Finder] Unified tests
[Console] Fixed comment
merged branch DenisGorbachev/2.0 (PR #7198)

This PR was merged into the 2.0 branch.

Commits
-------

3be3dde [Console] Fixed comment

Discussion
----------

[Console] Fixed comment

| Q             | A
| ------------- | ---
| Bug fix?      | no
| New feature?  | no
| BC breaks?    | no
| Deprecations? | no
| Tests pass?   | yes
| Fixed tickets | -
| License       | MIT
| Doc PR        | -
[DomCrawler] fix handling of schemes by Link::getUri()

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.
merged branch matthijsvandenbos/matthijsvandenbos/link-handle-scheme (PR #7214)

This PR was merged into the 2.1 branch.

Commits
-------

8f8ba38 [DomCrawler] fix handling of schemes by Link::getUri()

Discussion
----------

[DomCrawler] fixed handling of schemes by Link::getUri()

A link (anchor tag with an href attr) in pages 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.

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

by matthijsvandenbos at 2013-02-28T11:55:18Z

Ok, I will update the pull request

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

by matthijsvandenbos at 2013-02-28T12:25:45Z

Fixed
[Finder] adds adapter selection/unselection capabilities
merged branch jfsimon/finder-adapter-selection (PR #7212)

This PR was squashed before being merged into the 2.2 branch (closes #7212).

Commits
-------

f40adbc [Finder] adds adapter selection/unselection capabilities

Discussion
----------

[Finder] adds adapter selection/unselection capabilities

As we have many issues with the native finder adapter, it would be good to:
*  permit selection of a particular adapter which will be choosed over the others until its unselection
*  permit unselection of adapters to get the finder select trhe best on (by priority)
*  have `PhpAdapter` selected by default

This PR adds 2 methods to the `Finder`:
*  `setAdapter($adapter)`: selects an adapter by its name
*  `useBestAdapter()`: tells the finder to select best adapter by their priority

| Q             | A
| ------------- | ---
| Bug fix?      | no
| New feature?  | yes
| BC breaks?    | no
| Deprecations? | no
| Tests pass?   | yes

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

by jfsimon at 2013-02-28T14:05:25Z

@fabpot I just applied all your good advices, there was no bad one :)