Clawing back into the zone

For those of us who seem to work best “in the zone”, I don’t think we place enough emphasis on the effect our lifestyle choices can have on our work ethic.

I quit smoking two weeks ago, and I also stopped drinking caffeine before noon. Ever since, I’ve had trouble getting back into the “zone” where I used to thrive.

My work was starting to suffer.

Finally, late last week, I took a step I was dreading: I just stopped trying to code. It felt like a defeat, like I’d given too much credence to my previous lifestyle choices and allowed them to determine when I could or couldn’t effectively work.

I had to stop trying to find the excitement to work, and let the excitement find me.

The caffeine decision was less about health more about productivity. Turns out that drinking a jolt of caffeine in the morning causes an early afternoon crash … who knew? Now I just drink caffeine in the early afternoon so the crash comes after I’ve stopped working 😜

In some respects, I feel like I just needed to get out of my own head and let go of the “old way” of getting in the zone. I had to stop trying to find the excitement to work, and let the excitement find me.

The good news is that the excitement slowly started to creep back in over the weekend. Following my friend John Blackbourn’s lead, I started an Ideas repo on GitHub.

The concept is simple: document ideas you don’t have time to work on now, but want to write down out in the open so you can maybe work on them later. And if somebody else decides to come along and “take” an idea and run with it, that’s OK too!

Ultimately I wrote a few things down. Ideas for things like I’d like to learn, an old project I’d like to revive, a framework I’d like to explore. There’s only four ideas in there so far, but I feel like that’s a pretty good start.

I even took one of the ideas and pitched it to the Plugin-A-Palooza contest hosted the last few years by WordCamp Orange County. If that gets accepted, that might be just the fire I need to take it somewhere I always wanted to – delivery deadlines have a way of inspiring movement.

So here I am, two weeks out and still finding my way back “into the zone”. I don’t how well this is going to go, but I do feel like I’m on the right track.

It helps that I have a support network in family and friends, as well as in my WordPress family and with my awesome coworkers at Sandhills Development.

I’ll likely need some encouraging and understanding along the way, but I know that these recent choices are directly related to my health and wellness, so it’s worth the initial bumps along the way.


Featured photo by Doug Wilsen, and used with permission under CC.

Gutenberg first impressions … written in Gutenberg

Hmm. A "storytelling" angle. Is all new content written in Gutenberg considered a "story"?

* What about magic formatting, perhaps as a bulleted list?
Nope, apparently not.

It's kind of interesting how every time I hit enter, I effectively create a new block, whereas I guess experience suggests it should just be another paragraph in the same block. Maybe shift+enter will prevent that?

Nope. Hmm, OK.

I do kind of like how backspacing out of a thought effectively deletes the block and moves you back to the previous one. That seems intuitive. Having to double click on icons for previous blocks because they aren't currently the ones with focus isn't.

OK, so I've clicked out of the blocks and now there's a bunch of stuff in the sidebar. I get it, it's very much an indicator of "distraction free writing" but the transition is kind of jarring. Flash on, flash off.

Wonder what the difference is between naturally typing a new "paragraph", thereby getting a new block, and clicking this + symbol does?

Oh, apparently text is the default. Maybe the gear icon for each block that currently does nothing gives options to change the block type? Bug probably.
Oh, so it seems like you actually can hit enter inside a block and remain in there, but it only works sometimes and you can't space the text more than a single break apart without triggering a new block.

Somebody mentioned in another post that the drop cap doesn't seem to work.
I got it to work once (somehow) but now can't. Definitely a little buggy.

Anyhoo, part II will cover non-text blocks and part III sidebar settings that flash on flash off.

OK, actually, I'm just going to inject one quick thing here … if what are effectively post settings only show when you select out of a block, maybe the button that toggles the sidebar (that holds block settings when a block is focused, and post settings the rest of the time) should say Block Settings when a block is focused.

Breaking backward compatibility should not be about convenience

A big part of WordPress’ philosophies is embracing backward compatibility. And that commitment, for the most part, largely spills over to plugins and themes extending it. At least it should.

So when I read on the WooCommerce development blog about upcoming changes in 2.7+, I was at first encouraged that they’re embracing an abstraction layer for meta handling. Nice! Then I got to the part where they said they essentially plan to break backward compatibility in a future version for meta handling.

If you do anything with product, customer, orders, and coupons, you will be affected in some way. Even if you do a simple update meta call. This won’t break immediately, but your code will not be future proof. As soon as the schema changes in another update, your code will fail.

Yikes.

There are several good, even necessary reasons to break backward compatibility.  For instance, sometimes a product will force a backward incompatible change because something is being deliberately misused outside of the original intent. That’s not what’s going on here.

Frankly, the WooCommerce team’s decision smacks of convenience more than anything. Supporting backward compatibility is sometimes hard, but rarely impossible. And by choosing to break it, they may be unnecessarily playing with the fire that is user trust.

Won’t somebody please think of the users?

User trust isn’t something you earn and then just get to keep forever. It’s a maintenance relationship. So for WooCommerce – an extremely popular product with immense reach in the WordPress ecosystem – I would consider a backward compatibility break of this magnitude to be borderline irresponsible.

There are likely hundreds, probably even thousands of commercial and custom extensions for WooCommerce. Most, if not all of them, up until 2.7, will have probably relied on its usage of post meta for everything from products and coupons, to customer and order data.

Coming out and saying that at some point you will stop using post meta is completely fine. Coming out and saying that some point you will stop supporting post meta is not.

Use the hooks, Luke

There are more than enough hooks in the Post Meta API to facilitate backward-compatibility for previously-post-meta-now-something else data.

I know for a fact that the Easy Digital Downloads team are using those hooks since moving to a custom schema from post meta. Disclosure: I work for AffiliateWP, a sister product of Easy Digital Downloads.

There’s nothing saying that the WooCommerce team has to encourage use of post meta. Feel free to toss deprecated notices or use _doing_it_wrong()s, but don’t break what used to work before.

It’s easy enough for developers to shift to using the abstraction layers – I for one am looking forward to it – but WooCommerce wasn’t built for me. It was built for the people I (and an army of others) build things for, and it was built using post meta.

By all means, improve your code, but keep in mind: sometimes you gotta dance with the one that brung yuh.

“Chain Links” image by Danny Hope, used under Creative Commons.

I was on WP Round Table today.

I’ve been a longtime viewer of WP Round Table, so it was pretty neat to be asked to join Kyle Maurer today.

Check it out:

WordCamp Denver believes in possibilities.

5 lesser-known improvements in WordPress 4.6

WordPress 4.6, “Pepper” was released earlier this week to what has been by all accounts a pretty great reception. Notable features and improvements in 4.6 include Shiny Updates v2™, native fonts in the admin, editor improvements, and a whole host of developer goodies.

And as with any major release of WordPress, there are always features and improvements made that get overlooked. Here’s five little-known features, fixes, and improvements you may not know about in WordPress 4.6.

1. A modernized Import screen

Before and after (WordPress 4.6) screenshots of the Import screen

What began as an effort to remove title attributes for accessibility reasons eventually turned into a significant usability refresh of the Import screen.

Easily the biggest change was making this screen feel more like a place to manage and launch importers as separate actions. Each importer now has row actions to install and run, as well as a “Details” link that opens the plugin information popup just like with regular plugins.

As a bonus, importers can also now be installed in-line similarly to how shiny updates allows for in-line updates of plugins and themes. Click “Install” and it happens in place. Smart!

Finally, 4.6 also introduces help text to this screen. Overall, big – yet incremental – usability changes to a not oft-used screen. And of course, it’s now more accessible!

2. Network Admin and the Sites menu got a better icon

Before and after (WordPress 4.6) screenshots of the Sites menu icon in the Network Admin

In a relatively minor change, a new dashicon was introduced for the Network Admin toolbar item, as well as the Network Admin > Sites menu. Big improvement over the old ambiguous key icon.

3. Embed previews when inserting from a URL were fixed

Screenshot of the Insert From URL workflow in the media modal in WordPress 4.6

With the advent of embeddable WordPress content starting in 4.4, came the ability to embed that content via the Insert from URL workflow in the media modal. At some point, the preview mechanism was broken; this has been fixed in 4.6. Love this feature.

4. Upload and install plugins from the same screen

Add plugins drop-down panel in Add Plugins in WordPress 4.6

A core tenet of the Shiny Updates v2™ feature in WordPress 4.6 was to increase the efficiency of installing and updating plugins and themes.

One lesser-known way this was achieved was by integrating the plugin upload form into the main Add Plugins screen. The old way redirected users to a completely separate page.

If you’re wondering why that sounds familiar, it already worked this way in Add Themes. Regardless, nice to see incremental usability improvements like this.

5. Actions and filters can now be properly deprecated

One code change that really didn’t get a lot of play in feature announcements was that deprecating hooks is now possible in core. Add-on developers may now collectively rejoice!

No core hooks were deprecated in 4.6, but that shouldn’t stop plugin and theme developers from using it right away,

Two new global functions were added, do_action_deprecated() and apply_filters_deprecated(), along with the private helper they both use: _deprecated_hook(). All in all, deprecating hooks is pretty straightforward:

Old action call:

/**
 * Fires when writing Codex articles.
 *
 * @since 0.71
 *
 * @param bool $codex  Whether to write Codex articles. Default false.
 * @param bool $devhub Whether to write DevHub articles. Default true.
do_action( 'write_codex_articles', $codex, $devhub );

Deprecated action call:

/**
 * Fires when writing Codex articles.
 *
 * @since 0.71
 * @deprecated 3.7.0
 * @see 'write_devhub_articles'
 */
do_action_deprecated( 'write_codex_articles', array( $codex, $devhub ), '3.7.0', 'write_devhub_articles', 'woohoo!' );

Boom.


Hope you’ve enjoyed this post. Are there any other lesser-known improvements in WordPress 4.6 that tickled your fancy? Share them in the comments!