A quick review of Local by Flywheel

I recently decided to check out Local by Flywheel for local development, and my initial thoughts are that it’s strong for many things, but is far from perfect.

In the past, I’ve used MAMP, XAMPP, VVV, and custom docker environments for local development. Each of these has it’s own strengths and weaknesses. Local’s strength is that it is by the far the most user-friendly route to having a local development environment. It’s all GUI driven, you don’t need to mess with hosts files, and having an SSL cert for your local site couldn’t be easier. If your goal is to have a local site with little fuss, Local By Flywheel does it.

Where Local falls short is developer friendliness.  Installing XDebug, for example, isn’t easy. Customizing the environment to include anything beyond the standard config options also isn’t easy. If you are developer that needs XDebug or wants a PHP Extention that isn’t included out of the box, you are going to need to do some work for it.

Installing the development checkout of WordPress also isn’t straightforward. I would love for it to out of the box support using either the regular or development versions of WordPress. I could see a GUI tool like Local being very valuable for onboarding new WordPress Core Contributors who aren’t as familiar with git, svn, or the command line if it did this. 

Would I recommend Local by Flywheel?

For the right person, yes.  If you wouldn’t call yourself a developer and have no interest in contributing to core, then Local is definitely worth checking out. If you want XDebug, are comfortable on the command line, want to run PHPUnit, or need a nondefault PHP setup, then you likely should look elsewhere.

Have you tried Local by Flywheel?  What are your thoughts on it? 

Fall Conferences – PHP Madison and WordCamp NYC

Today I get to announce two conferences that I’m speaking at this fall. The first is here in NYC and is the 2015 WordCamp NYC.  I’ll be giving a talk entitled:
Lessons from Science Fiction and Fantasy we can use in Creating Websites.  Here is a short synopsis.

Science Fiction and Fantasy can teach web creators many valuable lessons. From seeing how Daleks with too narrow of a goal always fail to understanding the Klingons value of honor, to hundreds of other we can become better web creators by borrowing lessons from Science Fiction and Fantasy.

Next, I’ll be traveling to Madison, Wisconsin for the first time in almost 10 years to present “How Not To Build A WordPress Plugin” at Madison PHP.  A short synopsis of this talk is

WordPress has a powerful plugin architecture that enables you to build almost anything on top of WordPress. This power though can lead to anti-patterns that slow down sites, confuse users, and make it hard to scale. Let’s look at the wrong way of building plugins so you can avoid these traps.

Tickets for both events are on sale.  If you are either one, make sure to say hi!

The Year of the WordPress Accessibility Team – WerdsWords

This year has seen a lot of positive change in the WordPress contributor community, especially in the area of accessibility.

Take for instance, the appearance this year of two new faces on the credits screen as of WordPress 4.3:

Source: The Year of the WordPress Accessibility Team – WerdsWords

Drew is completely on target here. The WordPress Accessibility team has been rocking it lately. It wasn’t long ago that the question of if the Accessibility team should exist was floating around. They were the only team without a product, but instead focused on things across many teams. Since then, the team has stepped up big time and really is making WordPress better for everyone.  While Drew highlights the work they do for core in his post, they also have:

  • Created the Accessibility Ready guidlines and tag for themes
  • Helped to improve the accessibility of wordpress.org
  • Helped WordCamps have more accessible sites
  • much much more

Kudos to the WordPressAccessibility Team.  WordPress, and thus the web, is better because of the work they do.

Apply for the Kim Parsell Memorial Scholarship to attend WordCamp US 2015

I’d like to ask everyone reading this to take a moment to remember Kim, and to remember that it’s up to all of us to make people with different backgrounds feel welcome and included at events like these. Let’s do her proud. Apply for the Kim Parsell Memorial Travel Scholarship

Source: Kim Parsell Memorial Scholarship | WordCamp US 2015

 

Kim Parsell was a friend of mine even though we only met in person twice. Seeing her at WordCamp San Francisco last year, she was happier than nearly anyone I’ve ever met. Especially after Matt highlighted the work she had done for WordPress over the last year. At the contributor work days, she made a little office for herself on a couch and held court, bringing contributor after contributor over to discuss documentation, though I think the two of us spent almost as much time chatting about photography and how much she was enjoying WCSF.

This way of remembering Kim is one that I know she will be proud of and one I hope continues. Kim knew that WordPress benefits from having a diverse group of contributors, and that diversity comes in many ways. Let’s keep Kim’s spirit alive. If you are a woman who never attended WCSF, is an active WordPress contributor and needs help in order to attend WordCamp US, please apply for this scholarship.  WordPress needs your voice.

Following up on WordPress in a Next Generation PHP World

In April, just as WordPress 4.3 was beginning development, I started a conversation about WordPress, PHP7, and HHVM. Now that WordPress 4.3 has been released, I’m glad to say WordPress is looking great as far as PHP7 goes.

I’m planning on spending some time during the 4.3 development cycle focused on these next generation platforms.

The PHP core team did a solid job of not introducing many breaking changes with this release, which really helped to make the transition easier. The two major changes that WordPress needed to make in order to have passing unit tests on PHP7 were to deprecate PHP4 style constructors and updating some variable variables.

Screenshot of Travis-CI showing WordPress tests passing on PHP7
The final commit of WordPress 4.3 has PHP7 tests passing and running faster then any of the other PHP versions.

In 4.4, I intend to continue to focus on PHP7.  The release schedule targets Mid October 2015. I hope to move PHP7 out of the Allowed Failures bucket on Travis-CI the day it is released.

Next up is getting the unit tests passing on HHVM. Onward!

Five Years of Contributing to WordPress Core

Five years ago today, my first patch was accepted to WordPress core. Oh how the time has flown.

This last year has been one of my most exciting years as a part of the WordPress contributor community. At the end of September, I was given commit access to WordPress Core. I was excited to join a group that includes some of the smartest people I know, while also being terrified at the responsibility being handed to me. It’s been fun so far.

One of the coolest things in WordPress core that I worked on this year is the “Log Out of Other Sessions” button on the bottom of users profile screens. This seems like a simple button, but adding this iteration (which was a part of the 4.1 release) was the result of live user testing I organized as a part WordCamp San Francisco 2014.

In celebration, I made two commits to core today. One of them was to start user testing WordPress with PHP 7. I’m excited to see how we perform vs. the nightly builds there. The other introduced a new version of grunt-patch-wordpress which is one of my favorite parts of WordPress that I’ve been able to spearhead.

I’m lucky to share my committiversary with my partner who got her first props one year ago. I’m even more lucky that WordPress helped me meet her.

Five years of contributing is a long time. I’m especially happy that five years in, I’m more excited than ever to help build the software that powers so much of the web. Here is to another five years!

WordPress Hanukkah Releases

"Colorful dreidels2" by Adiel lo - Own work. Licensed under CC BY-SA 3.0 via Wikimedia Commons.
Colorful dreidels2” by Adiel loOwn work. Licensed under CC BY-SA 3.0 via Wikimedia Commons.

WordPress 4.1 is the fourth major version of WordPress and the sixth overall version of WordPress released during the festival of Hanukkah.  The first release during latke time was WordPress 1.2.2 which came out on December 15, 2004. It was a patch release and the notes highlight it as:

This release fixes a few bugs and security issues and is recommended for all 1.2 users.

The following year, the first major release during Hanukkah took place when WordPress 2.0 “Duke Ellington” was released.  This release featured WYSIWYG editing, and many other great features.  My favorite part of the release notes is this gem:

Faster Administration — Call it AJAX, call it DHTML, call it Larry, but we’ve paid close attention to streamlining some of the most common tasks in managing your blog

It would be four years before the next WordPress release during Hanukkah when WordPress 2.9 “Carmen McRae” was released on December 19, 2009.  Carmen featured trashing posts, a built in image editor and a feature that has continued to be updated (including in 4.1)

Easier video embeds that allow you to just paste a URL on its own line and have it magically turn it into the proper embed code, with Oembed support for YouTube, Daily Motion, Blip.tv, Flickr, Hulu, Viddler, Qik, Revision3, Scribd, Google Video, Photobucket, PollDaddy, and WordPress.tv (and more in the next release).

The following year, WordPress 3.0.3 was released on December 8, 2010. This release was a security release that fixed some XMLRPC security bugs.

After taking 2011 off, WordPress 3.5 “Elvin” was released on December 11, 2012. It featured a long desired update to media.  It also brought in a new default theme (just in time)

3.5 includes a new default theme, Twenty Twelve, which has a very clean mobile-first responsive design and works fantastic as a base for a CMS site.

Last Hanukkah was an early one (and featured a rare Thanksgivukkah ).  While there was no major release, RC1 of WordPress 3.8 came out on December 4, 2013.

A few more releases and we’ll be able to create a WordPress menorah.

Changes should happen in Code, not in UI

If you are deploying your WordPress site, it generally doesn’t make much sense to have to go in and setup changes when you push the newest version live. When you push to production, production should have all your changes.

One more benefit of this method is that you never need to be signed in with a user who can change settings, change plugins, or change themes. Being signed in as a user with as few capabilities as possible is a one part of limiting your vulnerability in case of attack

This is what I use to stop the majority of activities from happening in the UI.

tl;dr; Don’t Update Options in the admin, update them in the code.

The Twenty Fifteen Theme

Since the decision was made to update the WordPress default theme every year, I’ve contributed to all five new WordPress default themes. My contributions have varied from inline documentation, to accessibility testing, to refactoring PHP to cleaning up some JavaScript (and many things in between). Since Twenty Fourteen had it’s spectacular debut, the talk has already begun on the next one.

Konstantin Obenland proposed the idea that Twenty Fifteen should be a simple theme. Take _s and just add CSS. While that is a noble idea, I think we could also challenge ourselves to rethink themes completely for Twenty Fifteen. Since Twenty Fourteen was released early (Before we even hit Twenty Fourteen!), we have plenty of time to be experimental.

I would like to propose that Twenty Fifteen be a single page app largely done in JavaScript. This will require the addition of the Rest API the WP API team is building, but would enable us to demonstrate what is possible for a theme with almost no PHP. Imagine a theme where the only PHP is functions.php and index.php.

Maybe this is just a crazy idea. I don’t know. But I do know that we as a community can challenge ourselves to build something amazing.

Thoughts on Post Meta Boxes in WordPress

I’m generally of the opinion that the screen for adding content should be as simple as possible in a CMS.  It’s one of the reasons I really like the new Distraction Free Writing in WordPress 3.2 (sneak peek if case you haven’t seen it).  It’s why I was a huge fan of WordPress reducing the number of default metabox in 3.1.

This is why in the recently updated AddThis WordPress plugin, the meta box to disable AddThis on a post by post basis is disabled by default.  While it was a feature that users requested, it wasn’t something that people were beating down the door to enable.  I decided that thus for the majority of users, no reason to make the display show more than they need.

It was super simple code wise. All of this code sits inside of a class that controls all of the post meta box:

[php]
// These two lines are inside a function the hooks into init. $screen equals post and page
add_meta_box(‘addthis’, ‘AddThis’, array($this, ‘post_metabox’), $screen, ‘side’, ‘default’ );
add_filter(‘default_hidden_meta_boxes’, array($this, ‘default_hidden_meta_boxes’ ) );

function default_hidden_meta_boxes($hidden)
{
$hidden[] = ‘addthis’;
return $hidden;
}
[/php]

Now the addthis metabox will be hidden by default. Next time you add a post meta box to WordPress inside a plugin, ask your self if it’s one that all of your plugin users will need.

Learn more about AddThis for WordPress 2.1