Writing Documentation

To read documentation, go to docs.civicrm.org for the most high-level list of all active documentation.

This page describes the details of the documentation systems within CiviCRM and how to contribute. We also have a more basic overview on how to contribute to this guide or the user guide.

!!! note "Note: the wiki is not covered here" The wiki has historically been CiviCRM's documentation system but is being phased out as of 2017. The rest of this page describes MkDocs guides only and does not cover documentation processes that involve the wiki.

When to document {:#when}

If you are contributing to core, updating documenting along with your changes is an important step to ensure the long-term usability and maintainability of CiviCRM.

Not all changes require documentation updates. Here are some guidelines:

• Documentation should almost always accompany new features.
  • Keep in mind that some features are user-facing (and thus require new documentation in the User Guide) whereas some features are developer-facing (and thus require new documentation in the Developer Guide.)
• Bug fixes will occasionally require documentation updates. Check existing docs to see what changes might be necessary.

!!! tip Try writing documentation before writing your code! Then you have a way to organize your thoughts and measure whether the feature works.

If you are submitting a core pull request and would like to submit accompanying doc changes, please provide comments in both pull requests for cross reference. Your docs PR will not be merged until your core PR is merged first.

Guides in MkDocs

We are using MkDocs to produce guides. The content for each of these guides is written in markdown, stored in text files, and hosted in a repository on GitHub. Then, the guides are automatically published to docs.civicrm.org using our custom publishing system.

Versions

In an effort to maintain documentation anchored to specific versions of CiviCRM, some guides store separate versions of the documentation in different branches within the repository.

If you're improving current documentation, please edit the master branch, which will be periodically merged into other branches as needed.

In rarer cases, if you have an edit that pertains to a specific version, (e.g. documentation about a feature in an older version of CiviCRM, which does not require documentation in the latest version), then please edit the branch corresponding to that version.

Languages

A guide can have multiple languages, and we use separate repositories for different languages. For example, you can click See all X editions and find the repositories for additional languages.

Contributing to documentation {:#contributing}

We welcome contributions, small and large, to documentation!

Resources:

Before diving into editing, you may find helpful information within the following resources:

• Markdown syntax - necessary (but simple) syntax to format content
• Markdown coding standards - recommendations for markdown syntax to use
• Style guide - to maintain consistent language and formatting
• Documentation chat room - live discussion, fast (most of the time) answers to your questions
• Documentation mailing list - low traffic, mostly used for informational updates regarding documentation projects

Submitting issues

The simplest way to help out is to describe a change that you think should be made by writing a new issue in the issue queue for the GitHub guide you are reading. Then someone will see your issue and act on it, hopefully fast. Each guide has its own issue queue. First find the GitHub repository for the guide (listed in the above table), then when viewing on GitHub, click on "Issues". You will need an account on GitHub to submit a new issue, but creating one is quick and free.

Editing through GitHub

Please see the documentation for editing with Git in the CiviCRM user guide.

Testing locally with MkDocs {:#mkdocs}

The most advanced way to work on a guide is to use git to download all the markdown files to your computer, edit them locally, preview the changes with MkDocs, then use git to push those changes to your personal fork, and finally make a "pull request" on the main repository. This approach makes editing very fast and easy, but does require a bit of setup, and some knowledge of how git works.

1. Obtain the source files for the guide you want to edit

   1. Find the repository on GitHub (see "repository" links above, or the "GitHub" link on the bottom left of screen of the documentation you are reading)

   2. Fork the repository on GitHub.

   3. Clone your fork of the repository to your computer

      git clone https://github.com/YourGitHubUserName/civicrm-dev-docs.git
      cd civicrm-dev-docs

2. (optional) If you have Docker installed, then at this point you can run one of the following commands and then skip to the "view the guide locally ..." step below.

   1. For folks who have a full Docker for Windows / Mac / Linux environment, run this command:

      docker run --rm -v "$PWD":/docs -p 8000:8000 -w /docs seanmadsen/civicrm-docker-mkdocs serve --dirtyreload -a 0.0.0.0:8000

      and skip to the "view the guide" step below.

   2. For folks who have a legacy or "Home" operating system (Windows 7, 8.1, 10 Home Premium), the situation is a bit more complex. Follow these steps:

      1. Check that GitHub folder is in the path: c:\Users\<username>\Documents\.... If it is, all is good; if not, move it there, and edit your GitHub configuration to reflect the changed location.
      2. Set up a Docker-Toolbox environment (which depends on Oracle VM Box), and check that it is functioning properly (Hello-world container works).
      3. Run this command:

      docker run --rm -v "/c/Users/<username>/Documents/GitHub/civicrm-user-guide:/docs" -p 8000:8000 -w /docs seanmadsen/civicrm-docker-mkdocs serve --dirtyreload -a 0.0.0.0:8000

      and skip to the "view the guide locally ..." step below.

3. Install pip (python package manager)

   • OS X: brew install python
   • Debian/Ubuntu: sudo apt-get install python-pip python-wheel

4. Install MkDocs, plus the Material theme and the Pygments syntax highlighter.

   sudo pip install mkdocs mkdocs-material pygments pymdown-extensions

5. Serve a local copy of the guide with MkDocs

   1. Run:

      mkdocs serve

      • If you get [Errno 98] Address already in use then try using a different port with mkdocs serve -a localhost:8001

6. View the guide locally in your browser at http://localhost:8000.

7. Edit the markdown with an editor of your choice. As you save your changes mkdocs will automatically reprocess the page and refresh your browser.

8. When you are happy with your edits, use git to commit and push your changes up to your fork. Then submit a pull request on GitHub.

9. Ctrl-C will stop the MkDocs server.

Adding a new page {:#new-page}

1. Make sure you are already set up to edit locally with MkDocs
2. Decide where it should go in the menu. (Ask for advice in the documentation channel if you're unsure.)
3. Add a menu location for the new page by adding a new line appropriately in mkdocs.yml.
   • Follow the pattern you see on other lines of this file to specify a title and a file location.
   • When setting the title, keep in mind that the same title will display in the menu and in the reader's browser tab title, so choose a title that's short but that also stands on its own to some extent.
   • Specify a location for the markdown file for your new page which follows the folder structure of the menu location you decided on.
4. Add a new markdown file in the location specified by your new menu item and begin add content to it.
5. If you're copying existing content from other sources (e.g. wiki, StackExchange, etc.) then follow the instructions for providing attribution

Moving pages

If you'd like to move a page, take the following steps:

(Before-hand) if you have changes to page content, then make those in a separate git commit.

1. Move the file.
2. Update mkdocs.yml with the new path to the page.
3. Add a redirect rule to redirects/internal.txt.
   • Format is old/page/path new/page/path
   • Use the part of the path after the docs directory.
   • Don't use leading or trailing slashes
   • Don't use a .md extension
   • List the old path first and the new one second
   • Separate the paths with a space
4. Run mkdocs serve and see if it gives you any warnings about broken hyperlinks. If it does, go fix those.

!!! note Page redirection won't work locally (when previewing with mkdocs serve), but it will work once the guide is published on docs.civicrm.org. The redirection is implemented as part of our docs-publisher app.

Auto-generated documentation {:#auto-gen}

Some guides may have auto-generated content, which is summarized here.

In the Developer Guide {:#auto-gen-dev}

This Developer Guide has an automatically-generated list of all hooks. To re-create this list, run the following command from the root level of the repository:

./bin/tools generate:hooks-list

Our editing workflow currently requires someone to manually run this command after and commit its changes whenever hooks files are edited.

Content attribution guidelines {:#attribution}

All CiviCRM documentation content is licensed CC BY-SA 3.0. This means that if you want to copy content out of our docs and use it elsewhere, you're welcome to do so as long as your give attribution to the author.

How to obtain author information for content within our guides {:#attributing-exports}

This is relevant when you want to copy content out of our documentation books.

1. Find the GitHub repository for the book that contains the content you'd like to use. (There will usually be a link to this repository at the top right of ever page.)
2. Navigate to the corresponding markdown file within GitHub (it will match the URL path of the published content).
3. Click on "Blame" to see detailed information about content authors, line, by line.

How to display attribution for content migrated into our books {:#attributing-imports}

The CiviCRM wiki and Stack Exchange also use the CC BY-SA 3.0 license, which is convenient because content is regularly migrated into our MkDocs guides from these sources. But to comply with the license, we must attribute the original content authors

When migrating content into our docs guides which requires attribution, display this attribution at the bottom of the page as follows:

## Credits

Some content from this page was migrated from other sources
and contributed by the following authors:

* Mickey Mouse
* Lisa Simpson
* Big Bird

Commit messages should also reference the URL of the original content.