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:
Block Editor Handbook: An overview of documentation contributions of BlockBlockBlock is the abstract term used to describe units of markup that, composed together, form the content or layout of a webpage using the WordPress editor. The idea combines concepts of what in the past may have achieved with shortcodes, custom HTML, and embed discovery into a single consistent API and user experience. Editor / GutenbergGutenbergThe Gutenberg project is the new Editor Interface for WordPress. The editor improves the process and experience of creating new content, making writing rich content much simpler. It uses ‘blocks’ to add richness rather than shortcodes, custom HTML etc. https://wordpress.org/gutenberg/
Documentation Issue Tracker on GitHub: Submit any DevHub/HelpHub/”Doc Team Handbook” Docs-related issue on GitHubGitHubGitHub is a website that offers online implementation of git repositories that can 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/.
Join our discussions of documentation issues here on the blog and on Slack.
In general, emphasize on the task to be accomplished, rather than how the user should interact with the UIUIUI is an acronym for User Interface - the layout of the page the user interacts with. Think ‘how are they doing that’ and less about what they are doing. element.
Use select when referring to the action of the user selecting targets such as menu commands, checkboxes, items, and dropdown lists. Select can be used interchangeably instead of click or check in describing checkboxes and dropdown lists.
In general, emphasize on the task to be accomplished, rather than how the user should interact with the UI element.
Don’t use to describe a UI element such as a menu item, dropdown list option, or button that the user can’t interact with due to certain conditions. Instead, use not available or unavailable. If you must describe their appearance, use appears dimmed.
Use sorry only when the user is asked to do something inconvenient, the user can’t use the product, the application or site is to blame for the situation, or when there is an issue with the product. It’s OK to use sorry for other inconveniences such as data loss, errors, application failure, or when the user has to get help from a support representative.
Tip:Recommended: Sorry, the service is temporarily available.
OK to use in developer documentation and for a technical audience.
In general, emphasize on the task to be accomplished, rather than how the user should interact with the UI element. Refer to a spin box by its label. If you have to use a descriptor, use spin box or description box.
When the environment is presumably a touch surface or device, use swipe to describe a short, quick movement in the direction opposite to the way the page scrolls. Include the direction of the swipe—up, down, left, or right—if it’s needed to describe the action.
Don’t use symbol when you mean button or icon. A user can interact with a button or icon but cannot interact with a symbol.
It’s OK to use symbol to refer to text characters, as in the percent symbol (%). Don’t use symbol when you mean character, letter, or digit.
Use sign, not symbol, in the following terms: division sign, equal sign, greater-than sign, less-than sign, minus sign, multiplication sign, number sign, and plus sign.
When referring to a sign or symbol, introduce its spelled-out version and then the sign or symbol in parentheses. It’s acceptable to use a symbol by itself in UI, tables, or headings where space is limited.