Skip to content

Wrong handling of arrays in HTTP POST requests #93

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.

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

Closed
TobiasBg opened this issue Dec 16, 2022 · 3 comments
Closed

Wrong handling of arrays in HTTP POST requests #93

TobiasBg opened this issue Dec 16, 2022 · 3 comments

Comments

@TobiasBg
Copy link

While testing my plugin in the Playground, I found that either the "webserver part" or the "PHP part" seems to be treating HTTP POST variables wrong that are an array.

In particular, in my plugin I have an HTML form with inputs like

<input type="text" name="table[name]" value="" />

Note the array-type name attribute.

In PHP, this should be available as $_POST['table']['name']. However, $_POST['table'] does not exist.

A var_dump( $_POST ); gives

array(9) {
  ...
  ["table[name]"]=>
  string(4) "test"
  ["table[description]"]=>
  string(4) "test"
  ["table[rows]"]=>
  string(1) "5"
  ["table[columns]"]=>
  string(1) "5"
  ...
}

here (unneeded info stripped).

On a "normal" setup, I however (correctly) get

array(6) {
  ...
  ["table"]=>
  array(4) {
    ["name"]=>
    string(4) "test"
    ["description"]=>
    string(5) "test"
    ["rows"]=>
    string(1) "5"
    ["columns"]=>
    string(1) "5"
  }
  ...
}
@adamziel
Copy link
Collaborator

adamziel commented Dec 17, 2022

Great spot @TobiasBg - this should absolutely work as you outlined.

Noting that the bug resides in PHPServer#dispatchToPHP and an ideal fix would include a regression unit test similar to the ones PHP.ts has: https://github.com/WordPress/wordpress-playground/blob/trunk/src/php-wasm/__tests__/index.ts

@artemiomorales you might be interested in this issue

adamziel added a commit that referenced this issue Jan 4, 2023
Processes $_POST and $_FILES data using PHP’s parse_str function to ensure it’s treated like on a regular webserver.

For example, sending POST data like `table[name]=123` should yield $_POST array like `[„table” => [„name” => „123”]]`. Before this commit, it incorrectly yielded one like `[„table[name]” => „123”]`.

Solves #93
@adamziel
Copy link
Collaborator

adamziel commented Jan 4, 2023

Solved in 3359e60, thank you for reporting @TobiasBg!

@adamziel adamziel closed this as completed Jan 4, 2023
adamziel added a commit that referenced this issue Jan 4, 2023
@adamziel
Copy link
Collaborator

adamziel commented Feb 3, 2023

#107 introduced a full PHP SAPI that handles parsing data, populating $_GET, $_POST, $_FILES, $_SERVER, $_COOKIES etc. and populating the php://input stream

Pookie717 added a commit to Pookie717/wordpress-playground that referenced this issue Oct 1, 2023
Processes $_POST and $_FILES data using PHP’s parse_str function to ensure it’s treated like on a regular webserver.

For example, sending POST data like `table[name]=123` should yield $_POST array like `[„table” => [„name” => „123”]]`. Before this commit, it incorrectly yielded one like `[„table[name]” => „123”]`.

Solves WordPress/wordpress-playground#93
Pookie717 added a commit to Pookie717/wordpress-playground that referenced this issue Oct 1, 2023
bgrgicak added a commit that referenced this issue May 7, 2025
## Motivation for the change, related issues

[Emscripten merged a fix for
`statfs`](emscripten-core/emscripten#23381) in
`4.0.1`, so this PR updates Emscripten to allow us to run `statfs` in
PHP functions like `disk_total_space`.

## Implementation details

This PR updates the version of Emscripten to `4.0.5`, rebuilds all
PHP-wasm libraries, and recompiles PHP-wasm.

While rebuilding PHP-wasm libraries there was a bug in the `libcurl`
build script because it expected `libopenssl` to be located in
`libopenssl/asyncify/dist`, but in reality `libopenssl` was located in
`libopenssl/asyncify/dist/1.1.0h` (similarly for JSPI).
We have two versions of `libopenssl` because it [was requires for PHP
7.0](#2038).
This PR drops `libopenssl 1.1.0h` support because [Playground doesn't
support PHP 7.0
anymore.](Automattic/wordpress-playground-private#74)

## Testing Instructions (or ideally a Blueprint)

- CI
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants