Random Thoughts on Gutenberg

Gutenberg is being developed as the next generation WordPress editor. I made my first contribution earlier today. Nothing big, but something that will hopefully help people test it.  The contribution process was , but for end users, that’s not the important thing. What is important is the actual editor. I’ve seen talk that Gutenberg is in “Open Beta” now, but I think calling this beta software is still premature. I think there is plenty that will change between now and any possible inclusion in WordPress core for Gutenberg. Here are my random thoughts and my first reactions to using Gutenberg.
  • It’s pretty.  And Fast. I never thought of the post editor as being slow, but there is something about Gutenberg that makes it feel fast.
  • There are a lot of rough edges. It’s hard to know what is a bug, what is intentional,  what just hasn’t been done yet, and what hasn’t been thought of.
  • There is an option for “Drop Cap” that doesn’t seem to do anything on the front end yet.
  • I’ve also never intentionally been able to highlight multiple blocks at once, but I’ve sure done it on accident a lot.
  • I can’t seem to delete some blocks without going into the text format.
  • I really like how the plugin is implemented. Being able to test Gutenberg without completely giving up the current editor is awesome and will hopefully help encourage people to test it out.
  • The tab key doesn’t let me actually add a tab, even inside a code block.
  • Existing content can’t really be imported. I hope this is something that is on the roadmap since it sure would be odd to Gutenberg sometimes not work like Gutenberg.
  • I miss a lot of the meta boxes I’m used to seeing on the screen.  Things like Yoast SEO (on some sites) and custom taxonomies are just not shown. If every metabox ever made for WordPress needs to be remade, it sure is going to make developers lives a living hell.
  • Adding images and the image block in general are confusing. For example, despite having “All da” ( which I think is “All Dates” but is cut off) selected, only my 10 most recent images are shown initially.  There are no names/text associated with the
  • I can’t figure out how to add an image to this list.
  • Autoembeds seem to work, but don’t display anything in the UI.
  • The Embed URL block tells me that I can’t embed that content, but the front end of my site tells me differently.
  • The sidebar being empty 3/4 of the time feels really odd.
  • The default state is likely my favorite “Distraction Free Writing” implementation in WordPress yet.  I’m simultaneously able to focus on my content, and yet I have all the tools I need for writing. I don’t have all the tools I need for content creation.
  • I need to take my hands off my keyboard more than usual. Adding a paragraph after a list isn’t easy to do with just a keyboard.
Lots of things are constantly changing with Gutenberg ( my small change was merged within hours of proposing it). I’m going to keep my eye on it. The content for this post was drafted in Gutenberg and I’m going to try to continue to do that going forward.  Go install Gutenberg, so you can generate your own opinons on it.

A WordPress without Woman.

If WordPress had no Woman contributors, 4.7 wouldn’t have had a release lead.
If WordPress had no Woman contributors, The queue for plugin reviews would rarely be empty.
If WordPress had no Woman contributors, many WordCamps would lack lead organizers, speaker wranglers and sponsor wranglers.
If WordPress had no Woman contributors, most WordCamps never would have been approved to be organized.
If WordPress had no Woman contributors, The REST-API never would have made it into core.
If WordPress had no Woman contributors, WordPress for Dummies never would have been written.
If WordPress had no Woman contributors, many support questions would go unanswered.
If WordPress had no Woman contributors, the training team wouldn’t have created lesson plans to help anyone teach WordPress.
If WordPress had no Woman contributors, most waapuu would never have been designed.
If WordPress had no Woman contributors, WordPress would be inaccessible to many people using assistive technology.
If WordPress had no Woman contributors, WordPress wouldn’t be fully translated in over 60 languages.

There is no area of WordPress that is untouched by the contributions of Woman. In honor of International Woman’s Day tomorrow, my friend Mika is participating in “A Day Without Women”. I support her and every other Woman of WordPress that chooses to do the same.

The theme for 2017’s International Woman’s Day is “Women in the Changing World of Work: Planet 50-50 by 2030”. While Planet 50-50 ignores the gender non-binary members of the world, it’s a phrase that aims to seek equal representation, recognition, and opportunity.

For my fellow men of the WordPress community, I encourage you to make sure a woman who’s work you appreciate is known tomorrow. Without the contributions of woman, WordPress would be worse off.


WordPress JSHint Adventure

NOTE: I found this draft originally written on December 19, 2013.  Not sure why I decided it should remain unpublished, but I did and then like many drafts, I forgot about it.  So here it is.

One of the features of WordPress 3.8 is something that users will never notice. In fact, it’s something that most developers will never notice as well. It was establishing greater standards with the core JavaScript and adding JSHint.

JSHint is a tool that detects errors and potential problems with JavaScript code. They range from the annoying ( trailing whitespace ), to the potential bug inducing ( code in a function after a return ), to the likely to break a browser we still support ( a trailing comma in an object ). Adding JSHint was initially discussed around the same time as the creation of, but it wasn’t until the start of the WordPress 3.8 that much progress was made. K. Adam White led the effort to create the initial .jshintrc (which is the configuration JSHint uses) along with the grunt configuration to make running JSHint easy.

Once the configuration was decided upon, the process of fixing up the files was relatively quick and straightforward. A list was built and maintained of all files, and then edited to note the person who signed up to fix it and the ticket number.  Overall, from publishing the post until the last file was cleaned up it took 7 days.

By going file by file, we minimized the churn and made it simple for committers to review. It also made it easy to find bitesize chunks. Overall, 13 individuals wrote patches in addition to the committers who assisted.


Emoji to show you are here

I don’t know how it started, but sometime after WordPress switched to Slack in 2014 the norms for checking in to a dev chat switched to emoji.  Many people , some use slack specific emoji like the bowtie, and others change it up on a regular basis.

Like many traditions, this started completely organically and at this point it’s so normal, no one bats an .

I feel like It’s important to have traditions in open source software, but it’s also important to make them easy to pick up.  It helps new contributors feel a part of the process.  If the traditions are too hard to pick up on, then you risk creating an us vs. them problem. Thankfully, emoji’s to show you are present is one that people can pick up on right away and immediately feel a part of the WordPress team.


User Trust Matters now available in Japanese

ユーザーとの信頼関係の重要性 – WordPress コミュニティにおける後方互換性という哲学

When I was summarizing my last month of daily posting, I mentioned a few ways I felt like my writing was having impact. I didn’t even consider that my work would inspire someone to translate what I wrote my writing into another language.  However, I was incredibly honored when Takayuki Miyauchi asked to translate my post about user trust. I’m going to add having an article translated to my list. If you would prefer to read in Japanese, the link to the post is above.

Code WordPress

An alternative splitting algorithm for publishiza

My friend John built plugin for writing tweet storms in WordPress. I’ve now used it to tweet storm about salary negotiations and WordPress committer stats in 2016. I like it, but I wasn’t super happy with how it split up the the post into individual tweets. It essentially just splits it up so that each tweet is whole words and doesn’t exceed 119 characters. It also adds an ellipsis at the end of every tweet. So I decided to build my own version that prioritizes whole sentences.

My tweet splitting algorithm first splits the post by sentences.  It then tries to build tweets and prioritizes keeping sentences intact.  My thinking is that this helps the tweets stand on their own a bit more.  If you want to use this, download and activate both publishiza and the gist below as plugins.


User Trust Matters

Helen Hou-Sandi, in response to someone suggesting a large rewrite in slack wrote this:

Your plan as I understand it disregards a couple of core WordPress philosophies/practices: striving for maintenance of backwards-compatibility, and that an X.0 release is no more significant than X.1 or Y.9 (this is closely related to maintaining back-compat, in that something like semantic versioning is less meaningful for WordPress core).

Generally, the most successful refactorings in core have been done in support of features being built, whether that’s a user- or dev-focused feature. It’s not that core code can’t be improved (clearly it can), it’s that better decisions regarding back-compat and, more importantly, forward-compat for an API or other bit of code can be made when one eye is on practical application.

As a user centric project, WordPress chooses philosophies that put the user first.  There is also an unwritten philosophy point that many committers talk about which is that User Trust Matters. What that means to me is that users trust WordPress for running businesses, sharing content, and engaging with their own users. User trust must be maintained in order to provide features such as automatic updates.

User trust isn’t something you earn and then just get to keep forever. It’s a maintenance relationship.

Drew Jaynes

Trust is maintained by understanding that WordPress core is one piece of a WordPress website.  It doesn’t matter if it’s a plugin using an API in a novel way, a theme missing a needed CSS class, or an outdated version of PHP running on a server.  When a site running WordPress breaks, it’s WordPress that breaks and it’s user trust that is hurt.  It’s why WordPress has a beta and RC period with many calls for testing.  It’s why a field guide is published and plugin authors are emailed before a release.

It works for users now. When it stops working for them, it’s our fault and we lose their trust.

Andrew Nacin

Over the last 3 years, the underlining taxonomy code in WordPress has changed dramatically in order to support taxonomy meta.  In new versions though, WordPress still considers the case that data hasn’t been migrated.  At WordCamp NYC a few years ago, five contributors talked through how to best handle meta when a term hadn’t been split. By thinking through cases where things aren’t pristine, WordPress is stronger and users can trust it.

To design a spacecraft right takes an infinite amount of effort. This is why it’s a good idea to design them to operate when some things are wrong

Akin’s 2nd law of spacecraft design

WordPress can absolutely do a better job with maintaining user trust, but as long as it considers the fact that User Trust Matters, it will be a stronger project.


Always Press Publish

The year is coming to an end and I’ve spent the last 23 days successfully publishing something here each day. It hasn’t been easy. Some days it is as simple as seeing something online and being inspired, others I struggle with an idea all day, but I am guided by a couple principles.

  1. Always Press Publish. It’s easy to fall in the trap of wanting something to be perfect before you share it. It’s similar to the “one more feature” trap that hurts the ability for software to be released. By having a deadline of every single day something needs to be published, I force my self to understand that perfect is the enemy of complete.
  2. Press This is my friend. If I read something cool, I try to share it on my site.  Especially if it’s something I’ll want to reference later.
  3. My thoughts and opinions matter. Or at least they matter to me.  If they help someone else, that’s even better.  But I am ok with pressing publish because for me, at the time that I write something, know that my thoughts and opinions matter to at least myself.

If your goal is to blog more in 2017, those are the principles I used to blog more in 2016.


2016 WordPress Committer stats

I’m sharing these stats with the duel caveat that commits aren’t a great measure of impact and that commits only represent one type of core contribution. When I talk about employers it’s with the caveat that some people change jobs. Also not everyone works on donated time. Now that I have looked at these numbers for two years I think that it’s interesting to see the trends.

In 2015 31 people with 16 unique employers committed to WordPress core. In 2016 it’s 37 people with 20 employees.

The employer with the highest percentage of commits in 2016 remains Automattic at 14.66%. This is down from 20.37%.

The individual with the greatest number of commits is @ocean90 at 360. Last year it was @wonderboymusic.

The total number of commits is down from 5106 to 2967. While that number is big I don’t think it’s necessarily bad.

For props this year 750 individuals got props with 396 for the first time. This is up from 721 total and 379 first timers in 2015. 91 people contributed to every release in 2016 vs 94 in 2015.

Uncategorized WordPress

Video: The WordPress REST API Guide for Non-developers – Petya Raykovska

We rarely talk about are the challenges presented by the REST API, especially for non-developers, mostly because the only people who talk about the REST API are developers.

This talk  provides a short guide to the WordPress REST API from a non-developer perspective: what is it, how it will change WordPress development, combined with some thoughts on the impact it will have on projects created with WordPress and the people creating them.

Source: Video: The WordPress REST API Guide for Non-developers – Petya Raykovska

Petya gave an excellent talk at WCUS that I highly recommend everyone watch to better understand the REST API that shipped as a part of WordPress 4.7