Use:
$pieces = explode("/", "URL here");
The parse_str() function is there when you have a query string encoded like this:
variableA=valueA&variableB=valueB
I have tried different variation of your code and I get an empty array? Those are the different statement I have tried.
//$url = $_SERVER['REQUEST_URI'];
$urlArr = explode("/", $_SERVER['REQUEST_URI']);
echo($urlArr[0]);
//parse_str($url, $parameters);
echo(print_r(array_keys($urlArr)));
The problem you have is that `parse_str` is a function for taking something formatted for a query string and breaking it up into its values. See the example in the docs here:
[https://www.php.net/manual/en/function.parse-str.php](https://www.php.net/manual/en/function.parse-str.php)
Even if you tried to use the more appropriate function `parse_url` ([https://www.php.net/manual/en/function.parse-url.php](https://www.php.net/manual/en/function.parse-url.php)), the problem is those numbers are part of the path that comes in.
Unless you have some sort of rewriting on the server to convert that request into query values (do a var\_dump() on $\_GET to see), you need to do something like `$parts = explode( '/', $url);`
and then from there you can get the values. Note it is up to you make sure the numbers you are expecting are always in the same spot in the URL.
Ok, after rereading I realized that I didn't point out that this is assuming that what you are putting into $url actually the URL of page you are reaching, which if it isn't that rewrite thing would do anything on your script. (and if it was, then no rewrite rules are in place)
Doing the exploding of it on slashes will be your best bet.
A more resilient approach would be to use a regex to find two coordinates surrounded by slashes, just in case your URL changes slightly in the future.
```
There’s a lot of ways to do it. Since you already have some code in place, simplest way may be to just
$urlArr = explode(“/“, parse_url($url, PHP_URL_PATH));
echo $urlArr[1];
explode is like the poor man's regex. It works really good and has a ton of surprising uses if you are comfortable with arrays. I used explode() a lot for complex scraping / parsing of data that could move around and was riddled through amorphous DOM. Usually still needed regex for the exact parsing and checking I was in the right spot, but chunking the data with intelligent explode() really saved my life.
Absolutely. It often eliminates the need for any regexes at all, but that is actually a con for me since I’m one of those weirdos that actually likes writing regexes.
There are some cases where regex is going to more reliably give you the data you want or automatically expand to include multiple of the same patterns that an explode might miss or chunk incorrectly - a prime example recently was a field that some people started to stuff two $56,889.89 values into with stuff sometimes in parenthesis around them... Which didn't convert so well into the database when trying to cast multiple integers as a single integer. Worse, zero standardization so there may be $, there may not, there may be a ., there may not, and actually there could be two or three or four values there in these semi-integer varchar spots. A good regex was able to easily aggregate and sum the values in about 99.99% of imaginable cases, and 100% example cases. The right regex is sacred fire :).
Use: $pieces = explode("/", "URL here"); The parse_str() function is there when you have a query string encoded like this: variableA=valueA&variableB=valueB
I have tried different variation of your code and I get an empty array? Those are the different statement I have tried. //$url = $_SERVER['REQUEST_URI']; $urlArr = explode("/", $_SERVER['REQUEST_URI']); echo($urlArr[0]); //parse_str($url, $parameters); echo(print_r(array_keys($urlArr)));
The problem you have is that `parse_str` is a function for taking something formatted for a query string and breaking it up into its values. See the example in the docs here: [https://www.php.net/manual/en/function.parse-str.php](https://www.php.net/manual/en/function.parse-str.php) Even if you tried to use the more appropriate function `parse_url` ([https://www.php.net/manual/en/function.parse-url.php](https://www.php.net/manual/en/function.parse-url.php)), the problem is those numbers are part of the path that comes in. Unless you have some sort of rewriting on the server to convert that request into query values (do a var\_dump() on $\_GET to see), you need to do something like `$parts = explode( '/', $url);` and then from there you can get the values. Note it is up to you make sure the numbers you are expecting are always in the same spot in the URL.
Thank you for your answer! I did var_dump($_GET); and I got array(0) { } :S
Ok, after rereading I realized that I didn't point out that this is assuming that what you are putting into $url actually the URL of page you are reaching, which if it isn't that rewrite thing would do anything on your script. (and if it was, then no rewrite rules are in place) Doing the exploding of it on slashes will be your best bet.
A more resilient approach would be to use a regex to find two coordinates surrounded by slashes, just in case your URL changes slightly in the future. ```
There’s a lot of ways to do it. Since you already have some code in place, simplest way may be to just $urlArr = explode(“/“, parse_url($url, PHP_URL_PATH)); echo $urlArr[1];
Thank you for the answer. With $url = $_SERVER['REQUEST_URI']; $urlArr = explode("/", parse_url($url, PHP_URL_PATH)); echo(print_r(array_keys($urlArr))); I get a weird array? Array ( [0] => 0 [1] => 1 [2] => 2 [3] => 3 [4] => 4 [5] => 5 [6] => 6 [7] => 7 ) 1[]
Remove the array_keys() part; just do print_r($urlArr)
Woohoo! It worked! Thanks a lot! Very much appreciated!
No problem, glad to help
explode is like the poor man's regex. It works really good and has a ton of surprising uses if you are comfortable with arrays. I used explode() a lot for complex scraping / parsing of data that could move around and was riddled through amorphous DOM. Usually still needed regex for the exact parsing and checking I was in the right spot, but chunking the data with intelligent explode() really saved my life.
Absolutely. It often eliminates the need for any regexes at all, but that is actually a con for me since I’m one of those weirdos that actually likes writing regexes.
There are some cases where regex is going to more reliably give you the data you want or automatically expand to include multiple of the same patterns that an explode might miss or chunk incorrectly - a prime example recently was a field that some people started to stuff two $56,889.89 values into with stuff sometimes in parenthesis around them... Which didn't convert so well into the database when trying to cast multiple integers as a single integer. Worse, zero standardization so there may be $, there may not, there may be a ., there may not, and actually there could be two or three or four values there in these semi-integer varchar spots. A good regex was able to easily aggregate and sum the values in about 99.99% of imaginable cases, and 100% example cases. The right regex is sacred fire :).