Random Thoughts on Pressnomics

I spent the last few days in Tempe, Arizona at Pressnomics. This was an interesting event for me, as I don’t think I fit the mold of the attendees.  While I work on WordPress, and Happytables is built using WordPress, I’m not involved in the business of WordPress per say. None the less, I had some amazing conversations, met some great people, and got to know some others better. As I think back on the event, here are some random thoughts:

  • Alex King’s keynote was incredibly powerful. I was in tears. I’m glad Alex got to give a “Last Lecture” to the WordPress community.
  • Sally and Josh did a great job. Everything seemed well thought out and planned.
  • The themes that stood out to me over the course of the conference:
    • We need to think about people as people and take care of them. This especially includes ourselves.
    • On the underside of the iceberg, lots is going on.
    • The WordPress buisness ecosystem is growing, but it’s still not big.
  • I got positive reactions to my talk.  I should likely turn the rest into a blog post
  • The Jorbin Test seems to have had a mostly positive reception. I hope it helps other developers.
  • The quote of the conference was without a doubt “some of us crusty old broads code”.
  • I enjoyed making word art from quotes in speeches.  I have a few more to do, but here are the first four:

The featured image of Wapuu wearing a bowtie is by Michelle Schulp.


Random Thoughts on the WP REST API and WordPress Core

I like sharing my random thoughts on subjects related to WordPress.  Right now, there is a lot of discussion about how to merge the WordPress REST API into WordPress core.  Here (in particular order) are my thoughts on the subject:

  • Merging the rest infrastructure if 4.4 was a great decision. Adding the ability to create rest end-points easily helps plugin developers. Adoption, as with any developer feature takes time and this one seems to be going swimingly.
  • While completely replacing wp-admin is certainly a long-term goal, the idea that it needs to be the next step for the API destracts from real issues in the endpoints that are close to being “finished”.
  • Password-protected posts suck. The core WordPress implementation sucks. Did you know that passwords are singular for the site?  If you have two password protected posts with different passwords, you can’t see the content of both at the same time. If they have the same password, you get both even if you were only supposed to have one. That said, they are something many users use and something the API needs to support to be included in core.
  • Meta is one of the most powerful features of WordPress.  Anyone remember how excited developers where to get term meta? You should, it was two months ago. Meta needs to be included in the API and ideally all of it.
  • The Fields API would really help solve some of the meta issues, but I think that also has a long ways to go before it’s something that can seriously be looked at for core.
  • Due to the fact that every WordPress site’s API is going to look a little different, clients for the API are going to have to be a “smart”.  This means they are going to have to consider getting both more data than they expected and less.  This is very different from a lot of other API clients where the response is consistent.
  • The “Four Core Endpoints” will enable a lot of awesome things. Iterating on revisions design just started. Imagine iterating on them with a solid API in WordPress core for posts. Imagine a completely new post editing screen that is built from the API. REST-driven themes will become a lot more feasible. Developers have been forced to forced to write custom code for these four data types for way to long.
  • Let’s get the four core endpoints to a state that they are done. To do that, we need to have some serious discussions about them. That isn’t going to happen while we debate creating endpoints for everything under the sun.

Jeremy Felt wrote some good thoughts on the REST API as well.  I didn’t read it until I wrote the majority of mine since I didn’t want his thoughts to cloud my judgement. Daniel Bachhuber is trying to collect feedback. You should write your thoughts as well.


Thoughts on being an MC for A Day of Rest

Last week, I was given the opportunity to be the MC for the inaugural Day of Rest conference. I have to say, it was a lot of fun and an interesting challenge to be on stage all day.  I joked with some friends that it was my chance to be “All style and no substance” on stage, but in reality, I had to think about what I was going to do and had to improvise regularly. Here are some of my thoughts on the process.

  • It’s important to communicate with the organizers throughout.  Having a Slack channel is a must.
  • The process at ADoR was four blocks of two talks with breaks in between each block.  This mean that I was on stage twelve times with three main purposes for each one:
    • At the start of a block, I had to get the audience in their seats and quite while also introducing the first speaker. It’s important to speak loud to bring people back to a quite level.  It also helps if the first part of the introduction isn’t actually important since people will talk over you.
    • In the middle of the block, I had to fill a brief period of time and introduce the next speaker.  This block required the most improvisation.  When I could tell one speaker was going to need an extra moment, I had the audience introduce themselves to the people sitting around them.  I usually used an anecdote, jokes or broader lesson that was a continuing theme of the conference here.
    • At the end of the block, I had to make sure the audience had the information they needed to have a good break such as the location of food, drinks and things around the venue. For this, I used a Slack channel with the main organizers so that anything they wanted announced got announced.
  • It’s much easier to introduce people you know. I was lucky and knew every speaker (might be why I was given the honor of introducing everyone ). I tried to connect for at least a moment with each speaker so I knew how to pronounce names properly (important for everyone, including those that you worked with for multiple years)
  • I’ve written before about conference introductions and how a good introduction establishes a speakers ethos. I tried to do that for each of the speakers. I wanted them all to be able to begin and get to the meat of the presentation without having to say who they were and why they should be respected.
  • No one was there to hear me speak.  I tried to be succinct, but I know it will take some work to get even better at that.
  • The broader lessons I tried to highlight were the importance of getting to know people and that education comes from a variety of sources. Talks ranged from showing why the REST API is needed and is a game changer, to theoretical, realistic, and borderline insane demonstrations of what it could do, to case studies of practical examples of how it is being used right now.  Connecting all of those with the idea that you can take away something from everything was important to me.
  • I want to MC again.  It was a blast and at least one person seemed to think I did an ok job.

Thoughts on the PHP5.6 support timeline

I am really impressed with the recently passed PHP RFC to extend active support until 31 Dec 2016 and security support until 31 Dec 2018 for PHP 5.6.  It’s a very pro end user position.  Right now, the WordPress stats point to 72% of sites being on a version of PHP that the team which makes PHP doesn’t support.

We have to remember that the vast majority of end users and site owners don’t know what PHP is, let alone what version of PHP they are running.  Many have no control over the version of PHP they are running. It’s the hosts responsibility to ensure users are running an up to date server software and software vendors responsibility to ensure they work on the latest and greatest versions.

Many hosts are actively working on getting sites upgraded to the latest version of PHP, but it’s not happening quick.  By continuing to support 5.6, the PHP internals team is helping give hosts the time they need to get upgraded and vendors the time they need to make sure there code works.

That said, if you work on distributed PHP code and your latest version doesn’t work on PHP 7, it’s time to get on it.


Some Random Thoughts on WordPress and PHP versions

One thing that I’ve been working on for the last few months is ensuring WordPress supports PHP7 fully when PHP7 is released.  Last week, I had the honor of announcing WordPress will support PHP7 the day it is released (for all intents and purposes, it is supported now, but it will be official when PHP7 is official). What should have been a happy moment though was met with hostility and renewed of discussion of a different topic: the fact that the minimum supported version of PHP is 5.2.  While these issues are linked in theory, they aren’t the same.  Much like I did for the default themes, here are some random thoughts on WordPress and PHP versions:

  • It is important to support the latest and greatest version of PHP in WordPress core, and important to be ready as soon as possible. Much like we encourage downstream developers of WordPress to test and prepare for new versions, we need to do so upstream.
  • PHP’s consistent release schedule and minimal breaking changes over the last few years is going to make it easier for hosts to update in the future
  • WordPress is often blamed for hosts still running 5.2, but we need to remember that WordPress runs fine on newer versions of PHP, other applications, not so much.
  • No one wants to bump the minimum version of PHP more than the people actively writing WordPress. It just isn’t the responsible thing to do, which is why it’s not done.
  • PHP Core’s decision to drop 5.2 support when so much of the internet depended on it was one of the most harmful decisions it ever made.  It didn’t cause people to update, it caused people to run an insecure version of PHP.
  • Years ago, WordPress was thrown a lot of shade for supporting PHP 4.4 and not moving the minimum version while other open source PHP Content Management Systems had announced the switch with their next major version.  That took years to be released and in the end, the versions that dropped PHP4 support all came out around the same time.
  • When WordPress switched the minimum from 4.4 to 5.2, many users were stuck not being able to update. WordPress caused them to not be able to update WordPress.  That sucks for them and makes WordPress look bad.
  • The reason I hear from most hosts on why they don’t just update users is that it will break things other than WordPress.  If WordPress updates it’s required version and other applications/scripts are broken, WordPress broke the users site.  I don’t care if WordPress runs fine, if WordPress forced an update, WordPress is responsible for the update.
  • WordPress should continue testing nightly builds of PHP.

Some Random Thoughts on Default Themes

Twenty Sixteen was officially announced. This has lead to some renewed discussion of default themes. Here are some of my random thoughts on default themes in general and Twenty Sixteen.

  • WordPress is going to ship with multiple themes, so it’s important for different themes to hit different notes.  If Twenty Sixteen sets out with the same goals (or achieves the same goals) as Twenty Fifteen, it is a failure.  Twenty Sixteen seems to be a great way to show off photos.
  • Default themes serve as an entry point to contributing to WordPress.  Whereas core can seem daunting (it isn’t), plenty of people have worked on themes so they feel like they can contribute to a default theme.  This is part of why doing a new one every year is important.
  • Default themes help educate theme developers. By having a well commented theme, developers can learn how they can build themes.  The inline comments act similarly should be a tutorial for how to build child themes (and how to build themes in general).
  • Default themes allow for experimentation that isn’t as easy to do in core. Once code is in core, it’s likely going to be maintained forever. It also needs to be flexible.  This means that a default theme can experiment with things like new widgets, new ways to display content, and new ways to write code.  While I don’t think SASS has much of a place in core, I would love to see a default theme written in SASS.  Even better, I would love to see one use postcss with some fun plugins.
  • Core learns from default themes.  Nacin once said “Twenty Ten enabled the core team to become theme developers once again”. This is needed.  Most people on the core team that build themes are building pretty advanced themes.  The needs of Conde Nast, The New York Times and most of the clients of 10up, XWP, Human Made, etc are not the same as the needs of people who install a theme from the WordPress repository.
  • I wish there was an open call for ideas and that Matt would comb through them (with help as he sees fits) to come up with Twenty Seventeen.
  • Accessibility needs to stay a top focus of the default themes.
  • I really want to see a default theme that demonstrates wp-api.  I hope when the code for Twenty Sixteen is released, it is react and wp-api powered.
  • Twenty Sixteen looks good right now, but I think it will look better with a bow tie on it.