Thanks to visit codestin.com
Credit goes to github.com

Skip to content

[DomCrawler] phpFiles array is generated wrongly for fields with more than one level #14021

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Closed
albe opened this issue Mar 23, 2015 · 7 comments
Closed

[DomCrawler] phpFiles array is generated wrongly for fields with more than one level #14021

albe opened this issue Mar 23, 2015 · 7 comments
Labels
Bug DomCrawler Status: Needs Review

Comments

@albe
Copy link

albe commented Mar 23, 2015

Symfony DomCrawler is broken for file uploads. It creates a wrongly formatted phpFiles array, when the submit field has more than one level, e.g. "post[upload]" will create

    array(1) {
      ["post"]=>
      array(1) {
        ["upload"]=>
        array(5) {
          ["name"]=>
          string(0) ""
          ["type"]=>
          string(0) ""
          ["tmp_name"]=>
          string(0) ""
          ["error"]=>
          string(1) "0"
          ["size"]=>
          string(1) "0"
        }
      }
    }

instead of the expected that PHP creates

    array(1) {
      ["post"]=>
      array(5) {
        ["name"]=>
        array(1) {
          ["upload"]=>
          string(13) ""
        }
        ["type"]=>
        array(1) {
          ["upload"]=>
          string(15) ""
        }
        ["tmp_name"]=>
        array(1) {
          ["upload"]=>
          string(27) ""
        }
        ["error"]=>
        array(1) {
          ["upload"]=>int(0)
        }
        ["size"]=>
        array(1) {
          ["upload"]=>
          int(0)
        }
      }
    }
@albe albe changed the title [B][DomCrawler] phpFiles array is generated wrongly for fields with more than one level [DomCrawler] phpFiles array is generated wrongly for fields with more than one level Mar 23, 2015
@xabbuh
Copy link
Member

xabbuh commented Mar 23, 2015

Hi @albe, I'm not sure if I understand your issue. Can you please provide an example HTML snippet and how you used the DomCrawler component?

@albe
Copy link
Author

albe commented Mar 23, 2015

Sorry for the short description. I'm using it in TYPO3 Flow currently for writing (functional) tests. There DomCrawler is used to simulate a browser to send a request from given HTML forms.
But the issue is really just DomCrawler\Form::getPhpFiles() method. That method should provide output that resembles PHP's $_FILES global variable, right?

So here is an example to show the behaviour:

    $html = <<<'HTML'
    <!DOCTYPE html>
    <html>
        <body>
            <form method="post">
                <input type="file" name="post[upload]" />
            </form>
        </body>
    </html>
    HTML;
    $crawler = new \Symfony\Component\DomCrawler\Crawler($html, 'http://localhost');
    $form = $crawler->filterXPath('//form')->form();
    var_dump($form->getPhpFiles());

The output is as given above, while submitting this form in a browser and handling it with PHP var_dump'ing $_FILES, it gives the expected output. Just let me know if you need any further information on this issue.

@jakzal
Copy link
Contributor

jakzal commented Mar 31, 2015

That method should provide output that resembles PHP's $_FILES global variable, right?

Correct. I think this is a bug, as here's what we promise in getPhpFiles() comment:

This method converts fields with the array notation (like foo[bar] to arrays) like PHP does.

like PHP does part is currently a lie. Looks like it never worked properly. There's even a test verifying invalid behaviour. Changing it at this point might be problematic due to BC promise :(

@albe
Copy link
Author

albe commented Apr 1, 2015

Yeah ok, I understand that :) But really should be adressed in the next major update that is breaking BC

@albe albe mentioned this issue Apr 2, 2015
Closed
@albe
Copy link
Author

albe commented Apr 2, 2015

I created a pull request with a possible solution that I use locally for the time being. That solution is not complete though, since getPhpValues (and maybe other places I don't know of) might need change too. Still in any case you consider fixing this, you can use that as base freely to your liking.

fabpot pushed a commit to fabpot/symfony that referenced this issue Apr 7, 2015
@albe @fabpot
bug symfony#14021 Make getPhpFiles actually behave like PHP $_FILES
ce37133
@fabpot fabpot mentioned this issue Apr 7, 2015
Closed
@dosten
Copy link
Contributor

dosten commented Apr 13, 2015

This can be closed?

@jakzal
Copy link
Contributor

jakzal commented Apr 13, 2015

@dosten it hasn't been resolved in any way yet.

@jakzal jakzal mentioned this issue Feb 12, 2016
Merged
fabpot added a commit that referenced this issue Feb 12, 2016
@fabpot
minor #17776 [DomCrawler] Clarify the value returned by getPhpFiles()…
1be2d34 
… (jakzal)

This PR was merged into the 2.3 branch.

Discussion
----------

[DomCrawler] Clarify the value returned by getPhpFiles()

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

The comment was previously suggesting the returned value is similar to the one stored in $_FILES, while it is more similar to the way PHP stores submitted form values. It is actually more convenient to have it this way, so rather then changing the returned value (which would break BC), it is better to clarify the comment.

Commits
-------

a694401 [DomCrawler] Clarify the value returned by getPhpFiles()
@fabpot fabpot closed this as completed Feb 12, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
Bug DomCrawler Status: Needs Review
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
7 participants
@fabpot @javiereguiluz @jakzal @dosten @xabbuh @albe @carsonbot