I have been using a wonderful web development tool, Tinkerwell, in my workflow to test and refine queries and code while I build out websites. For those not familiar with Tinkerwell, it is an application that allows you to run and test PHP code and immediately see the results. It is like Tinker for Laravel but works with other PHP projects like WordPress.
What do I like so much about Tinkerwell? Well, let’s look at how I might have normally tweaked code in the past. I would:
- Open my code editor
- Make changes to my code and save
- Switch to my browser
- Hit reload and view the results
- Rinse and repeat
This set of steps also assumes that I have code in place to view the results I am looking for. I could var_dump values or use XDebug but those add even more little steps to the process. Then there are situations where maybe I am trying to load information in using Ajax and, for some reason, am just getting a JavaScript error. That would send me scrambling to the Web Inspector’s Network tab.
Instead of repeating all of these steps Tinkerwell will allow me to just run commands directly. Tinkerwell has more features than I will go into now but the way I most often use it is by typing my PHP into the editor on the left-hand side of the window, clicking the run button, and seeing the results on the right-hand side of the window.
As you can imagine, trying out different properties in the $args array would be much easier in Tinkerwell than the process described earlier of editing a page on my site. This was working well for me. However I recently changed my local hosting tool from MAMP Pro to Local by Flywheel.
Local by Flywheel provides a local development environment for WordPress by using virtual machines. The problem with this approach, from the perspective of using with Tinkerwell, is that Tinkerwell uses the wp-config.php file to determine the database connection. Tinkerwell is running on the host machine, not the virtual machine provided by Local by Flywheel, so when it tries to connect to the DB_HOST “localhost,” it will fail. The database is running on the virtual machine, not on the host. Furthermore, Local by Flywheel uses Socket to connect to MySQL and not simply the server address that I was most familiar with.
Fortunately, it turns out that there is a way to set the wp-config.php to use a socket file to connect to the database. Local by Flywheel sets up the database host with this line:
define( 'DB_HOST', 'localhost' );It is possible to point localhost to a socket file in wp-config.php, like this:
define( 'DB_HOST', 'localhost:/Users/user/Library/Application Support/Local/run/hprYVZH4q/mysql/mysqld.sock' );The location of the socket file can be found in the website’s settings in Local by Flywheel under the Database tab:
Copy that path, prepend “localhost:/” to the front of it, and use it for the DB_HOST value in wp-config.php. When you now use Tinkerwell it should connect correctly. This DB_HOST value should work in both Tinkerwell and in Local by Flywheel.
If, for some reason, you needed to change the DB_HOST value for just when the code is being run through Tinkerwell, there is a way to do that. By checking PHP’s $_SERVER['SCRIPT_NAME'], we can look for the text “tinkerwell” and, if it is found, change the DB_HOST as desired. Here is an example of how we could do that:
if ( isset( $_SERVER['SCRIPT_NAME'] )
&& false !== stripos( $_SERVER['SCRIPT_NAME'], 'tinkerwell' ) ) {
define( 'DB_HOST', 'localhost:/Users/stirrell/Library/Application Support/Local/run/hprYVZH4q/mysql/mysqld.sock' );
} else {
define( 'DB_HOST', 'localhost' );We can verify the $_SERVER['SCRIPT_NAME'] contains “tinkerwell” when run in Tinkerwell by using Tinkerwell:
I am happy to have Tinkerwell up and running again. If you haven’t checked it out, I definitely recommend you take a look.