Bits of Simplicity

Dude, where's my php.ini?


Ever need to adjust your php.ini file but never know which file to edit?

If you need to adjust the ini file for php-cli simply run:

php --ini

Unfortunately if you want to find the ini file for mod-php or php-fpm you will have to add

<?php phpinfo(); ?>

to a file and do a quick search.

Usually I find that you can get the location of the ini files using the cli command and go from there to find the mod/fpm files.

Accessing the localhost of one Docker container from another


This requires a little bit of explanation before we can really dive into the meat and potatoes.
Lets say you have a WordPress project in docker. Your docker environment is built to reflect your production environment.
Your docker-compose file looks something like the following: A mysql container with data volume, a php-fpm container exposing on port 9000, and finally a nginx container serving the php's exposed fpm port over port 80. You have a link setup between php and nginx so they can talk to each other. On your host visiting http://localhost:80 brings up your project.

You are coding away and all is well; until it isn't. For one reason or another you need to have your backend code make a request to itself. Maybe you are implementing batch processing, or maybe using a badly written theme; what ever the case might be. Your code looks something like this: `$response = wp_remote_get('site_url( '/batchit/' );');` and it isn't working. Even more frustrating is that it is working perfectly on production. The reason might not be obvious at fist. Docker containers are like mini isolated computers. They are confined to their own filesystems, process lists, and network stacks with resource limits. When containers are linked it creates a virtual network in which the isolated containers can talk to each other. Remember that in our setup `site_url()` is `localhost`, but on production that is changed to our live url. Localhost inside of nginx is not the same as localhost inside of php-fpm. So when our code runs inside of php-fpm and accesses localhost, it finds there is nothing running on port 80.

Now there are a few clever DNS hacks that will allow you to access nginx's localhost, but those require you to change `site_url()` which in turn also means changing the url you access the site from. There is a better way! Docker will allow you to have two or more containers share the same network stack. They will share the same IP address and port numbers as the first container, and processes on the two containers will be able to connect to each other over the loopback interface. Exactly what we need. If you are not using docker-compose you can use the `--net` flag, and if you are using docker-compose you can use `network_mode`. In both causes the options are the same. Two options in particular:

network_mode: "service:[service name]"
network_mode: "container:[container name/id]"

In our case we just need to remove the link from php-fpm to nginx and add `network_mode: "service:nginx"`. We also want to make sure to add `depends_on` with nignx to our php service. This is to ensure that our nginx network is ready before you try and start our php service. Now both containers share the same network namespace! Note: You may also have to edit your nignx config to point to localhost:9000 instead of php:9000.

Here is an example docker-compose:

version: '3'
      image: mysql:5.6
        - mysql_data:/var/lib/mysql
        MYSQL_ROOT_PASSWORD: secret
        MYSQL_DATABASE: project
        MYSQL_USER: project
        MYSQL_PASSWORD: project
        - 3306

      build: ./build/docker/nginx/
          - 80:80
        - mysql
        - .:/var/www/html

      build: ./build/docker/php/
        - nginx
      network_mode: "service:nginx"
        - .:/var/www/html

      image: phpmyadmin/phpmyadmin
        - 8080:80
        - mysql
        PMA_HOST: mysql

Test driving Firefox Quantum: Developer Edition


I have decided to test out the new Firefox Developer Edition, and so far so good! It's pretty fast and light weight (compared to Chrome). The dev tools are pretty similar, but they take some getting used to. I did run into some trouble with Optimizely and do not track features, but I was able to disabled those (It is never a good idea to run adblock or do not track extensions when doing dev). There are still a few things I am not sure about, but going to give it a week or two before giving a final review. I also switched to using duck duck go for work as well. That has also been going really well, although it takes some getting used to.