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.

We’ve made a Facebook group. We’re not completely sure how it’ll work, and what’s allowed, but we’re really interested in seeing what more we can do with more frequent communication in a space that a whole bunch of people are already hanging out. So check it out and play along with us.

We’re trying our best here are WPShout to make sure that you’re learning everything we can usefully teach you about WordPress. We’re continually trying new things, and seeing if it helps. We’ve been selling Up and Running for years, and we know it’s really helping people. We’ve been selling WordPress Security with Confidence, and that’s been good (though less clearly what the market needs or wants). People love that we’re maintaining and improving WPHierarchy.com, and I’m hopeful that WPSecurityCompared.com can become similarly useful and loved. We’re looking at putting together a “PHP for WordPress Course” and a paid, supportive learning community–far more ambitious than a Facebook group :).

Anyway, that’s all just to say that we’re trying things. We hope we can make a group that’s free, useful to us, useful to you, and that everyone is happy exists. We know that that requires some less-fun things like moderation of members and comments, steering the community, etc. We’re hoping that the less-fun pales in comparison to the value it provides on both side. And so we’ve got a Facebook Group.

Over on Thoughtful Code, I spilled a bunch of words about semantic version numbers. WordPress 4.9.6 is imminent, and it got me to thinking about why semantic version numbers are so important to me. And because WordPress matters a lot to me, I think a lot about the (weird) way WordPress does version numbers.

On the topic of 4.9.6 in particular, here’s what I say:

So why, in May of 2018, is WordPress releasing 4.9.6 as a “major” version? Because, for political reasons, BDFL Matt Mullenweg is holding WordPress 5.0 to be the release where the new visual editor “Gutenberg” is added. This means that if the WordPress team want to release something before 5.0, they must release a 4.x. And because in WordPress we’ve never seen version numbers like 4.10.0, we’re stuck with a major set of new features coming out in 4.9.6.

I think it’s great that WordPress is getting GDPR-compliance-based changes. I think it’s great that Gutenberg isn’t stopping all forward-progress on the rest of WordPress. But I really don’t like that 4.9.6 isn’t as safe and simple a release as 4.9.1 or 4.9.5. No one will know that from version number alone either.

I’m really excited about the future of WordPress, with Gutenberg on the horizon. But WordPress’s steadfast refusal to acknowledge that semantic versioning is a useful and worth practice continues to grind my gears. Now that it’s undeniable the Gutenberg hasn’t made the (artificial, silly) April deadline, we’re officially in the time of silly and counter-productive holding pattern because of a feature that’s delaying a release. It’s not the end of the world, but it sure is silly.

I get like four emails a day about the GDPR, and because we’re not Facebook, Google, or an ad network, it doesn’t seem world-shaking to what we do. But I wanted to know a bit more, and so I Googled for “ELI5 GDPR,” “ELI5” being short for “Explain Like I’m Five,” Reddit’s awesome format for simplifying complex topics.

This Medium article is a decent high-level introduction to the topic. I came away feeling that the GDPR is basically a Good Thing that will stop big companies from doing sketchy stuff with consumer data—at least to EU citizens :(.

That left me still wanting an ELI5 for is “How do I know if this matters to my particular business, and if so what parts it matters to?” So I searched a bit more and found the linked article. It contains a good list of user rights that the GDPR encodes, and some more practical stuff about opt-ins.

From my best reading, the only way I think GDPR will really affect our particular business is making sure we don’t auto-subscribe anybody to our mailing list, which we already don’t. I’m guessing that most non-enormous websites (as opposed to web applications like Airbnb or Twitter) will be in a similar boat.

If you do business in the EU, worth at least a skim to know what kinds of things are and aren’t under discussion.