Symbols of Hate at WordCamps

Be considerate, respectful, and collaborative.
Refrain from demeaning, discriminatory or harassing behavior and speech.
Be mindful of your surroundings and of your fellow participants. Alert conference organizers if you notice a dangerous situation or someone in distress.
Participate in an authentic and active way. In doing so, you help to create WordCamp CITYNAMEHERE and make it your own.

WordCamp Code of Conduct

I’ve spoken, attended, or organized over 50 WordCamps over the last 10 years in large part due to the overwhelming acceptance and respect in our community. WordPress as a whole is a place that people generally are able to work together towards the common mission of Democratizing Publishing and WordCamps are a physical manifistation. However, over the last few years I’ve started to see something crop in which worries me. Outright symbols of hate and oppression.

The red “Make America Great Again” hat is a potent symbol of racism. It’s a symbol used by white supremacists that is just as vulgar as a swastika or “14 words”, and it’s one that has no place in a community that seeks to have people who are “considerate, respectful, and collaborative.”

Symbols have been co-opted before. The swastika has its roots in ancient religions. The word comes from Sanskrit and means “conducive to well being”, but the adoption of it by the Nazi party has effectively ruined it for everyone.

While the origins of the hat is in political speech, that has changed. “…I think what happened is that the hat was essentially kidnapped, weaponized by Charlottesville and by white supremacists and by the violence that went on in some of those rallies by a minority of people at those rallies.” Washington Post fashion critic Robin Givhan told NPR.

Does the red MAGA hat have a place at WordCamps? I don’t think so based on the first two points at the top of the code of conduct.

Be Considerate, Respectful, and Collaborative.

There is nothing considerate, respectful, or collaborative about a symbol of hate. A symbol meant to divide. “Make America Great Again” is a phrase meant to inspire folks to inspire white supremacists to “Make America White Again.” The phrase doesn’t even get used as a dog whistle at times:

In June 2016, a Tennessee politician even put that on a billboard. Rick Tyler, running for a congressional seat in mostly white Polk County, Tennessee, explained that his “Make America White Again” billboard was meant to evoke the mood of 1950s America, when television shows idealized the image of the happy white family. 

Is ‘Make America Great Again’ Racist?

Refrain from demeaning, discriminatory or harassing behavior and speech.

While MAGA can appear to not break this part of the code of conduct, due to it’s being used as a symbol of white power around the globe, that is not the case. A mass murder who shot up a masque in French speaking Quebec wore a MAGA hat. Throughout the world, the most common word in biographies of the altr-right is MAGA. This isn’t a strictly America problem, it’s one being faced by much of the world. MAGA and localized derogates is used to harass immigrants, refugees, and anyone that doesn’t fit the local definition of normal.

We, the WordPress community, wouldn’t be ok with someone walking in to a WordCamp with a swastika, why should we be ok with someone wearing a Make America Great Again hat? People are welcome with all political beliefs, but when those political beliefs cross over to hate speech, our code of conduct needs to step up. I think our code of conduct should be clear that symbols of hate are just as unacceptable as overt sexual imagery.

Programming WordPress

Ten Commandments for Automated Testing

Though Shalt Write Tests

If you are not writing tests, none of the rest of these matter. You must always start somewhere, and getting some tests is better than not having any.

Though Shalt Prove Bugs Exist With Tests Before Fixing Them

A bug report is one of the best times to write a test. And one of the worst feelings as a developer is fixing the same bug over and over again. Test driven development isn’t something that always works for features, but test driven bug fixing always leads to a concrete issue being fixed.

Though Shalt Aim For High Test Coverage

You don’t need to get 100% test coverage for almost everything. It’s often an unachievable target for legacy software projects, but that doesn’t mean we can’t aim for high coverage. Aiming for high coverage allows you to take calculated risks on where the return on writing a test is low

Though Shalt Setup Test Processes Whenever Setting Up A Project

This should be as innate a process as possible and you should never have an excuse to not write tests. By having your test infrastructure as a part of your boilerplate, you reduce the friction of writing tests and it can be a normal part of your development.

Though Shalt Understand the Code You Test

It’s unrealistic to expect someone to write tests without knowing how and why code works the way it does. It’s why it’s best not to go back and add tests to old code but instead to get in the habit of writing new tests for new code or when changing existing code.

Thou Shalt Never Trust The User

User entered data is one of the most important things to test since it’s something that is going to be hard to predict and the area where you have the greatest likelihood of a security issue. Tests will help safeguard your application.

Though Shalt Never Merge Code That Hasn’t Been Tested

Auomated tests aren’t perfect. There is no substitite to a human doing a real test, but when you get a high amount of test coverage, you can deploy with higher confidence without using as much human testing time.

Though Shalt Never Delete or Ignore Tests Without Removing Code

Deleting or ignoring tests without removing code is tantamount to having never written the tests in the first place. If you’re having problems with your tests, you are better off fixing them since…

Though Shalt Never Allow Flaky Tests to Remain Flaky

Inconsistent failures should be fixed as tests that provide false failures can reduce your trust in your tests. Some of the areas it’s important to consider when testing include anything related to time and anything that relies on the network.

Though Shalt Never Trust The User

Seriusly. This is important enough to mention twice since user input is the most likely thing to cause a problem for your application.

My team is currently hiring for a developer to work on our RevOps team. If things like testing interest you, please check it out and apply.

Programming WordPress

Potential Tech Conference Talks

I am constantly thinking of new potential talks that I would want to either give or convince others to give. Some of these have been on my list for almost a decade, while others are relatively recent ideas.

Roles on a web team

There is a big difference between roles, jobs, and titles. I cosider a role to be the atomic unit and they bunch up into a job. So for example, a role is “Writer of CSS” and that might be a part of the “Front end developer” job. It also might be a part of the “Designer” job. I want to look at all the roles that need to be filled (I think there are somewhere around 100-200) in order to build, launch, and maintain a website and how successful teams are able to define jobs.

Improv for Web Developers

It’s been a long time since I did improv, but many of the things I learned from it are foundational things I use every day. This could be participatory; this could be a disaster. Just like an improv scene.

This is likely closer to a lightening talk than a full talk.

Axioms for the Web

Axioms are ideas we use to start our reasoning that are so fundamentally true, we use them to define what is true. They come from a Greek term that roughly translates to ‘that which commends itself as evident.’ They are phrases as simple as: A + B = B + A. One look at this phrase and we understand the truth within it.

I want to expand on a lightening talk I did a few years ago to look at what things are so fundamentally true for websites that they define what is true.

DUX – Developer User Experience

What is the experience of contributing to and using your code base like and how can we use lessons from user experience design to influence ways in which we improve it?

Interviewing developers

I’ve refined my interview questions over the last decade and think it could be interesting to share these questions, perhaps even doing a mock interview on stage. I might even talk about questions I used to use and why I don’t use them any more.

Foundations of HTTP

A look at the http standard, how it has evolved to http/2, how it is evolving to http/3 and the foundational concepts of http verbs and status codes that are incredibly relevant to all web developers.

Get in touch if you would like for me to give one of these at an event you are organizing. None of these are fully flushed out so they will take some time, but I think there would be interest in all of them.


Random Thoughts on… Keynotes and WordCamps

Dave Bisset shared some of his thoughts in response to my random thoughts on travel and WordCamps post. One paragraph stood out to me:

Some organizers associate keynotes with “headline speakers”. I personally don’t like keynotes as a speaker organizer and in 12+ years with WordCamp Miami I only did two official planned ones. I’ve too often seen events have a single keynote that is often executed poorly – where it’s seen to put a spotlight on a local or national speaker that was meant to be used as a “see… see… our conference has someone important!”. You can tell this because their subject material didn’t apply to the majority of the audience – they were just there because they were a “big name”. I’m not saying keynotes are bad, but i’ve walked out of more awkward keynotes at WordCamps that I have feel good ones.

I’ve given three WordCamp keynotes and have also organized camps with and without keynotes. In that time, I’ve developed a handful of random thoughts on the topic.

  • Not every WordCamp needs a keynote. It’s far from a requirement.
  • When it is decided to have a keynote, I think it’s best to come in one of three flavors:
    • If you are a new camp and want to bring in someone who can really help build up your community.
    • If you have someone in your local community who should be given a chance to give “One Big Message”, a message that everyone should hear. The best one of these I have seen is Tracy Levesque at WordCamp Philly. Boone Gorges also gave a fantastic one at WordCamp NYC.
    • If you can bring someone from outside that wouldn’t normally be a part of the WordPress community who has an interesting thing to share. WordCamp Lancaster 2017 had a local computer science professor.
  • Keynotes should leave the audience asking questions of themselves, and this should be for just about everyone in the audience.
    • My WordCamp Baltimore Keynote from 2013 “Citizenship in the Open Source World” aimed to ask what does it mean to be a part of Open Source.
    • My WordCamp Philly 2015 Keynote “Why WordPress Works This Way” aimed to get the audience to question what philosophies they wanted to use in their decision making
    • My WordCamp St. Louis 2016 keynote was somewhat last minute, so I based it on my 2015 WordCamp Philly one. Though this time it was more based on “We can learn from something without emulating it exactly” and asked “What can we learn from WordPress?”
  • A poorly executed keynote makes a sizable portion of the audience question why they were there.
  • Keynotes are opportunities for “Big Messages”, not minutia. It’s not a time for “How”, it’s a time for “What”.
  • You should never take questions at the end of a Keynote. If you are giving one, it’s your stage and your message. The hallway is the right place for the conversation to continue.
  • Opening/Closing/Mid day keynotes all are ok.
  • I would rather no keynote than a bad keynote.
  • I would rather no keynote than an ok keynote.
  • A “regular talk” should not become a keynote simply because they are the biggest ”name” attending. Great keynotes and Great instructional talks are different
    • You still want to be careful with your scheduling. Don’t put another developer talk at the same time as Andrew Nacin preparing an “Advanced Topics in WordPress Development” talk.
  • It’s ok to save a good talk idea for when you are going to keynote. Or let organizers know in your application that you only want a specific topic considered if it would be a keynote.

Comments and ping backs are open: What are your thoughts on keynotes and WordCamps?

Random Opinions WordPress

Random Thoughts on… Travel and WordCamps

While looking at the list of WordCamps that I’ve spoken at, it got me thinking about travel and going to WordCamps away from home. Here are some random thoughts on that matter.

  • In General, I think it’s best for local camps (i.e. not specialized events like WordCamp for Publishers or regional camps like WordCamp US) to be majority local.
  • Defining local is hard. Am I local to Montclair? It’s less than an hour for me to get there via train. If yes, does that also mean I am local to Philly? I would say I’m not really local to either of them even though they are all NYC Suburbs.
  • I like to think of things as being in kind of four different classifications:
    • Very Local. This is the place you live or the place you work.
    • Day trippable. These are the places where it’s super realistic to wake up one morning and decide “I’m going to visit X today”. It’s generally things in like a 2 hour not flying radius.
    • Hard Day Trips. These are the places that it is possible to do a not flying day trip to, but it’s not going to be the easiest trip. If flight times work, a flying day trip is completely doable.
    • Overnight trip required. There is no way around, this is real travel
  • For the past few years, I’ve limited myself to speaking in the first 3 categories. Partially to take it easy on travel, and partially since I took 2018 off from speaking entirely.
  • It’s important for people who can be considered “Names” to make space for the next group of contributors and this includes not speaking all the time.
    • Sidenote: I was chatting with another core committer recently and we noted “We are not the future of WordPress”. I don’t intend to go anywhere, but I also recognize that my strength for the project today isn’t to be the loudest voice.
  • I’m not at all convinced that “Names” sell tickets for local WordCamps. I am convinced that developing and nurturing a quality community sells tickets to WordCamps.
  • It’s important to visit other communities to meet people, but that doesn’t mean I need to speak. One of my favorite camps was WordCamp Seattle 2014 as I got to meet a number of people and see some old friends that it had been years since we spent time in person.
  • My first ever camp that I went to with no connection to the local community was super important to my growth as it allowed me to meet a lot of folks, many who became long time friends. WordCamp Phoenix 2011 was a special event.

Overall, I think going forward I’m going to try to travel a bit more, while staying firmly in my local and near local communities.

What are your thoughts on WordCamps and travel? How do you approach your decisions on when to fly to a different city for a camp?

Code Programming WordPress

__DIR__ vs dirname( __FILE__ )

Calling a constant should always be faster than a function call, right? PHP contains two different ways to get the directory that a file is currently in. __DIR__ is a magic constant added to PHP in 5.3. The official PHP documentation specifically states: “This is equivalent to dirname(__FILE__).” Equivalent in return doesn’t necessarily mean equivalent in performance though, so I decided to test the performance of both accross a couple of variables.

Testing Methodology

When running lots of tests, I’ve found that travis-ci can be a big helper. You can define the matrix of the tests you want to run as your testing matrix and then use the results. So I setup a repo for my tests. The repo contains four main pieces:

  1. A file generator which creates the code I’ll actually run the performance test on.
  2. A test running script which runs the actual tests.
  3. The travis.yml file to define my tests matrix
  4. Files used for the actual test. This is not linked, there are 400,000 files. The generator shows them off.

My test calls the function I am looking for 100,000 each. One run has all the files in 1 directory, and the other has one file per directory. I wanted to rule out the possibility that a single directory could affect this call.

I ran this test on six version of PHP: 5.6.40, 7.0.33, 7.1.27, 7.2.15, 7.3.9 and 7.4-dev. Each test did 650 runs and I looked at the user time for each of those runs. This means that I called both __dir__ and dirname( __file__ ) 130,000,000 times each. I then took the times for each of these runs and looked at that maximum (slowest) run for each and the 95% time ( the average between the 618th and 619th slowest) to rule out any extreme cases. Overall, the results between maximum and 95% are similar.

User is the amount of CPU time spent in user-mode code (outside the kernel) within the process. This is only actual CPU time used in executing the process. Other processes and time the process spends blocked do not count towards this figure.

Stack Overflow

__DIR__ vs dirname( __FILE__) Test Results

95% performance

dir ( 1 folder)1.42.762.082.512.271.3615
dir ( many folders)1.382.292.552.36152.651.57
dirname( 1 folder)1.58152.272.74153.242.411.5215
dirname( many folders)1.682.292.08153.292.68151.87

Overall, the results show that __dir__ is generally faster, but it’s rarely much faster. Consider that in the slowest run ( using PHP 7.2 and calling dirname( __FILE__ ) on multiple folders), each call took 0.0000329 seconds. The fastest run was 2 hundred-thousandths of a second faster. This is such a micro optimization that except under extreme scale, it’s unlikely you will ever notice a difference. That said, under most versions of PHP, __DIR__ is faster.

So: __dir__ or dirname?

At the end of the day, the performance of __DIR__ is ever so slightly better, but more importantly I think it’s clearer and easier to read. So I’m on team __dir__, but the performance is only a bonus.

If you have a different thought, or think that my testing methodology could be improved, please let me know in the comments below.


This might be the first post ever published on WordPress using PHP7.4.

I have every reason to believe that this is the first post ever published on WordPress using PHP7.4. It’s likely coming a bit premature, but if you aren’t willing to have some fun, then why maintain upstream language compatibility of an open source project. I’ve worked on php version support in WordPress since PHP7.0 and made the first post using WordPress on php7.3, so this is becoming a fun tradition.

Yesterday I added code to WordPress core to fix a number of deprecations in PHP7.4. PHP7.4 is scheduled to be released on November 28, which is 74 days and 5 release candidates away. The goal for WordPress is that version 5.3 will fully support PHP7.4 and that version is scheduled to be released 12 November 2019.

The biggest deprecations in 7.4 that affect WordPress core are around magic quotes and

For plugin and theme authors, you’ll want to look into:

PHP7.4 features for WordPress Developers

It’s not just deprecations in PHP7.4 that WordPress developers can look forward to, but the PHP internals team has added some new features for us to use as well.

Typed Properties continue the evolution of PHP’s type system to allow for class properties to be type strict. The only Property types you can’t use are void and callable, otherwise every type decleration is supported.

Arrow Functions allow for simpler anonymous functions. I recommend only using these in callbacks such as with array_map in order to make your debugging simpler.

Coalescing Assignment is here as syntactical sugar. ??= allows for you to add default values easier.

If you see any errors or notices on this site, let me know in the comments. Assuming this actually publishes, then WordPress can be used with PHP7.4, but I only recommend it for those feeling especially adventurous.

Art Programming WordPress

Art and Commit Messages: Volume 2

Last year I published volume 1 of Art And Commit messages and sold nearly 50 copies! For my first zine, I was ecstatic that so many people were willing to spend $3 on something so unknown. I have already started thinking about Volume 2 and think that it will be a great thing to publish at WordCamp US. I’m also thinking it might make sense to include some different things this time.

Art by more Artists

Volume 1 featured my art, for Volume 2 I would like to feature the art by more artists. I am also thinking of budgeting a small amount so that artists are compensated, but as Volume 1 didn’t make any money I think this is going to be a low amount. Maybe $50 for each piece.

Are you interested in having your artwork featured in Art and Commit Messages? Let me know:

Essays by More Writers

Along the same lines, I want to feature a couple of essays about commit messages from a variety of people. What kind of essays would you like to see in volume 2?

Finally, I want to figure out some sort of game to include. Maybe I loved reading Highlights for Children too much as a kid, but I think a game would be fun.

Art and Commit Messages: Strange Bedfellows

Art and Commit Messages might feel like an odd combination but the best of both are snapshots that convey an intent. Art transposes the emotion of the creator to an audience. It can transport you into the brain of the artist. The best commit messages similarly transport you into the brain of the creator. They share the coders intent.

That’s the message from the cover of volume 1. I absolutely recognize the odd combination, but they are two things that I care about and I hope that by combining these two strange bedfellows I can encourage people to write better commit messages.

Overall, my goal remains to encourage high quality commit messages through education, entertainment, and an understanding of history. I’m not looking to make money, if I was I wouldn’t be making a zine.

Do you have other ideas for making Art and Commit Messages better? Leave a comment or get it touch and let me know!

mostly pointless. WordPress

An adventure with a super useless one-liner to find the most common words in WordPress commit messages

I read some insight into Drupal committing and they had a chart of the most common words in drupal commit messages. I thought it would be interesting to do something like that with WordPress Core, so I through together a bash one-liner to find this. It’s not the most eloquent solution, but it answers the question that I had. Here is what I initially came up with.

svn log -rHEAD:1 -v --xml | xq '.log.logentry | .[].msg' | sed 's/.$//' | sed 's/^.//' | sed 's/\\n/ /g' |  tr ' \t' '\n' | tr '[:upper:]' '[:lower:]' | sort | uniq -c | sort -nr | head -n 25

Let’s walk through this since there is enough piping going on, that it may not be the easiest to follow.

svn log -rHEAD:1 -v --xml

I start by getting an xml version of the SVN history, starting at the first changeset and going until the current head.

xq '.log.logentry | .[].msg'

Next, I use xq which takes xml and allows me to run jq commands on it. It’s a handy tool if you ever need to use xml data on the command line. In this case, I am taking what is inside <log><logentry> and then for each sub element, extracting the msg. At this point, the messages are on a single line wrapped in quotation marks with \n to signify newlines. So I run three seds to fix that up.

 sed 's/.$//' | sed 's/^.//' | sed 's/\\n/ /g'

I’m sure there is a better way to do this, but the first one removes the last character, the next one removes the first character, and the last one converts new lines to spaces. Since words are what we are aiming to look at, we need to get all the words onto their own lines.

 tr ' \t' '\n'

tr is a powerful program for doing transforms of text. In this case, I am taking whitespace and turning it into actual newlines (rather than just the new line charachters). There is likely a more elegant way to have solved this, but my goal isn’t the best solution it’s the working one.

tr '[:upper:]' '[:lower:]'

Word and word are not equal, so we need to make everything a single case. In this case, I am again using tr, but now I am transforming upper case characters to lowercase.

sort | uniq -c | sort -nr | head -n 25

Counting things on the command line is something I have done so many times, I have an alias for a version of this. Sort puts everything in alphabetical order, uniq -c then counts how many uniq values there are and outputs it along with how many of each it counted. uniq requires things common things to be in adjacent lines, hence the initial sort. Next up, we want to sort based on the number and we want high numbers first. Finally, we output the top 25.

 28997 the
 20429 fixes
 17844 to
 17818 props
 15251 for
 15189 in
 14441 see
 10856 and
 10272 a
 7549 of
 5594 is
 5227 when
 5133 add
 4444 from
 4143 fix
 3847 *
 3821 on
 3489 use
 3320 that
 3267 this
 3064 with
 3043 remove
 2983 be
 2766 as 

That’s not super helpful. The isn’t my idea of interesting. So I guess I need to remove useless words. Since I have groff on this machine, I can use that and fgrep

 fgrep -v -w -f /usr/share/groff/1.19.2/eign

I also noticed that the second most common word is whitespace. Remember when we used to put two spaces between sentences? WordPress Core commit messages remember. So let’s add another sed command to the chain:

sed '/^$/d'

And now the final command to see the 25 most used words in WordPress Core Commit messages:

svn log -rHEAD:1 -v --xml | xq '.log.logentry | .[].msg' | sed 's/.$//' | sed 's/^.//' | sed 's/\\n/ /g' | tr '[:upper:]' '[:lower:]' | tr ' \t' '\n' | fgrep -v -w -f /usr/share/groff/1.19.2/eign | sed '/^$/d' | sort | uniq -c | sort -nr | head -n 25

And since you’ve made it this far, here is the list

 20429 fixes
 17818 props
 15189 in
 5594 is
 5133 add
 4143 fix
 3847 *
 3320 that
 3267 this
 3064 with
 3043 remove
 2766 as
 2435 an
 2432 it
 2109 post
 2103 if
 2080 are
 1889 don't
 1793 update
 1735 -
 1688 twenty
 1523 more
 1500 make
 1471 docs:
 1416 some 

Have an idea for another way to do this with the command line? I would love to hear it.


Mobile Block editor – Initial Thoughts

I’m writing this using a beta version of the WordPress iOS mobile app that integrates Gutenberg. It is fairly stripped down as far as blpacks go.

While this site has blocks from multiple plugins (including Gutenberg so I can try the latest features), the app has much fewer options.

Blocks available from the mobile app

I was definitely surprised to not see all the core blocks, especially not to see my reusable blocks that I have saved to the site.

Another thing that surprised me as a power user is that slash commands for new blocks don’t work.

I also can’t figure out how to access the block inspector to save options on differnet blocks.

Opening up posts with blocks in them other than this initial set shows those blocks as “unavailable”. This includes all the embed blocks.

Unsupported is the new black

The responsiveness of the editor is amazing, and the ability to move blocks up and down makes editing inside the mobile app much easier.

Overall, as a version 1, I like it. I also think that it has long way to go before I will abandon opening a mobile browser for the majority of my on the go blogging.