diff --git a/__pycache__/__init__.cpython-33.pyc b/__pycache__/__init__.cpython-33.pyc deleted file mode 100644 index 6ad08228..00000000 Binary files a/__pycache__/__init__.cpython-33.pyc and /dev/null differ diff --git a/__pycache__/__init__.cpython-34.pyc b/__pycache__/__init__.cpython-34.pyc deleted file mode 100644 index 004f0efd..00000000 Binary files a/__pycache__/__init__.cpython-34.pyc and /dev/null differ diff --git a/__pycache__/__init__.cpython-35.pyc b/__pycache__/__init__.cpython-35.pyc deleted file mode 100644 index 2bc8dd3a..00000000 Binary files a/__pycache__/__init__.cpython-35.pyc and /dev/null differ diff --git a/about/contributing/index.json b/about/contributing/index.json deleted file mode 100644 index 0405be64..00000000 --- a/about/contributing/index.json +++ /dev/null @@ -1,6 +0,0 @@ -{ - "content": "
An introduction to contributing to the MkDocs project.
\nThe MkDocs project welcomes, and depends, on contributions from developers and\nusers in the open source community. Contributions can be made in a number of\nways, a few examples are:
\nPlease include as much detail as you can. Let us know your platform and MkDocs\nversion. If the problem is visual (for example a theme or design issue) please\nadd a screenshot and if you get an error please include the the full error and\ntraceback.
\nIf you want to just install and try out the latest development version of\nMkDocs you can do so with the following command. This can be useful if you\nwant to provide feedback for a new feature or want to confirm if a bug you\nhave encountered is fixed in the git master. It is strongly recommended\nthat you do this within a virtualenv.
\npip install https://github.com/mkdocs/mkdocs/archive/master.tar.gz\n\n\nFirst you'll need to fork and clone the repository. Once you have a local\ncopy, run the following command. It is strongly recommended that you do\nthis within a virtualenv.
\npip install --editable .\n\n\nThis will install MkDocs in development mode which binds the mkdocs command\nto the git repository.
To run the tests, it is recommended that you use Tox. This just needs\nto be pip installed and then the test suite can be ran for MkDocs but running\nthe command tox in the root of your MkDocs repository.
It will attempt to run the tests against all of the Python versions we\nsupport. So don't be concerned if you are missing some and they fail. The rest\nwill be verified by Travis when you submit a pull request.
\nOnce you are happy with your changes or you are ready for some feedback, push\nit to your fork and send a pull request. For a change to be accepted it will\nmost likely need to have tests and documentation if it is a new feature.
", - "url": "/about/contributing/", - "language": "en", - "title": "Contributing" -} \ No newline at end of file diff --git a/about/license/index.json b/about/license/index.json deleted file mode 100644 index 4aa0274e..00000000 --- a/about/license/index.json +++ /dev/null @@ -1,6 +0,0 @@ -{ - "content": "The legal stuff.
\nThemes used under license from the Bootstrap, ReadTheDocs, GhostWriter and\nBootswatch projects.
\nMany thanks to the authors and contributors of those wonderful projects.
\nCopyright \u00a9 2014, Tom Christie. All rights reserved.
\nRedistribution and use in source and binary forms, with or without modification,\nare permitted provided that the following conditions are met:
\nRedistributions of source code must retain the above copyright notice, this list\nof conditions and the following disclaimer. Redistributions in binary form must\nreproduce the above copyright notice, this list of conditions and the following\ndisclaimer in the documentation and/or other materials provided with the\ndistribution.
\nTHIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS \"AS IS\" AND\nANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED\nWARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE\nDISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE LIABLE FOR\nANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES\n(INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;\nLOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON\nANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT\n(INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS\nSOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
", - "url": "/about/license/", - "language": "en", - "title": "License" -} \ No newline at end of file diff --git a/about/release-notes/index.json b/about/release-notes/index.json deleted file mode 100644 index be71bcb8..00000000 --- a/about/release-notes/index.json +++ /dev/null @@ -1,6 +0,0 @@ -{ - "content": "To upgrade MkDocs to the latest version, use pip:
\npip install -U mkdocs\n\nYou can determine your currently installed version using mkdocs --version:
$ mkdocs --version\nmkdocs, version 0.14.0\n\nMkDocs now supports themes that are distributed via Python packages. With this\naddition, the Bootstrap and Bootswatch themes have been moved to external git\nrepositories and python packages. See their individual documentation for more\ndetails about these specific themes.
\n\nThey will be included with MkDocs by default until the 1.0 release. After that\nthey will be installable with pip: pip install mkdocs-bootstrap and pip\ninstall mkdocs-bootswatch
See the documentation for Styling your docs for more information about using\nand customising themes and Custom themes for creating and distributing new\nthemes
\n-m flag. (#706)ancestors rather than just\n the initial one. (#693)--quiet and --verbose options to all subcommands. (#579)-a) to most command line options. (#579)mkdocs serve is already in use, don't show the\n user a full stack trace. (#596)In this release the mkdocs json command has been marked as deprecated and\nwhen used a deprecation warning will be shown. It will be removed in a future\nrelease of MkDocs, version 1.0 at the latest. The mkdocs json command\nprovided a convenient way for users to output the documentation contents as\nJSON files but with the additions of search to MkDocs this functionality is\nduplicated.
A new index with all the contents from a MkDocs build is created in the\nsite_dir, so with the default value for the site_dir It can be found in\nsite/mkdocs/search_index.json.
This new file is created on every MkDocs build (with mkdocs build) and\nno configuration is needed to enable it.
Provide a new way to define pages, and specifically nested pages, in the\nmkdocs.yml file and deprecate the existing approach, support will be removed\nwith MkDocs 1.0.
\nAll themes other than mkdocs and readthedocs will be moved into external\npackages in a future release of MkDocs. This will enable them to be more easily\nsupported and updates outside MkDocs releases.
\nSupport for search has now been added to MkDocs. This is based on the\nJavaScript library lunr.js. It has been added to both the mkdocs and\nreadthedocs themes. See the custom theme documentation on supporting search\nfor adding it to your own themes.
The command line interface for MkDocs has been re-written with the Python\nlibrary Click. This means that MkDocs now has an easier to use interface\nwith better help output.
\nThis change is partially backwards incompatible as while undocumented it was\npossible to pass any configuration option to the different commands. Now only\na small subset of the configuration options can be passed to the commands. To\nsee in full commands and available arguments use mkdocs --help and\nmkdocs build --help to have them displayed.
Like the extra_javascript and extra_css configuration options, a new\noption named extra_templates has been added. This will automatically be\npopulated with any .html or .xml files in the project docs directory.
Users can place static HTML and XML files and they will be copied over, or they\ncan also use Jinja2 syntax and take advantage of the global variables.
\nBy default MkDocs will use this approach to create a sitemap for the\ndocumentation.
\n--no-livereload to mkdocs serve for a simpler development server. (#511)mkdocs gh-deploy (#516)docs_dir. (#254)mkdocs serve. (#341)mkdocs new command. (#412)mkdocs build --clean. (#346)__pycache__ from the package tar. (#196)prettyprint well CSS classes to all HTML, only add it in\n the MkDocs theme. (#183)markdown_extensions. (#74)mkdocs json command to output your rendered\n documentation as json files. (#128)--clean switch to build, json and gh-deploy commands to\n remove stale files from the output directory. (#157)<ul> rendering in readthedocs theme. (#171)use_directory_urls config behaviour. (#63)extra_javascript and extra_css in all themes. (#90)extra_javascript and extra_css. (#92)#mkdocs on freenode.
diff --git a/index.json b/index.json
deleted file mode 100644
index 102ebeac..00000000
--- a/index.json
+++ /dev/null
@@ -1,6 +0,0 @@
-{
- "content": "Project documentation with Markdown.
\nMkDocs is a fast, simple and downright gorgeous static site\ngenerator that's geared towards building project documentation. Documentation\nsource files are written in Markdown, and configured with a single YAML\nconfiguration file.
\nBuilds completely static HTML sites that you can host on GitHub pages, Amazon\nS3, or anywhere else you choose.
\nThere's a stack of good looking themes included by default. Choose from\nbootstrap, readthedocs, or any of the 12 bootswatch themes.
\nThe built-in devserver allows you to preview your documentation as you're\nwriting it. It will even auto-reload whenever you save any changes, so all you\nneed to do to see your latest edits is refresh your browser.
\nGet your project documentation looking just the way you want it by customizing\nthe theme.
\nIn order to install MkDocs you'll need Python installed on your system, as\nwell as the Python package manager, pip. You can check if you have these\nalready installed like so:
\n$ python --version\nPython 2.7.2\n$ pip --version\npip 1.5.2\n\n\nMkDocs supports Python 2.6, 2.7, 3.3 and 3.4.
\nOn Windows we recommend that you install Python and pip with Chocolatey.
\nInstall the mkdocs package using pip:
pip install mkdocs\n\n\nYou should now have the mkdocs command installed on your system. Run mkdocs\n--version to check that everything worked okay.
$ mkdocs --version\nmkdocs, version 0.14.0\n\n\nGetting started is super easy.
\nmkdocs new my-project\ncd my-project\n\n\nLet's take a moment to review the initial project that's been created for us.
\n
There's a single configuration file named mkdocs.yml, and a folder named\ndocs that will contain our documentation source files. Right now the docs\nfolder just contains a single documentation page, named index.md.
MkDocs comes with a built-in webserver that lets you preview your documentation\nas you work on it. We start the webserver by making sure we're in the same\ndirectory as the mkdocs.yml config file, and then running the mkdocs serve\ncommand:
$ mkdocs serve\nRunning at: http://127.0.0.1:8000/\n\n\nOpen up http://127.0.0.1:8000/ in your browser, and\nyou'll see the index page being displayed:
\n
The webserver also supports auto-reloading, and will rebuild your documentation\nwhenever anything in the configuration file, documentation directory or theme\ndirectory changes.
\nGo ahead and edit the docs/index.md file now and save the file. Then simply\nhit reload in the browser and you'll see your updated documentation.
Now's also a good time to edit the configuration file, mkdocs.yml. Change the\nsite_name setting to something else and save the file.

Once you hit reload in the browser you'll see your new site name take effect.
\n
Go ahead and edit the docs/index.md document, and change the initial heading to\nMkLorum, then reload the site in your browser, and you should see the change\ntake effect immediately.
Let's also add a second page to our documentation:
\ncurl 'jaspervdj.be/lorem-markdownum/markdown.txt' > docs/about.md\n\n\nWe'd like our documentation site to include some navigation headers, so we'll\nedit the configuration file and add some information about the order and title\nto use for out headers:
\nsite_name: MkLorum\npages:\n- Home: index.md\n- About: about.md\n\n\nRefresh the browser and you'll now see a navigation bar with Home and About\nheaders.
While we're here can also change the configuration file to alter how the\ndocumentation is displayed. Let's go ahead and change the theme. Edit the\nmkdocs.yml file to the following:
site_name: MkLorum\npages:\n- Home: index.md\n- About: about.md\ntheme: readthedocs\n\n\nRefresh the browser again, and you'll now see the ReadTheDocs theme being used.
\n
That's looking good. We're ready to deploy the first pass of our MkLorum\ndocumentation now. Let's build the documentation.
mkdocs build\n\n\nThis will create a new directory, named site. Let's take a look inside the\ndirectory:
ls site\nabout css fonts img index.html js\n\n\nNotice that our source documentation has been output as two HTML files named\nindex.html and about/index.html. We also have various other media that's\nbeen copied into the site directory as part of the documentation theme.
If you're using source code control such as git you probably don't want to\ncheck your documentation builds into the repository. Add a line containing\nsite/ to your .gitignore file.
echo "site/" >> .gitignore\n\n\nIf you're using another source code control you'll want to check it's\ndocumentation on how to ignore specific directories.
\nAfter some time, files may be removed from the documentation but they will still\nreside in the site directory. To remove those stale files, just run mkdocs\nwith the --clean switch.
mkdocs build --clean\n\n\nThere are various other commands and options available. For a complete list of\ncommands, use the --help flag:
mkdocs --help\n\n\nTo view a list of options available on a given command, use the --help flag\nwith that command. For example, to get a list of all options available for the\nbuild command run the following:
mkdocs build --help\n\n\nThe documentation site that we've just built only uses static files so you'll be\nable to host it from pretty much anywhere. GitHub project pages and Amazon\nS3 are good hosting options. Upload the contents of the entire site directory\nto wherever you're hosting your website from and you're done. For specific\ninstructions for a number of common hosts, see the Deploying your Docs page.
To get help with MkDocs, please use the discussion group, GitHub issues or\nthe MkDocs IRC channel #mkdocs on freenode.
Guide to all available configuration settings.
\nProject settings are always configured by using a YAML configuration file in the\nproject directory named mkdocs.yml.
As a minimum this configuration file must contain the site_name setting. All\nother settings are optional.
This is a required setting, and should be a string that is used as the main\ntitle for the project documentation. For example:
\nsite_name: Marshmallow Generator\n\n\nWhen rendering the theme this setting will be passed as the site_name context\nvariable.
Set the canonical URL of the site. This will add a link tag with the canonical\nURL to the generated HTML header.
\ndefault: null
When set, provides a link to your GitHub or Bitbucket repository on each page.
\nrepo_url: https://github.com/example/repository/\n\n\ndefault: null
When set, provides a link to your GitHub or Bitbucket repository on each page.
\ndefault: 'GitHub' or 'Bitbucket' if the repo_url matches those\ndomains, otherwise null
Set the site description. This will add a meta tag to the generated HTML header.
\ndefault: null
Set the name of the author. This will add a meta tag to the generated HTML\nheader.
\ndefault: null
Set the favicon to use. Putting a favicon.ico into the docs/ directory, the\nconfig would look as follows:
site_favicon: favicon.ico\n\n\ndefault: null
Set the copyright information to be included in the documentation by the theme.
\ndefault: null
Set the Google analytics tracking configuration.
\ngoogle_analytics: ['UA-36723568-3', 'mkdocs.org']\n\n\ndefault: null
Set the remote branch to commit to when using gh-deploy to deploy to Github\nPages. This option can be overridden by a command line option in gh-deploy.
default: gh-pages
Set the remote name to push to when using gh-deploy to deploy to Github Pages.\nThis option can be overridden by a command line option in gh-deploy.
default: gh-pages
This setting is used to determine the set of pages that should be built for the\ndocumentation. For example, the following would create Introduction, User Guide\nand About pages, given the three source files index.md, user-guide.md and\nabout.md, respectively.
pages:\n - 'Introduction': 'index.md'\n - 'User Guide': 'user-guide.md'\n - 'About': 'about.md'\n\n\nSee the section on configuring pages and\nnavigation for\na more detailed breakdown, including how to create sub-sections.
\nSets the theme of your documentation site, for a list of available themes visit\nstyling your docs.
\ndefault: 'mkdocs'
Lets you set a directory to a custom theme. This can either be a relative\ndirectory, in which case it is resolved relative to the directory containing\nyour configuration file, or it can be an absolute directory path.
\nSee styling your docs for an explanation\nof custom themes.
\ndefault: null
Lets you set the directory containing the documentation source markdown files.\nThis can either be a relative directory, in which case it is resolved relative\nto the directory containing you configuration file, or it can be an absolute\ndirectory path.
\ndefault: 'docs'
Lets you set the directory where the output HTML and other files are created.\nThis can either be a relative directory, in which case it is resolved relative\nto the directory containing you configuration file, or it can be an absolute\ndirectory path.
\ndefault: 'site'
Note:
\nIf you are using source code control you will normally want to ensure that\nyour build output files are not committed into the repository, and only\nkeep the source files under version control. For example, if using git\nyou might add the following line to your .gitignore file:
site/\n\nIf you're using another source code control tool, you'll want to check its\ndocumentation on how to ignore specific directories.
\nSet a list of CSS files to be included by the theme. For example, the\nfollowing example will include the the extra.css file within the css\nsubdirectory in your docs_dir.
\nextra_css:\n - css/extra.css\n - css/second_extra.css\n\n\ndefault: By default extra_css will contain a list of all the CSS files\nfound within the docs_dir, if none are found it will be [] (an empty list).
Set a list of JavaScript files to be included by the theme. See the example\nin extra_css for usage.
\ndefault: By default extra_javascript will contain a list of all the\nJavaScript files found within the docs_dir, if none are found it will be []\n(an empty list).
Set a list of templates to be built by MkDocs. To see more about writing\ntemplates for MkDocs read the documentation about custom themes and\nspecifically the section about the variables that are available to templates.\nSee the example in extra_css for usage.
\ndefault: Unlike extra_css and extra_javascript, by default extra_templates\nwill be [] (an empty list).
A set of key value pairs, where the values can be any valid YAML construct, that\nwill be passed to the template. This allows for great flexibility when creating\ncustom themes.
\nFor example, if you are using a theme that supports displaying the project\nversion, you can pass it to the theme like this:
\nextra:\n version: 1.0\n\n\ndefault: By default extra will be an empty key value mapping.
This setting controls the style used for linking to pages within the\ndocumentation.
\nThe following table demonstrates how the URLs used on the site differ when\nsetting use_directory_urls to true or false.
| Source file | \nGenerated HTML | \nuse_directory_urls=true | \nuse_directory_urls=false | \n
|---|---|---|---|
| index.md | \nindex.html | \n/ | \n/index.html | \n
| api-guide.md | \napi-guide/index.html | \n/api-guide/ | \n/api-guide/index.html | \n
| about.md | \nabout/index.html | \n/about/ | \n/about/index.html | \n
The default style of use_directory_urls=true creates more user friendly URLs,\nand is usually what you'll want to use.
The alternate style can occasionally be useful if you want your documentation to\nremain properly linked when opening pages directly from the file system, because\nit create links that point directly to the target file rather than the target\ndirectory.
\ndefault: true
Determines if a broken link to a page within the documentation is considered a\nwarning or an error (link to a page not listed in the pages setting). Set to\ntrue to halt processing when a broken link is found, false prints a warning.
\ndefault: false
Determines the address used when running mkdocs serve. Setting this allows you\nto use another port, or allows you to make the service accessible over your\nlocal network by using the 0.0.0.0 address.
As with all settings, you can set this from the command line, which can be\nuseful, for example:
\nmkdocs serve --dev-addr=0.0.0.0:80 # Run on port 80, on the local network.\n\n\ndefault: '127.0.0.1:8000'
MkDocs uses the Python Markdown library to translate Markdown files\ninto HTML. Python Markdown supports a variety of extensions\nthat customize how pages are formatted. This setting lets you enable a list of\nextensions beyond the ones that MkDocs uses by default (meta, toc, tables,\nand fenced_code).
For example, to enable the SmartyPants typography extension, use:
\nmarkdown_extensions:\n - smarty\n\n\nSome extensions provide configuration options of their own. If you would like to\nset any configuration options, then you can nest a key/value mapping\n(option_name: option value) of any options that a given extension supports.\nSee the documentation for the extension you are using to determine what options\nthey support.
For example, to enable permalinks in the (included) toc extension, use:
markdown_extensions:\n - toc:\n permalink: True\n\n\nNote that a colon (:) must follow the extension name (toc) and then on a new\nline the option name and value must be indented and seperated by a colon. If you\nwould like to define multipe options for a single extension, each option must be\ndefined on a seperate line:
markdown_extensions:\n - toc:\n permalink: True\n separator: "_"\n\n\nAdd an additional item to the list for each extension. If you have no\nconfiguration options to set for a specific extension, then simply omit options\nfor that extension:
\nmarkdown_extensions:\n - smarty\n - toc:\n permalink: True\n - sane_lists\n\n\nSee Also:
\nThe Python-Markdown documentation provides a list of extensions\nwhich are available out-of-the-box. For a list of configuration options\navailable for a given extension, see the documentation for that extension.
\nYou may also install and use various third party extensions. Consult\nthe documentation provided by those extensions for installation instructions\nand available configuration options.
\ndefault: []
A guide to creating and distributing custom themes.
\nWhen creating a new theme, you can either follow the steps in this guide to\ncreate one from scratch or you can download the mkdocs-basic-theme as a\nbasic, yet complete, theme with all the boilerplate required. You can find\nthis base theme on GitHub.\nIt contains detailed comments in the code to describe the different features\nand their usage.
The bare minimum required for a custom theme is a base.html Jinja2\ntemplate file. This should be placed in a directory which will be the\ntheme_dir and it should be created next to the mkdocs.yml configuration\nfile. Within mkdocs.yml, specify the theme_dir option and set it to the\nname of the directory containing base.html. For example, given this example\nproject layout:
mkdocs.yml\ndocs/\n index.md\n about.md\ncustom_theme/\n base.html\n ...\n\nYou would include the following setting to use the custom theme directory:
\ntheme_dir: 'custom_theme'\n\nIf used in combination with the theme configuration value a custom theme can\nbe used to replace only specific parts of a built-in theme. For example, with\nthe above layout and if you set theme: mkdocs then the base.html file\nwould replace that in the theme but otherwise it would remain the same. This\nis useful if you want to make small adjustments to an existing theme.
The simplest base.html file is the following:
<!DOCTYPE html>\n<html>\n <head>\n <title>{% if page_title %}{{ page_title }} - {% endif %}{{ site_name }}</title>\n </head>\n <body>\n {{ content }}\n </body>\n</html>\n\n\nArticle content from each page specified in mkdocs.yml is inserted using the\n{{ content }} tag. Stylesheets and scripts can be brought into this theme as\nwith a normal HTML file. Navbars and tables of contents can also be generated\nand included automatically, through the nav and toc objects, respectively.\nIf you wish to write your own theme, it is recommended to start with one of\nthe built-in themes and modify it accordingly.
Each template in a theme is built with a template context. These are the\nvariables that are available to themes. The context varies depending on the\ntemplate that is being built. At the moment templates are either built with\nthe global context or with a page specific context. The global context is used\nfor HTML pages that don't represent an individual Markdown document, for\nexample a 404.html page or search.html.
\nThe following variables in the context map directly the configuration options\n.
\n| Variable Name | \nConfiguration name | \n\n |
|---|---|---|
| site_name | \nsite_name | \n\n |
| site_author | \nsite_author | \n\n |
| favicon | \nsite_favicon | \n\n |
| page_description | \nsite_description | \n\n |
| repo_url | \nrepo_url | \n\n |
| repo_name | \nrepo_name | \n\n |
| site_url | \nsite_url | \n\n |
| extra_css | \nextra_css | \n\n |
| extra_javascript | \nextra_javascript | \n\n |
| extra | \nextra | \n\n |
| include_nav | \ninclude_nav | \n\n |
| include_next_prev | \ninclude_next_prev | \n\n |
| copyright | \ncopyright | \n\n |
| google_analytics | \ngoogle_analytics | \n\n |
The following variables provide information about the navigation and location.
\nThe nav variable is used to create the navigation for the documentation.\nFollowing is a basic usage example which outputs the first and second level\nnavigation as a nested list.
<ul>\n {% for nav_item in nav %}\n {% if nav_item.children %}\n <li>{{ nav_item.title }}\n <ul>\n {% for nav_item in nav_item.children %}\n <li class="{% if nav_item.active%}current{%endif%}">\n <a href="{{ nav_item.url }}">{{ nav_item.title }}</a>\n </li>\n {% endfor %}\n </ul>\n </li>\n {% else %}\n <li class="{% if nav_item.active%}current{%endif%}">\n <a href="{{ nav_item.url }}">{{ nav_item.title }}</a>\n </li>\n {% endif %}\n\n {% endfor %}\n</ul>\n\n\nThe base_url provides a relative path to the root of the MkDocs project.\nThis makes it easy to include links to static assets in your theme. For\nexample, if your theme includes a js folder, to include theme.js from that\nfolder on all pages you would do this:
<script src="{{ base_url }}/js/theme.js"></script>\n\n\nProvides a relative path to the documentation homepage.
\nContains the current MkDocs version.
\nA Python datetime object that represents the date and time the documentation\nwas built in UTC. This is useful for showing how recently the documentation\nwas updated.
\nThe page context includes all of the above Global context and the following\nadditional variables.
\nContains the Title for the current page.
\nContains the description for the current page on the homepage, it is blank on\nother pages.
\nThe rendered Markdown as HTML, this is the contents of the documentation.
\nAn object representing the Table of contents for a page. Displaying the table\nof contents as a simple list can be achieved like this.
\n<ul>\n{% for toc_item in toc %}\n <li><a href="{{ toc_item.url }}">{{ toc_item.title }}</a></li>\n {% for toc_item in toc_item.children %}\n <li><a href="{{ toc_item.url }}">{{ toc_item.title }}</a></li>\n {% endfor %}\n{% endfor %}\n</ul>\n\n\nA mapping of the metadata included at the top of the markdown page. In this\nexample we define a source property above the page title.
source: generics.py\n mixins.py\n\n# Page title\n\nContent...\n\n\nA template can access this metadata for the page with the meta.source\nvariable. This could then be used to link to source files related to the\ndocumentation page.
{% for filename in meta.source %}\n <a class="github" href="https://github.com/.../{{ filename }}">\n <span class="label label-info">{{ filename }}</span>\n </a>\n{% endfor %}\n\n\nThe full, canonical URL to the current page. This includes the site_url from\nthe configuration.
\nThe page object for the current page. The page path and url properties can be\ndisplayed like this.
\n<h1>{{ current_page.title }}</h1>\n<p> This page is at {{ current_page.url }}</p>\n\n\nThe page object for the previous page. The usage is the same as for\ncurrent_page.
The page object for the next page.The usage is the same as for current_page.
Additional variables can be passed to the template with the\nextra configuration option. This is a\nset of key value pairs that can make custom templates far more flexible.
For example, this could be used to include the project version of all pages\nand a list of links related to the project. This can be achieved with the\nfollowing extra configuration:
extra:\n version: 0.13.0\n links:\n - https://github.com/mkdocs\n - https://docs.readthedocs.org/en/latest/builds.html#mkdocs\n - http://www.mkdocs.org/\n\n\nAnd then displayed with this HTML in the custom theme.
\n{{ config.extra.version }}\n\n{% if config.extra.links %}\n <ul>\n {% for link in config.extra.links %}\n <li>{{ link }}</li>\n {% endfor %}\n </ul>\n{% endif %}\n\n\nAs of MkDocs 0.13 client side search support has been added to MkDocs with\nLunr.js.
Search can either be added to every page in the theme or to a dedicated\ntemplate which must be named search.html. The search template will be build\nwith the same name and can be viewable with mkdocs serve at\nhttp://localhost:8000/search.html. An example of the two different\napproaches can be seen by comparing the mkdocs and readthedocs themes.
The following HTML needs to be added to the theme so the JavaScript is loaded\nfor Lunr.js.
\n<script>var base_url = '{{ base_url }}';</script>\n<script data-main="{{ base_url }}/mkdocs/js/search.js" src="{{ base_url }}/mkdocs/js/require.js"></script>\n\n\nNote
\nThe above JavaScript will download the search index, for larger\ndocumentation projects this can be a heavy operation. In those cases, it\nis suggested that you either use the search.html approach to only\ninclude search on one page or load the JavaScript on an event like a form\nsubmit.
This loads the JavaScript and sets a global variable base_url which allows\nthe JavaScript to make the links relative to the current page. The above\nJavaScript, with the following HTML in a search.html template will add a\nfull search implementation to your theme.
<h1 id="search">Search Results</h1>\n\n<form action="search.html">\n <input name="q" id="mkdocs-search-query" type="text" >\n</form>\n\n<div id="mkdocs-search-results">\n Sorry, page not found.\n</div>\n\n\nThis works by looking for the specific ID's used in the above HTML. The input\nfor the user to type the search query must have the ID mkdocs-search-query\nand mkdocs-search-results is the directory where the results will be placed.
MkDocs makes use of Python packaging to distribute themes. This comes with a\nfew requirements.
\nTo see an example of a package containing one theme, see the MkDocs Bootstrap\ntheme and to see a package that contains many themes, see the MkDocs\nBootswatch theme.
\nThe following layout is recommended for themes. Two files at the top level\ndirectory called MANIFEST.in amd setup.py. Then a directory with the name\nof your theme and containing a base.html file and a __init__.py.
.\n|-- MANIFEST.in\n|-- theme_name\n| |-- base.html\n| |-- __init__.py\n`-- setup.py\n\n\nThe MANIFEST.in file should contain the following contents but with\ntheme_name updated and any extra file extensions added to the include.
recursive-include theme_name *.ico *.js *.css *.png *.html *.eot *.svg *.ttf *.woff\nrecursive-exclude * __pycache__\nrecursive-exclude * *.py[co]\n\n\nThe setup.py should include the following text with the modifications\ndescribed below.
from setuptools import setup, find_packages\n\nVERSION = '0.0.1'\n\n\nsetup(\n name="mkdocs-themename",\n version=VERSION,\n url='',\n license='',\n description='',\n author='',\n author_email='',\n packages=find_packages(),\n include_package_data=True,\n entry_points={\n 'mkdocs.themes': [\n 'themename = theme_name',\n ]\n },\n zip_safe=False\n)\n\n\nFill in the URL, license, description, author and author email address.
\nThe name should follow the convention mkdocs-themename (like mkdocs-\nbootstrap and mkdocs-bootswatch), starting with MkDocs, using hyphens to\nseparate words and including the name of your theme.
Most of the rest of the file can be left unedited. The last section we need to\nchange is the entry_points. This is how MkDocs finds the theme(s) you are\nincluding in the package. The name on the left is the one that users will use\nin their mkdocs.yml and the one on the right is the directory containing your\ntheme files.
\nThe directory you created at the start of this section with the base.html file\nshould contain all of the other theme files. The minimum requirement is that\nit includes a base.html for the theme. It must also include a\n__init__.py file which should be empty, this file tells Python that the\ndirectory is a package.
With the above changes, your theme should now be ready to install. This can be\ndone with pip, using pip install . if you are still in the same directory as\nthe setup.py.
Most Python packages, including MkDocs, are distributed on PyPI. To do this,\nyou should run the following command.
\npython setup.py register\n\n\nIf you don't have an account setup, you should be prompted to create one.
\nFor a much more detailed guide, see the official Python packaging\ndocumentation for Packaging and Distributing Projects.
", - "url": "/user-guide/custom-themes/", - "language": "en", - "title": "Custom Themes" -} \ No newline at end of file diff --git a/user-guide/deploying-your-docs/index.json b/user-guide/deploying-your-docs/index.json deleted file mode 100644 index 52217c60..00000000 --- a/user-guide/deploying-your-docs/index.json +++ /dev/null @@ -1,6 +0,0 @@ -{ - "content": "A basic guide to deploying your docs to various hosting providers
\nIf you host the source code for a project on GitHub, you can easily use\nGitHub Pages to host the documentation for your project. After you checkout\nthe primary working branch (usually master) of the git repository where you\nmaintain the source documentation for your project, run the following command:
mkdocs gh-deploy --clean\n\n\nThat's it! Behind the scenes, MkDocs will build your docs and use the ghp-import\ntool to commit them to the gh-pages branch and push the gh-pages branch to\nGitHub.
\nUse mkdocs gh-deploy --help to get a full list of options available for the\ngh-deploy command.
Be aware that you will not be able to review the built site before it is pushed\nto GitHub. Therefore, you may want to verify any changes you make to the docs\nbeforehand by using the build or serve commands and reviewing the built\nfiles locally.
Warning
\nYou should never edit files in your gh-pages branch by hand if you're using\nthe gh-deploy command because you will lose your work.
Read the Docs offers free documentation hosting. You can import your docs\nusing any major version control system, including Mercurial, Git, Subversion,\nand Bazaar. Read the Docs supports MkDocs out-of-the-box. Follow the\ninstructions on their site to arrange the files in your repository properly,\ncreate an account and point it at your publicly hosted repository. If properly\nconfigured, your documentation will update each time you push commits to your\npublic repository.
\nNote
\nTo benefit from all of the features offered by Read the Docs, you will need\nto use the Read the Docs theme which ships with MkDocs. The various\nthemes which may be referenced in Read the Docs' documentation are Sphinx\nspecific themes and will not work with MkDocs.
\nIf you maintain a Python project which is hosted on the Python Package\nIndex (PyPI), you can use the hosting provided at pythonhosted.org to\nhost documentation for your project. Run the following commands from your\nproject's root directory to upload your documentation:
\nmkdocs build --clean\npython setup.py upload_docs --upload-dir=site\n\n\nYou documentation will be hosted at http://pythonhosted.org/<projectname>/\nwhere <projectname> is the name you used to register your project with PyPI.
There are a few prerequisites for the above to work:
\nsetup.py script (Distutils does\n not offer an upload_docs command).python setup.py\n register).mkdocs.yml config file and your \"docs\" directory (value assigned to\n the docs_dir configuration option) are presumed to be in the root directory\n of your project alongside your setup.py script.\"site\") is assigned to the site_dir\n configuration option in your mkdocs.yaml config file. If you have set a\n different value, assign that value to the --upload-dir option.Any hosting provider which can serve static files can be used to serve\ndocumentation generated by MkDocs. While it would be impossible to document how\nto upload the docs to every hosting provider out there, the following guidelines\nshould provide some general assistance.
\nWhen you build your site (using the mkdocs build command), all of the files\nare written to the directory assigned to the site_dir configuration option\n(defaults to \"site\") in your mkdocs.yaml config file. Generally, you will\nsimply need to copy the contents of that directory to the root directory of your\nhosting provider's server. Depending on your hosting provider's setup, you may\nneed to use a graphical or command line ftp, ssh or scp client to transfer\nthe files.
For example, a typical set of commands from the command line might look\nsomething like this:
\nmkdocs build --clean\nscp -r ./site usr@host:/path/to/server/root\n\n\nOf course, you will need to replace user with the username you have with your\nhosting provider and host with the appropriate domain name. Additionally, you\nwill need to adjust the /path/to/server/root to match the configuration of\nyour hosts' file system.
See your host's documentation for specifics. You will likely want to search\ntheir documentation for \"ftp\" or \"uploading site\".
", - "url": "/user-guide/deploying-your-docs/", - "language": "en", - "title": "Deploying Your Docs" -} \ No newline at end of file diff --git a/user-guide/styling-your-docs/index.json b/user-guide/styling-your-docs/index.json deleted file mode 100644 index 9f80c046..00000000 --- a/user-guide/styling-your-docs/index.json +++ /dev/null @@ -1,6 +0,0 @@ -{ - "content": "How to style and theme your documentation.
\nMkDocs includes a number of different builtin themes and\nexternal themes which can easily be\ncustomised with extra CSS or JavaScript or you can\ncreate a custom theme for your documentation.
\nTo use a theme that is included in MkDocs, simply add this to your\nmkdocs.yml config file.
theme: readthedocs\n\nReplace readthedocs with any of the builtin themes listed below.
To create a new custom theme or more heavily customise an existing theme, see\nthe custom themes section below.
\n

MkDocs also includes themes provided by two packages. MkDocs Bootstrap and\nMkDocs Bootswatch. The Bootstrap theme provides a theme based on Bootstrap\nand the Bootstrap theme provides 12 different themed Bootstrap themes based on\nthe Bootswatch project.
\nNote
\nThe Bootstrap and Bootswatch themes will not be included by default from\nMkDocs version 1.0. They will need to be installed manually with pip\ninstall mkdocs-bootstrap or pip install mkdocs-bootswatch.

![]()
![]()
![]()
![]()
![]()
![]()
![]()
![]()
![]()
![]()
![]()
![]()
The extra_css and extra_javascript configuration options can be used to\nmake tweaks and customisations to existing themes. To use these, you simply\nneed to include either CSS or JavaScript files within your documentation\ndirectory.
\nFor example, to change the colour of the headers in your documentation, create\na file called extra.css and place it next to the documentation Markdown. In\nthat file add the following CSS.
h1 {\n color: red;\n}\n\n\nNote
\nIf you are deploying your documentation with ReadTheDocs. You will need\nto explicitly list the CSS and JavaScript files you want to include in\nyour config. To do this, add the following to your mkdocs.yml.
\nextra_css: [extra.css]\n\nAfter making these changes, they should be visible when you run\nmkdocs serve - if you already had this running, you should see that the CSS\nchanges were automatically picked up and the documentation will be updated.
How to write and layout your markdown source files.
\nThe pages configuration in your\nmkdocs.yml defines which pages are built by MkDocs and how they appear in the\ndocumentation navigation. If not provided, the pages configuration will be\nautomatically created by discovering all the Markdown files in the\ndocumentation directory.
A simple pages configuration looks like this:
\npages:\n- 'index.md'\n- 'about.md'\n\n\nWith this example we will build two pages at the top level and they will\nautomatically have their titles inferred from the filename. Assuming docs_dir\nhas the default value, docs, the source files for this documentation would be\ndocs/index.md and docs/about.md. To provide a custom name for these pages,\nthey can be added before the filename.
pages:\n- Home: 'index.md'\n- About: 'about.md'\n\n\nSubsections can be created by listing related pages together under a section\ntitle. For example:
\npages:\n- Home: 'index.md'\n- User Guide:\n - 'Writing your docs': 'user-guide/writing-your-docs.md'\n - 'Styling your docs': 'user-guide/styling-your-docs.md'\n- About:\n - 'License': 'about/license.md'\n - 'Release Notes': 'about/release-notes.md'\n\n\nWith the above configuration we have three top level sections: Home, User Guide\nand About. Then under User Guide we have two pages, Writing your docs and\nStyling your docs. Under the About section we also have two pages, License and\nRelease Notes.
\nYour documentation source should be written as regular Markdown files, and\nplaced in a directory somewhere in your project. Normally this directory will be\nnamed docs and will exist at the top level of your project, alongside the\nmkdocs.yml configuration file.
The simplest project you can create will look something like this:
\nmkdocs.yml\ndocs/\n index.md\n\n\nBy convention your project homepage should always be named index. Any of the\nfollowing extensions may be used for your Markdown source files: markdown,\nmdown, mkdn, mkd, md.
You can also create multi-page documentation, by creating several markdown\nfiles:
\nmkdocs.yml\ndocs/\n index.md\n about.md\n license.md\n\n\nThe file layout you use determines the URLs that are used for the generated\npages. Given the above layout, pages would be generated for the following URLs:
\n/\n/about/\n/license/\n\n\nYou can also include your Markdown files in nested directories if that better\nsuits your documentation layout.
\ndocs/\n index.md\n user-guide/getting-started.md\n user-guide/configuration-options.md\n license.md\n\n\nSource files inside nested directories will cause pages to be generated with\nnested URLs, like so:
\n/\n/user-guide/getting-started/\n/user-guide/configuration-options/\n/license/\n\n\nMkDocs allows you to interlink your documentation by using regular Markdown\nhyperlinks.
\nWhen linking between pages in the documentation you can simply use the regular\nMarkdown hyperlinking syntax, including the relative path to the Markdown\ndocument you wish to link to.
\nPlease see the [project license](license.md) for further details.\n\nWhen the MkDocs build runs, these hyperlinks will automatically be transformed\ninto a hyperlink to the appropriate HTML page.
\nWhen working on your documentation you should be able to open the linked\nMarkdown document in a new editor window simply by clicking on the link.
\nIf the target documentation file is in another directory you'll need to make\nsure to include any relative directory path in the hyperlink.
\nPlease see the [project license](../about/license.md) for further details.\n\nYou can also link to a section within a target documentation page by using an\nanchor link. The generated HTML will correctly transform the path portion of the\nhyperlink, and leave the anchor portion intact.
\nPlease see the [project license](about.md#license) for further details.\n\nAs well as the Markdown source files, you can also include other file types in\nyour documentation, which will be copied across when generating your\ndocumentation site. These might include images and other media.
\nFor example, if your project documentation needed to include a GitHub pages\nCNAME\nfile\nand a PNG formatted screenshot image then your file layout might look as\nfollows:
\nmkdocs.yml\ndocs/\n CNAME\n index.md\n about.md\n license.md\n img/\n screenshot.png\n\n\nTo include images in your documentation source files, simply use any of the\nregular Markdown image syntaxes:
\nCupcake indexer is a snazzy new project for indexing small cakes.\n\n\n\n*Above: Cupcake indexer in progress*\n\n\nYou image will now be embedded when you build the documentation, and should also\nbe previewed if you're working on the documentation with a Markdown editor.
\nMkDocs supports the following Markdown extensions.
\nA simple table looks like this:
\nFirst Header | Second Header | Third Header\n------------ | ------------- | ------------\nContent Cell | Content Cell | Content Cell\nContent Cell | Content Cell | Content Cell\n\n\nIf you wish, you can add a leading and tailing pipe to each line of the table:
\n| First Header | Second Header | Third Header |\n| ------------ | ------------- | ------------ |\n| Content Cell | Content Cell | Content Cell |\n| Content Cell | Content Cell | Content Cell |\n\n\nSpecify alignment for each column by adding colons to separator lines:
\nFirst Header | Second Header | Third Header\n:----------- | :-----------: | -----------:\nLeft | Center | Right\nLeft | Center | Right\n\n\nThe first line should contain 3 or more backtick (`) characters, and the\nlast line should contain the same number of backtick characters (`):
```\nFenced code blocks are like Stardard\nMarkdown\u2019s regular code blocks, except that\nthey\u2019re not indented and instead rely on\nstart and end fence lines to delimit the\ncode block.\n```\n\n\nWith this approach, the language can optionally be specified on the first line\nafter the backticks:
\n```python\ndef fn():\n pass\n```\n",
- "url": "/user-guide/writing-your-docs/",
- "language": "en",
- "title": "Writing Your Docs"
-}
\ No newline at end of file