Uncategorized WordPress

WordPress 4.7 downloads: 4 million in 7 days

I glanced over at the WordPress Download Counter and saw that WordPress 4.7 surpassed Four million since it came out last Tuesday.

Five years ago, during the State of the Word, Matt highlighted that WordPress 3.2 had 500,000 downloads in two days.  5 years and 15 releases later, it’s amazing to see the growth of WordPress.

In five years, how many times will that release of WordPress be downloaded?  Will we get to the point that we hit 1 million downloads in the first hour?

Uncategorized WordPress

A Free WordPress Development course – Part 1

Want to Learn WordPress?  There is no need to pay for a course that you may not ever finish it. You can level up your WordPress development skills for free. How? By watching some of the really great developers and designers of WordPress and by reading great examples of WordPress code. This isn’t a great intro if you don’t know code at all, but you will get better with code from this course. So, here are 30 hours of lessons for you.  That’s about equal to a 2 credit course in many colleges.

This is a Survey Course. All of the topics are things that an intermediate WordPress developer must know and a beginning WordPress developer should know/be learning.

Here are the first 10 hours of your course with the next 20 coming in the next few weeks:

Uncategorized WordPress

WordPress contributor continuity and other stats

I posted a graph of new WordPress contributors per release and Brian Krogsgard had some questions that I decided to look into.  Mostly he wanted to know how well WordPress did at maintaining contributors. So I made some more graphs.

In general, past contributions as a predictor of future contributions are pretty consistent across releases. If you contribute to one release, there is a 46% chance you will contribute to the next release. Overall, 44% of individuals who have contributed, have contributed at least twice.  While on its head, that means 56% of people only contributed once, digging in I was able to find that from 3.2 to 4.3, if you contribute, there is a 70% chance you will contribute again.

A total of 12 individuals contributed to all 14 versions analyzed and 57 contributed to 10 or more versions.

What does this mean? Mostly that we need to continue watching for change in this regard. Outside of 4.4, WordPress has remained consistent. Adding the git mirrors didn’t change anything. Switching to including the build tools and tests in the repo didn’t either.  As the WordPress contribution process continues to evolve, it will be interesting to see what if anything moves the needle.


New WordPress Contributors Per Release (graphed)

4.4 was an outlier, 4.5 returned to regular levels.  What will 4.6 show?  There are still a few weeks to contribute.

Uncategorized WordPress

grunt-patch-wordpress v0.4.0

Today I released an update to grunt-patch-wordpress which adds 2 cool features.

  1. GitHub URL support. You can now use grunt patch: with any copy of WordPress on GitHub. No longer will you need to download the patch manually. Works for both core and develop mirrors on GitHub. This feature was suggested by Helen 侯-Sandí
  2. Upload patches directly from the command line. No longer will you need to create a patch and manually upload it to trac. grunt upload_patch:20000 will upload a patch to the appropriate ticket after a user enters a username and password. This is limited to users with the appropriate XML-RPC privileges in trac (right now, that is just bug gardeners). You still need to manually add the `has patch` keyword. This feature was added by Eric Andrew Lewis. Thanks Eric!

Full changelog:…0.4.0
Thanks to the following additional people for contributing to this release: Stephen Edgar and Michael Beil.  Further enhancements to make it easier to work with WordPress Trac are always welcome. Also, I would love a logo or wapuu for grunt-patch-wordpress, so if you have ideas, send them my way.

Uncategorized WordPress

WordPress Automated Testing Next Gen

Thinking more about next steps for my half-baked idea for automated WordPress testing. So far, I’ve had multiple hosts reach out with nothing but positive feedback. The next step in my eyes is to come up with some next steps, proposing this as a featured project, and then building the pieces and recruiting hosts.  In order to really be successful, it’s not just the big hosts that we need to reach out to (most of them already follow WordPress core development), but the long tail of hosts and places that self-host. In my eyes, here is an initial brain dump of the tasks (and sub tasks) needed.

  • Test Runner and Reporter
    • We need a script that runs the tests and formats the results for reporting purposes. This script needs to be able to detect and/or know information about the environment along with information about the results of the tests (passed, failed, errored, skipped) and the revision this was run against.
    • The script needs to report the results to a centralized source. This could include tracking test length time, slow tests (to see if certain tests are slow under certain circumstances).
    • This likely needs to be written in PHP which is the only language we can be sure is on a WordPress server.
  • Test results receiver.
    • We need a place that results can be sent to. This will need to store the results of each test.
    • This could possibly be done by creating a WordPress plugin with a CPT for test results, along with the Rest API Infrastructure in core for sending in the results.
    • Hosts need to be able to register to send in results.
      • The barrier here should be as low as possible. We want people that self host to be able to easiely participate.
    • If a host doesn’t send in results for a platform after X number of runs, there should be alerting of some kind to make sure they know it isn’t working properly (it could be on purpose, it could be an accident).
  • Test Results Viewer/Reporter
    • When a test fails, or passes a certain threshold (multiple runners reporting failure, multiple failures in a row for a single result), there should be a notification to the #core channel on slack.
    • Developers should be able to quickly scan for test failures.  1) We should be able to see which commits triggered multiple failures.  We should also be able to see which configurations are unstable (maybe there are changes to the unit test or core code to improve stability).
    • Some UI/UX design will be needed.
  • Documentation on the test runner needs to be written
    • This will help make it easier for people to contribute.
  • Outreach to hosts
  • Infrastructure for hosting the test results receiver and test results viewer. This could be (would simplify the slack notifications and logins), or it could be donated by someone else.

I think the next step is for me to propose this as a formal feature project. If accepted, I’ll setup a chat in #core to go over what needs to be done and see if people are intrested in volunteering to work on specific pieces. Here is how I would describe it for the feature project proposal:

Problem:  The current automated testing infrastructure doesn’t test a realistic matrix of where WordPress sites are hosted. What would we learn if the test matrix matched the hosting matrix?

Action: Exploring and building an infrastructure for automated testing that relies upon those that host sites.

Uncategorized WordPress

The variable pieces of the WordPress Stack

Yesterday I shared a half backed idea about having hosts help more with automated testing for WordPress. Continuing that thread, there are a handful of things that need to be figured out.  The first of which is what are the pieces of the WordPress Stack that we need to track and are the real variables. Here is my initial list (along with tickets for many showing when WordPress has been bitten).

  • PHP Version (all the way down)
  • MySQL Version (or MySQL variant)
  • OpenSSL Version. ( #30434 showed that different versions of OpenSSL respond differently to the order that SSL Certificates are presented)
  • ImageMagick version.  #36501 demonstrates that we can have issues that only show up in certain versions of ImageMagick.
  • Curl version. [37430] demonstrates this necessity.
  • PHP Extensions installed. #36629

What else?  I’m sure there are things that I’m missing.  What variable in the WordPress hosting stack have you noticed cause a bug?

Uncategorized WordPress

WordPress Testing: Hosts Matter

So this is a half-baked idea. Well, maybe 3/4 baked since I’ve mentioned it to a few people.

Right now, Automated testing in WordPress is based on Travis CI.  Which works pretty well.  Tests are run on 1 OS vs 8 versions of PHP (plus hhvm, but those don’t pass) which based on my completely unscientific estimates covers less than 0.1% of the actual WordPress userbase.  If WordPress really wants to do quality automated testing, we need to rely on the people hosting sites to test vs their stack. To do that, Core needs to provide an infrastructure that both encourages and enables easy automated testing.

It’s not that the current test matrix is bad, but it currently is only covering a small corner of the true test matrix.

What I would like to see is an API that hosts (both shared and dedicated) could use to register their unique setups for automated testing. Using PUBSUBHUB,  WordPress Core would signal that a change has taken place.  Then, the hosts could run their setup(s) vs the new version of trunk.  They could run both a plain version of trunk, but also perhaps the version that includes everything they install as a part of a new site and whatever “one click installer” they use.

Between versions and configurations of OpenSSL, Imagemagick, PHP, MySQL, MariaDB, CURL, and the operating system I wouldn’t be surprised to find out that WordPress runs on well over 100,000 different stacks. The only way for the automated tests to cover that is if the community participates.


Uncategorized WordPress

What You Don’t See on my WordPress Profile Activity Tab

A lot goes on in WordPress Core development that doesn’t make it into the WordPress Profile Activity log. Here is a handful of the things I’ve worked on over the last month to give you an idea of what I have worked on. Many other contributors work on things that also don’t make it into the report, so it’s import to recognize that this screen is far from a good recognition of effort put into WordPress.  This isn’t an exhaustive list (I wish I could remember everything).

  • Organize the Field-Guide posts.
    • Work with each author to help make sure they know the importance of the posts
    • Review drafts to ensure the posts have quality information and wording is clear.
  • Organize sending the email to all plugin authors about 4.5. This is worked on by the Core, Plugins Repo, and Meta teams.
    • Work with Polyglots team to help publicize Global Translation Day.
    • Work to help measure the impact of this email (so we can see if there are ways to be more effective in the future)
    • Start documenting how this happens to reduce the bus factor
  • During releases, remind people to not share the link to packages
  • Provide some mentorship to a guest committer
  • Review the credits list before the release
  • Review News posts announcing release
  • Draft Release Haikus (This is one of my favorite contributions)
  • Help document release activities and steps (aka, the release checklist)
  • Work with the Forums team on the OMGWTFBBQ! post
  • Review and test patches for other committers to commit
  • Help brainstorm the About Page and the release tagline
  • Attend weekly dev chats and contribute during those
  • Early-stage discussions around ways to help make core better serve the readers and commenters
  • Participate in the first Feature Projects chat.
  • Test various parts of WordPress
  • Work to Recruit new contributors
  • Be a sounding board for ideas from other contributors

As anyone who has ever worked on a project at scale knows, coding is just a small piece of the puzzle. While the work of WordPress generally happens in the open, it doesn’t always get logged.

Uncategorized WordPress

Job Hunting Tips for WordPress Engineers

I decided to setup a Ask Me Anything repo on github, where people can ask me anything they want (go ahead, ask). The second question asked was about WordPress Jobs.  While the response was aimed at the asker, much of the advice is general.

Let’s step back for a second, what does it mean to be a WordPress Engineer? I personally don’t want to work with people that paint themselves into the corner of just knowing WordPress. I like T-shaped people. Have you worked on things other than WordPress? Your resume doesn’t list much else technical. Are you most comfortable in PHP, JavaScript, or something else? Have you done much (or any) systems/server work? Resumes are about helping you prepare the interviewer to ask you good questions.

When finding jobs (and deciding between jobs), The question I often asked is “How will this prepare me for the job I want after it?”. Make sure that the position is going to help you become qualified for a job you want that you aren’t qualified yet.

Read the full response.