Simple testing of different Git commits

I use branches a lot with Git, as I find them easy to understand and a great tool for organizing. If you want to easily switch back and forth between versions of your code base for testing, you can just create a branch with a particular commit:

git checkout -b before-refactor a8b912c0ebdce6173f6e7af5d93fafc0f50175c0

This also lets you easily compare versions by diffing the branches:

git diff master before-refactor

How to tail a log with live server clock

Super helpful timestamp clock while tailing error logs.

Andy Skelton on WordPress

At work I have to watch my server’s error log. Good old tail -F /path/to/log runs over SSH all day, every day. Each entry is timestamped. Sometimes those timestamps give me trouble. The age of a timestamp is found by subtracting it from the current time. If I need to know whether the last error occurred 1 minute ago or 61 minutes ago I have to contend with:

  • timestamps in UTC vs. local clock in CST
  • timestamps in 24h vs. local clock in 12h
  • terminal window on second screen vs. clock on main screen
  • daylight savings vs. non-crazy time
  • being at home vs. traveling in other time zones

Finding the age of a timestamp should be simpler than that! So I put a real-time UTC clock in the most convenient place I could find: on the blank line where the next log entry will be written. It refreshes itself every…

View original post 395 more words

Debugging theme mods

When developing themes, it can be useful to see what theme mods (setting values from get_theme_mod()) are set for your themes at the database level. However, this information is serialized, making it difficult to access, read, and modify while testing.

I’ve been relying on two tools for this sort of work lately: Sequel Pro and the Online PHP Unserializer.

Sequel Pro is a Mac-only, open-source tool for working with MySQL databases; it’s much faster, robust, and intuitive than PHPMyAdmin, and easier to work with than MySQL Workbench. The Online PHP Unserializer does its one thing, and does it well.

Copying serialized data from the database back and forth from the Unserializer makes it easy for me to troubleshoot mod settings, revert to previous values, or zero out certain values without having to delete the whole row from the database. This can be invaluable when testing code for the Customizer, or anything involving multiple themes at the same time.

If you have other troubleshooting tips, or any other tools to suggest than those above, let me know!

Evolving the Customizer

The Customizer is dead. Long live the Customizer.


The Customizer is great. I’ve been working in and around it to offer site customization features to our users since it launched with 3.41, coinciding with when I joined Automattic on Team Custom. We’ve especially used it to build great tools as part of the Custom Design upgrade, but as we’ve pushed the boundaries of what awesomeness we can unlock for our users, certain aspects of the Customizer have started to create roadblocks for us. Some of these are addressable, and some probably aren’t.


The Customizer doesn’t work on a phone/small screen. Anyone who thinks this isn’t a dealbreaker is just wrong. The UI was designed for the desktop web. This could possibly be addressed in core, but it will require a pretty fundamental rethinking of the interface.


The Customizer can get really slow. This is partly because of its two-requests-to-load model: one for the

View original post 834 more words

REST Development Console — now open source!

This is a great tool to get started playing with WordPress APIs.

Developer Resources

For developers working with the REST API, the browser-based API console is an essential debugging tool. It allows you to test your API queries and interactively explore the results (or errors) that the API returns.

REST API console - exploring results

It also puts the documentation at your fingertips and allows you to build a custom query right from any method’s description.

REST API console - building a query

Like the REST API itself, this tool works for any blog on and for any self-hosted WordPress install using Jetpack.

With the addition of implicit OAuth, we’ve released an open-source version of the API console that you can run yourself.

First, you’ll want to create a application (or modify an existing one) and make sure to set the Javascript Origins option. This should be the fully-qualified URL (including http:// or https:// ) of the site you’ll be running the API console on. To run it locally, just use “http://localhost”.

REST API console - JS origins setting

Then, just head…

View original post 147 more words