Here’s a quick and simple one that many of you might not know. This helps dramatically if you want to better match your UI with the current color scheme being used in the WordPress admin dashboard.

function build_admin_colors() {
    global $_wp_admin_css_colors;

    $current_color_scheme = get_user_meta( get_current_user_id(), 'admin_color', true );

    $colors = array_merge(
        $_wp_admin_css_colors[ $current_color_scheme ]->colors,
        $_wp_admin_css_colors[ $current_color_scheme ]->icon_colors
    );

    return $colors;
}

When running this snippet, you’ll get an array containing the hex codes for the current colors and icon colors that are currently in use. Just call that function when you need it.

I’ve decided to begin offering quick code snippets every day. These can range, but will likely be mostly WordPress and PHP.  This first code snippet will allow you to see all of the actions fired within a particular request in WordPress.

add_action( 'shutdown', function(){
    foreach( $GLOBALS['wp_actions'] as $action => $count )
        printf( '%s (%d) <br/>' . PHP_EOL, $action, $count );
});

Just toss that in any PHP file that you know will be firing on the desired page, and you’re good to go. Have a better solution? Let me know in the comments below.

I’m often asked by people starting out in development, how they can become better developers. Their proposed solution is typically formal education, while my response is almost always to contribute to open source software.  While my opinions regarding formal education in the development space are entirely the topic of another post entirely, there’s a major advantage to open source contributions that can be directly witnessed by anyone. That advantage is criticism.

While chatting with my friend George Stephanis a few days ago, I noticed something: George loves to nitpick people’s code. We’re not just talking about things like major bugs, but rather every slight detail of code quality, organization, and readability. He’s not ashamed of telling someone to fix something. Because of this, George and many others, have dramatically contributed to making me a better developer over the years.

In the last few days, while considering writing this post, I began thinking about those who have criticized my work. At times, I may have even been a bit discouraged by incoming criticism about my code quality, but looking down the road, I see that it has given me habits that I could only gain from that criticism. Without people reviewing my code in pull requests, or submitting issues on GitHub, there are so many things I may not have learned. Essentially, by putting my code out there for the world to see, I have expedited the growth of skills that only practical experience can provide.

When receiving criticism on my code, I’ve learned to always consider each suggestion as an attempt to increase my potential. People don’t spend hours digging through your code with malcontent, they’re doing it with love. Each issue report is done to benefit you, not to harm you; especially if a solution is provided.

I’ve noticed that over the years, I have begun doing the same thing that George and many others have done to me: take the time to go through someone’s project (that they are usually rather fond of), and rip it apart. I will intentionally go through your hours of hard work and pick out everything that I feel is wrong with it. Why? Because I want to make you a better developer just like many others have done for me.

The point of this post is simple: put your code out there for the world to criticize. Without it, you’ll just keep making the same mistakes over and over again, usually because you don’t know any better. Don’t be afraid of issue reports; embrace them. Your future self will thank you.