PHPStorm, Docker and Xdebug

I use Docker for development; on the whole, I love it; however, getting a couple of things set up proved a little challenging, namely debugging from PHPStorm with Xdebug.

Eventually, I will update my Docker quick start project on GitHub, however for now, here are some basic instructions.

We need a couple of arguments in our .env file;

 WITH_XDEBUG=true
PHP_IDE_CONFIG=serverName=[name-of-server-in-IDE]
XDEBUG_CONFIG=remote_host=host.docker.internal

Next, we update the Dockerfile

ARG WITH_XDEBUG=false

RUN if [ $WITH_XDEBUG = "true" ] ; then \
pecl install xdebug; \
docker-php-ext-enable xdebug; \
echo "error_reporting = E_ALL" >> /usr/local/etc/php/conf.d/docker-php-ext-xdebug.ini; \
echo "display_startup_errors = On" >> /usr/local/etc/php/conf.d/docker-php-ext-xdebug.ini; \
echo "display_errors = On" >> /usr/local/etc/php/conf.d/docker-php-ext-xdebug.ini; \
echo "xdebug.remote_enable=1" >> /usr/local/etc/php/conf.d/docker-php-ext-xdebug.ini; \
fi ;

Finally, on the Docker side, we need to update our docker-compose file.

 services:
yourservice:
build:
args:
- WITH_XDEBUG=${WITH_XDEBUG}
env_file: .env

Set up your server, making sure to choose your debugger, Xdebug in this case. Settings -> Languages & Frameworks -> PHP -> Servers. The name of the server should match the name you set in the .env file.

Set the debug port and enable “can accept external connections”, PHPStorm, settings -> Languages & Frameworks -> PHP -> Debug, the port defaults to 9000.

Add a run/debug configuration (Run -> Edit configurations), select your server and optionally set an IDE key. To ensure everything is set correctly, you can use the validate option to check your configuration.

Start listening, add a breakpoint and away you go, you can now debug an app running in Docker.

API endpoints, filtering, sorting, searching, limiting and summarising

The Costs to Expect API is developing slowly; features get added as I need them, v1.15.0 is an exciting release, it will be the first time an endpoint in the API can be filtered, sorted, limited, searched and summarised.

I’ve written previously about summarising collections, with the release of search in v1.15.0 it makes send to describe all options supported by the items (/v1/resource-types/[resource-type]/resources/[resource]/items) collection on the Costs to Expect API.

By default, the items collection returns all child expenses in reverse chronological order, ‘all’ and ‘reverse chronological’ are sensible defaults; however, the API is limited if the collection always returns everything, you need to be able to filter, sort, limit, search and summarise.

The Costs to Expect API supports filtering, sorting, limiting and searching via parameters appended to the URI, collections are summarised by prepending /summary/ to the URI. Summary endpoints support the same filtering and searching options as their companion collections, limiting and sorting don’t make any sense in the context of a summary.

A URI can quickly become unreadable when multiple GET parameters are assigned, to attempt and improve readability I have grouped sorting and searching.

The OPTIONS requests for the Costs to Expect API detail all the supported GET parameters, in addition to giving an overview of each parameter, the OPTIONS requests list which fields and sortable and searchable. The sort and search parameters both allow multiple conditions.

Limiting a collection is handled as expected, there is an offset parameter to define the start record and a limit parameter to define the number of records requested.

Filtering a collection is handled via individual parameters, filtering is more common than searching and in my opinion needs to be the most verbose, when reviewing a URI the filtering parameters should be more visible.

This solution won’t work for everyone; however, if you need to support filtering, searching, sorting, limiting and summarising, I think it provides an excellent level or readability while still being practical.