3pp-mirror/docusaurus
1
0
Fork 0
mirror of https://github.com/facebook/docusaurus.git synced 2025-08-06 02:08:55 +02:00
Code Issues Projects Releases Packages Wiki Activity

v1.8.0 (#1324)

Browse source 
* v1.8.0

* typo
This commit is contained in:
Endilie Yacop Sucipto 2019-03-30 22:00:02 +07:00 • committed by Yangshun Tay
parent 43e0221b56
commit bf6074c4c2
9 changed files with 929 additions and 3 deletions
Download patch file Download diff file Expand all files Collapse all files

26
CHANGELOG.md
View file

@ -6,6 +6,29 @@ The format is based on [Keep a Changelog](http://keepachangelog.com/en/1.0.0/) a
## [Unreleased]
## [1.8.0] - 2019-3-30
This version mainly include bug fixes and a new feature to skip the next release documents when versioning is enabled.
Thank you to the following contributors:
- @yangshun
- @endiliey
- @vikrantsinghthakur
- @parthpp
### Fixed/Added
- feat: Add --skip-next-release option to yarn build ([#1292](https://github.com/facebook/Docusaurus/pull/1292))
- fix: handle case insensitive table of contents token ([#1288](https://github.com/facebook/Docusaurus/pull/1288))
- fix: anchors links for underscore character ([#1309](https://github.com/facebook/Docusaurus/pull/1309))
- fix: autogenerated versions.js should not be confusing ([#1314](https://github.com/facebook/Docusaurus/pull/1314))
### Internal
- Change Docusaurus landing page ([#1290](https://github.com/facebook/Docusaurus/pull/1290))
- We restructured our repository as a monorepo ([#1297](https://github.com/facebook/Docusaurus/pull/1297))
- We folded docusaurus versions (e.g: 1.1.0, 1.1.1, 1.1.2 -> 1.1.x) ([#1313](https://github.com/facebook/Docusaurus/pull/1313))
- optimize docusaurus continuous integration ([#1308](https://github.com/facebook/Docusaurus/pull/1308))
## [1.7.3] - 2019-3-19
This version mainly includes bug fixes found in 1.7.0 that improves stability.
@ -1013,7 +1036,8 @@ N/A
- Blog
- Documentation
[unreleased]: https://github.com/facebook/Docusaurus/compare/v1.7.3...HEAD
[unreleased]: https://github.com/facebook/Docusaurus/compare/v1.8.0...HEAD
[1.8.0]: https://github.com/facebook/Docusaurus/compare/v1.7.3...v1.8.0
[1.7.3]: https://github.com/facebook/Docusaurus/compare/v1.7.2...v1.7.3
[1.7.2]: https://github.com/facebook/Docusaurus/compare/v1.7.1...v1.7.2
[1.7.1]: https://github.com/facebook/Docusaurus/compare/v1.7.0...v1.7.1

2
packages/docusaurus-1.x/package.json
View file

@ -1,7 +1,7 @@
{
"name": "docusaurus",
"description": "Easy to Maintain Open Source Documentation Websites",
"version": "1.7.3",
"version": "1.8.0",
"license": "MIT",
"keywords": [
"documentation",

2
scripts/prerelease.sh
View file

@ -36,7 +36,7 @@ select VERSION in patch minor major "Specific Version"
# Create new branch
git checkout -B $NEW_VERSION master
# Cut docusaurus docs version
cd ../website-1.x && yarn $DOCS_VERSION_COMMAND $NEW_VERSION
cd ../../website-1.x && yarn $DOCS_VERSION_COMMAND $NEW_VERSION
# Create commit
git add ../

174
website-1.x/versioned_docs/version-1.8.0/api-commands.md Normal file
View file

@ -0,0 +1,174 @@
---
id: version-1.8.0-commands
title: CLI Commands
original_id: commands
---
Docusaurus provides a set of scripts to help you generate, serve, and deploy your website. These scripts can be invoked with the `run` command when using Yarn or npm. Some common commands are:
* [`yarn run start`](api-commands.md#docusaurus-start-port-number): build and serve the website from a local server
* [`yarn run examples`](api-commands.md#docusaurus-examples): create example configuration files
## Running from the command line
The scripts can be run using either Yarn or npm. If you've already gone through our Getting Started guide, you may already be familiar with the `start` command. It's the command that tells Docusaurus to run the `docusaurus-start` script which generates the site and starts up a server, and it's usually invoked like so:
```bash
yarn run start
```
The same script can be invoked using npm:
```bash
npm run start
```
To run a particular script, just replace the `start` command in the examples above with the command associated with your script.
## Using arguments
Some commands support optional arguments. For example, to start a server on port 8080, you can specify the `--port` argument when running `start`:
```bash
yarn run start --port 8080
```
If you run Docusaurus using npm, you can still use the command line arguments by inserting a `--` between `npm run <command>` and the command arguments:
```bash
npm run start -- --port 8080
```
## Configuration
These scripts are set up under the `"scripts"` key in your `website/package.json` file as part of the installation process. If you need help setting them up again, please refer to the [Installation guide](getting-started-installation.md).
Docusaurus provides some default mappings to allow you to run commands following Node conventions. Instead of typing `docusaurus-start` every time, you can type `yarn run start` or `npm start` to achieve the same.
## Commands
<AUTOGENERATED_TABLE_OF_CONTENTS>
---
## Reference
### `docusaurus-build`
Alias: `build`.
| Options | Default | Description |
| -------------------------- | ------- | --------------------------------------------------------------------------------------------------------------------- |
| `--skip-image-compression` | `false` | Skip compression of image assets. You usually won't want to skip this unless your images have already been optimized. |
| `--skip-next-release` | `false` | Skip the next release documents when versioning is enabled. This will not build HTML files for documents in `/docs` directory.|
Generates the static website, applying translations if necessary. Useful for building the website prior to deployment.
See also [`docusaurus-start`](api-commands.md#docusaurus-start).
---
### `docusaurus-examples`
Alias: `examples`
| Arguments | Default | Description |
| ----------- | ------- | ---------------------------------------------------------------------------------------------------- |
| `<feature>` | - | Specify a feature `translations` or `versions` to generate the extra example files for that feature. |
**Example**
```bash
docusaurus-examples <feature>
```
When no feature is specified, sets up a minimally configured example website in your project. This command is covered in depth in the [Site Preparation guide](getting-started-preparation.md).
---
### `docusaurus-publish`
Alias: `publish-gh-pages`
[Builds](api-commands.md#docusaurus-build), then deploys the static website to GitHub Pages. This command is meant to be run during the deployment step in CircleCI, and therefore expects a few environment variables to be defined:
The following environment variables are generally set manually by the user in the CircleCI `config.yml` file.
* `GIT_USER`: The git user to be associated with the deploy commit.
* `USE_SSH`: Whether to use SSH instead of HTTPS for your connection to the GitHub repo.
**Example**
```bash
GIT_USER=docusaurus-bot USE_SSH=true yarn run publish-gh-pages
```
The following environment variables are [set by CircleCI](https://circleci.com/docs/1.0/environment-variables/) during the build process.
* `CIRCLE_BRANCH`: The git branch associated with the commit that triggered the CI run.
* `CI_PULL_REQUEST`: Expected to be truthy if the current CI run was triggered by a commit in a pull request.
The following should be set by you in `siteConfig.js` as `organizationName` and `projectName`, respectively. If they are not set in your site configuration, they fall back to the [CircleCI environment](https://circleci.com/docs/1.0/environment-variables/).
* `CIRCLE_PROJECT_USERNAME`: The GitHub username or organization name that hosts the Git repo, e.g. "facebook".
* `CIRCLE_PROJECT_REPONAME`: The name of the Git repo, e.g. "Docusaurus".
You can learn more about configuring automatic deployments with CircleCI in the [Publishing guide](getting-started-publishing.md).
---
### `docusaurus-rename-version`
Alias: `rename-version`
Renames an existing version of the docs to a new version name.
| Arguments | Default | Description |
| ------------------ | ------- | ------------------------- |
| `<currentVersion>` | - | Version to be renamed. |
| `<newVersion>` | - | Version to be renamed to. |
**Example**
```bash
docusaurus-rename-version <currentVersion> <newVersion>
```
See the [Versioning guide](guides-versioning.md#renaming-existing-versions) to learn more.
---
### `docusaurus-start`
Alias: `start`.
This command will build the static website, apply translations if necessary, and then start a local server.
| Options | Default | Description |
| ----------------- | ------- | ------------------------------------------------------------------------------------------------------------------------------------ |
| `--port <number>` | `3000` | The website will be served from port 3000 by default, but if the port is taken up, Docusaurus will attempt to find an available one. |
| `--watch` | - | Whether to watch the files and live reload the page when files are changed. Defaults to true. Disable this by using `--no-watch`. |
You can specify the browser application to be opened by setting the `BROWSER` environment variable before the command, e.g.:
```
$ BROWSER=firefox yarn start
```
---
### `docusaurus-version <version>`
Alias: `version`
Generates a new version of the docs. This will result in a new copy of your site being generated and stored in its own versioned directory. Useful for capturing snapshots of API docs that map to specific versions of your software. Accepts any string as a version number.
See the [Versioning guide](guides-versioning.md) to learn more.
---
### `docusaurus-write-translations`
Alias: `write-translations`
Writes the English for any strings that need to be translated into an `website/i18n/en.json` file. The script will go through every file in `website/pages/en` and through the `siteConfig.js` file and other config files to fetch English strings that will then be translated on Crowdin. See the [Translation guide](guides-translation.md) to learn more.

225
website-1.x/versioned_docs/version-1.8.0/api-pages.md Normal file
View file

@ -0,0 +1,225 @@
---
id: version-1.8.0-api-pages
title: Pages and Styles
original_id: api-pages
---
Docusaurus provides support for writing pages as React components inside the `website/pages` directory which will share the same header, footer, and styles as the rest of the site.
## Provided Props
Docusaurus provides your [siteConfig.js](api-site-config.md) as a `config` props. Hence, you can access `baseUrl` or `title` through this props.
Example
```js
const React = require('react');
class MyPage extends React.Component {
render() {
const siteConfig = this.props.config;
return <div>{siteConfig.title}</div>;
}
}
module.exports = MyPage;
```
## URLs for Pages
Any `.js` files in `website/pages` will be rendered to static HTML using the path of the file after `pages`. Files in `website/pages/en` will also get copied out into `pages` and will OVERRIDE any files of the same name in `pages`. For example, the page for the `website/pages/en/help.js` file will be found at the URL `${baseUrl}en/help.js` as well as the URL `${baseUrl}help.js`, where `${baseUrl}` is the `baseUrl` field set in your [siteConfig.js file](api-site-config.md).
## Titles for Pages
By default, the title of your page is `<title> • <tagline>` where `title` and `tagline` fields are set in [`siteConfig.js`](api-site-config.md). You can exclude the tagline in the title by setting `disableTitleTagline` to `true`. If you want to set a specific title for your custom pages, add a `title` class property on your exported React component.
Example:
```js
const React = require('react');
class MyPage extends React.Component {
render() {
// ... your rendering code
}
}
MyPage.title = 'My Custom Title';
module.exports = MyPage;
```
## Description for Pages
By default, the description your page is `tagline` set in [`siteConfig.js`](api-site-config.md). If you want to set a specific description for your custom pages, add a `description` class property on your exported React component.
Example:
```js
const React = require('react');
class MyPage extends React.Component {
render() {
// ... your rendering code
}
}
MyPage.description = 'My Custom Description';
module.exports = MyPage;
```
This will be translated to a description metadata tag on the generated HTML.
```html
<meta property="og:description" content="My Custom Description"/>
<meta name="description" content="My Custom Description"/>
```
## Page Require Paths
Docusaurus provides a few useful React components for users to write their own pages, found in the `CompLibrary` module. This module is provided as part of Docusaurus in `node_modules/docusaurus`, so to access it, pages in the `pages` directory are temporarily copied into `node_modules/docusaurus` when rendering to static HTML. As seen in the example files, this means that a user page at `pages/en/index.js` uses a require path to `'../../core/CompLibrary.js'` to import the provided components.
What this means to the user is that if you wish to use the `CompLibrary` module, make sure the require path is set correctly. For example, a page at `page/mypage.js` would use a path `'../core/CompLibrary.js'`.
If you wish to use your own components inside the website directory, use `process.cwd()` which will refer to the `website` directory to construct require paths. For example, if you add a component to `website/core/mycomponent.js`, you can use the require path, `'process.cwd() + /core/mycomponent.js'`.
## Provided Components
Docusaurus provides the following components in `CompLibrary`:
### `CompLibrary.MarkdownBlock`
A React component that parses markdown and renders to HTML.
Example:
```jsx
const MarkdownBlock = CompLibrary.MarkdownBlock;
<MarkdownBlock>
[Markdown syntax for a link](http://www.example.com)
</MarkdownBlock>;
```
### `CompLibrary.Container`
A React container component using Docusaurus styles. Has optional padding and background color props that you can configure.
**Props**
| Prop | Type | Default | Description |
| ------------ | ---------------------------------------------------------- | ------- | ----------------------------------- |
| `padding` | Array of `'all'`, `'bottom'`, `'left'`, `'right'`, `'top'` | `[]` | Positions of the padding. |
| `background` | One of `'dark'`, `'highlight'`, `'light'` | `null` | Background styling of the element. |
| `className` | String | - | Custom class to add to the element. |
**Example**
```jsx
<Container
padding={['bottom', 'top']}
background="light"
className="myCustomClass">
...
</Container>
```
### `CompLibrary.GridBlock`
A React component to organize text and images.
**Props**
| Prop | Type | Default | Description |
| ----------- | ----------------------------------------------------- | ------------- | ---------------------------------------------------------------------------------------------------------------- |
| `align` | One of `'left'`, `'center'`, `'right'` | `'left'` | Text alignment of content. |
| `layout` | One of `'twoColumn'`, `'threeColumn'`, `'fourColumn'` | `'twoColumn'` | Number of column sections in the `GridBlock`. |
| `className` | String | - | Custom class to add to the element. |
| `contents` | Array of content objects | `[]` | Contents of each section of the GridBlock. Refer to the next table for the fields available on a content object. |
**Content Object**
| Key | Type | Default | Description |
| ------------ | ----------------------------------------------- | -------- | ----------------------------------------------------------------- |
| `title` | String | - | The display title of this section, which is parsed using Markdown |
| `content` | String | - | The text of this section, which is parsed using Markdown |
| `image` | String | - | The path of the display image |
| `imageAlt` | String | - | The text that will be shown in case the image is not available |
| `imageAlign` | One of `'top'`, `'left'`, `'bottom'`, `'right'` | `'left'` | Image alignment relative to the text |
| `imageLink` | String | - | Link destination from clicking the image |
**Example**
```jsx
<GridBlock
align="center"
layout="threeColumn"
className="myCustomClass"
contents={[
{
title: `[Learn](${siteConfig.baseUrl}${siteConfig.docsUrl}/tutorial.html)`,
content: 'Learn how to use this project',
image: siteConfig.baseUrl + 'img/learn.png',
imageAlt: 'Learn how to use this project',
imageLink: siteConfig.baseUrl + 'docs/tutorial.html',
},
{
title: 'Frequently Asked Questions',
content: 'Questions gathered from the community',
image: siteConfig.baseUrl + 'img/faq.png',
imageAlign: 'top',
},
{
title: 'More',
content: 'Lots of documentation is on this site',
},
]}
/>
```
More examples of how these components are used can be found in the [generated example files](getting-started-preparation.md) as well as in Docusaurus' own repository for its website set-up.
## Translating Strings
When translations are enabled, any pages inside `website/pages/en` will be translated for all enabled languages. URLs for non-English pages will use their language tags as specified in the `languages.js` file. E.g. The URL for a French page of `website/pages/en/help.js` would be found at `${baseUrl}fr/help.html`.
When writing pages that you wish to translate, wrap any strings to be translated inside a `<translate>` tag. e.g.,
```jsx
<p>
<translate>I like translations</translate>
</p>
```
You can also provide an optional description attribute to provide context for translators. e.g,
```jsx
<a href="/community">
<translate desc="Footer link to page referring to community GitHub and Slack">
Community
</translate>
</a>
```
Add the following require statement as well:
```js
const translate = require('../../server/translate.js').translate;
```
Note that this path is valid for files inside `pages/en` and should be adjusted accordingly if files are in different locations, as discussed [above](#page-require-paths).
## Using Static Assets
Static assets should be placed into the `website/static` directory. They can be accessed by their paths, excluding `static`. For example, if the site's `baseUrl` is `/docusaurus/`, an image in `website/static/img/logo.png` is available at `/docusaurus/img/logo.png`.
## Styles
You should configure your site's primary, secondary, and code block colors using the `colors` field in `siteConfig` as specified [here](api-site-config.md). You can also configure other colors in the same way as described in the `siteConfig` doc.
There are several ways to access the default styles provided for your site. If you have started developing your website and executed the `docusaurus-init` or `yarn install` command, your default styles can be found at `website/node_modules/docusaurus/lib/static/css/main.css`. Alternatively, the `main.css` file may be inspected directly at the [Docusarus GitHub repository](https://github.com/facebook/docusaurus/blob/master/packages/docusaurus-1.x/lib/static/css/main.css).
You can provide your own custom styles by adding them anywhere in the `website/static` directory. Any `.css` files you provide in the `static` directory will get concatenated to the end of Docusaurus' provided styles, allowing you to add to or override Docusaurus default styles as you wish.
An easy way to figure out what classes you wish to override or add to is to [start your server locally](api-commands.md) and use your browser's inspect element tool.

119
website-1.x/versioned_docs/version-1.8.0/getting-started-installation.md Normal file
View file

@ -0,0 +1,119 @@
---
id: version-1.8.0-installation
title: Installation
original_id: installation
---
Docusaurus was designed from the ground up to be easily installed and used to get your website up and running quickly.
## Installing Docusaurus
We have created an easy script that will get all of the infrastructure set up for you:
1. Ensure you have the latest version of [Node](https://nodejs.org/en/download/) installed. We also recommend you install [Yarn](https://yarnpkg.com/en/docs/install) as well.
> You have to be on Node >= 8.x and Yarn >= 1.5.
1. Create a project, if none exists, and change your directory to this project's root.
You will be creating the docs in this directory. The root directory may
contain other files. The Docusaurus installation script will create two new
directories: `docs-examples-from-docusaurus` and `website`.
> Commonly, either an existing or newly created GitHub project will be the location for your Docusaurus site, but that is not mandatory to use Docusaurus.
1. Run the Docusaurus installation script: `npx docusaurus-init`.
> If you don't have Node 8.2+ or if you prefer to install Docusaurus globally, run `yarn global add docusaurus-init` or `npm install --global docusaurus-init`. After that, run `docusaurus-init`.
## Verifying Installation
Along with previously existing files and directories, your root directory will now contain a structure similar to:
```bash
root-directory
├── docs-examples-from-docusaurus
│ ├── doc1.md
│ ├── doc2.md
│ ├── doc3.md
│ ├── exampledoc4.md
│ └── exampledoc5.md
└── website
├── blog-examples-from-docusaurus
│ ├── 2016-03-11-blog-post.md
│ ├── 2017-04-10-blog-post-two.md
│ ├── 2017-09-25-testing-rss.md
│ ├── 2017-09-26-adding-rss.md
│ └── 2017-10-24-new-version-1.0.0.md
├── core
│ └── Footer.js
├── package.json
├── pages
├── sidebars.json
├── siteConfig.js
└── static
```
## Running the example website
After running the Docusaurus initialization script, `docusaurus-init` as
described in the [Installation](#installing-docusaurus) section, you will have a
runnable, example website to use as your site's base. To run:
1. In your root, rename `docs-examples-from-docusaurus` to `docs`.
1. `cd website`
1. Rename `blog-examples-from-docusaurus` to `blog`.
1. From within the `website` directory, run the local webserver using
`yarn start` or `npm start`.
1. Load the example site at http://localhost:3000 if it did not already open
automatically.
You should see the example site loaded in your web browser. There's also a LiveReload server running and any changes made to the docs and files in the `website` directory will cause the page to refresh.
![](/img/getting-started-preparation-verify.png)
### Launching the server behind a proxy
If you are behind a corporate proxy, you need to disable it for the development server requests. It can be done using the `NO_PROXY` environment variable.
```sh
SET NO_PROXY=localhost
yarn start (or npm run start)
```
## Updating Your Docusaurus Version
At any time after Docusaurus is installed, you can check your current version of Docusaurus by going into the `website` directory and typing `yarn outdated docusaurus` or `npm outdated docusaurus`.
You will see something like this:
```
$ yarn outdated
Using globally installed version of Yarn
yarn outdated v1.5.1
warning package.json: No license field
warning No license field
info Color legend :
"<red>" : Major Update backward-incompatible updates
"<yellow>" : Minor Update backward-compatible features
"<green>" : Patch Update backward-compatible bug fixes
Package Current Wanted Latest Package Type URL
docusaurus 1.0.9 1.2.0 1.2.0 devDependencies https://github.com/facebook/Docusaurus#readme
✨ Done in 0.41s.
```
> If there is no noticeable version output from the `outdated` commands, then you are up-to-date.
You can update to the [latest version](https://www.npmjs.com/package/docusaurus) of Docusaurus by:
```
yarn upgrade docusaurus --latest
```
or
```
npm update docusaurus
```
> If you are finding that you are getting errors after your upgrade, try to either clear your Babel cache (usually it's in a [temporary directory](https://babeljs.io/docs/en/babel-register/#environment-variables) or run the Docusaurus server (e.g., `yarn start`) with the `BABEL_DISABLE_CACHE=1` environment configuration.

245
website-1.x/versioned_docs/version-1.8.0/getting-started-publishing.md Normal file
View file

@ -0,0 +1,245 @@
---
id: version-1.8.0-publishing
title: Publishing your site
original_id: publishing
---
You should now have a [site up and running locally](getting-started-site-creation.md). Once you have [customized](api-site-config.md) it to your liking, it's time to publish it. Docusaurus generates a static HTML website that is ready to be served by your favorite web server or online hosting solution.
## Building Static HTML Pages
To create a static build of your website, run the following script from the `website` directory:
```bash
yarn run build # or `npm run build`
```
This will generate a `build` directory inside the `website` directory containing the `.html` files from all of your docs and other pages included in `pages`.
## Hosting Static HTML Pages
At this point, you can grab all of the files inside the `website/build` directory and copy them over to your favorite web server's `html` directory.
> For example, both Apache and nginx serve content from `/var/www/html` by default. That said, choosing a web server or provider is outside the scope of Docusaurus.
> When serving the site from your own web server, ensure the web server is serving the asset files with the proper HTTP headers. CSS files should be served with the `content-type` header of `text/css`. In the case of nginx, this would mean setting `include /etc/nginx/mime.types;` in your `nginx.conf` file. See [this issue](https://github.com/facebook/Docusaurus/issues/602) for more info.
### Hosting on a Service:
* [GitHub Pages](#using-github-pages)
* [Netlify](#hosting-on-netlify)
### Using GitHub Pages
Docusaurus was designed to work really well with one of the most popular hosting solutions for open source projects: [GitHub Pages](https://pages.github.com/).
#### Deploying to GitHub Pages
1. Docusaurus supports deploying as [project pages or user/organization pages](https://help.github.com/articles/user-organization-and-project-pages), your code repository does not even need to be public.
> Even if your repository is private, anything published to a `gh-pages` branch will be [public](https://help.github.com/articles/user-organization-and-project-pages/).
__Note:__ When you deploy as user/organization page, the publish script will deploy these sites to the root of the __`master`__ branch of the _username_.github.io repo. In this case, note that you will want to have the Docusaurus infra, your docs, etc. either in __another branch of the _username_.github.io repo__ (e.g., maybe call it `source`), or in another, separate repo (e.g. in the same as the documented source code).
2. You will need to modify the file `website/siteConfig.js` and add the required parameters.
| Name | Description |
| ------------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `organizationName` | The GitHub user or organization that owns the repository. If you are the owner, then it is your GitHub username. In the case of Docusaurus, that would be the "_facebook_" GitHub organization. |
| `projectName` | The name of the GitHub repository for your project. For example, the source code for Docusaurus is hosted at https://github.com/facebook/docusaurus, so our project name in this case would be "docusaurus". |
| `url` | Your website's URL. For projects hosted on GitHub pages, this will be "https://_username_.github.io" |
| `baseUrl` | Base URL for your project. For projects hosted on GitHub pages, it follows the format "/_projectName_/". For https://github.com/facebook/docusaurus, `baseUrl` is `/docusaurus/`. |
```js
const siteConfig = {
...
url: 'https://__userName__.github.io', // Your website URL
baseUrl: '/testProject/',
projectName: 'testProject',
organizationName: 'userName'
...
}
```
In case you want to deploy as a user or organization site, specify the project name as `<username>.github.io` or `<orgname>.github.io`. E.g. If your GitHub username is "user42" then _user42.github.io_, or in the case of an organization name of "org123", it will be _org123.github.io_.
__Note:__ Not setting the `url` and `baseUrl` of your project might result in incorrect file paths generated which can cause broken links to assets paths like stylesheets and images.
> While we recommend setting the `projectName` and `organizationName` in `siteConfig.js`, you can also use environment variables `ORGANIZATION_NAME` and `PROJECT_NAME`.
3. Now you have to specify the git user as an environment variable, and run the script [`publish-gh-pages`](./api-commands.md#docusaurus-publish)
| Name | Description |
| ---------- | ------------------------------------------------------------------------------------------------------------------------------------------------ |
| `GIT_USER` | The username for a GitHub account that has commit access to this repo. For your own repositories, this will usually be your own GitHub username. The specified `GIT_USER` must have push access to the repository specified in the combination of `organizationName` and `projectName`. |
To run the script directly from the command-line, you can use the following, filling in the parameter values as appropriate.
```bash
GIT_USER=<GIT_USER> \
CURRENT_BRANCH=master \
USE_SSH=true \
yarn run publish-gh-pages # or `npm run publish-gh-pages`
```
There are also two optional parameters that are set as environment variables:
| Name | Description |
| ---------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `USE_SSH` | If this is set to `true`, then SSH is used instead of HTTPS for the connection to the GitHub repo. HTTPS is the default if this variable is not set. |
| `CURRENT_BRANCH` | The branch that contains the latest docs changes that will be deployed. Usually, the branch will be `master`, but it could be any branch (default or otherwise) except for `gh-pages`. If nothing is set for this variable, then the current branch will be used. |
If you run into issues related to SSH keys, visit [GitHub's authentication documentation](https://help.github.com/articles/connecting-to-github-with-ssh/).
You should now be able to load your website by visiting its GitHub Pages URL, which could be something along the lines of https://_username_.github.io/_projectName_, or a custom domain if you have set that up. For example, Docusaurus' own GitHub Pages URL is https://facebook.github.io/Docusaurus because it is served from the `gh-pages` branch of the https://github.com/facebook/docusaurus GitHub repository. However, it can also be accessed via https://docusaurus.io/, via a generated `CNAME` file which can be configured via the `cname` [siteConfig option](api-site-config.md#cname-string).
We highly encourage reading through the [GitHub Pages documentation](https://pages.github.com) to learn more about how this hosting solution works.
You can run the command above any time you update the docs and wish to deploy the changes to your site. Running the script manually may be fine for sites where the documentation rarely changes and it is not too much of an inconvenience to remember to manually deploy changes.
However, you can automate the publishing process with continuous integration (CI).
## Automating Deployments Using Continuous Integration
Continuous integration (CI) services are typically used to perform routine tasks whenever new commits are checked in to source control. These tasks can be any combination of running unit tests and integration tests, automating builds, publishing packages to NPM, and yes, deploying changes to your website. All you need to do to automate deployment of your website is to invoke the `publish-gh-pages` script whenever your docs get updated. In the following section we'll be covering how to do just that using [CircleCI](https://circleci.com/), a popular continuous integration service provider.
### Using CircleCI 2.0
If you haven't done so already, you can [setup CircleCI](https://circleci.com/signup/) for your open source project. Afterwards, in order to enable automatic deployment of your site and documentation via CircleCI, just configure Circle to run the `publish-gh-pages` script as part of the deployment step. You can follow the steps below to get that setup.
1. Ensure the GitHub account that will be set as the `GIT_USER` has `write` access to the repository that contains the documentation, by checking `Settings | Collaborators & teams` in the repository.
1. Log into GitHub as the `GIT_USER`.
1. Go to https://github.com/settings/tokens for the `GIT_USER` and generate a new [personal access token](https://help.github.com/articles/creating-a-personal-access-token-for-the-command-line/), granting it full control of private repositories through the `repository` access scope. Store this token in a safe place, making sure to not share it with anyone. This token can be used to authenticate GitHub actions on your behalf in place of your GitHub password.
1. Open your CircleCI dashboard, and navigate to the Settings page for your repository, then select "Environment variables". The URL looks like https://circleci.com/gh/ORG/REPO/edit#env-vars, where "ORG/REPO" should be replaced with your own GitHub organization/repository.
1. Create a new environment variable named `GITHUB_TOKEN`, using your newly generated access token as the value.
1. Create a `.circleci` directory and create a `config.yml` under that directory.
1. Copy the text below into `.circleci/config.yml`.
```yaml
# If you only want circle to run on direct commits to master, you can uncomment this out
# and uncomment the filters: *filter-only-master down below too
#
# aliases:
# - &filter-only-master
# branches:
# only:
# - master
version: 2
jobs:
deploy-website:
docker:
# specify the version you desire here
- image: circleci/node:8.11.1
steps:
- checkout
- run:
name: Deploying to GitHub Pages
command: |
git config --global user.email "<GITHUB_USERNAME>@users.noreply.github.com"
git config --global user.name "<YOUR_NAME>"
echo "machine github.com login <GITHUB_USERNAME> password $GITHUB_TOKEN" > ~/.netrc
cd website && yarn install && GIT_USER=<GIT_USER> yarn run publish-gh-pages
workflows:
version: 2
build_and_deploy:
jobs:
- deploy-website:
# filters: *filter-only-master
```
Make sure to replace all `<....>` in the `command:` sequence with appropriate values. For `<GIT_USER>`, it should be a GitHub account that has access to push documentation to your GitHub repository. Many times `<GIT_USER>` and `<GITHUB_USERNAME>` will be the same.
**DO NOT** place the actual value of `$GITHUB_TOKEN` in `circle.yml`. We already configured that as an environment variable back in Step 3.
> If you want to use SSH for your GitHub repository connection, you can set `USE_SSH=true`. So the above command would look something like: `cd website && npm install && GIT_USER=<GIT_USER> USE_SSH=true npm run publish-gh-pages`.
> Unlike when you run the `publish-gh-pages` script manually, when the script runs within the Circle environment, the value of `CURRENT_BRANCH` is already defined as an [environment variable within CircleCI](https://circleci.com/docs/1.0/environment-variables/) and will be picked up by the script automatically.
Now, whenever a new commit lands in `master`, CircleCI will run your suite of tests and, if everything passes, your website will be deployed via the `publish-gh-pages` script.
> If you would rather use a deploy key instead of a personal access token, you can by starting with the CircleCI [instructions](https://circleci.com/docs/1.0/adding-read-write-deployment-key/) for adding a read/write deploy key.
### Tips & Tricks
When initially deploying to a `gh-pages` branch using CircleCI, you may notice that some jobs triggered by commits to the `gh-pages` branch fail to run successfully due to a lack of tests (This can also result in chat/slack build failure notifications).
You can work around this easily by:
- Setting the environment variable `CUSTOM_COMMIT_MESSAGE` flag to the `publish-gh-pages` command with the contents of `[skip ci]`.
e.g.
```bash
CUSTOM_COMMIT_MESSAGE="[skip ci]" \
yarn run publish-gh-pages # or `npm run publish-gh-pages`
```
- Alternatively you can work around this by creating a basic CircleCI config with the following contents:
```yaml
# CircleCI 2.0 Config File
# This config file will prevent tests from being run on the gh-pages branch.
version: 2
jobs:
build:
machine: true
branches:
ignore: gh-pages
steps:
- run: echo "Skipping tests on gh-pages branch"
```
Save this file as `config.yml` and place it in a `.circleci` directory inside your `website/static` directory.
### Using Travis CI
1. Go to https://github.com/settings/tokens and generate a new [personal access token](https://help.github.com/articles/creating-a-personal-access-token-for-the-command-line/)
1. Using your GitHub account, [add the Travis CI app](https://github.com/marketplace/travis-ci) to the repository you want to activate.
1. Open your Travis CI dashboard. The URL looks like https://travis-ci.com/USERNAME/REPO, and navigate to the `More options` > `Setting` > `Environment Variables` section of your repository.
1. Create a new environment variable named `GH_TOKEN` with your newly generated token as its value, then `GH_EMAIL` (your email address) and `GH_NAME` (your GitHub username).
1. Create a `.travis.yml` on the root of your repository with below text.
```yaml
# .travis.yml
language: node_js
node_js:
- '8'
branches:
only:
- master
cache:
yarn: true
script:
- git config --global user.name "${GH_NAME}"
- git config --global user.email "${GH_EMAIL}"
- echo "machine github.com login ${GH_NAME} password ${GH_TOKEN}" > ~/.netrc
- cd website && yarn install && GIT_USER="${GH_NAME}" yarn run publish-gh-pages
```
Now, whenever a new commit lands in `master`, Travis CI will run your suite of tests and, if everything passes, your website will be deployed via the `publish-gh-pages` script.
### Hosting on Netlify
Steps to configure your Docusaurus-powered site on Netlify.
1. Select **New site from Git**
1. Connect to your preferred Git provider.
1. Select the branch to deploy. Default is `master`
1. Configure your build steps:
* For your build command enter: `cd website; npm install; npm run build;`
* For publish directory: `website/build/<projectName>` (use the `projectName` from your `siteConfig`)
1. Click **Deploy site**
You can also configure Netlify to rebuild on every commit to your repository, or only `master` branch commits.
### Publishing to GitHub Enterprise
GitHub enterprise installations should work in the same manner as github.com; you only need to identify the organization's GitHub Enterprise host.
| Name | Description |
| ------------- | ---------------------------------------------- |
| `GITHUB_HOST` | The hostname for the GitHub enterprise server. |
Alter your `siteConfig.js` to add a property `'githubHost'` which represents the GitHub Enterprise hostname. Alternatively, set an environment variable `GITHUB_HOST` when executing the publish command.

138
website-1.x/versioned_docs/version-1.8.0/guides-blog.md Normal file
View file

@ -0,0 +1,138 @@
---
id: version-1.8.0-adding-blog
title: Adding a Blog
original_id: adding-blog
---
## Initial Setup
To setup your site's blog, start by creating a `blog` directory within your repo's `website` directory.
Then, add a header link to your blog within `siteConfig.js`:
```js
headerLinks: [
...
{ blog: true, label: 'Blog' },
...
]
```
## Adding Posts
To publish in the blog, create a file within the blog directory with a formatted name of `YYYY-MM-DD-My-Blog-Post-Title.md`. The post date is extracted from the file name.
For example, at `website/blog/2017-08-18-Introducing-Docusaurus.md`:
```yml
---
author: Frank Li
authorURL: https://twitter.com/foobarbaz
authorFBID: 503283835
title: Introducing Docusaurus
---
Lorem Ipsum...
```
## Header Options
The only required field is `title`; however, we provide options to add author information to your blog post as well.
* `author` - The text label of the author byline.
* `authorURL` - The URL associated with the author. This could be a Twitter, GitHub, Facebook account, etc.
* `authorFBID` - The Facebook profile ID that is used to fetch the profile picture.
* `authorImageURL` - The URL to the author's image. (Note: If you use both `authorFBID` and `authorImageURL`, `authorFBID` will take precedence. Don't include `authorFBID` if you want `authorImageURL` to appear.)
* `title` - The blog post title.
## Summary Truncation
Use the `<!--truncate-->` marker in your blog post to represent what will be shown as the summary when viewing all published blog posts. Anything above `<!--truncate-->` will be part of the summary. For example:
```yaml
---
title: Truncation Example
---
All this will be part of the blog post summary.
Even this.
<!--truncate-->
But anything from here on down will not be.
Not this.
Or this.
```
## Changing How Many Blog Posts Show on Sidebar
By default, 5 recent blog posts are shown on the sidebar.
You can configure a specific amount of blog posts to show by adding a `blogSidebarCount` setting to your `siteConfig.js`.
The available options are an integer representing the number of posts you wish to show or a string with the value `'ALL'`.
Example:
```js
blogSidebarCount: 'ALL';
```
## Changing The Sidebar Title
You can configure a specific sidebar title by adding a `blogSidebarTitle` setting to your `siteConfig.js`.
The option is an object which can have the keys `default` and `all`. Specifying a value for `default` allows you to change the default sidebar title. Specifying a value for `all` allows you to change the sidebar title when the `blogSidebarCount` option is set to `'ALL'`.
Example:
```js
blogSidebarTitle: { default: 'Recent posts', all: 'All blog posts' },
```
## RSS Feed
Docusaurus provides a simple RSS feed for your blog posts. Both RSS and Atom feed formats are supported. This data is automatically to your website page's HTML `<HEAD>` tag.
A summary of the post's text is provided in the RSS feed up to the `<!--truncate-->`. If no `<!--truncate-->` tag is found, then all text up 250 characters are used.
## Social Buttons
If you want Facebook and/or Twitter social buttons at the bottom of your blog posts, set the `facebookAppId` and/or `twitter` [site configuration](api-site-config.md) options in `siteConfig.js`.
## Advanced Topics
### I want to run in "Blog Only" mode.
You can run your Docusaurus site without a landing page and instead have your blog load first.
To do this:
1. Create a file `index.html` in `website/static/`.
1. Place the contents of the template below into `website/static/index.html`
1. Customize the `<title>` of `website/static/index.html`
1. Delete the dynamic landing page `website/pages/en/index.js`
> Now, when Docusaurus generates or builds your site, it will copy the file from `static/index.html` and place it in the site's main directory. The static file is served when a visitor arrives on your page. When the page loads it will redirect the visitor to `/blog`.
You can use this template:
```html
<!DOCTYPE HTML>
<html lang="en-US">
<head>
<meta charset="UTF-8">
<meta http-equiv="refresh" content="0; url=blog/">
<script type="text/javascript">
window.location.href = 'blog/';
</script>
<title>Title of Your Blog</title>
</head>
<body>
If you are not redirected automatically, follow this <a href="blog/">link</a>.
</body>
</html>
```

1
website-1.x/versions.json
View file

@ -1,4 +1,5 @@
[
"1.8.0",
"1.7.3",
"1.6.x",
"1.5.x",