The WordPress CoreCoreCore is the set of software required to run WordPress. The Core Development Team builds WordPress. Performance Team is dedicated to monitoring, enhancing, and promoting performance in WordPress core and its surrounding ecosystem. We build and manage the Performance Lab plugin, a collection of performance-related “feature projects” for WordPress core.
The Performance Lab plugin is a collection of “feature projects” for WordPress coreCoreCore 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 pluginPluginA 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 betaBetaA 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.
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 SiteYou 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.
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 PHPPHPPHP (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 multisiteMultisiteMultisite 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
We use GitHubGitHubGitHub 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.
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 [Type] label
Optional: A [Plugin] label if the issue relates to a specific plugin as part of the monorepo
If it’s already clear, please also add a milestone, for instance using the next milestone for the plugin the issue is about. 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.
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.
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.
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.
Have [Type] label matching the related issue’s [Type] label
Have either an assigned milestone for the plugin modified, or the no milestone label if the PR touches central monorepo infrastructure that affects multiple plugins. 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.
The PR title is used as the changelog entry via automated tooling, so try to use a title that describes the change well. If the PR is about a low-level detail that is not useful to include in the changelog, please add the skip changelog label to it.
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.
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 TracTracTrac 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.
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.
As a plugin on the WordPress.orgWordPress.orgThe 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.
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.