WordPress 5.0 is releasing tomorrow. December 6, 2018. Yay!?

I don’t think–as I sit in the airport restaurant–I can or should try to write out all of the thoughts about Gutenberg and the chaos that has been the WordPress 5.0 release process and decision. I feel like this tweet from our friend Jeff over at the Tavern actually summarizes it pretty well:

There is Gutenberg the product and Gutenberg the process.

Gutenberg the product is rough around the edges but shows promise of being the future of the platform.

Gutenberg the process is simply Holy Shit.

I hope the lessons learned translate into a smoother phase 2 and 3.

— Jeff (@jeffr0) December 4, 2018

What Jeff gets very right here is that a lot of people have worked very hard to make something that they call “Gutenberg” and it’s very good. It’s not yet mind-blowingly good, nor “whole new game” good. But it’s very good, and it’s probably approximately stable enough to push onto “30% of the internet.”

But the process by which that decision was made, and the seeming capriciousness with which the process has been operated is very disappointing. And while I believe that saying this risks earning me a “no-longer-welcome” status in certain conversations (specifically with Matt himself), I think it’s undeniable that Matt Mullenweg’s general style as the leader of this release was the cause of a lot of the community agitation and pain.

Throughout, the process has seemed very arbitrary. No timeline was ever published, but neither were timeline-less acceptance criteria. This means that the whole community spent 2018 holding its breath, fearful of when Gutenberg would arrive and in what state it would be.

The most recent example is perhaps the clearest: it was just a few short months ago that Gary Pendergast posted a proposal of (roughly) three dates that WordPress 5.0 would drop: November 19, November 27 (19th schedule, slipped 8 days), or January 22.

Best I can tell, the December 6 date is not listed in the post about that. And because Gary is a rather prominent and trusted lieutenant, most casual observers (myself included) took his post as the clearest truth about the plan.

Then two days ago, first posted on Twitter and then on the official blog, we’re just told that Gutenberg is coming out Thursday. This is after Matt Mullenweg performed and somewhat-prominently promoted a “public listening tour,” which at least one participant now feels was a waste of time:

After a weekend where @photomatt had specific office hours. He reached out to me and we spoke on the phone because I thought I was making an impact on the release date and communication around it.

All that call did was delay my family from decorating our Christmas tree.

— Joe Casabona @ #WCUS (@jcasabona) December 4, 2018

One of the more interesting arguements in support of this new plan came from Helen Hou-Sandí, a person for whom I have tremendous respect:

I think mostly I’m surprised that anybody is surprised that releasing a huge update before the big conference for the year would be a significant motivator? I guess people wanted it said explicitly but then I wonder if all the fighting would just have been about that instead…

— Helen ?-Sandí (@helenhousandi) December 4, 2018

The fact that it’s understandable that Matt wants to release now so he can go on stage at WordCamp US and say “Yay! Gutenberg is here!” is completely “understandable.” That is: it makes a kind of sense looking at it from a distance. But after-the-fact understandable-ness doesn’t really permit people to have, develop, or execute a plan around that date. And “understandable” is a very long journey from saying that it’s either the right process or the best that Matt is capable of.

I know Matt Mullenweg has WordPress in his heart. I know he does care about the community. But this process hasn’t shown that, so it’s just been a long slow disappointment for me.

Times story on Facebook’s problems

This New York Times story on how Facebook has dealt with its crises over the last two-ish years has been doing the rounds this week, and for good reason: it’s really good. The primary insight is referenced in the headline: “Delay, Deny and Deflect”. This broadly describes how Facebook has dealt with all incidents, and is a cyclical process; when “deflect” has finished, the “delay” kicks in again.

The sheer scope of how many crises and how many issues Facebook has sought to sweep under the rug – including recently through inexcusably hiring a “opposition-research firm to discredit activist protesters… [who also lobbied] a Jewish civil rights group to cast some criticism of the company as anti-Semitic” – is boggling, as is the notion Facebook doesn’t understand and/or can’t control the machine it has built.

This post first appeared in MasterWP, a weekly newsletter for WordPress professionals.

I’m not particularly into either npm (the JavaScript dependency library and installer) or cryptocoins (approximately “Bitcoins”), but I was talking some fellow WordPress developers and this pretty interesting and complex security story came up. The summary is this:

On September 9, right9control added flatmap-stream as a dependency to event-stream, and then on September 16, removed the dependency by implementing the code themselves. However, this latter change was not automatically pushed out to the library’s users. On October 5, flatmap-stream was altered by a user called “hugeglass” to include obfuscated code that attempted to drain Bitcoins from wallets using the software.

Thus, anyone using event-stream and pulling in the cursed flatmap-stream, rather than the rewritten code, since October 5 would be potentially hit by the malicious script. The offending code has been removed from event-stream. If it’s any relief, the hidden malware is highly targeted, and not designed to attack every programmer or application using event-stream.

This is what’s commonly called a “supply chain attack“. It’s one of the less-common attacks a WordPress site needs to worry about, but it’s still real, and very interesting to see one in the wild. The heart problem in them is that not everyone can realistically vet all their dependencies, and the chain-of-trust in many software ecosystems is long and thus pretty weak. So it’s nearly impossible that the current state of the JavaScript ecosystem will prevent events like this. As awareness goes, I think thoughtful solutions will start to get executed. But right now it’s still quite a wild-west.

Want to know more about WordPress security? Check out our paid course on the topic, or this great free article.

This code demo saved my bacon on a client project that needed a very specifically styled file upload input box.

Why would that be difficult? It turns out there’s no default way to override the browser’s <input type="file"> styling! Isn’t that weird?

The key information is in the “Hiding the <input>” and “Styling the <label>” sections. Requires quite a bit of confidence with CSS, but very worth it for beautifully styled and customized file upload inputs.

Writing as a proxy for “when do we work best”?

Grab a cup of coffee and indulge in this preposterously detailed post on the “morning writing effect”, which tries to understand whether the “I do my best work in the morning” effect often described by writers is actually real, and if so how strong it is.

The level of detail and insight is very interesting on its own, but it’s taking writing as a proxy for “when’s the best time to do creative work” that deserves further investigation. I tend to do admin-style work in the morning and creative work in the afternoons; after reading this I will have a look at switching it around.

This post first appeared in MasterWP, a weekly newsletter for WordPress professionals.

Our friend Jason Bahl has put together one of the most quietly exhaustive tutorials I’ve seen on what it’s like to actually make a “Gutenblock” with all the code bits and where all of them go. One of my biggest uncertainties about Gutenberg is how many WordPress developers will need to be creating Gutenberg block and how easy they will find it. All of that points to the fact that regardless of how it turns out we’ll need a lot of different good tutorials about making Gutenblocks and the subtleties of that process.

That’s where tutorials like Jason’s come in. And because he highlights two rather-different methods, you get a well-rounded sense of how you’d actually make a Gutenblock. The extent to which people (myself included) are really excited that the method of Gutenblocks using Advanced Custom Fields is looking so PHP-focused. I think the jury’s still out on if the core-Gutenberg block registration being JavaScript focused is good or bad.

With tutorials like Jason’s, you can take a look and form your own opinion 🤓

Black Friday is a great opportunity for WordPress products, but offering a straight discount isn’t necessarily the best way to go: you need to balance existing customers, price-sensitive potential customers, and deal-searchers, and a straight discount leaves at least one of those groups dissatisfied.

The solution, then, is to look into bundling your product. This lets you offer a steep headline discount, whilst maintaining a high-ish purchase price, and giving you scope to reward existing customers.

Pricing is a really interesting and high-impact area, and this post gets into more detail on how to get Black Friday right for WordPress products.

This post first appeared in MasterWP, a weekly newsletter for WordPress professionals.

A sort-of goal of starting my Thoughtful Code hobby site was to use it it say a little more on theory than “here’s how to set up Java projects” or “here are five cool things you didn’t know about PHP.” I love articles like that (and should write more of them), but they don’t speak to the name or concept of what makes code worth writing and what makes it valuable to the word. And that’s something I think about a lot, both in our work here with WordPress, and with my role in Code for Fort Collins.

So today I’m publishing the first in a series of pieces that explore in a bit more detail what I think makes code “good” and also why I find so many of those conversations become useless mires of subjectivity. In short, I think defining the values that you think makes code good must come conceptually prior to asserting that code it good. That sentence, hopefully, did more than prove that I’ve taken a few (too many?) philosophy courses.

Anyway, I think the piece itself works well, but I’m less sold on these ramblings. So I’ll just urge you again to read it. And ask that if you have any thoughts at all I’d love to hear them. This idea is young enough that I’m not over-attached to it, and should be able to listen well. 🤓

Last week I linked my piece on marketing channels, and the importance of testing new channels to see what works. This is a great write-up of a marketing channel experiment – YouTube sponsorships – and how it really didn’t work.

The side-effect is it’s also a great example of how even if you try something that doesn’t work (ie the YouTube sponsorships), if you’re creative you can still get some results out of it (ie this blog post!). The most interesting stat was this one: “On a CPM basis this [YouTube] was actually ten times more expensive than advertising on prime-time TV.”

This post first appeared in MasterWP, a weekly newsletter for WordPress professionals.

This article from Pascal Birchler about text domain in plugins got into some territory I’d not considered. I shouldn’t be surprised, Pascal is very smart, a regular contributor to WordPress itself.

Discussing it in light of a new WP-CLI command that he’s working on to make plugin translation easier, Pascal highlights the idea that a plugin should have a single text domain slug, like my-plugin, and that you should use that everywhere in the code. That’s relatively common knowledge among people who both consider themselves developers and know that i18n is short for “internationalization.”

What’s I’d not considered is what you should do when your WordPress plugin either extends an existing plugin, or pulls in some external code automagically for you. That’s where I found Pascal most interesting:

A similar situation [that you want to always use your plugin’s text domain] arises when adding customized WooCommerce shop templates to your WordPress theme. Usually you don’t need to add these to your theme unless you really need to change the markup.

Since these templates are coming from the WooCommerce plugin, all localizable strings use the woocommerce text domain. And when you don’t change any of these strings you might consider just keeping the text domain so WordPress will still translate these.

However, not changing the WooCommerce text domain is a bad idea. The reasons are simple:

1. Strings with a different text domain than your theme’s might not be extracted in the future.
2. It’s unreliable.
   When WooCommerce changes its templates in a new version, your strings might suddenly not be localized anymore.
3. You take control away from users.
   Users and translators have no way to translate your customized shop templates.
4. Context might change.
   When you heavily customize the WooCommerce templates, some of the strings in them might not be 100% accurate anymore. At this point you have to rephrase and use your own text domain anyway.

For the same reasons you shouldn’t use WordPress core strings, without your project’s text domain, in your plugin or theme either.

My take on this broader topic of internationalization in WordPress is called “Making Plugins and Themes Translation Ready,” by the way. 🤓

A member from the WPShout Facebook Group blew my mind last week with this set of instructions for either resetting WordPress user passwords or adding new users using only an FTP connection. This was in response to our Quick Guide that describes how to do the same thing inside phpMyAdmin, which requires cPanel (or similar) access. For many situations, I believe this FTP route is quite a bit simpler and requires requesting less complete access from your clients.

These FTP password reset tools seem obvious in retrospect—they’re based on PHP functions I’ve known WordPress has—but they had simply never occurred to me. Enjoy!

Alex on his marketing philosophy.

My day job is doing marketing for WordPress businesses, and I wrote this to explain how I approach marketing strategy, and how this offers an extremely good way of thinking about and running your marketing.

The thesis is as follows: marketing channels are categories of marketing activities, and these range from content marketing to TV ads. You want to identify which channels work for you (even just one is fine!) and then extract as much value as possible from them before adding any more channels.

You try and have as few channels as possible, and this forces you to focus on what works, and lets you easily filter new opportunities. This is so useful because it’s so simple, but it works at any scale – all the way from the newest WordPress plugins to the biggest in the industry. The post gets into more detail: if you run a WordPress business, check it out!

This post first appeared in MasterWP, a weekly newsletter for WordPress professionals.