Joshua Wold shares his thoughts / experience and lessons learned on contributing to WordPress as a non-developer.
What is Core contributing? Contributing to WordPress core as a non-developer can feel a little confusing. After 10 years of benefitting from the efforts of WordPress Core contributors, I was finally able to find a path toward giving back and making a meaningful impact.
WordPress is an Open Source project. It’s maintained by folks around the world who care about its future and believe in a product that can be used and tweaked to meet the needs of countless individuals and organizations.
The beautiful thing about WordPress is we can help make it better. We’ve previously written about ways you can contribute to WordPress.
Barriers to contributing
In the past I tried to find ways to contribute. I even created an account for Trac, a place where much of the discussion and management of the WordPress project occurs, and wrote my first ticket.
But I felt blocked from going further by:
Time – It didn’t make sense to try and figure out how to contribute to WordPress, since I didn’t have a great starting point. There was no obvious path for digging in.
Experience – While I have experience as a designer, I wasn’t sure how this could translate to working
Interesting read, from the lead devs of WordPress! Mad props for all the work you guys do. Keep setting the bar high for WordPress.
WordPress 4.9 hit the shelves last week meaning 29% of the web woke to a nicely wrapped package of code filled with improvements to the way they work with the Customizer, safer and clearer ways to work with code in the admin, and new and upgraded widgets. To peek behind the curtain (which is nicely transparent in our world of open source), we’ve asked Weston, Mel, and Jeff, Co and Deputy Leads on the 4.9 release, some questions about their experiences on the project and their thoughts for where WordPress is heading in 2018.
Q: So how does one find themselves leading a release that impacts 29% of the web?
Mel: With a great sense of responsibility and a bit of trepidation. The customization focus has been somewhat “on hold” while work on Gutenberg progresses, but there’s plenty of updates we can make while we wait. It made the most sense for Weston and I to co-lead 4.9, so we could concentrate on making some site customization improvements and lay some groundwork for Gutenberg in the future.
Weston: This year is somewhat different than previous years in how the WordPress project has been managed. This is the first year we’ve had dedicated focuses (Editor,
A major update focused on content editing within the Customizer.
We’re pleased to announce the v0.5 release of the Customize Posts plugin! Check out my rough release demo video: Key features in this release:
A framework for registering postmeta types, adding controls, and previewing changes.
Changes to the page template can now be previewed, both in the Customizer and from the edit page admin screen. The Customizer now opens when clicking “Preview Changes” to preview the page. Further edits can be made from the page template control in this Customizer page preview, and the changes get synced back to the page template dropdown in the page attributes metabox on the edit page screen.
Similarly to the page template, changes to the featured image can now be previewed where normally this is not possible in WordPress. The featured image selection on edit post screen has been improved to not update featured image in place, instead waiting until the post is saved before updating the featured image postmeta. The featured image can be set from the post edit screen and then previewed in the Customizer via the post Preview Changes button: the featured image can be further changed in the Customizer post preview, with
Ideas for improving workflow and encouraging more PHPUnit test writing.
We use Varying Vagrant Vagrants (VVV) as the development environment for as many projects as we can. It provides a great foundation not only for developing client projects but also for core development itself. One great thing about VVV is that it installs all of the tools needed to run the core unit tests right out of the box. Our wp-dev-lib project has a PHPUnit plugin bootstrap that makes use of the core unit tests as installed by VVV, and we have a pre-commit hook which can run the plugin PHPUnit tests inside the VM even when making a commit from outside (on the host machine). This ability to run PHPUnit tests inside the VM makes it easy for getting developers quickly set up to run PHPUnit tests, and it’s also something that is suggested for core’s PHPUnit Grunt task (#36190).
Tests running outside of the VM are a fast and happy place.
— Jeremy Felt (@jeremyfelt) March 10, 2016
Even though VVV lets you run core’s PHPUnit tests right out of the box, the tests can run more slowly in the box. If you have a pre-commit hook that runs unit tests with each commit, your workflow can be really slowed down (especially since the tests should eventually by run by Travis CI after
A guide to setting up the PHP interpreter and configuring PHPUnit settings.
PhpStorm has excellent out of the box support for running unit tests using the PHPUnit testing framework. It also provides you with great code coverage statistics of your unit tests. The challenge however is getting it setup properly and actually running your WordPress unit tests. On my local development environment, I specifically use VVV and ideally I wanted PhpStorm to run the tests from within the VVV virtual machine. Since PHP and PHPUnit are bundled with VVV, it makes sense to have PhpStorm utilise those libraries inside the virtual machine than for me to have to install the libraries independently on my Mac. I love having clear separation between my computer and development environments.
There is a downside to running your tests from inside a VVV virtual machine and that is that it can be a bit slower. This is because there is extra overhead involved with the communication over a SSH connection between your host machine and the guest/virtual machine. The virtual machine also does not have the same computing power as your host machine. The good news is that I’ve found that even though there is a slight reduction in speed, it’s fast enough that it’s not of concern to me.
Weston gives an overview of what's possible now with Customizer and explores the intersection with Gutenberg.
A couple days ago Helen Hou-Sandí live tweeted her first time trying out Gutenberg, the feature plugin for the next generation WordPress editor. One of her tweets stood out to me and started a thread: 36) I still wish there was a good way to preview featured images in different contexts. What will this look like in an archive vs. single?
So how can I understand how a featured image is going to look in all those contexts? How multiple changes look all together?
— Helen 侯-Sandí (@helenhousandi) August 2, 2017
tl;dr You can use the Customize Posts plugin to add and edit posts in the Customizer and preview your changes—to the title, excerpt, featured image, etc—on any area of your site where the post may appear. Here is a demo video that shows the plugin in action along with the Customize Snapshots and Customizer Browser History plugins in a child theme of Twenty Seventeen:
Framework for Previewing
The problem of post previewing is something I’m really interested in. Post previews in core don’t work for postmeta (like the featured image and page template) and you can’t preview changes on anything other than the singular template. Actually,
Weston Ruter offers his thoughts on the Customizer as a future frontend-focused admin interface.
A comprehensive write-up on the what, why, and how of Google's AMP.
AMP is an emerging technology that’s gaining the attention of online marketers in all fields. It formats content in a way that loads blazingly fast for mobile visitors, whose page load time expectations can be as little as three seconds. Abraham Lincoln has no patience for bad UX.
I recently worked with a client who wanted to improve their page load times by integrating the AMP project into their existing WordPress site. This was a great opportunity for me to expand my toolset, as well as learn something that I can now share with you.
Below you’ll find (perhaps too much) information to get you rolling with AMP, as well as many code samples to help you include AMP in your WordPress projects.
What is AMP?
AMP stands for “Accelerated Mobile Pages.” It is an Open Source project backed by Google that makes web pages load really, really fast. These pages are cached and served by Google itself, receive it’s “Mobile-friendly” label in search results, and can even increase Search PageRank for these pages.
After all of the advances that have been made over the last 25 years to give users a rich web experience, AMP takes a huge step backward toward
An introduction, overview, and preview of the Customize REST Resources plugin.
Jeff Paul, a deputy release lead for WordPress 4.7, offers a bunch of ideas for ways you can begin contributing to WordPress.
Me: Do you regularly use WordPress? You: Yes, I love it, it’s fantastic!
Me: Have you ever thought about helping contribute to WordPress?
You: No, I am not a developer.
Me: Well, good news, you do not have to be!
You: Ok, tell me more…
Whether you have considered it or not, I am so certain that you CAN contribute to WordPress that I will personally offer to help you find a way to do so. I will outline some options below, but feel free to reach out to me directly and I promise to help!
But first, a little background on me…
I graduated from college in 2001 with a degree in Computer Science, but have not spent any significant time coding since then. I have held roles in project management, product management, and team and customer management. The way I tell it, no one would realistically hire me these days to do development. And yet, there has been a fantastic opportunity for me to help contribute to WordPress as a deputy release lead on WordPress 4.7. While this was a significant time commitment for me, there are ways you can contribute with minimal time commitment.
Now let us focus on how you could contribute…
I am going to give you some options to describe
XML-RPC is now enabled for all Trac users, per Dev Chat Notes: June 29, 2016.
In Contributing to WordPress Core via GitHub, I detailed the somewhat-tedious workflow that I’ve been using for developing and collaborating on patches that get manually uploaded to Trac. Now that the topic of using GitHub for Core contributions is again up for discussion at the WordPress Community Summit, I wanted to jot down some ideas for how to automate the workflow I’ve been using; I’ll be looking specifically at what a streamlined workflow for contributions looks like via a GitHub fork of the WordPress repo managed by a component maintainer, such as our XWP clone. (For how to set up a GitHub clone of develop.git.wordpress.org, see my previous post.) Caveat: This is intended for users in trusted contributor teams as it requires the user to open an internal (intra-repo) pull request from feature branch to master. It will not work when opening a pull request from a fork due to Travis CI’s security restrictions on environment variables. So any pull requests from external contributors will need to be manually applied to a feature branch by a repo contributor and then open an intra-repo pull request (while closing the original inter-repo pull request).