# Introduction to pkgdown

The goal of pkgdown is to make it easy for package developers to make elegant and useful packages websites. The defaults are tailored for smaller packages and for use on GitHub (particularly with new docs/ directory support), but it is flexible enough to be used as part of a bigger website. There are five parts to a pkgdown site:

2. Function reference
3. Articles
4. News
5. Navbar

To build a pkgdown site, run build_site(). The function has some arguments (mostly to control where the output), but most of the configuration options are controlled by _pkgdown.yaml. These options include:

• The site title, if different from the package name.

• A path to a set of template, if you want to override the default page templates provided by the site.

• A bootswatch theme name to easily tweak the overall appearance of the site.

Other options control the appearance of the other parts of the site.

pkgdown checks for a site configuration file in these locations:

1. _pkgdown.yml
2. _pkgdown.yaml
3. pkgdown/_pkgdown.yml
4. inst/_pkgdown.yml

Including the configuration file in inst/ enables sites to be built from packages on CRAN without needing the development version of a package.

The home page will be automatically generated from one of the following four files:

1. index.Rmd
2. README.Rmd
3. index.md
4. README.md

pkgdown tries them in order, which means that if you want different display for GitHub and pkgdown, you can have both README.md and an index.md

When including big graphics in the README, you may find it easier to use knitr::include_graphics("foo.png") combined with chunk option out.width = '100%'. This will make the graphic scale with the size of the page.

## Reference

The function reference generates one page for each .Rd file in man/, placing the results in reference/. This is mostly a straightforward translation of Rd to HTML, along with evaluating the examples, and auto-linking function names to their documentation.

pkgdown will also generate an overall index, which by default, is just an alphabetically ordered list of functions. However, the index is better with human curation because functions can be grouped by function and described en masse. To override the defaults, provide a reference key in _pkgdown.yml:

reference:
- title: "Connecting to Spark"
desc: >
Functions for installing Spark components and managing
connections to Spark
contents:
- spark_config
- spark_connect
- spark_disconnect
- spark_install
- spark_log
- title: "Reading and Writing Data"
desc: "Functions for reading and writing Spark DataFrames."
contents:
- starts_with("spark_write")
- sdf-saveload

The reference should be an array of objects containing title, desc (description), and list of contents. Since common prefix and suffixes are often used for functional grouping, you can use the functions starts_with() and ends_with() to automatically include all functions with a common prefix or suffix. To match more complex patterns, use matches() with a regular expression.

The objects in reference can also contain a list of exclude, which allow you to exclude unwanted topics included via contents.

pkgdown will warn if you’ve forgotten to include any non-internal functions.

## Articles

pkgdown will automatically build all .Rmd vignettes, including those in subdirectories. The only exception are .Rmd vignettes that start with ’_’. This enables the use of child documents in bookdown. The output of the vignettes is rendered to articles/. pkgdown will ignore the output format defined in the yaml header, and always use html_fragment(toc = TRUE, toc_float = TRUE).

If you want to include an article on the website, but not in the package (e.g. because it’s large), you can either place it in a subdirectory of vignettes/ or add to .Rbuildignore. As well, you must ensure that there is no vignettes: section in the article’s yaml header. In the extreme case where you want to produce only articles but not vignettes, you should add the complete vignettes/ directory to .Rbuildignore and make sure that DESCRIPTION has no VignetteBuilder field.

As with the function reference, articles will also get a default index, and it can be customised in a similar way (referring to file names rather than function names):

articles:
- title: "Extend shiny"
desc: >
- htmlwidgets
If NEWS.md is present, it will be parsed into pieces broken up by second level headings. These will be rendered to news/, with one page per minor release (so that 2.2.0, 2.2.1, and 2.2.2 are all described on a single page).
If you want more detailed release notes (aimed at teaching people about the new features), you could put these in (e.g.) vignettes/news and customise the navbar.