Introducing GitHub Actions for Automated Testing

As of [49162], CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. is now running automated tests using GitHubGitHub GitHub is a website that offers online implementation of git repositories that can can easily be shared, copied and modified by other developers. Public repositories are free to host, private repositories require a paid subscription. GitHub introduced the concept of the ‘pull request’ where code changes done in branches by contributors can be reviewed and discussed before being merged be the repository owner. https://github.com/ Actions as a runner, in addition to the existing Travis CI and Appveyor runs. This post is to publicize the change, document the reasoning, communicate next steps, and share how people contributing to WordPress Core will benefit.

GitHub Actions allows us to automate software workflows directly in GitHub, triggered by GitHub events. By switching, we are able to take advantage of a unified interface, inline annotations for linting issues in pull requests, the broader open sourceOpen Source Open Source denotes software for which the original source code is made freely available and may be redistributed and modified. Open Source **must be** delivered via a licensing model, see GPL. ecosystem building and using Actions including existing work in Gutenberg, and free availability for public repositories. Note that private repositories do use the monthly bucket of included minutes.

For contributors, this continues to refine the experience of working on Trac tickets using GitHub pull requests, most notably by showing linting errors inline in the diff view of the PR (known as annotations). This also consolidates external tooling into one place. If you have not already, please take a moment to associate your GitHub account with your WordPress.org profile.

Screenshot of inline annotation examples

These 6 workflows cover all current testing and analysis performed in Travis CI and Appveyor:

There is also an additional 7th workflow that is meant to leave a welcome message when it’s the contributor’s first pull request, letting them know how we use GitHub pull requests and how to link them to a TracTrac An open source project by Edgewall Software that serves as a bug tracker and project management tool for WordPress. ticketticket Created for both bug reports and feature development on the bug tracker.. There appears to be an issue concerning permissioning when PRs are sent from forks, so this is pending.

Currently, Travis CI and Appveyor will continue to run for a transition period (ending TBD) to allow for any issues to be ironed out, and so that real-world usage data can be collected. So far, even in early testing, runs appear to be completing more quickly and with fewer/no false negatives, e.g. when Travis CI does not see the commit in the mirror yet. @desrosj will be collating run data in a spreadsheet, including but not limited to: overall build time, run time comparison (where 1:1 comparisons can be made), and frequency of false negatives.

Known next steps

  • Add and configure SlackSlack Slack is a Collaborative Group Chat Platform https://slack.com/. The WordPress community has its own Slack Channel at https://make.wordpress.org/chat/. notifications. In addition to sending the results of the whole build of a core commit into #core, we may also want to consider a firehose channel for PRs.
  • Move to GitHub badges for build status indicators – note that these are per-workflow, which is different from the single badge for the entire Travis build for a given commit. However, GitHub does report an overall status for a commit/PR, so we may be able to use that information as well.
  • Report test results to the Host Test Results page.
  • Switch to ESLint from JSHint, as the latter does not appear to easily support inline annotations, and the former is in broader usage including in core for docs, GutenbergGutenberg The Gutenberg project is the new Editor Interface for WordPress. The editor improves the process and experience of creating new content, making writing rich content much simpler. It uses ‘blocks’ to add richness rather than shortcodes, custom HTML etc. https://wordpress.org/gutenberg/ and many community projects. See #31823 for more – volunteers very much appreciated here.
  • Backportbackport A port is when code from one branch (or trunk) is merged into another branch or trunk. Some changes in WordPress point releases are the result of backporting code from trunk to the release branch. the workflow files to actively maintained older branches.

As always, please report any issues you are seeing with our GitHub Actions, as well as further ideas for use you may have. Major thanks to @desrosj for all the heavy lifting he’s done in just a couple of weeks, and to @ocean90 and @ayeshrajans for their help along the way.

#5-6, #build-tools, #unit-tests

PHP related improvements & changes: WordPress 5.5 edition

As part of an ongoing effort to improve compatibility across all supported versions of PHPPHP The web scripting language in which WordPress is primarily architected. WordPress requires PHP 5.6.20 (currently 5.6.20–7.4), several tooling additions and improvements have been made during the 5.5 cycle.

A large handful of changes were made to address the findings from these tools. Below are some that you need to be aware of.

Automated PHP compatibility scanning

During the WordPress 5.3 cycle, a new job was added to Core’s Travis-CI builds to scan for potential PHP compatibility issues using the PHPCompatibilityWP PHPCS ruleset (see #46152). However, because the scan was reporting a large number of potential issues, it was placed in the allowed_failures list until each issue could be inspected and addressed.

During the 5.5 cycle, each potential issue was examined individually and either fixed, or manually marked as a false-positive.

As of [48046], the job performing a PHP compatibility scan has been removed from the allowed_failures list. 🎉

Now that this scan is not allowed to produce errors or warnings, potential PHP incompatibilities can be flagged and inspected immediately after being committed, ensuring they are never released to the world in WordPress.

In the future when the versions of PHP supported by WordPress change (in either direction), the configuration file can easily be adjusted to detect potential problems within the new range of supported versions.

For more information, see the related ticketticket Created for both bug reports and feature development on the bug tracker. on TracTrac An open source project by Edgewall Software that serves as a bug tracker and project management tool for WordPress. (#49922).

Deprecated: wp_unregister_GLOBALS()

The register_globals directive in PHP was deprecated in version 5.3 and removed entirely in 5.4. Because the first line of the function calls ini_get() (which returns false if the directive is not recognized), this function will always return early making it unnecessary.

The wp_unregister_GLOBALS() function is deprecated as of WordPress 5.5.

For more information, see the related ticket on Trac (#49938).

Deprecated: $HTTP_RAW_POST_DATA

The $HTTP_RAW_POST_DATA global variable was deprecated in PHP 5.6.0 and removed completely in PHP 7.0.0. Because of this, developers should not be relying the presence or accuracy of this variable. However, a search of the plugin directory for this variable still yields ~1,500 results. Although some of these matches are flagging $HTTP_RAW_POST_DATA within comments or in compatibility shims, developers should audit their code to remove this variable whenever possible.

Because PHP 5.6 is still supported and this variable is present in a large number of plugins, it will not be completely removed in WordPress 5.5. However, it will be removed from CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. when the supported versions of PHP is changed to PHP >= 7.0.

The following is the recommended replacement:

$var = file_get_contents( 'php://input' );

A few occurrences of this variable that did not affect the outcome of the code have been removed in 5.5. However, there are 2 instances that will remain because they were deemed particularly risky to remove before communicating the bad practice to the community.

  • xmplrpc.php (source)
  • wp-includes/rest-api/class-wp-rest-server.php (source)

For more information, refer to the related ticket on Trac (#49810).

Spread operator usage in the IXR library

In WordPress 5.3, the PHP spread operator was introduced throughout the code base. There are several benefits to utilizing the spread operator in addition to code modernization:

“Using the spread operator allowed for simplifying the code and improves performance – both in speed as well as memory use -, especially as it has been introduced in a number of functions which are used a multitude of times during every single pageload…”

WP 5.3: Introducing the spread operator by @jrf

The IXR library bundled with Core (now treated as an “adopted” library) powers XML-RPC related functionality in WordPress.

All func_get_args() calls within the IXR library’s code have now been updated to utilize the spread operator.

For more information, refer to the Trac ticket (#48267), the WP 5.3: Introducing the spread operator dev notedev note Each important change in WordPress Core is documented in a developers note, (usually called dev note). Good dev notes generally include: a description of the change; the decision that led to this change a description of how developers are supposed to work with that change. Dev notes are published on Make/Core blog during the beta phase of WordPress release cycle. Publishing dev notes is particularly important when plugin/theme authors and WordPress developers need to be aware of those changes.In general, all dev notes are compiled into a Field Guide at the beginning of the release candidate phase., or the Trac ticket that originally introduced the spread operator to Core (#47678).

Installing PHPUnit with Composer

Getting a local environment up and running for contributing to WordPress Core can sometimes be difficult, especially when running the PHPUnit test suite is desired. Different combinations of WordPress and PHP versions require different versions of PHPUnit.

Composer is a tool for dependency management in PHP. When project dependencies are specified, it will manage installing and updating those dependencies for you appropriately.

As of [47881], PHPUnit is now defined as a dev requirement in WordPress Core’s composer.json file.

Running composer install will determine the appropriate version of PHPUnit to install based on the PHP version Composer runs on.

For more information, refer to the Trac ticket (#46815).

Other Build/Test Tool improvements

  • Plugins and themes within src are now ignored when running Core linting locally. This will prevent coding standards violations from being flagged when developing locally using src instead of build (see #49781).
  • Previously, when the lint:php job ran on Travis-CI, the code was formatted using PHPCBF prior to linting. Since running composer format returns an error when changes are made, the linting part would not execute and a report would not be generated. Core will no longer run the formatting command prior to linting the code base for issues (see #49722).
  • The WordPress Coding Standards ruleset has been updated from version 2.1.1 to 2.3.0. For a full list of changes included in this update, read ruleset’s release notes (see #50258).
  • The recommended version of PHP specified in the readme.html file has been changed from 7.3 to 7.4. This brings the recommendation in line with the recommendations found on WordPress.org (see #50480)

Props @earnjam for review.

#5-5, #build-tools, #dev-notes, #php

Build tools: We’ve enabled running WordPress from /src again

In May 2018 we’ve introduced a build step to WordPress coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. development as preparation to WordPress 5.0. While these changes never ended up in 5.0, the idea was to reorganize the way the JavaScript in WordPress is managed and structured so that it would be easier to include GutenbergGutenberg The Gutenberg project is the new Editor Interface for WordPress. The editor improves the process and experience of creating new content, making writing rich content much simpler. It uses ‘blocks’ to add richness rather than shortcodes, custom HTML etc. https://wordpress.org/gutenberg/.

Since then, it was no longer possible to run WordPress from the src folder. This gave some issues, especially with developing WordPress core PHPPHP The web scripting language in which WordPress is primarily architected. WordPress requires PHP 5.6.20. Today, @atimmer committed a patchpatch A special text file that describes changes to code, by identifying the files and lines which are added, removed, and altered. It may also be referred to as a diff. A patch can be applied to a codebase for testing. which allows developers to build into src again.

Developers can now run grunt build --dev to build the JavaScriptJavaScript JavaScript or JS is an object-oriented computer programming language commonly used to create interactive effects within web browsers. WordPress makes extensive use of JS for a better user experience. While PHP is executed on the server, JS executes within a user’s browser. https://www.javascript.com/. and CSSCSS Cascading Style Sheets. into src and use grunt watch --dev to automatically rebuild JavaScript and CSS files when their source is changed.

Advantages

The biggest advantage of running WordPress from src is that changes in the PHP are immediately reflected on the server again, without an extra build step. If you are only making PHP changes, then you can now build the JSJS JavaScript, a web scripting language typically executed in the browser. Often used for advanced user interfaces and behaviors. and CSS once using grunt build --dev and continue coding PHP like you were used to.

Backwards compatibility

This change is fully backwards compatible with the previous setup. grunt build without the --dev flag still works exactly the same. No setups based on it should break.

Up next: Use Webpack to build all JavaScript and CSS

There’s an effort going on to move all JavaScript and CSS build logic into the Webpack configuration. Work done on this so far promises to reduce build times significantly. Especially rebuilds triggered by grunt watch should become much faster. Relevant ticketticket Created for both bug reports and feature development on the bug tracker.: Use Webpack + NPM scripts to build all the things.

#build-tools, #grunt

Core Build/Test tools chat

I’ll be hosting a chat for Build and Test tools on Wednesday, October 8, 2014 2:00am UTC . The goal will be to triagetriage The act of evaluating and sorting bug reports, in order to decide priority, severity, and other factors. and discuss the existing tickets along with identifying enhancements, new initiatives, and other improvements.

Please comment below if you have any suggested build/test improvements that are not currently in a ticketticket Created for both bug reports and feature development on the bug tracker..

Note, that this may not be the permanent time for Build/Test tool chats. I know it isn’t ideal for everyone (especially Europe).

#build-tools

Finding and Fixing JavaScript errors with JSHint

The JavaScript Coding Standards have been updated, so it’s time to move on to tackling our JSHint errors!

JSHint is a tool to check for errors in JavaScriptJavaScript JavaScript or JS is an object-oriented computer programming language commonly used to create interactive effects within web browsers. WordPress makes extensive use of JS for a better user experience. While PHP is executed on the server, JS executes within a user’s browser. https://www.javascript.com/. code. As was discussed last week, we’re kicking off a small effort to work through our coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. JavaScript files. To get through the errors revealed by JSHint as quickly as possible, we’re following the model established by the Inline Docsinline docs (phpdoc, docblock, xref) team and posting a list of files with issues so that people can “claim” the files they’d like to fix!

At the bottom is a list of every file in core that is displaying JSHint errors. Files with a checkmark have been patched and should now be passing lint. Files marked with (@username #xxxxx) are already claimed, and being worked on.

Please read and understand the process we’ll be following to address these issues! Many thanks to @azaozz, @nacin and @jorbin for helping identify the safest way to approach fixing these errors, and to @rzen for posting the Inline Docs article on which we based this guide.

How to contribute:

  1. Leave a comment on this post with the file* you’re about to edit (check the list first to make sure it hasn’t already been claimed).
  2. Update your local WordPress SVN to the latest version of WordPress trunktrunk A directory in Subversion containing the latest development code in preparation for the next major release cycle. If you are running "trunk", then you are on the latest revision. (currently 3.8-alpha).
  3. Create a new ticket on Trac for the file.
    JSHint-related trac ticket settings
    • Format the title as “jshint shouldn’t throw errors – path/to/file.js”.
    • Assign the ticketticket Created for both bug reports and feature development on the bug tracker. to the “Build Tools” component.
    • Make sure your email is stored in TracTrac An open source project by Edgewall Software that serves as a bug tracker and project management tool for WordPress.’s preferences

    If you are logged in, you can click this link to automatically open a ticket with the right settings.

  4. Edit the file, and make a patchpatch A special text file that describes changes to code, by identifying the files and lines which are added, removed, and altered. It may also be referred to as a diff. A patch can be applied to a codebase for testing.. Please make sure you create the patch from the root directory of your WordPress SVNSVN Subversion, the popular version control system (VCS) by the Apache project, used by WordPress to manage changes to its codebase. checkout. If you are working on a large file, consider making multiple patches for each type of change.
  5. Upload your patch to the Trac ticket you created, and add the keyword “has-patch”.

*Note: We strongly encourage you to work on one file at a time. These shouldn’t take very long, but if you call a bunch at once and get tied up, we won’t be able to get through these as quickly as possible. To quote @rzen from the inline docs effort, “your edits should be made and patched swiftly so that they aren’t invalidated by (or don’t invalidate) another patch.”

Keeping Discussions Focused:

Any discussion about the specifics of a patch itself should happen on Trac. Discussion about the overall effort should take place during our standing weekly meeting, on Wednesdays at 1900 UTC in #wordpress-dev*.

Files needing patches:

Checked files are now passing JSHint

  • wp-adminadmin (and super admin)/js/common.js (@jorbin, #25912)
  • wp-admin/js/custom-background.js (@jorbin, #25915)
  • wp-admin/js/custom-header.js (@jorbin, #25916)
  • wp-admin/js/customize-controls.js (@jorbin, #25917)
  • wp-admin/js/dashboard.js (@tommcfarlin, #25943) (@nacin)
  • wp-admin/js/edit-comments.js (@adamsilverstein, #25979)
  • wp-admin/js/editor.js (@dougwollison, #25947) (@nacin)
  • wp-admin/js/gallery.js (@dougwollison, #25999) (@jorbin)
  • wp-admin/js/image-edit.js ( #26000)
  • wp-admin/js/inline-edit-post.js ( #26001) (@jorbin)
  • wp-admin/js/inline-edit-tax.js ( #26002) (@jorbin)
  • wp-admin/js/link.js ( #26034)
  • wp-admin/js/media-gallery.js (@tommcfarlin, #25942) (@nacin)
  • wp-admin/js/media-upload.js ( #26023)
  • wp-admin/js/media.js ( #26020)
  • wp-admin/js/nav-menu.js (51 errors)
  • wp-admin/js/password-strength-meter.js ( #25990)
  • wp-admin/js/pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party-install.js ( #25993)
  • wp-admin/js/post.js ( #25994)
  • wp-admin/js/postbox.js (10 errors)
  • wp-admin/js/revisions.js ( #25864)
  • wp-admin/js/set-post-thumbnail.js ( #26008)
  • wp-admin/js/tags.js ( #26009)
  • wp-admin/js/theme-install.js (@kovshenin, #26045) (@nacin)
  • wp-admin/js/theme-preview.js (@tommcfarlin, #25944) (@nacin)
  • wp-admin/js/theme.js (22 errors) (@nacin)
  • wp-admin/js/user-profile.js ( #26016) (@jorbin)
  • wp-admin/js/user-suggest.js ( #26017) (@jorbin)
  • wp-admin/js/word-count.js ( #26018) (@nacin)
  • wp-admin/js/wp-fullscreen.js ( #26029)
  • wp-admin/js/xfn.js ( #25997)
  • wp-content/themes/twentyfourteen/js/functions.js ( #26031) (@jorbin)
  • wp-content/themes/twentyfourteen/js/slider.js ( #26032) (@jorbin)
  • wp-includes/js/admin-bar.js (@kadamwhite, #25970)
  • wp-includes/js/autosave.js ( #26035)
  • wp-includes/js/comment-reply.js ( #26038)
  • wp-includes/js/customize-base.js ( #26039)
  • wp-includes/js/customize-loader.js ( #26040)
  • wp-includes/js/customize-preview.js ( #26019)
  • wp-includes/js/heartbeat.js ( #25986)
  • wp-includes/js/jquery/jquery.table-hotkeys.js ( #26015)
  • wp-includes/js/media-editor.js ( #26022)
  • wp-includes/js/media-models.js (@kadamwhite, #26132)
  • wp-includes/js/media-views.js (@kadamwhite, #25974)
  • wp-includes/js/mediaelement/wp-mediaelement.js (3 errors)
  • wp-includes/js/plupload/handlers.js ( #26041)
  • wp-includes/js/plupload/wp-plupload.js (@atimmer, #26044)
  • wp-includes/js/quicktags.js (@kovshenin, #26046)
  • wp-includes/js/shortcode.js (@tommcfarlin, #25945) (@nacin)
  • wp-includes/js/tinymce/mark_loaded_src.js ( #26014)
  • wp-includes/js/tinymce/plugins/wordpress/editor_plugin_src.js ( #26048)
  • wp-includes/js/tinymce/plugins/wpdialogs/editor_plugin_src.js ( #26048)
  • wp-includes/js/tinymce/plugins/wpeditimage/editor_plugin_src.js ( #26048)
  • wp-includes/js/tinymce/plugins/wpfullscreen/editor_plugin_src.js ( #26048)
  • wp-includes/js/tinymce/plugins/wpgallery/editor_plugin_src.js ( #26048)
  • wp-includes/js/tinymce/plugins/wplink/editor_plugin_src.js ( #26024)
  • wp-includes/js/tinymce/plugins/wpview/editor_plugin_src.js ( #26027)
  • wp-includes/js/utils.js (@adamsilverstein, #25957)
  • wp-includes/js/wp-ajax-response.js (@originalexe, #25954)
  • wp-includes/js/wp-auth-check.js ( #26009)
  • wp-includes/js/wp-list-revisions.js (#25864)
  • wp-includes/js/wp-lists.js ( #26012)
  • wp-includes/js/wp-pointer.js ( #26012)
  • wp-includes/js/wp-util.js ( #25957)
  • wp-includes/js/wplink.js (@jorbin, #25914)

See all open tickets in the Build Tools component

For tips on dealing with global variables, inlined third-party code within first-party scripts, etc, see the JSHint tips in the JavaScript Coding Standards

For the curious, this list was created with a jazzy little command @nacin came up with to pipe Grunt output through ack:

grunt jshint --force | ack '^Linting src/' | ack -o 'wp-.*.js' | sort | uniq -c | sort

What we’re NOT doing

The two JSHint options called out in the earlier post, “curly” and “eqeqeq,” would ordinarily make up the vast majority of the errors JSHint reports in our files. We’ve currently set Grunt and JSHint to ignore these two types of errors when JSHint is run against core. While these are best practices, we’ll come back to them once we address the more significant code smell issues like undefined variables.

Also note that we’re not tackling whitespace or non-JSHint-related refactoring during this effort. We’ll get there, but we have to mitigate the risk to core as much as possible so we don’t interrupt the 3.8 cycle. Keep your changes focused on passing JSHint this go-around.

#build-tools, #javascript, #jshint