Welcome to the CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. Contributor Handbook, the place to learn how to get involved with the WordPress core development community, and start contributing to WordPress core.
Whether you are 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. tester, casual contributor, or serious contributor, this handbook will provide the information you need to get started.
Here you can learn about how the WordPress project is organized, communication channels, best practices, the TracTrac An open source project by Edgewall Software that serves as a bug tracker and project management tool for WordPress. workflow process, and more. There are also guides to help you set up the tools you’ll need to start contributing to WordPress core.
Contribute with Testing
Testing is a very important part of the release cycle. You can install the latest development version locally to test new features, and how the changes work with your site setup (theme/plugins/etc.). You can start testing as soon as a new development version is available (alpha), and continue throughout the release cycle to ensure the next version of WordPress is as bugbug A bug is an error or unexpected result. Performance improvements, code optimization, and are considered enhancements, not defects. After feature freeze, only bugs are dealt with, with regressions (adverse changes from the previous version) being the highest priority.-free as possible.
You don’t need to know how to code or create 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., just provide a well-written bug report, with details of the issue and steps to reproduce. You can confirm the issue is fixed once a patch is committed and a new bleeding edgebleeding edge The latest revision of the software, generally in development and often unstable. Also known as trunk. nightly version released.
Found a security vulnerability? WordPress believes in responsible and private disclosure. Report it directly to our security team.
Contribute with Code
Whether you need to report one bug and provide a patch to fix it, or wish to become involved in maintaining one or more WordPress components, contributing code is a great way to improve WordPress. This section walks through the WordPress codebase and how it’s laid out, then teaches you more about the code repository and our bug tracker (Trac).
Design decisions made within WordPress are often a consideration when contributing code and are outlined in this section as well. Finally, if you’re interested in fixing bugs, our walkthrough is made to get you quickly started.
Best Practices
Over time, the WordPress community has developed some best practices, which keep the code base consistent and understandable by the community.
In the best practices section, we outline the coding standards for CSS, HTML, JavaScript, and PHP. Additionally, inline documentation standards for both JavaScript and PHP are documented in-depth.
Finally, the section walks through the Core APIs and the best practices to follow when writing patches.
Tutorials & Guides
Completely new to WordPress development? In this section, we include a number of tutorials and guides to help get you setup. Whether you want to setup WordPress for local development, install a local server, install a version control system (VCS), understand how to work with patches, or better understand how to work with Trac, we have you covered.
Need help?
We all start somewhere. If you’re having trouble getting involved with contributing to WordPress core, come find us on Slack in #core. We don’t bite. đŸ˜
If you’re interested in improving this handbook, leave a message in #coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress.-docs.
9 responses to “Core Contributor Handbook”
Hi guys – am going to read through some of the manual today and come up with some thoughts/comments etc. I can’t believe how much has been added since yesterday – can see everyone was working really hard. Wish I could have been in SF but was in rainy England đŸ™
Anyway, at the risk of stepping on toes, I’ll add some thoughts – I hope they’re useful. If you guys discussed any of it yesterday tell me to stfu.
First things first – the landing page is a bit confusing. Title is “CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. Contributor Handbook” and underneath it says “Howdy! This is a rough draft of the handbook for contributing to WordPress.” So I’m not 100% sure if the handbook is just for core, or for more general contributions.
My own feeling is to keep it for core (I think that’s the intention, right?) but to have a clear notice somewhere that says “Can’t Code? Check out These Other Ways to Contribute” – this could link to a list of the other handbooks (and the theme could be carried across the handbooks to direct people to the right place). Am assuming that there will be other handbooks – that would be fantastic. I can see a handbook for writing the Codex being really useful – also for all of the other contributor groups.
So, back to the CCH: that top line can be remedied by changing it to: “”Howdy! This is a rough draft of the handbook for contributing to WordPress core.”
Believe it or not, I tried to contribute to core a few weeks ago myself. I was chatting to @duck_ 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. Edinburgh and he was saying that there is a massive list of documentation errors: https://core.trac.wordpress.org/ticket/20425 So I thought that this was something I could take a look at. Anyway, I tried to figure out what to do, but I failed, mostly because I wasn’t sure about where to get started. What I thought would be really useful for people like me, (and for people who can actually write code) was a “First Steps” Guide. An off-the-top-of-my-head sketch of how this would look was:
1. Requirements (the level of knowledge required (with links to places where people can learn more should they not have the required level), what’s expected, any software that is needed)
2. Essential reading (the absolute essentials that someone needs to read before contributing. Or even a bulletpointed list of the essential things that someone needs to know)
3. Setting up your dev environment (with links to tutorials on how to set up MAMP, XAMPP etc)
4. Setting up Subversion
5. Creating your first 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. (with a link to coding standards)
6. Available patches (would it be possible to generate a list of things that need to be done, and tagtag A directory in Subversion. WordPress uses tags to store a single snapshot of a version (3.6, 3.6.1, etc.), the common convention of tags in version control systems. (Not to be confused with post tags.) them so they appear under different headings e.g. beginner PHPPHP The web scripting language in which WordPress is primarily architected. WordPress requires PHP 7.4 or higher, advanced PHP, CSSCSS Cascading Style Sheets., Docs, etc etc)
7. Learn More & Getting Help (links to more things that need to be read)
For an absolute beginner like me that would be really helpful in telling me exactly what I need to do. In fact, this sort of “First Steps” guide could be replicated across the manuals, so in each manual there is consistency
this is definitely the beginnings of what I was thinking re: first steps guide: https://make.wordpress.org/core/handbook/submitting-a-patch/
Contributing to coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. doesn’t mean you have to know how to code, though.
UIUI User interface is part of core. As is 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), documentation, the help screens, etc etc đŸ™‚ So part of learning how to contribute to core is learning where you best fit. That’s why @hanni and I put things in the order. We’re assuming people start at 0 – what’s going on here? and move on to 10 – re-writing ms-files.php
Hello,
Sorry for the n00b question.
What is the best way to get in contact with a WordPress coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. developer to request access to the site so that I can contribute to https://make.wordpress.org/core/handbook/coding-standards/. I will be able to give about 10 hours a week to WordPress. I wanted to know the right etiquette so that I do not piss anyone off. I thought about using Twitter but then decided to ask the community to help.
I’d like to start contributing and editing, particularly on the localization sections. I’m happy to start by adapting and adding this:
http://wprealm.com/blog/translate-wordpress-part-i-getting-started-and-adding-support-for-a-language/
I came here looking for tips on how to disable WP loading the minified CSSCSS Cascading Style Sheets./JSJS JavaScript, a web scripting language typically executed in the browser. Often used for advanced user interfaces and behaviors. by default, without finding anything specific. This was the section I primarily looked at:
https://make.wordpress.org/core/handbook/the-wordpress-codebase/#javascript-css
It would seem as if almost every designer working on coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. CSS would need to apply this in their wp-config to have their changes show up immediately:
define(‘SCRIPT_DEBUG’, true);
I’m pretty sure this is mentioned somewhere else in the handbook, but given that this is something that almost every contributor will run into it might make sense to make it more prominent (and perhaps link to it directly from the section above).
Are there other things that a designer (or developer) should always do when they start working on patches? This could warrant a tutorial: something along the lines of “How to Set Up WordPress to Work on CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress.” – could include:
a) turn on script debugging
b) something else
c) something else
Is that something that would be useful?
I think a tutorial on that would definitely be useful. I’ve never contributed to coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress., but if I did, I would start by looking for such a tutorial.
I’d find this very useful. Questions like this, to be more specific:
1. I want to work on ticketticket Created for both bug reports and feature development on the bug tracker. x. It has 10 diffs on it already. Where do I start?
2. What is a diff? Is it 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.? How do I download a patch? How do I apply the patch?
3. How can I undo a patch?
4. How do I make my own patch?
5. Now that I’ve made all these changes, my repo is now completely out of sync. What now?
5. Can I manage this workflow with git?
I think it would be really helpful to walk through that workflow — ie: coming into an ticket that’s well underway.