Welcome to the official home of the WordPress documentation team.
This team is responsible for coordinating all documentation initiatives around WordPress, including the Codex (moving to HelpHub and DevHub), handbooks, parts of developer.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/, admin help, inline docs, and other general wordsmithing across the WordPress project.
Want to get involved?
There are many ways in which you can help the Docs team. Every small contribution counts and helps! You can report an issue or typo you found in the docs, or even help us write new documentation for parts that are still missing. These are some helpful links to find out more about what we do and how to collaborate:
WordPress’ current inline documentation efforts really kicked off starting in the 3.7 releaseReleaseA release is the distribution of the final version of an application. A software release may be either public or private and generally constitutes the initial or new generation of a new or upgraded application. A release is preceded by the distribution of alpha and then beta versions of the software. cycle, and gained momentum as the hook docs initiative progressed. The inline documentation, or “inline docs” initiative is a hybrid project, reporting to the CoreCoreCore is the set of software required to run WordPress. The Core Development Team builds WordPress., Documentation, and Developer Hub teams.
Inline documentation provides both necessary and useful information in the form of inline-comments, doc blocks, and more within the source code of WordPress itself.
The inline documentation is parsed with each release, and that documentation is displayed in the Code Reference at developer.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/.
Inline documentation is considered to be “technical” documentation, so some familiarity with the WordPress codebase will be necessary – you have to understand the code to write about it.
2. Set up a local copy of the developer version of the WordPress codebase using Varying Vagrant Vagrants (VVV). WordPress is versioning using SVNSVNApache Subversion (often abbreviated SVN, after its command name svn) is a software versioning and revision control system. Software developers use Subversion to maintain current and historical versions of files such as source code, web pages, and documentation. Its goal is to be a mostly compatible successor to the widely used Concurrent Versions System (CVS). WordPress core and the wordpress.org released code are all centrally managed through SVN. https://subversion.apache.org/., but you can also use GitGitGit 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/. (the VVV link for how to do that).
3. Read Opening a Ticket to learn how to create a TracTracTrac is the place where contributors create issues for bugs or feature requests much like GitHub.https://core.trac.wordpress.org/. ticket.
4. Creating patches:
Always update your local copy of WordPress trunk before editing the file and creating patches. Use svn up or git pull, as appropriate.
Generate the patch from the root directory of your WordPress SVN or Git checkout. For example, svn diff dir/filename.php > function_name.diff.
5. How to submit a patch
There is one patch to report the inline documentation failures and For example, #48303 is such patch for the WordPress 5.4.
If a ticket is marked needs-patch or needs-refresh, it’s possible the existing patch(es) might just need a touch-up or be refreshed against the latest trunk. Every little bit helps!
Adam Brown’s Hooks Database (useful for hints on the @since versions of hooksHooksIn WordPress theme and development, hooks are functions that can be applied to an action or a Filter in WordPress. Actions are functions performed when a certain event occurs in WordPress. Filters allow you to modify certain functions. Arguments used to hook both filters and actions look the same.)
Basically, there is one ticket to report the inline documentation failures and improvements. But, if you need create new ticket for some reason, follow below steps:
Suggested Title formats could be “PHPDoc correction for path/to/file.php” or “Improve documentation for path/to/file.php”.
The Type should be defect (bug).
Assign the ticket to the Component the file is associated with.
Leave the Version blank.
Add the docsFocus by clicking on it.
Upload your patch to the Trac ticket you created, and add the keyword has-patch.
Make sure to leave a comment describing your newly-uploaded patch. Simply uploading patches doesn’t trigger a notification for anyone watching the ticket.
Note: Documentation changes should not mix with code changes (even whitespacing) unless the ticket specifically calls for both.
