I learned a few things today: first, that WordPress has a built-in colorpicker called Iris, and second, that you can use it on the front end of your website if you need custom colorpicker functionality.

Iris is evidently actually designed for admin options pages, and so it’s usually included via WordPress’s admin_enqueue_scripts() calls, as explained in its main documentation (actually a release note from WordPress 3.5 when it was added).

Including the Iris colorpicker on the front end is not as easy as simply changing admin_enqueue_scripts() to wp_enqueue_scripts(). Fortunately, as always, Stack Exchange has an amazing perfect-fitting answer. Please visit the linked thread for the explanation, and here’s the code snippet itself, with comments added:

add_action( 'wp_enqueue_scripts', 'wpa82718_scripts', 100 );
function wpa82718_scripts() {
    // Enqueuing CSS stylesheet for Iris (the easy part)
    wp_enqueue_style( 'wp-color-picker' );

    // Manually enqueing Iris itself by linking directly to it and naming its dependencies
    wp_enqueue_script(
        'iris',
        admin_url( 'js/iris.min.js' ),
        array( 'jquery-ui-draggable', 'jquery-ui-slider', 'jquery-touch-punch' ),
        false,
        1
    );

    // Now we can enqueue the color-picker script itself, naming iris.js as its dependency
    wp_enqueue_script(
        'wp-color-picker',
        admin_url( 'js/color-picker.min.js' ),
        array( 'iris' ),
        false,
        1
    );

    // Manually passing text strings to the JavaScript
    $colorpicker_l10n = array(
        'clear' => __( 'Clear' ),
        'defaultString' => __( 'Default' ),
        'pick' => __( 'Select Color' ),
        'current' => __( 'Current Color' ),
    );
    wp_localize_script( 'wp-color-picker', 'wpColorPickerL10n', $colorpicker_l10n ); 

}

Enjoy being able to use WordPress’s awesome built-in colorpicker on the front end!

Over on Thoughtful Code, I wrote about why even in 2018 I’d choose PHP to make a new software application in. The heart of my reasoning is the conclusion:

If you’ve got a team of Python programmers, write your application in Python. If you’ve got a cofounder who knows Java, write your SaaS in that. The personnel considerations of software should always outweigh the languages ones.

I am myself a PHP programmer. And the article touches on some of thing ugly sides of being a PHP programmer. But I live and love and use the language regularly, and no amount of complaining from anyone about it would make me change my mind but for anything where I alone was writing an application.

In addition to what I think about PHP in general, the article compares PHP to specific popular alternatives. One of the most interested to WordPress developers, I feel, is Node/JavaScript. About which, the article says:

Like PHP, JavaScript is an eclectic and sometimes ugly language with a lot of warts and “gotchas”. But JavaScript has gotten hugely fast in the last decade, so the case for it is real. Why pick PHP over JavaScript? You’ve got expertise or need to use libraries in PHP. Otherwise, I think JavaScript may be a better choice.

PS: If you want to read *everything* I write, here’s how I make pour over coffee.

There’s a good chance you know about Discord already. Especially if you’re one of the many n00bs I had to pwn in my long climb to Gold elo in League of Legends. (Hints: one-trick Xin Zhao, learn to farm the jungle efficiently, countergank top level 3.)

But it’s worth pointing out Discord as a good, always-free, group-voice-chat enabled alternative to the ultra-popular Slack service. If you can get past the heavily gamerish branding, you’ll find a service that works properly, and won’t punish you with $7 per user per month team fees if you want group voice calling or full chat archives.

The team over at Wordfence have put together a study of a particular piece of WordPress malware. What makes the infection they’re calling BabaYaga interesting? This malware fights other infections for control of the site. This has been a little trend in the wider security field; interesting to see it’s come to WordPress.

To monopolize control of the compromised system, these malwares actually patch holes made by other infections. This makes sense, in the wild west any co-infectant is likely to compromise your mission. And what is BabaYaga’s mission:

BabaYaga’s primary function is to generate spam content to be hosted on the victim’s site. These pages are loaded with keyword-heavy and meaningless word salad, designed to attract search engine traffic based on those keywords.

Sounds awesome. :p

The linked PDF white-paper goes into pretty thorough and impressive depth on how BabaYaga works. It’s nto for the faint-of-heart, but it’s pretty cool.

This website, which we stubbornly insist on reading as “Make Frontends Hit Again,” is about something we can really get behind: returning to making completely useless stuff on the web because it’s cool and fun.

As it says toward the bottom (just past the flashing GIF diamond wall):

We used to make websites because it was fun and at a point we lost the way.
We need to make dumb shit! Make useless stuff; make the web fun again!

Totally!

All that aside, have a browse. You’ll get hit with the 90’s harder than sipping Surge off an AOL CD.

By the way, if you do notice any display irregularities, the site mentions it’s best viewed with Netscape 3.0. So that’s likely the issue.

If you or your client is working with web images and wondering about web image DPI guidelines, this article’s for you. It explains why DPI doesn’t matter for web images, and why pixel count does.

When we say “DPI doesn’t matter on the web,” we don’t mean “it’s not that important”; rather, we mean “it’s completely meaningless”—like asking about your car’s favorite color. Image resolution online is a function of the pixel count of the image, the size of the space it’s being used in, and the display resolution of the device it’s being viewed on, and of those variables only pixel count is a property of the image itself.

Image resolution online is a function of the pixel count of the image, the size of the space it’s being used for, and the display resolution of the device it’s being viewed on. Of those variables, only pixel count is a property of the image itself.

So what does matter on the web is pixel count. “This image is 72 DPI” tells me nothing as someone who might want to use it on a website. “This image is 2000px by 1000px” tells me everything I need to know about whether it’s large enough to look good if we use it in whatever space we’re considering it for.

The article also answers common questions like:

• Does DPI still not matter for how web images display on “high-DPI”/”high-PPI”/”retina” devices? (Correct, it still doesn’t matter, only pixel count does.)
• Then how do we change an image’s resolution online? (“Retina” and other high-resolution devices cram more pixels into the same space if they’re allowed to, for example displaying all 1 million pixels of a 1000px-by-1000px image inside only a 500px-by-500px space. So the thing that allows for high-resolution images online is still the images’ pixel count, relative to the size of the space they’re being shown in.)
• How are DPI and PPI different? (They’re similar—dots per inch and pixels per inch—and are relevant to physically printing things and building device screens, respectively. Neither is relevant to web images.)
• So are rules of thumb like “images for the web should be 72 DPI while images for print should be at least 300 DPI” not valid, then? (Print DPI guidelines do matter, but any sort of “web image DPI guidelines” definitely aren’t valid because DPI is meaningless on the web.)

I Googled up this article just to make sure I wasn’t going crazy, after the second client in under a month asked me about DPI for web images. Really well-written and comprehensive. Kudos to the author!

If you want to know a lot more about how to work with images, and image sizes, in WordPress, we have a comprehensive article on the topic.

There are few brands more synonymous with quality in the web development niche than CSS-Tricks. (A List Apart comes to mind. Smashing Magazine, maybe. We work for you to think of us that way…)

So when I saw that CSS-Tricks had a free text-based walk-through of how to do Gutenberg development for free, I knew I had to share. That Lara Schenck is a coauthor just made it even more important that I do. (I totally mean to name-drop here, but I had the pleasure of meeting Lara at Loop Conf this year. We’re low-key nerd friends because we played a board game and saw Black Panther. :p)

Because of how different Gutenberg development is from what “WordPress developers” have been doing for years, the course is not brief. I’d schedule a half-day or so to read it all and put chunks of it into practice if you want to get the most out of it. But this is a clear, concise, and fantastic free offering from Lara and Andy Bell. It’s got the requisite stuff: what’s React anyway? What’s a block? What’s create-guten-block? All there.

If you’re starting to think you should get to the bottom of this Gutenberg blocks thing (you should!), this is the new de-facto place to start. Do not miss it!

For those who are really into WordPress community events, and world-wide, there’s do_action. For people in the US, there’s something called Code for America, and local brigades. My local brigade is called Code for Fort Collins, and I’m more-or-less in charge right now. The terms for this whole area aren’t super clear for me, some say “civic hacking”, some call it “charity hackathon”, I typically call it “trying to do good” which is maybe less useful. :p

Anyway, it’s been both challenging and fun for me to be involved with Code for Fort Collins. The organization, being 100% volunteer, is really interested and slightly complex to manage. And I wasn’t even intending, initially to manage it. That and more is all in the post. Here’s a quick summary from the post of what CFFC is and does:

As I write this, Code for Fort Collins has about 250 members on Meetup, and about 5-10 regularly-involved members. We’re loosely affiliated (as I think all brigades are) with the Code for America brigade program. We’ve completed a few projects, the most recent is a data-dashboard for Homeward 2020. We made it to aid the organization and the city come to terms with the data-problem that has stopped them from solving homelessness for too long.

If you’re working in this topic area, or would like to be, please don’t hesitate to reach out to me. I welcome it via email, as the most convenient channel. I’m “david” at either this or the Code for FoCo domain.

I’ve written here on WPShout about PHP namespaces before. But that article is old, and lacks among other things the fun expanding brain meme that our friend Steve Grunwell included in his post. Steve’s post has other reasons to recommend it, aside from the dope meme game.

For one, much more than when I first wrote our post here three years ago, it’s possible for a WordPress developer to use PHP namespaces for WordPress, and not just on one-off client projects where you control the hosting. That transition to more-modern PHPs is a big and important step for us, and great opportunity for developers to up their PHP game.

Also, Steve’s post has everything. He’s a really smart guy, and I loved and recognized this bit about why most WordPress PHP lacks use of real namespaces:

The second group of developers recognized that these plugins were rarely being handled as true objects, instead being used as pseudo-namespaces — constructs to encapsulate code from global namespace collisions without using true PHP namespaces. However, since WordPress still (at the time of this writing) supports PHP 5.2 (which lacks PHP namespace support), developers trying to reach the broadest possible audience still needed a way to reasonably encapsulate their code without relying on (or having to learn, depending on who you ask) PHP namespaces.

This Sunday is when we’re “officially” celebrating that WordPress is 15. (I’m going to a party in Denver, with Matt Mullenweg in attendance.) That’s because it was 15 years ago to the day that the first code was pushed to the fork of b2/cafelog that WordPress is today.

Now, WordPress history is a complex topic, but one thing that’s pretty easy to understand is that WordPress has visually come a long way. And it’s really cool (either as an insider who has used it for year, or an outsider who just discovered it yesterday) to see the visuals that underpin WordPress.

Over the years I’ve seen a number of projects that attempt to capture what WordPress has been like over the years. This WordPress Time Machine from 93digital is less-featured but more useful than some my brain vaguely recalls. What I love about it is that you get a quick side-by-side highlight of what WordPress looked like on both the back and the front at the time. For that simplicity, you do lose some of the other very important changes to WordPress: API, edit screen changes, etc.

Check it out! When did you first use WordPress?

WordSesh was the first (at least to my knowledge) WordPress-focused virtual conference. The last one ran in 2016, and since than I’ve from time-to-time heard pining for its return. Brian Richards from WPSessions is doing just that: bringing it back.

A few things have changed, most notably that the schedule is 12-hours, and admission is no longer free. But the price is modest ($25 US) and 12 hours feels much more realistic to me than 24. I also know that Brian is paying speakers and making sure that all the talks are transcribed. These are two very cool changes, and things that have pushed him to charge for admission.

I’m most excited by the speaker and talk lineup. Brian is someone whose taste about dev-conferences I have a high degree of trust in. I’m also really happy that Brian clearly made an effort to have a diverse line-up. He’s pulled in not just a diverse-looking group of speakers, but a diverse set of topics as well.

If you’re free on Wednesday, July 25th, I encourage you to watch live. If you can’t watch live, I think it’s a great conference to watch replays of after the fact. No matter what, you should definitely give the site a quick perusal.