\ No newline at end of file
diff --git a/blog/2017/09/26/adding-rss.html b/blog/2017/09/26/adding-rss.html
deleted file mode 100644
index 51a76ce6ef..0000000000
--- a/blog/2017/09/26/adding-rss.html
+++ /dev/null
@@ -1,19 +0,0 @@
-Adding RSS Support · Docusaurus
\ No newline at end of file
diff --git a/blog/2017/10/24/new-version-1.0.0.html b/blog/2017/10/24/new-version-1.0.0.html
deleted file mode 100644
index 3e70acd93d..0000000000
--- a/blog/2017/10/24/new-version-1.0.0.html
+++ /dev/null
@@ -1,18 +0,0 @@
-New Version 1.0.0 · Docusaurus
Docusaurus provides support for writing pages as React components inside the website/pages folder which will share the same header, footer, and styles as the rest of the site.
-
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.
-
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 folder 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 folder, use process.cwd() which will refer to the website folder 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:
-
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 attributes that you can configure.
The align attribute determines text alignment. Text alignment defaults to left and can be set to center or right.
-
The layout attribute determines number of column sections per GridBlock. layout defaults to twoColumn and can be set to threeColumn or fourColumn as well.
-
The contents attribute is an array containing the contents of each section of the GridBlock. Each content object can have the following fields:
-
-
content for the text of this section, which is parsed from markdown
-
image for the path to an image to display
-
imageAlign field for image alignment relative to the text, which defaults to top and can be set to bottom, left, or right
-
title for the title to display for this section, which is parsed from markdown
-
imageLink for a link destination from clicking the image
-
-
Example:
-
<GridBlock
- align="center"
- contents={[
- {
- content: "Learn how to use this project",
- image: siteConfig.baseUrl + "img/learn.png",
- title: `[Learn](${siteConfig.baseUrl}docs/tutorial.html)`,
- imageLink: siteConfig.baseUrl + "docs/tutorial.html"
- },
- {
- content: "Questions gathered from the community",
- image: siteConfig.baseUrl + "img/faq.png",
- imageAlign: "top",
- title: "Frequently Asked Questions"
- },
- {
- content: "Lots of documentation is on this site",
- title: "More"
- }
- ]}
- layout="threeColumn"
-/>
-
-
More examples of how these components are used can be found in the generated example files as well as in Docusaurus's own repo 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.,
-
<p><translate>I like translations</translate></p>
-
-
You can also provide an optional description attribute to provide context for translators. e.g,
-
<a href="/community">
- <translate desc="footer link to page referring to community github and slack">Community</translate>
-</a>
-
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.
-
Using Static Assets
-
Static assets should be placed into the website/static folder. They can be accesssed 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. You can also configure other colors in the same way as described in the siteConfig doc.
-
You can provide your own custom styles by adding them anywhere in the website/static folder. Any .css files you provide in the static folder will get concatenated to the end of Docusaurus's 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 and use your browser's inspect element tool.
\ No newline at end of file
diff --git a/docs/en/blog.html b/docs/en/blog.html
deleted file mode 100644
index e217ace4b2..0000000000
--- a/docs/en/blog.html
+++ /dev/null
@@ -1,67 +0,0 @@
-Adding a Blog · Docusaurus
To publish in the blog, create a file within the blog folder 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:
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 ID that is used to extract the profile picture.
-
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 blog published blog posts. Anything above <!--truncate--> will be part of the summary. For example:
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
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 chacters are used.
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: build and serve the website from a local server
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:
-
yarn run start
-
-
The same script can be invoked using npm:
-
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:
-
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:
-
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.
-
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.
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. Specify a feature translations or versions to generate the extra example files for that feature.
-
-
docusaurus-publish
-
Alias: publish-gh-pages
-
Builds, then deploys the static website to GitHub Pages. This command is meant to be run during the deployment step in Circle CI, and therefore expects a few environment variables to be defined:
-
-
GIT_USER: The git user to be associated with the deploy commit.
-
CIRCLE_BRANCH: The git branch associated with the commit that triggered the CI run.
-
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".
-
CI_PULL_REQUEST: Expected to be truthy if the current CI run was triggered by a commit in a pull request.
-
-
You can learn more about configuring automatic deployments with CircleCI in the Publishing guide.
This script will build the static website, apply translations if necessary, and then start a local server. The website will be served from port 3000 by default.
-
-
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 folder. Useful for capturing snapshots of API docs that map to specific versions of your software. Accepts any string as a version number.
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 to learn more.
You can add pages to your site that are not part of the standard docs or blog markdown files. You can do this by adding .js files to the website/pages directory. These files are React components and the render() is called to create them, backed by CSS classes, etc.
You can start your local server and go to http://localhost:3000 to see what the example home page looks like. From there, edit the website/pages/en/index.js file and its various components to use the images and text you want for your project.
-
Adding Other Custom Pages
-
Docusaurus provides some simple example pages in the website/pages/en directory, including index.js, users.js, and help.js. These are good examples to showcase how to create a custom page for Docusaurus.
Of course, you are also free to write your own pages. It is strongly suggested that you at least have an index page, but none of the pages provided are mandatory to include in your site. More information on how to use the provided components or include your own can be found here. Information on how to link to your different pages in the header navigation bar can be found here.
-
Adding Static Pages
-
Static .html files can also be used, but they will not include Docusaurus's header, footer, or styles by default. These can be added to the static folder in the same way as other static assets. Alternatively, they can be placed in the pages folder and would be served as-is instead of being rendered from React.
-
If you wish to use Docusaurus's stylesheet, you can access it at ${baseUrl}css/main.css. If you wish to use separate css for these static pages, you can exclude them from being concatenated to Docusaurus's styles by adding them into the siteConfig.separateCss field in siteConfig.js.
-
Customizing Your Site Footer
-
Starting from the example core/Footer.js file that was created when you ran the Docusaurus initialization script, edit the footer to include any links to pages on your site or other sites that you wish to have.
-
The example provided has three columns with a footer image on the left and Facebook's open source logo and copyright at the bottom. If your project is not a Facebook open source project, remove the logo and copyright. Otherwise, feel free to get creative with your footer and make it look however you'd like!
-
Some suggestions for links you may want to provide: documentation, API, Twitter, Discord, Facebook groups, Stack Overflow, GitHub, etc.
-
Your footer will automatically get applied to all pages on your site, including docs and blog posts. The sole exception to this is any static html pages you include.
-
If you do not want a footer for your site, change the render function of core/Footer.js to return null. e.g.,
\ No newline at end of file
diff --git a/docs/en/doc-markdown.html b/docs/en/doc-markdown.html
deleted file mode 100644
index a9e862f7ff..0000000000
--- a/docs/en/doc-markdown.html
+++ /dev/null
@@ -1,117 +0,0 @@
-Markdown Features · Docusaurus
Documents use the following markdown header fields that are enclosed by a line --- on either side:
-
id: A unique document id. If this field is not present, the document's id will default to it's file name (without the extension).
-
title: The title of your document. If this field is not present, the document's title will default to it's id.
-
sidebar_label: The text shown in the document sidebar for this document. If this field is not present, the document's sidebar_label will default to it's title.
-
For example:
-
---
-id: doc1
-title: My Document
-sidebar_label: Document
----
-
-
Versioned documents have their ids altered to include the version number when they get copied. The new id is version-${version}-${id} where ${version} is the version number of that document and ${id} is the original id. Additionally, versioned documents get an added original_id field with the original document id.
Blog Posts use the following markdown header fields that are enclosed by a line --- on either side:
-
title: The title of this blog post.
-
author: The author of this blog post. If this field is omitted, no author name will be shown.
-
authorURL: A page to link to when a site user clicks the author's name. If this field is omitted, the author's name will not link to anything.
-
authorFBID: The author's Facebook id, used only to get the author's profile picture to display with the blog post. If this field is omitted, no author picture will be shown for the blog post.
-
For example:
-
---
-title: My First Blog Post
-author: Frank Li
-authorURL: http://twitter.com/franchementli
-authorFBID: 100002976521003
----
-
-
Extra Features
-
Docusaurus supports some extra features when writing documentation in markdown.
-
Linking other Documents
-
You can use relative urls to other documentation files which will automatically get converted to the corresponding html links when they get rendered.
-
Example:
-
[This links to another document](other-document.md)
-
-
This markdown will automatically get converted into a link to /docs/other-document.html (or the appropriately translated/versioned link) once it gets rendered.
-
This can help when you want to navigate through docs on GitHub since the links there will be functional links to other documents (still on GitHub), but the documents will have the correct html links when they get rendered.
-
Linking to Images and Other Assets
-
Static assets can be linked to in the same way that documents are, using relative urls. Static assets used in documents and blogs should go into docs/assets and website/blog/assets, respectively. The markdown will get converted into correct link paths so that these paths will work for documents of all languages and versions.
-
Example:
-

-
-
Generating Table of Contents
-
You can make an autogenerated list of links, which can be useful as a table of contents for API docs.
-
In your markdown file, insert a line with the text <AUTOGENERATED_TABLE_OF_CONTENTS>. Write your documentation using h3 headers for each function inside a code block. These will be found by Docusaurus and a list of links to these sections will inserted at the text <AUTOGENERATED_TABLE_OF_CONTENTS>.
-
Example:
-
### `docusaurus.function(a, b)`
-
-Text describing my function
-
-
-### `docdoc(file)`
-
-Text describing my function
-
-
will lead to a table of contents of the functions:
-
- `docusaurus.function(a, b)`
-- `docdoc(file)`
-
-
and each function will link to their corresponding sections in the page.
-
Syntax Highlighting
-
Syntax highlighting is enabled by default on fenced code blocks. The language should be detected automatically, but you can sometimes get better results by specifying the language. You can do so using an info string, following the three opening backticks. The following JavaScript example...
Highlighting is provided by Highlight.js using the theme specified in your siteConfig.js file as part of the highlight key:
-
highlight: {
- theme: 'default'
-}
-
-
You can find the full list of supported themes in the Highlight.js styles directory.
-
Registering additional languages
-
While Highlight.js provides support for many popular languages out of the box, you may find the need to register additional language support. For these cases, we provide an escape valve by exposing the hljs constant as part of the highlight config key. This in turn allows you to call registerLanguage:
Docusaurus was designed from the ground up to be easily installed and used to get your website up an running quickly. To install Docusaurus, we have created an easy script that will get all of the infrastructure setup for you:
-
-
Go into the root of your GitHub repo directory where you will be creating the docs.
-
yarn global add docusaurus-init or npm install --global docusaurus-init
-
docusaurus-init
-
-
Along with previously existing files and directories, your root directory will now contain a structure similar to:
If you do not want to install the init script globally, you can install it locally and then run it from the node_modules directory that is created via ./node_modules/.bin/docusaurus-init. You may want to remove the created package.json file and node_modules directory after you run the script.
\ No newline at end of file
diff --git a/docs/en/navigation.html b/docs/en/navigation.html
deleted file mode 100644
index 0a49ae0ffe..0000000000
--- a/docs/en/navigation.html
+++ /dev/null
@@ -1,117 +0,0 @@
-Navigation and Sidebars · Docusaurus
New markdown files within docs will show up as pages on the website. Links to those documents are created first by using the id in the header of each document. If there is no id field, then the name of the file will serve as the link name.
-
For example, creating an empty file such as "docs/getting-started.md" will enable the new page URL as /docs/getting-started.html.
If you set the id field in the markdown header of the file, the doc will then be accessed from a URL of the form /docs/intro.html.
-
-
You need an id field to be able to add the document to the sidebar.
-
-
Adding Documents to a Sidebar
-
Many times, you will want to add a document to a sidebar that will be associated with one of the headers in the top navigation bar of the website. The most common sidebar, and the one that comes installed when Docusaurus is initialized, is the docs sidebar.
-
-
"docs" is just a name. It has no inherit meaning. You can change it as you wish.
-
-
You configure the contents of the sidebar, and the order of its documents, in the website/sidebars.json file.
-
-
Until you add your document to website/sidebars.json, they will only be accessible via a direct URL. The doc will not show up in any sidebar.
-
-
Within sidebars.json, add the id you used in the document header to existing sidebar/category. In the below case, docs is the name of the sidebar and Getting Started is a category within the sidebar.
Or you can create a new category within the sidebar:
-
{
- "docs": {
- ...
- "My New Sidebar Category": [
- "getting-started"
- ],
- ...
-
-
Adding New Sidebars
-
You can also put a document in a new sidebar. In the following example, we are creating an examples-sidebar sidebar within sidebars.json that has a category called My Example Category containing a document with an id of my-examples.
-
{
- "examples-sidebar": {
- "My Example Category": [
- "my-examples"
- ],
- },
- ...
-
To expose sidebars, you will add clickable labels to the site navigation bar at the top of the website. You can add documents, pages and external links.
-
Adding Documents
-
After creating a new sidebar for the site by adding it to sidebars.json, you can expose the new sidebar from the top navigation bar by editing the headerLinks field of siteConfig.js.
A label called Examples will be added to the site navigation bar and when you click on it at the top of your site, the examples-sidebar will be shown and the default document will be my-examples.
-
Adding Custom Pages
-
To add custom pages to the site navigation bar, entries can be added to the headerLinks of siteConfig.js. For example, if we have a page within website/pages/help.js, we can link to it by adding the following:
A label called Help will be added to the site navigation bar and when you click on it at the top of your site, the content from the help.js page will be shown.
-
Adding External Links
-
Custom links can be added to the site navigation bar with the following entry in siteConfig.js:
A label called GitHub will be added to the site navigation bar and when you click on it at the top of your site, the content of the external link will be shown.
-
-
To open external links in a new tab, provide an external: true flag within the header link config.
-
-
Site Navigation Bar Positioning
-
You have limited control where the search and languages dropdown elements are shown in the site navigation bar at the top of your website.
-
Search
-
If search is enabled on your site, your search bar will appear to the right of your links. If you want to put the search bar between links in the header, add a search entry in the headerLinks config array:
If translations is enabled on your site, the language dropdown will appear to the right of your links (and to the left of the search bar, if search is enabled). If you want to put the language selection drop down between links in the header, add a languages entry in the headerLinks config array:
\ No newline at end of file
diff --git a/docs/en/publishing.html b/docs/en/publishing.html
deleted file mode 100644
index 53b66b1a8f..0000000000
--- a/docs/en/publishing.html
+++ /dev/null
@@ -1,123 +0,0 @@
-Publishing your site · Docusaurus
You should now have a site up and running locally. Once you have customized 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:
-
yarn run build # or `npm run build`
-
-
This will generate a build folder 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 folder 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.
-
-
Using GitHub Pages
-
While choosing a web server or host is outside Docusaurus' scope, Docusaurus was designed to work really well with one of the most popular hosting solutions for open source projects: GitHub Pages.
-
Deploying your Docusaurus site to GitHub Pages is straightforward if you are already using GitHub to host your project. Your code repository does not even need to be public.
-
-
Even if your repo is private, anything published to a gh-pages branch will be public.
-
-
Most of the work to publish to GitHub pages is done for you automatically through the publish-gh-pages script. You just need to determine the values for a few parameters required by the script.
-
Two of the required parameters are set in the siteConfig.js:
-
-
organizationName: The GitHub user or organization that owns the repository. In the case of Docusaurus, that would be the "facebook" GitHub organization.
-
projectName: The name of the GitHub repository for your project. For example, Docusaurus is hosted at https://github.com/facebook/docusaurus, so our project name in this case would be "docusaurus".
-
-
-
While we recommend setting the above in siteConfig.js, you can also use environment variables ORGANIZATION_NAME and PROJECT_NAME.
-
-
One of the required parameters is set as a environment variable:
-
-
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.
-
-
There is also an optional parameter that is set as an environment variable. If nothing is set for this variable, then the current branch will be used.
-
-
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.
-
-
-
Docusaurus also supports deploying user or organization sites. Just set your project name to "username.github.io" (where username is your username or organization name on GitHub) and the publish script will automatically deploy your site to the root of the master branch instead.
-
-
Once you have the parameter value information, you can go ahead and run the publish script, ensuring you have inserted your own values inside the various parameter placeholders:
-
To run the script directly from the command-line, you can use the following, filling in the parameter values as appropriate.
-
GIT_USER=<GIT_USER> \
- CURRENT_BRANCH=master \
- yarn run publish-gh-pages # or `npm run publish-gh-pages`
-
-
-
The specified GIT_USER must have push access to the repository specified in the combination of organizationName and projectName.
-
-
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://docusaurus.io (it can also be accessed via https://facebook.github.io/docusaurus), because it is served from the gh-pages branch of the https://github.com/facebook/docusaurus GitHub repo. We highly encourage reading through the GitHub Pages documentation 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 Circle CI, a popular continuous integration service provider.
-
Using Circle CI
-
If you're already using Circle CI for your project, all you need to do to enable automatic deployments is to configure Circle to run the publish-gh-pages script as part of the deployment step.
-
-
Ensure the GitHub account that will be set as the GIT_USER has write access to the repo that contains the documentation.
-
Log into GitHub as the GIT_USER.
-
Go to https://github.com/settings/tokens for the GIT_USER and generate a new personal access token, granting it full control of private repositories through the repo 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.
-
Open your Circle CI 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 org/repo.
-
Create a new environment variable named "GITHUB_TOKEN", using your newly generated access token as the value.
-
Open your circle.yml file and add the following under the machine: section to tell Circle to use relatively recent versions of node and npm, replacing npm with yarn if applicable:
Make sure to replace <GIT_USER> with the actual username of the GitHub account that will be used to publish the documentation.
-
DO NOT place the actual value of $GITHUB_TOKEN in circle.yml. We already configured that as an environment variable back in Step 3.
-
-
Unlike when you run the publish-gh-pages script manually, when the script runs within the Circle environment, the values of ORGANIZATION_NAME, PROJECT_NAME, and CURRENT_BRANCH are already defined as environment variables within CircleCI 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 Circle CI instructions for adding a read/write deploy key.
-
-
Tips & Tricks
-
When initially deploying to a gh-pages branch using Circle CI, you may notice that some jobs triggered by commits to the gh-pages branch fail to run successfully due to a lack of tests. You can easily work around this by creating a basic Circle CI config with the following contents:
-
# Circle CI 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 folder inside your website/assets folder.
Docusaurus supports search using Algolia DocSearch. Once you have set up your site, enter your site information to have Algolia crawl your website's documentation pages. Algolia will then send you an API key and index name for your site.
-
Enabling the Search Bar
-
Enter your search-only API key and index name into siteConfig.js in the algolia section to enable search for your site.
You can also specify extra search options used by Algolia by using an algoliaOptions field in algolia. This may be useful if you want to provide different search results for the different versions or languages of your docs. Any occurrences of "VERSION" or "LANGUAGE" will be replaced by the version or language of the current page, respectively. More details about search options can be found here.
By default, the search bar will be the rightmost element in the top navigation bar.
-
If you want to change the default location, add the searchBar flag in the headerLinks field of siteConfig.js in your desired location. For example, you may want the search bar in between your internal and external links.
A large part of site configuration is done by editing the siteConfig.js file.
-
User Showcase
-
The users array is used to store objects for each project/user that you want to show on your site. Currently this field is used by example the pages/en/index.js and pages/en/users.js files provided. Each user object should have caption, image, infoLink, and pinned fields. The caption is the text showed when someone hovers over the image of that user, and the infoLink is where clicking the image will bring someon. The pinned field determines whether or not it shows up on the index page.
-
Currently this users array is used only by the index.js and users.js example files. If you do not wish to have a users page or show users on the index page, you may remove this section.
-
siteConfig Fields
-
The siteConfig object contains the bulk of the configuration settings for your website.
-
Mandatory Fields
-
title - Title for your website.
-
tagline - Tagline for your website.
-
url - url for your site.
-
baseUrl - baseUrl for your site.
-
projectName - Project name. This must match your GitHub repo project name (case sensitive).
-
noIndex - Boolean. If true, Docusaurus will politely ask crawlers and search engines to avoid indexing your site. This is done with a header tag and so only applies to docs and pages. Will not attempt to hide static resources. This is a best effort request. Malicious crawlers can and will still index your site.
-
headerLinks - Links that will be used in the header navigation bar. The label field of each object will be the link text and will also be translated for each language.
-
Example Usage:
-
headerLinks: [
- // Links to document with id doc1 for current language/version
- { doc: "doc1", label: "Getting Started" },
- // Link to page found at pages/en/help.js or if that does not exist, pages/help.js, for current language
- { page: "help", label: "Help" },
- // Links to href destination
- { href: "https://github.com/", label: "GitHub" },
- // Links to blog generated by Docusaurus (${baseUrl}blog)
- { blog: true, label: "Blog" },
- // Determines search bar position among links
- { search: true },
- // Determines language drop down position among links
- { languages: true }
-],
-
-
headerIcon - url for icon used in header navigation bar.
-
favicon - url for site favicon.
-
colors - Color configurations for the site.
-
-
primaryColor is the color used the header navigation bar and sidebars.
-
secondaryColor is the color seen in the second row of the header navigation bar when the site window is narrow (including on mobile).
-
Custom color configurations can also be added. For example, if user styles are added with colors specified as $myColor, then adding a myColor field to colors will allow you to easily configure this color.
-
-
copyright - The copyright string at footer of site and within feed
-
Optional Fields
-
customDocsPath - By default, Docusaurus expects your documentation to be in a directory called docs. This directory is at the same level as the website directory (i.e., not inside the website directory). You can specify a custom path to your documentation with this field. *Note that all of your documentation .md files must still reside in a flat hierarchy. You cannot have your documents in nested directories.
-
customDocsPath: "docs/site"
-
-
customDocsPath: "website-docs"
-
-
organizationName - GitHub username of the organization or user hosting this project. This is used by the publishing script to determine where your GitHub pages website will be hosted.
-
editUrl - url for editing docs, usage example: editUrl + 'en/doc1.md'. If this field is omitted, there will be no "Edit this Doc" button for each document.
-
users - The users array mentioned earlier.
-
disableHeaderTitle - An option to disable showing the title in the header next to the header icon. Exclude this field to keep the header as normal, otherwise set to true.
-
disableTitleTagline - An option to disable showing the tagline in the title of main pages. Exclude this field to keep page titles as Title • Tagline. Set to true to make page titles just Title.
-
separateCss - Folders inside which any css files will not be processed and concatenated to Docusaurus's styles. This is to support static html pages that may be separate from Docusaurus with completely separate styles.
-
footerIcon - url for a footer icon. Currently used in the core/Footer.js file provided as an example, but it can be removed from that file.
-
translationRecruitingLink - url for the Help Translate tab of language selection when languages besides English are enabled. This can be included you are using translations but does not have to be.
-
algolia - Information for Algolia search integration. If this field is excluded, the search bar will not appear in the header.
-
gaTrackingId - Google Analytics tracking ID to track page views.
theme is the name of the theme used by Highlight.js when highlighting code.
-
version specifies a particular version of Highlight.js to be used.
-
hljs provides an escape valve by passing an instance of Highlight.js to the function specified here, allowing additional languages to be registered for syntax highlighting.
-
-
markdownPlugins - An array of plugins to be loaded by Remarkable, the markdown parser and renderer used by Docusaurus. The plugin will receive a reference to the Remarkable instance, allowing custom parsing and rendering rules to be defined.
-
scripts - Array of JavaScript sources to load. The script tag will be inserted in the HTML head.
-
stylesheets - Array of CSS sources to load. The link tag will be inserted in the HTML head.
-
cname - The CNAME for your website. It will go into a CNAME file when your site it built.
-
Users can also add their own custom fields if they wish to provide some data across different files.
\ No newline at end of file
diff --git a/docs/en/site-creation.html b/docs/en/site-creation.html
deleted file mode 100644
index be03ba55b2..0000000000
--- a/docs/en/site-creation.html
+++ /dev/null
@@ -1,67 +0,0 @@
-Creating your site · Docusaurus
This assumes that you removed the example .md files that were installed with the initialization script.
-
-
All of your documentation files should be placed inside the docs folder as markdown .md files. Any blog posts should be inside the blog folder.
-
-
The blog posts must be formatted as yyyy-mm-dd-your-file-name.md
-
-
Create Your Basic Site
-
To create a fully functional site, you only need to do a few steps:
-
-
Add your documentation to the /docs folder as .md files, ensuring you have the proper header in each file. The simplest header would be the following, where id is the link name (e.g., docs/intro.html) and the title, is, of course, the title of the browser page.
Add zero or more docs to the sidebars.json file so that your documentation is rendered in a sidebar, if you choose them to be.
-
-
-
If you do not add your documentation to the sidebars.json file, the docs will be rendered, but they can only be linked to from other documentation and visited with the known URL.
-
-
-
Modify the website/siteConfig.js file to configure your site, following the comments included in the docs and the website/siteConfig.js to guide you.
-
Create any custom pages and/or customize the website/core/Footer.js file that provides the footer for your site.
-
Place assets, such as images, in the website/static/ folder.
-
Run the site to see the results of your changes.
-
-
cd website
-yarn run start # or `npm run start`
-# navigate to http://localhost:3000
-
After installing Docusaurus, you now have a skeleton to work from for your specific website. With a few changes, you can verify that Docusaurus was installed correctly by running the site locally.
-
Directory Structure
-
As shown after you installed Docusaurus, the initialization script created a directory structure similar to:
The website/core/Footer.js file is a React component that acts as the footer for the site generated by Docusaurus and should be customized by the user.
-
The website/blog-examples-from-docusaurus folder contains examples of blog posts written in markdown.
-
The docs-examples-from-docusaurus folder contains example documentation files written in markdown.
-
The website/pages folder contains example top-level pages for the site.
-
The website/static folder contains static assets used by the example site.
-
The website/siteConfig.js file is the main configuration file used by Docusaurus.
-
-
You will need to keep the website/siteConfig.js and website/core/Footer.js files, but may edit them as you wish.
-
You should keep the website/pages and website/static folders, but may change the content inside them as you wish. At the bare minimum you should have an en/index.js or en/index.html file inside website/pages and an image to use as your header icon inside website/static.
-
The website/blog-examples-from-docusaurus and docs-examples-from-docusaurus folders contain example blog and document markdown files. As shown below when you verify that the example site runs correctly, if you wish to run Docusaurus with these files, you need to rename the folders to website/blog and docs, respectively.
-
Verifying Installation
-
Running the Docusaurus initialization script, docusaurus-init, produces a runnable, example website to base your site upon.
-
-
In your root, rename docs-examples-from-docusaurus to docs.
-
cd website
-
Rename blog-examples-from-docusaurus to blog.
-
Run the local webserver via yarn run start or npm run start.
-
Load the example site at http://localhost:3000. You should see the example site loaded in your web browser.
Docusaurus allows for easy translation functionality using Crowdin. Documentation files written in English are uploaded to Crowdin for translation by users within a community. Top-level pages written with English strings can be translated by wrapping any strings you want to translate in a <translate> tag. Other titles and labels will also be found and properly translated.
-
Docusaurus Translation Configurations
-
To generate example files for translations with Docusuaurus, run the examples script with the command line argument translations:
The pages/en/help-with-translations.js file includes the same starter help page generated by the examples script, but now includes translation tags.
-
The languages.js file tells Docusaurus what languages you want to enable for your site. By default, we expect English to be enabled.
-
The crowdin.yaml file is used to configure crowdin integration, and is copied up one level into your docusaurus project repo. If your docusaurus project resides in /project/website, then crowdin.yaml will be copied to /project/crowdin.yaml.
-
Translating Your Existing Docs
-
Your documentation files do not need to be changed or moved to support translations. They will be uploaded to Crowdin to be translated directly.
-
Enabling Translations on Pages
-
Pages allow you to customize layout and specific content of pages like a custom index page or help page.
-
Pages with text that you want translated should be placed in website/pages/en folder.
-
Wrap strings you want translated in a <translate> tag, and add the following require statement to the top of the file:
-
...
-const translate = require("../../server/translate.js").translate;
-...
-<h2>
- <translate>This header will be translated</translate>
-</h2>
-...
-
-
You can also include an optional description attribute to give more context to a translator about how to translate the string:
-
<p>
- <translatedesc="flower, not verb">Rose</translate>
-<p>
-
-
Gathering Strings to Translate
-
The strings within localized Pages must be extracted and provided to Crowdin.
-
Add the following script to your package.json file:
Running the script will generate a website/i18n/en.json file containing all the strings that will be translated from English into other languages.
-
The script will include text from the following places:
-
-
title and sidebar_label strings in document markdown headers
-
category names in sidebars.json
-
tagline in siteConfig.js
-
header link label strings in siteConfig.js
-
strings wrapped in the <translate> tag in any .js files inside pages
-
-
How Strings Get Translated
-
Docusaurus itself does not do any translation from one language to another. Instead, it integrates Crowdin to upload translations and then downloads the appropriately translated files from Crowdin.
-
How Docusaurus Uses String Translations
-
This section provides context about how translations in Docusaurus works.
-
Strings
-
A Docusaurus site has many strings used throughout it that require localization. However, maintaining a list of strings used through out a site can be laborious. Docusaurus simplifies this by centralizing strings.
-
The header navigation, for example can have links to 'Home' or your 'Blog'. This and other strings found in the headers and sidebars of pages are extracted and placed into i18n/en.json. When your files are translated, say into Spanish, a i18n/es-ES.json file will be downloaded from Crowdin. Then, when the Spanish pages are generated, Docusaurus will replace the English version of corresponding strings with translated strings from the corresponding localized strings file (e.g. In a Spanish enabled site 'Help' will become 'Ayuda').
-
Markdown Files
-
For documentation files themselves, translated versions of these files are downloaded and then rendered through the proper layout template.
-
Other Pages
-
For other pages, Docusaurus will automatically transform all <translate> tags it finds into function calls that return the translated strings from the corresponding localized file locale.json.
-
Crowdin
-
Crowdin is a company that provides translation services. For Open Source projects, Crowdin provides free string translations
-
Create your translation project on Crowdin. You can use Crowdin's guides to learn more about the translations work flow. We suggest that you deselect and do not include "English" as a translateable language to prevent the creation of en-US localization files as this can lead to confusion.
-
Your project will need a crowdin.yaml file generated.
The example below can be automatically generated by the docusaurus cli with the examples script. It should be placed in the top level of your project directory to configure how and what files are uploaded/downloaded.
-
Below is an example crowdin configuration for the respective languages: German, Spanish, French, Japanese, Korean, Behasa Indonesia, Portuguese Brazilian, Chinese Simplified, and Chinese Traditional.
You can go here to learn more about customizing your crowdin.yaml file.
-
Manual File Sync
-
You will want to manually sync your files to and from crowdin. The sync process will upload any markdown files in /docs as well as translatable strings in website/i18n/en.json. (These strings can be generated by running yarn write-translations.)
-
You can add the following to your package.json to manually trigger crowdin.
These commands require having an environment variable set with your crowdin project id and api key (CROWDIN_PROJECT_ID, CROWDIN_API_KEY). You can add them inline like above or add them permanently to your .bashrc or .bash_profile.
-
If you run more than one localized Docusaurus project on your computer, you should change the name of the enviroment variables to something unique (CROWDIN_PROJECTNAME_PROJECT_ID, CROWDIN_PROJECTNAME_API_KEY).
-
Automated File Sync Using CircleCI
-
You can automate pulling down and uploading translations for your files using the CircleCI web continuous integration service.
-
First, update the circle.yml file in your project directory to include steps to upload English files to be translated and download translated files using the Crowdin CLI. Here is an example circle.yml file:
The crowdin command uses the crowdin.yaml file generated with the examples script. It should be placed in your project directory to configure how and what files are uploaded/downloaded.
-
Note that in the crowdin.yaml file, CROWDIN_PROJECT_ID and CROWDIN_API_KEY are environment variables set-up in Circle for your Crowdin project. They can be found in your Crowdin project settings.
-
Now, Circle will help you automatically get translations prior to building your website. The provided crowdin.yaml file will copy translated documents into website/translated_docs/, and translated versions of the i18n/en.json strings file will into i18n/${language}.json.
-
If you wish to use Crowdin on your machine locally, you can install the Crowdin CLI tool and run the same commands found in the circle.yaml file. The only difference is that you must set project_identifier and api_key values in the crowdin.yaml file since you will not have Circle environment variables set up.
-
Versioned Translations
-
If you wish to have translation and versioning for your documentation, add the following section to the end of your crowdin.yaml file:
Translated, versioned documents will be copied into website/translated_docs/${language}/${version}/.
-
-
Ensure in your Crowdin settings, in the Translations section, that "Duplicate Strings" are set to "Hide - all duplicates will share the same translation". This setting will ensure that identical strings between versions share a single translation.
You can use the version script to cut a new documentation version based on the latest content in the docs folder. That specific set of documentation will then be preserved and accessible even as the documentation in the docs folder changes moving forward.
-
How to Create New Versions
-
Run the following script to generate a starter versions page listing all the site versions:
-
yarn examples translations
-
-
This creates the following file:
-
pages/en/versions.js
-
-
You can edit this file later on to customize how you display the versions.
-
Add the following script to your package.json file if it doesn't already exist:
Run the script with a command line argument of the version you wish to create. e.g.,
-
yarn run version 1.0.0
-
-
This will preserve all documents currently in the docs folder and make them available as documentation for version 1.0.0.
-
If, for example, you ran the version script with 1.0.0 as the version number, version 1.0.0 is considered the latest release version for your project. The site will display the version number next to the title in the header. This version number links to a versions page that you created earlier.
-
Documents in the docs folder will be considered part of version next and they are available, for example, at the url docs/next/doc1.html. Documents from the latest version use the url docs/doc1.html.
-
Running the script again with yarn run version 2.0.0 will create a version 2.0.0, making version 2.0.0 the most recent set of documentation. Documents from version 1.0.0 will use the url docs/1.0.0/doc1.html while 2.0.0 will use docs/doc1.html.
-
Versioning Patterns
-
You can create version numbers in whatever format you wish, and a new version can be created with any version number as long as it does not match an existing version. Version ordering is determined by the order in which versions are created, independently of how they are numbered.
-
Storing Files for Each Version
-
Versioned documents are placed into website/versioned_docs/version-${version}, where ${version} is the version number you supplied the version script.
-
The markdown header for each versioned doc is altered by renaming the id frontmatter field to original_id, then using "version-${version}-${original_id}" as the value for the actual id field.
-
Versioned sidebars are copied into website/versioned_sidebars and are named as version-${version}-sidebars.json.
-
A website/versions.json file is created the first time you cut a version and is used by Docusaurus to detect what versions exist. Each time a new version is added, it gets added to the versions.json file.
-
If you wish to change the documentation for a past version, you can access the files for that respective version.
-
Fallback Functionality
-
Only files in the docs folder and sidebar files that differ from those of the latest version will get copied each time a new version is specified. If there is no change across versions, Docusaurus will use the file from the latest version with that file.
-
For example, a document with the original id doc1 exists for the latest version, 1.0.0, and has the same content as the document with the id doc1 in the docs folder. When a new version 2.0.0 is created, the file for doc1 will not be copied into versioned_docs/version-2.0.0/. There will still be a page for docs/2.0.0/doc1.html, but it will use the file from version 1.0.0.
-
Renaming Existing Versions
-
To rename an existing version number to something else, first make sure the following script is in your package.json file:
Run the script with command line arguments of first, the current version name, then second, the new version name. e.g.,
-
yarn run rename-version 1.0.0 1.0.1
-
-
Versioning and Translations
-
If you wish to use versioning and translations features, the crowdin.yaml file should be set up to upload and download versioned documents to and from Crowdin for translation. Translated, versioned files will go into the folder translated_docs/${language}/version-${version}/. For more information, check out the translations guide.
\ No newline at end of file
diff --git a/docs/installation.html b/docs/installation.html
deleted file mode 100644
index 6acdc54eee..0000000000
--- a/docs/installation.html
+++ /dev/null
@@ -1,5 +0,0 @@
-Docusaurus · Easy to Maintain Open Source Documentation Websites
\ No newline at end of file
diff --git a/docs/navigation.html b/docs/navigation.html
deleted file mode 100644
index 5c3e69d70a..0000000000
--- a/docs/navigation.html
+++ /dev/null
@@ -1,5 +0,0 @@
-Docusaurus · Easy to Maintain Open Source Documentation Websites
\ No newline at end of file
diff --git a/docs/publishing.html b/docs/publishing.html
deleted file mode 100644
index 178d3b162f..0000000000
--- a/docs/publishing.html
+++ /dev/null
@@ -1,5 +0,0 @@
-Docusaurus · Easy to Maintain Open Source Documentation Websites
\ No newline at end of file
diff --git a/docs/search.html b/docs/search.html
deleted file mode 100644
index 3c7bc43101..0000000000
--- a/docs/search.html
+++ /dev/null
@@ -1,5 +0,0 @@
-Docusaurus · Easy to Maintain Open Source Documentation Websites
\ No newline at end of file
diff --git a/docs/site-config.html b/docs/site-config.html
deleted file mode 100644
index fcb6ab935f..0000000000
--- a/docs/site-config.html
+++ /dev/null
@@ -1,5 +0,0 @@
-Docusaurus · Easy to Maintain Open Source Documentation Websites
\ No newline at end of file
diff --git a/docs/site-creation.html b/docs/site-creation.html
deleted file mode 100644
index 07ac7d0601..0000000000
--- a/docs/site-creation.html
+++ /dev/null
@@ -1,5 +0,0 @@
-Docusaurus · Easy to Maintain Open Source Documentation Websites
\ No newline at end of file
diff --git a/docs/site-preparation.html b/docs/site-preparation.html
deleted file mode 100644
index 6192a6691f..0000000000
--- a/docs/site-preparation.html
+++ /dev/null
@@ -1,5 +0,0 @@
-Docusaurus · Easy to Maintain Open Source Documentation Websites
\ No newline at end of file
diff --git a/docs/translation.html b/docs/translation.html
deleted file mode 100644
index 879f2e8496..0000000000
--- a/docs/translation.html
+++ /dev/null
@@ -1,5 +0,0 @@
-Docusaurus · Easy to Maintain Open Source Documentation Websites
\ No newline at end of file
diff --git a/docs/versioning.html b/docs/versioning.html
deleted file mode 100644
index c2eaa5908c..0000000000
--- a/docs/versioning.html
+++ /dev/null
@@ -1,5 +0,0 @@
-Docusaurus · Easy to Maintain Open Source Documentation Websites
\ No newline at end of file
diff --git a/en/help.html b/en/help.html
deleted file mode 100644
index 60fc5bc8b3..0000000000
--- a/en/help.html
+++ /dev/null
@@ -1,17 +0,0 @@
-Docusaurus · Easy to Maintain Open Source Documentation Websites
Submit issues and pull requests for any new features you may want to see or bugs you've found on GitHub.
-
Stay up to date
-
Find out what's new with this project by checking back on the site.
-
\ No newline at end of file
diff --git a/en/index.html b/en/index.html
deleted file mode 100644
index f62b3390e3..0000000000
--- a/en/index.html
+++ /dev/null
@@ -1,51 +0,0 @@
-Docusaurus · Easy to Maintain Open Source Documentation Websites
Save time and focus on your project's documentation. Simply
-write docs and blog posts with Markdown
-and Docusaurus will publish a set of static html files ready
-to serve.
-
Built Using React
-
Extend or customize
-your project's layout by reusing React. Docusaurus can be
-extended while reusing the same header and footer.
-
Ready for Translations
-
Localization
-comes pre-configured. Use Crowdin to translate your docs
-into over 70 languages.
-
Document Versioning
-
Support users on all versions of your project. Document
-versioning
-helps you keep documentation in sync with project releases.
Get up and running
-quickly without having having to worry about site design.
-
Develop and Deploy
-
Make design and documentation changes by using the included
-live server.
-Publish
-your site to GitHub pages or other static file hosts
-manually, using a script, or with continuous integration
-like CircleCI.
\ No newline at end of file
diff --git a/en/users.html b/en/users.html
deleted file mode 100644
index 6b13ae07b3..0000000000
--- a/en/users.html
+++ /dev/null
@@ -1,11 +0,0 @@
-Docusaurus · Easy to Maintain Open Source Documentation Websites
\ No newline at end of file
diff --git a/help.html b/help.html
deleted file mode 100644
index 60fc5bc8b3..0000000000
--- a/help.html
+++ /dev/null
@@ -1,17 +0,0 @@
-Docusaurus · Easy to Maintain Open Source Documentation Websites
Save time and focus on your project's documentation. Simply
-write docs and blog posts with Markdown
-and Docusaurus will publish a set of static html files ready
-to serve.
-
Built Using React
-
Extend or customize
-your project's layout by reusing React. Docusaurus can be
-extended while reusing the same header and footer.
-
Ready for Translations
-
Localization
-comes pre-configured. Use Crowdin to translate your docs
-into over 70 languages.
-
Document Versioning
-
Support users on all versions of your project. Document
-versioning
-helps you keep documentation in sync with project releases.
Get up and running
-quickly without having having to worry about site design.
-
Develop and Deploy
-
Make design and documentation changes by using the included
-live server.
-Publish
-your site to GitHub pages or other static file hosts
-manually, using a script, or with continuous integration
-like CircleCI.