Performance Lab

The Performance Lab plugin is a collection of “feature projects” for WordPress coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. that aim to improve performance in WordPress. These projects (known as “modules” in the 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) are intended to eventually be merged into WordPress core. As such, Performance Lab is considered a betaBeta A pre-release of software that is given out to a large group of users to trial under real conditions. Beta versions have gone through alpha testing in-house and are generally fairly close in look, feel and function to the final product; however, design changes often occur as part of the process. testing plugin.

More details about the plugin are available in this blog post.

Getting started

Top ↑

Prerequisites

Top ↑

Set up the development environment

1. Install and configure the prerequisites noted above

2. Clone the repository

Start by cloning the repository into your local machine using this command:

git clone https://github.com/WordPress/performance.git

3. Install local development dependencies

Then, install local development dependencies by first running composer install followed by npm install in the project folder.

4. Start the local WordPress environment

Run npm run wp-env start to start the WordPress environment. The WordPress development siteDevelopment Site You can keep a copy of your live site in a separate environment. Maintaining a development site is a good practice that can let you make any changes and test them without affecting the live/production environment. will be available at http://localhost:8888 and WP admin will be available at http://localhost:8888/wp-admin/. You can log in to the admin using the username admin and password password.

Top ↑

Useful commands

  • npm install: Installs local development dependencies
  • npm run wp-env start: Starts the local development environment
  • npm run wp-env stop: Stops the local development environment
  • npm run lint-php: Lints all PHPPHP PHP (recursive acronym for PHP: Hypertext Preprocessor) is a widely-used open source general-purpose scripting language that is especially suited for web development and can be embedded into HTML. http://php.net/manual/en/intro-whatis.php. code (run after adding new code to the repository)
  • npm run format-php: Formats all PHP code (run after adding new code to the repository)
  • npm run test-php: Runs PHPUnit tests for all PHP code
  • npm run test-php-multisite: Runs PHPUnit tests in multisiteMultisite Multisite is a WordPress feature which allows users to create a network of sites on a single WordPress installation. Available since WordPress version 3.0, Multisite is a continuation of WPMU or WordPress Multiuser project. WordPress MultiUser project was discontinued and its features were included into WordPress core.https://codex.wordpress.org/Create_A_Network. for all PHP code

Top ↑

GitHub workflow

We use GitHubGitHub GitHub is a website that offers online implementation of git repositories that 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/ to manage all code and related discussions for the Performance Lab plugin. Please follow the workflow below to ensure that all issues are properly tracked.

Top ↑

Issues

When opening a new issue, use the appropriate template: Bug report, Feature request, New module proposal, or Report a security vulnerability. All new issues should include the following labels:

  • A [Focus] label, or Infrastructure if the issue relates to the plugin infrastructure. The [Focus] labels are aligned with the Performance Team’s focus areas and GitHub Projects.
  • A [Type] label
  • A [Module] label if the issue relates to an existing module
  • OPTIONAL: A [Milestone]. Use your best judgment here – if it’s a smaller issue and we’re early in the release cycle, it can be assigned to the next release milestone. If it’s a large issue and we’re only a week out from the release, it should not be assigned to the next milestone, but the one after.

In addition, the new issue should be assigned to an appropriate Project. By default, new issues will automatically be added to the Backlog column within its project. This is intended for tracking any future work that is not currently a high priority as defined by the project’s point(s) of contact (POCs). Contributors are welcome to work on issues in the Backlog, but response rates may be slower than they are on prioritized issues.

Top ↑

Working on an issue

If you’re interested in working on an issue, it’s helpful to notify the POC for the issue’s focus area by tagging them on the issue and/or notifying them in the weekly performance chat so that everyone is aware that someone is working on it and effort is not duplicated. For an updated list of POCs, please see the CODEOWNERS file.

When you’re ready to begin work on an issue:

  • Assign it to yourself – Depending on your permissions levels, you may not be able to self-assign an issue. Please tag @WordPress/performance-admins on an issue if you need assistance with permissions. Please only assign an issue if you plan to work on it within a reasonable time frame, i.e. within the next 2 weeks.
  • Change the Project column to In Progress
  • Remove the Needs Dev label, if applicable

In addition, there are several Needs labels that can be used to clarify next steps on an issue.

Needs Discussion

Many issues require discussion and definition before development begins. For example, multiple approaches may be considered and the community should discuss them before a contributor proceeds with development. For those issues, add the Needs Discussion label and raise the issue in the weekly performance chat.

Needs Decision

After discussion, a formal vote may be needed to determine how to proceed. If that’s the case, please tag @WordPress/performance-admins in the issue for assistance with setting up a vote via GitHub comment. An example vote can be found here.

Needs Dev

If an issue requires (more) development and you are unable to complete it yourself, remove yourself as the assignee and add a Needs Dev label.

Needs Triage

If you believe you may have discovered a possible bug or have an engineering-related question about the plugin, add the Needs Triage label.

Needs Testing

If you have completed initial engineering and want community members to test prior to merge, add the Needs Testing label.

Top ↑

Pull requests

Top ↑

Coding standards

In general, all code must follow the WordPress Coding Standards and best practices. For complete documentation about Performance Lab plugin modules specifications, please see the Writing a module section below. 

For details about WordPress and PHP version requirements, please see the CONTRIBUTING.md file.

Top ↑

Branch name

Before opening a pull request, create a new branch for your suggested changes. This branch can use almost any name, although it is recommended to include a reference to the issue number in it. Please avoid prefixing your branch with feature/ or release/ as those are reserved names for special protected branches in the Performance Lab plugin. If you use one of those names, you will not be able to push code to the branch directly.

Top ↑

Pull request requirements

All pull requests must:

  • Be associated with an issue
  • Have [Type] and [Focus] label matching the related issue’s [Type] and [Focus] labels
  • Have either an assigned milestone or the no milestone label. Milestones should be assigned based upon the complexity of the PR as well as how close we are to the due date of the next milestone. Use your best judgment here – if it’s a smaller PR and we’re early in the release cycle, it can be assigned to the next release milestone. If it’s a large PR and we’re only a week out from the release, it should not be assigned to the next milestone, but the one after. NOTE: PRs that have zero effect on the plugin end-user (e.g. documentation changes, engineering tooling, anything that doesn’t require a changelog) do not need a milestone, and should instead receive the no milestone label.

When a PR for an issue is ready for review:

  • Change the Project column on the issue to Review
  • Add the Needs Review label to the issue

Reviewers will be auto-assigned based upon the issue’s assigned Project. Note that all PRs require at least two reviewers.

Top ↑

Trac tickets

Trac is the system used to track issues related to WordPress core. There is a performance label in Trac that has been added to over 300 issues dating back nearly 15 years.

While the Performance Team’s focus is on the work in the GitHub repo, the community is welcome to consult with the Team on performance-related TracTrac Trac is the place where contributors create issues for bugs or feature requests much like GitHub.https://core.trac.wordpress.org/. tickets. There may also be tickets in Trac that are duplicates of planned work in the GitHub repo, or warrant further discussion for inclusion in the plugin.

Top ↑

POC responsibilities

Each focus area has a set one or more assigned points of contact (POCs), as defined in the CODEOWNERS file. POCs are expected to:

  • Monitor new issues to ensure that new issues are appropriately designated to their focus area
  • Make sure issues in their focus area are also added to the focus area’s GitHub Project
  • Monitor and update issues labeled with their focus area

Top ↑

Testing

Since the Performance Lab plugin is intended to allow for testing and adjustments to feature projects that will ultimately land in WordPress core, one of the best ways to help with the plugin is to simply install and test the existing features. If you find any bugs or errors, please report them in GitHub using the Bug Report issue template.

In addition, we can always use support from developers with testing features and code before they are released in the plugin. Issues that we could use additional testing support with are labeled with the Needs Testing label, but feel free to review all issues/PRs that need review and assist with testing.

Top ↑

Support forum

As a plugin on the WordPress.orgWordPress.org The community site where WordPress code is created and shared by the users. This is where you can download the source code for WordPress core, plugins and themes as well as the central location for community conversations and organization. https://wordpress.org/ repository, the Performance Lab plugin has its own support forum. Designated members of the Performance Team actively monitor the forum and reply to new support topics and reviews. Community members are always welcome to assist with forum topics, as well – just be sure to follow the WordPress.org forum guidelines.

Top ↑

Translations

Translation of the Performance Lab plugin is done through the work of community volunteers as part of the Polyglots Team. We would love for the plugin to be translated into as many languages as possible! If you’d like to help, check out the Translator’s Handbook for more details.

Last updated: