In a new post to his site Sammy Kaye Powers shows you how to test unreleased features of PHP using a pull request related to a RFC that's officially been proposed.

We'll be discovering and testing a completely unreleased feature of php-src from an RFC that's still under discussion.

If you've ever wanted to be ahead of the curve of PHP features or you've just wanted to contribute back to PHP internals, testing an unreleased feature from an RFC is a fun and educational way to do so.

He uses the typed properties RFC in his example (allowing the addition of types to class properties). He then walks through the checkout of the PHP source, grabbing the pull request for the RFC and compiling PHP with the new code in place. He shows an example of a script that makes use of this new feature and tries it out. Finally, he covers how to run tests on this new version and some suggestions on adding typed properties to real-world projects.

In a post to his site Freek van Der Herten shares some functionality that Spatie uses to help keep the stale pull requests under control across their 180+ repositories: a Botman-based bot that assesses the last updated date and closes after a given amount of time.

At Spatie we have over 180 public repositories. Some of our packages have become quite popular. We're very grateful that many of our users open up issues and PRs to ask questions, notify us of problems and try to solve those problems, ...

Most of these issues and PRs are handled by our team. But sometimes those issues and PRs become stale. [...] That's why we created a bot that can automatically close stale issues and PRs. Here's [an example] of the bot in action.

He then shares the code they currently use for the bot, making use of the BotMan package as a base and the knp-labs/github-api package for the GitHub interaction. The code includes the GitHub service provider, a client class, an Issue object and the command that's run to find and close out the stale pull requests and issues.

As is mentioned by the Laravel News site and announced on the GitHub blog, repositories that have PHP have a new feature - introspection showing what methods and functions have changed in pull requests.

The file finder makes it easy to review pull requests and understand how changes impact your code. Now PHP developers can navigate to changed methods and functions right in their pull requests, too.

Searching the file finder for the term function or the name of a changed function in a PHP file will provide you with a filtered view of the results, so you can easily identify and view the most impactful parts of a pull request. Check out the documentation to learn more.

An animation in the post shows the feature at work, making use of the "Jump to" menu to show a drop-down listing of all files changed and the methods changed inside them. These can then be used to jump to parts of the pull request (rather than having to search through the entire thing for changes).

On the SitePoint PHP blog editor Bruno Skvorc has posted a tutorial showing how to combine Git and WordPress to make it easier to update posts on the site via pull requests.

At Bitfalls.com, we also use WordPress for now, and use the same peer review approach for content as we do at SitePoint.

We decided to build a tool which automatically pulls content from merged pull requests into articles, giving us the ability to fix typos and update posts from Github, and see the changes reflected on the live site. This tutorial will walk you through the creation of this tool, so you can start using it for your own WordPress site, or build your own version.

He starts by outlining the plan for the process including some of the functionality that will be put to use - like WPGlobus and Markdown files. He then walks you through the creation of an environment for the end WordPress installation (for testing), creates the webhook on the GitHub side to handle the push and the code needed to grab the content and push it into WordPress. He also includes an example of the workflow, showing a PR being created and merged to ensure the flow is functioning as expected.

Sammy Powers has a new post to his site today showing you how to find and patch a bug in php-src, the source of the PHP language itself.

While he does provide all of the details in the post he also has created a screencast that walks you through the whole process as well. He breaks up the process into the different steps of the process:

• Find the bug (his was with the JSON handling)
• Submit a bug report (on bugs.php.net)
• Make a patch
• Run GDB
• Make a test
• Submit a PR and update the bug

He includes code and descriptions along the way and finishes out with further suggestions about feedback on the PR and how his own situation finished out.

On the AWS Developer blog they've posted about a new update in their PHP SDK functionality: a "changelog builder" that helps with automated changelog generation.

Starting with version 3.22.10 of the AWS SDK for PHP, released February 23, 2017, the Changelog Builder automatically processes all changelog entries. Each pull request is required to have a changelog JSON blob as part of the request. The system also calculates the next version for the SDK based on the type of the changes that are defined in the given changelog JSON blob.

The update simplifies the process of adding release notes to the CHANGELOG.md file for each pull request. Each merged pull request that was part of the release results in a new entry to the CHANGELOG.md file. The entry describes the change and provides the TAG number and release date.

This changelog is generated from a required JSON document for each pull request that provides information about the type of change, category and a brief description. They explain each of these items to give a little more context as to what they should contain along with a few examples.

This is something that could definitely help to improve other libraries as well, gathering the required change information from the contributor rather than having a project administrator have to sift through the PR to locate all changes.

Sammy Kaye Powers has posted the latest parts in his series looking at testing the PHP language with phpt tests. So far he's helped you compile PHP from source, run the test suite, learn about the phpt files and debug failing tests. He continues the series with two new posts:

• 05: Finding untested code
• 06: Submitting a PR to php-src

In the 5th part of his series he shows how to use the PHP gcov site to locate lines of code in the PHP language core that aren't tested yet, how to create a new test to cover it and generating a code coverage report to see how much you've tested. In Part 6 he shows you how to take what you've created and submit it back to the PHP project on GitHub as a Pull Request (no RFC needed) based on changes from your own forked repository.

On the Laravel News site there's a post talking about a holiday-themed project, 24 Pull Requests, and a bit of personal perspective about it from a participant, Joe Ferguson (of LaraTraining.com).

24 Pull Requests is a project to promote open source collaboration during the month of December. The idea is to “Send 24 pull requests between December 1st and December 24th,” and it encourages developers to give back to open source with little gifts of code.

This is the fourth year and there are currently 11,093 developers and 10,201 organizations participating. If you are new to open source or are a seasoned pro it’s a great way of supporting the community.

The remainder of the post is the interview with Joe sharing answers to questions about:

• why he decided to start participating
• how it has improved his skills
• what his biggest take away from participation is

There's plenty of links and suggestions in the post too helping you get started on your own road to 24PullRequests this month.

If you've ever contributed to an Open Source project on GitHub (or really even just used Git in general) chances are there's been a time when you needed to rebase your branch with what's on master. It can be a bit confusing to Rob Allen is here to help with this brief guide to walk you through the steps for a successful rebase.

You've successfully created a PR and it's in the queue to be merged. A maintainer looks at the code and asks you to rebase your PR so that they can merge it. Say what?

The maintainer means that there have been other code changes on the project since you branched which means that your branch cannot be merged without conflicts and they would like to you to sort this out. These are the steps you should take.

He breaks it down into three main steps and includes the commands you'll need and how to push the result back up into the waiting repository:

• Update your target branch from upstream
• Rebase your branch
• Push your newly rebased branch to origin

There's really about six steps involved but that's only when you break it down to the individual commands. It's a relatively simple process that, while a bit confusing from the outside, can be very helpful to a project maintainer when it comes merge time.

The development group behind the Laravel framework have introduced a new tool that aims to make it easier to report bugs with the framework (not the applications built with them): Laravel Liferaft.

To encourage active collaboration, Laravel currently only accepts pull requests, not bug reports. "Bug reports" may be sent in the form of a pull request containing a failing unit test. [...] A failing unit test or sandbox application provides the development team "proof" that the bug exists, and, after the development team addresses the bug, serves as a reliable indicator that the bug remains fixed.

Following along with this method, Liferaft provides a simple way to download a clean copy of the framework, make the needed changes for the pull request and automatically submit it via GitHub back to the project for handling. In this video on Laracasts Taylor Otwell walks you through a simple example of using it to submit an issue back (and what happens behind the scenes).