[DomCrawler] Fixed incorrect value name conversion in getPhpValues() and getPhpFiles() #10193
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
Just noticed that, even though my branch was based off of 2.3, GitHub defaulted my PR target to master. Would you like me to close this and create a new PR with target 2.3, or will you merge this by hand (if accepted)? |
|
@robbertkl No problem, I will probably be able to merge it properly on 2.3. |
…bertkl) This PR was merged into the 2.3 branch. Discussion ---------- [DomCrawler] Fixed incorrect handling of image inputs | Q | A | ------------- | --- | Bug fix? | yes | New feature? | no | BC breaks? | no | Deprecations? | no | Tests pass? | yes | Fixed tickets | #10204 | License | MIT | Doc PR | A possible approach to fix #10204, but I'm open to suggestions to fix this another way, as this might not be the most 'elegant' way. Initially, my thoughts were to create a new DomCrawler\Field\FormField subclass, especially for image inputs. However, this does not solve the problem, because such a FormField would still exist under 1 name in the FormFieldRegistry. Instead, I've changed it to have 2 separate FormFields instead (which both reference the same input node), with different names (.x and .y) so that both values can be set separately and will both be submitted. Commits ------- 816cf17 [DomCrawler] Fixed incorrect handling of image inputs
This PR was merged into the 2.3 branch. Discussion ---------- [DomCrawler] Fixed filterXPath() chaining | Q | A | ------------- | --- | Bug fix? | yes | New feature? | no | BC breaks? | debatable (see below) | Deprecations? | no | Tests pass? | yes | Fixed tickets | #10206 | License | MIT | Doc PR | As @stof mentions in #10206, each node in the Crawler can belong to a different \DOMDocument. Therefore, I've made each node do its own XPath, relative to itself, and add all the results to a new Crawler. This way, all resulting nodes are still part of their original \DOMDocument and thus can reach all of their parent nodes. No current tests break on this change. I've added a new test for this case, by checking if the number of parents is correct after obtaining a node through chaining of `filterXPath()`. Now for BC: I can think of a number of cases where this change would give a different result. However, it's debatable/unclear if: - the old behavior was a bug in the first place (which would validate this change), or - the old behavior was intended (which would make this a BC breaking change) As an example, consider the following HTML: ```html <div name="a"><div name="b"><div name="c"></div></div></div> ``` What would happen if we run this: ```php echo $crawler->filterXPath('//div')->filterXPath('div')->filterXPath('div')->attr('name'); ``` Aside from breaking reachability of the parent nodes by chaining, with the original code it would echo 'a'. With this patch it would echo 'c', which, to me, makes more sense. Commits ------- 43a7716 [DomCrawler] Fixed filterXPath() chaining
…and getPhpFiles()
|
Just did a rebase with 2.3. Now, unfortunately, this PR shows these commits in the patch, since the target is accidentally set to master instead of 2.3. So, to clarify, it's just about commit a960ab8, which was meant for 2.3. |
|
Closing in favor of #10444 |
fabpot
added a commit
that referenced
this pull request
Mar 14, 2014
…hpValues() and getPhpFiles() (romainneutron) This PR was merged into the 2.3 branch. Discussion ---------- [DomCrawler] Fixed incorrect value name conversion in getPhpValues() and getPhpFiles() | Q | A | ------------- | --- | Bug fix? | yes | New feature? | no | BC breaks? | no | Deprecations? | no | Tests pass? | yes | Fixed tickets | #6908 | License | MIT This PR replaces #10193 Commits ------- 89c599e [DomCrawler] Add tests for recursive cases of getPhpValues() and getPhpFiles() e961f57 [DomCrawler] Fixed incorrect value name conversion in getPhpValues() and getPhpFiles()
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Possibly fixes #9009 as well, but not sure how HttpFoundation relates to DomCrawler and how to reproduce there.
The problem is that
getPhpValues()andgetPhpFiles()depend onparse_str()to do the conversion. While this is a great and reliable way, it has an unwanted side effect: any occurences of a period '.' (as #6908 mentions) or a space ' ' get replaced by an underscore. This results in different values, or even collisions (as 'foo_bar=5&foo.bar=6' would map to foo_bar => 6!). This replacement is specific to PHP and should not happen in DomCrawler\Form, which should support any kind of form.I ran into this issue while using fabpot/Goutte, which could not post a form field with a name containing '.', while the receiving web server (which isn't running PHP) required this.
PR #9730 tried to fix this in BrowserKit, which doesn't seem to be the correct place, aside from it breaking BC.
This change, however, does not break BC and works by feeding each value through
http_build_query()andparse_str()separately, then find the original name and change it back, and finally merging the results witharray_replace_recursive().I've also added 2 simple test cases to FormTest which will ensure this replacement will not sneak back in.