What does the CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. team do?

Core is made up of contributors from many different areas and teams across 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/. Because Core is made up of many different components and parts, there is a ton of overlap with the other Make teams (polyglots, themes, plugins, metaMeta Meta is a term that refers to the inside workings of a group. For us, this is the team that works on internal WordPress sites like WordCamp Central and Make WordPress., etc.). It is an exciting and dynamic place to observe or contribute.

The team holds a weekly developer chat in the Make WordPress #core channel on 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/. every Wednesday at 20:00 UTC.

New Contributor Meetings are held in the same channel on the 2nd and 4th Wednesdays just prior to the weekly developer chat at 19:00 UTC.

What areas of Core will I be able to work on at WordCampWordCamp WordCamps are casual, locally-organized conferences covering everything related to WordPress. They're one of the places where the WordPress community comes together to teach one another what they’ve learned throughout the year and share the joy. Learn more. Europe 2023?

The Core team and the Core WordPress software is segmented in a number of ways. While there will be some community leaders present representing some specific parts of the Core team, you can contribute to any of these segments at Contributor DayContributor Day Contributor Days are standalone days, frequently held before or after WordCamps but they can also happen at any time. They are events where people get together to work on various areas of https://make.wordpress.org/ There are many teams that people can participate in, each with a different focus. https://2017.us.wordcamp.org/contributor-day/ https://make.wordpress.org/support/handbook/getting-started/getting-started-at-a-contributor-day/. and there will likely be several contributors experienced in these areas. These are the most common ways that you’ll see Core divided.

Components

Currently, there are 62 components and sub-components within Core. These represent overarching categories of functionality within the code base. Some examples of these are Database, External Libraries, TaxonomyTaxonomy A taxonomy is a way to group things together. In WordPress, some common taxonomies are category, link, tag, or post format. https://codex.wordpress.org/Taxonomies#Default_Taxonomies., Feeds, etc. A handful of components also have sub-components. For example, Embeds, Gallery, and Upload are sub-components of the Media component.

Focuses

In TracTrac An open source project by Edgewall Software that serves as a bug tracker and project management tool for WordPress., there are also several focuses. Focuses are disciplines or concepts that span many components, or even the entire Core code base. Some examples of these are accessibility, coding-standards, rest-api. Contributors that specialize in these focuses often work with many different component maintainers.

Sub Teams

There are also a few contributor groups that are still technically under Core, but operate as their own team. Some examples of this are Editor, Performance, AccessibilityAccessibility Accessibility (commonly shortened to a11y) refers to the design of products, devices, services, or environments for people with disabilities. The concept of accessible design ensures both “direct access” (i.e. unassisted) and “indirect access” meaning compatibility with a person’s assistive technology (for example, computer screen readers). (https://en.wikipedia.org/wiki/Accessibility). These sub teams will each be represented by table leads at contributor day.

Preparing for Contributor Day before leaving home

Register for a WordPress.org profile and the WordPress.org Slack instance

The large majority of the communication around contributing to the WordPress 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. projects happens on WordPress.org or in the WordPress Slack instance. Your first step should be to register for both in that order.

• WordPress.org sign up
• WordPress Slack sign up

There are 5-minutes videos to help you get started with the tools of communications. The Marketing Team with other contributors has been making different versions on this in a number of languages.
Set up a WordPress.org and Slack account for the Make WordPress Channel.

A majority of the Core components and sub teams also have their own channels within the WordPress Slack instance.

Install required software to contribute to the code

For those who would like to contribute by way of writing or checking code, the most popular method is by having a local development environment installed on your system.

Installing local environments are likely to be easier and quicker before you arrive at the conference venue. Conference WiFi can often be unreliable or be over-burdened. Getting set up before the event can help reduce the time you will spend installing and setting up the software on the day. You can then get onto more interesting things when you are at the conference!

In order to contribute to Core from a development perspective, you will need the following software installed on your machine:

• GitGit Git is a free and open source distributed version control system designed to handle everything from small to very large projects with speed and efficiency. Git is easy to learn and has a tiny footprint with lightning fast performance. Most modern plugin and theme development is being done with this version control system. https://git-scm.com/. or SVNSVN Subversion, the popular version control system (VCS) by the Apache project, used by WordPress to manage changes to its codebase. (whichever you prefer)
• NodeJS (WordPress currently requires NodeJS 14.x)
• npm (comes bundled with NodeJS)
• Composer (optional, but highly recommended)

Additionally, you will need to choose one of the following:

• Docker
• Vagrant & Virtualbox in order to use Varying Vagrant Vagrants
  
  For those who would like to contribute by way of writing or checking code, the most popular method is by having Vagrant & VVV (Varying Vagrant Vagrants) installed on your system.
• To start, have a look at the introductions section of: https://varyingvagrantvagrants.org/
• Once you are ready, move on to https://varyingvagrantvagrants.org/docs/en-US/installation/ where you will find all the relevant information on how to get set-up and ready to run a local version of WordPress. Where you will be able to edit plugins, themes and core WordPress files.

Note: There are other tools that can be used to set up a local development environment (such as Local), but the two above are the ones maintained and have official support.

Decide how you’re going to work with the codebase

There’s a few options for you to work with the wordpress-develop codebase.

Note: if you chose the Vagrant/Virtualbox/VVV option above, the default is the third option below, but you can change that later.

Forking WordPress/wordpress-develop on 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/

This option will allow you to submit and work within a pull request on GitHub. When using this option, all of the configured automated testing will run on your code to help verify your change. You can read more about this option in the Core Handbook.

Using WordPress/wordpress-develop directly

With this option, you’ll clone the wordpress-develop repository locally and use that as your codebase. You won’t be able to push any changes or submit pull requests, but you will be able to create patches with your changes to submit on Trac.

Using SVN to check out WordPress

With this option, you’ll checkout the `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.` branchbranch A directory in Subversion. WordPress uses branches to store the latest development code for each major release (3.9, 4.0, etc.). Branches are then updated with code for any minor releases of that branch. Sometimes, a major version of WordPress and its minor versions are collectively referred to as a "branch", such as "the 4.0 branch". of the develop.svn.wordpress.org repository to use as your local WordPress site. Any changes you make need to be submitted as patches.

Docker Option

Below are the basic steps to get started with the local Docker environment:

1. Clone your repository of choice from the previous section. If you’re using a fork that you created, the command will look like this: git clone git@github.com:{your GitHub username}/wordpress-develop
2. Run cd wordpress-develop to move into the directory created by the git clone.
3. Run npm install to install dependencies
4. Run npm run env:start to start the development environment
5. Run npm run env:install to set up clean installation with the user adminadmin (and super admin) and the password password
6. Run npm run build:dev to run a build.

You can now load WordPress:

Frontend: http://localhost:8889

Backend: http://localhost:8889/wp-admin/

• Username: admin
• Password: password

You will find these steps and more details in the project’s README.md file.

Varying Vagrant Vagrants option

You will find detailed instructions for how to get started on the project’s website.

Other tips

• Running npm install, vagrant up, or npm run env:start can be networknetwork (versus site, blog) intensive. Run these at home before you leave for the event and confirm everything’s working as expected. Depending on what you work on during Contributor Day, you may need to run these commands again. But having dependencies, virtual boxes, and containers cached locally will greatly decrease the time they take to run at the event.
• Try creating patches or a PR ahead of time. If you’re able to start working on a ticketticket Created for both bug reports and feature development on the bug tracker. before the event, contributors at the event can give you feedback on your work so far.
• Read about finding bugs to fix and identify any you are interested in prior to heading to the event.
• The ‘good first bugs‘ report in Trac is a great place to find easier tickets to get your feet wet. There’s also a similar list of “good first issues” for Gutenberg.
• There is also now support for GitHub Codespaces to contributor to Core.

Helpful links

Below are a handful of other helpful links that will help you be better prepared for Contributor Day.

• FAQs for New Contributors
• Trac Quick Start Guide
• Trac Workflow Keywords
• Core Contributor Handbook
• Core Components
• Bug Gardening
• Jonathan Desrosiers on Ticket Triage
• Working with Patches
• Running PHPUnit tests
• Writing PHP Tests
• WordPress Local Docker Environment
• WPTracSearch
• For the Test team, it has a Get Started at Contributor Day page in the Test handbook

---

Many thanks to all the contributors who helped with materials for this post – as ever with WordPress, it is a real team effort! Special thanks to @desrosj who collected much of the preparation information, to @wpscholar for sharing his more detailed document from a previous WordCamp, and to @webcommsat who pulled together the material from different editions. Thanks also to @sergeybiryukov, @jeffpaul and @webcommsat for review and contributions, and to @audrasjb, @paulbearne, @mark99, @vimes1984, @meher, @oglekler for contributions and review for material used from previous editions of this post. Thanks to @davidbaumwald, @joemcgill for review of the checklist.

After WordCamp Europe, a version of this post will be added to the Core Team Handbook.

#contributor-day