;tldr: The php ini directive request_order controls the order of options passed to the php superglobal $_REQUEST. The default value for request_order varies based on distribution.
Recently we dockerised the development environment of our SaaS application. While I was the only developer this hadn’t been necessary. As the team grew, unpredictable bugs began to creep into development. This made a consistent development environment more important.
Initially we used Homestead from Laravel. This was very fast to get going, but didn’t easily allow different configurations based on different branches. Like many companies, We are currently working on moving to php 8. In Homestead, changing the php versions between branches required different sites to configure a different php version for each site. On the other hand, using docker, we could commit our docker compose file and boot different environments depending on the branch.
In one of our development branches we have started replacing our older CI controllers with psr 15 compliant handlers. Compatibility with our older CI code base is temporarily provided by a wrapper controller. The wrapper controller is accessed on an existing CI route, converts the request into a psr 7 Server Request and calls the psr 15 handler.
After changing to docker many of our search and filtering endpoints on this branch started to fail. These endpoints used request parameters to build a filtered where clause to find data. This did not occur in the staging environment.
When I looked at the request data that was being passed to the handler I noticed that cookie information was also being passed. Since we were using cookies to store some state information for previously selected filtering this was overwriting the filtering passed in the query string. ie. request_order was sent to GPC rather than GP.
The solution, obviously, was to set the request_order to GP. At the same time I also changed the code in the wrapper to build the ServerRequest explicitly from $_GET and $_POST rather than using the $_REQUEST superglobal. I did this to ensure that moving environments or changing the docker container images in the future wouldn’t re-introduce the same error.