From 1431df623fdfe6344076ca3eff40be397976ac56 Mon Sep 17 00:00:00 2001 From: Daniel Sockwell Date: Sun, 8 Jul 2018 11:21:24 -0400 Subject: [PATCH 01/13] Edit docs to clarify RSS process Add details to the templates/RSS page to clarify that the `rss.xml` page is only generated if the `generate_rss = true` variable is set in the site's `config.toml` page. This information is already present in other parts of the documentation, but is not present in the RSS page, which could be confusing. --- docs/content/documentation/templates/rss.md | 9 ++++++--- 1 file changed, 6 insertions(+), 3 deletions(-) diff --git a/docs/content/documentation/templates/rss.md b/docs/content/documentation/templates/rss.md index f96824d..6633043 100644 --- a/docs/content/documentation/templates/rss.md +++ b/docs/content/documentation/templates/rss.md @@ -3,9 +3,12 @@ title = "RSS" weight = 50 +++ -Gutenberg will look for a `rss.xml` file in the `templates` directory or -use the built-in one. Currently it is only possible to have one RSS feed for the whole -site, you cannot create a RSS feed per section or taxonomy. +If the site `config.toml` file sets `generate_rss = true`, then Gutenberg will +generate an `rss.xml` page for the site, which will live at `base_url/rss.xml`. To +generate the `rss.xml` page, Gutenberg will look for a `rss.xml` file in the `templates` +directory or, if one does not exist, will use the use the built-in rss template. +Currently it is only possible to have one RSS feed for the whole site; you cannot +create a RSS feed per section or taxonomy. **Only pages with a date and that are not draft will be available.** From 9dd206d92517d1eb64eb9b06869f73038bef5b57 Mon Sep 17 00:00:00 2001 From: Daniel Sockwell Date: Sat, 14 Jul 2018 03:07:36 -0400 Subject: [PATCH 02/13] Edit docs to clarify role of static folder (#329) --- .../content/documentation/content/overview.md | 39 +++++++++++++++++++ 1 file changed, 39 insertions(+) diff --git a/docs/content/documentation/content/overview.md b/docs/content/documentation/content/overview.md index c5eac34..c2e30d1 100644 --- a/docs/content/documentation/content/overview.md +++ b/docs/content/documentation/content/overview.md @@ -63,3 +63,42 @@ the public web site. You can achieve this by simply setting `ignored_content` in ``` ignored_content = ["*.xlsx"] ``` + +## Static assets + +In addition to placing content files in the `content` directory, you may also place content +files in the `static` directory. Any files/folders that you place in the `static` directory +will be copied, without modification, to the public directory. + +Typically, you might put site-wide assets (such as the site favicon, site logos or site-wide +JavaScript) in the root of the static directory. You can also place any HTML or other files that +you wish to be included without modification (that is, without being parsed as Markdown files) +into the static directory. + +Note that the static folder provides an _alternative_ to colocation. For example, imagine that you +had the following directory structure (a simplified version of the structure presented above): + +```bash +. +└── content + └── blog +    ├── configuration + │    └── index.md // -> https://mywebsite.com/blog/configuration/ +    └── _index.md // -> https://mywebsite.com/blog/ +``` + +If you wanted to add an image to the `https://mywebsite.com/blog/configuration` page, you would +have three options: + * You could save the image to the `content/blog/configuration` folder and then link it with a + relative path from the `index.md` page. This is the approach described under **colocation**, + above. + * You could save the image to a `static/blog/configuration` folder and link it in exactly the + same way as if you had colocated it. If you do this, the generated files will be identical to + if you had colocated; the only difference will be that all static files will be saved in the + static folder rather than in the content folder. Depending on your organizational needs, this + may be better or worse. + * Or you could save the image to some arbitrary folder within the static folder. For example, + you could save all images to `static/images`. Using this approach, you would no longer be able + to use relative links, but could use an absolute link to `images/[filename]` to access your + image. This might be preferable for small sites or for sites that associate images with + multiple pages (e.g., logo images that appear on every page). From ae0ade94f671aa53d67c1e4c0cb1f6a399220fac Mon Sep 17 00:00:00 2001 From: Daniel Sockwell Date: Mon, 16 Jul 2018 02:47:04 -0400 Subject: [PATCH 03/13] Render live demo link for themes if there is one --- docs/content/themes/after-dark/index.md | 2 +- docs/templates/theme.html | 3 +++ 2 files changed, 4 insertions(+), 1 deletion(-) diff --git a/docs/content/themes/after-dark/index.md b/docs/content/themes/after-dark/index.md index 0d999e4..8b75931 100644 --- a/docs/content/themes/after-dark/index.md +++ b/docs/content/themes/after-dark/index.md @@ -67,4 +67,4 @@ instead. ## Original This template is based on the Hugo template https://github.com/comfusion/after-dark - \ No newline at end of file + diff --git a/docs/templates/theme.html b/docs/templates/theme.html index 1640214..344e524 100644 --- a/docs/templates/theme.html +++ b/docs/templates/theme.html @@ -10,6 +10,9 @@

Author: {{page.extra.author.name}}

License: {{page.extra.license}}

Homepage: {{page.extra.homepage}}

+ {% if page.extra.live_demo%} +

Live Demo: {{page.extra.live_demo}}

+ {% endif %}

Last updated: {{page.extra.updated }}

From b563142fc05570c5951ad600bf0c743a7ac2ca3f Mon Sep 17 00:00:00 2001 From: Daniel Sockwell Date: Mon, 16 Jul 2018 02:49:26 -0400 Subject: [PATCH 04/13] Add `index page` section to documentation (#331) * Add `index page` section to documentation The current documentation does not describe how to create a index page. I initially found this confusing, because I expected an index page to be a **page** rather than a section. Thus, I tried to access the page content with `{{ page.content }}` and was very frustrated when I could not. This addition clarifies that the index page is **always** a section, even if it does not have any sub-pages. This should also help people who intend to use Gutenberg to build stand-alone webpages, rather than blogs. --- .../documentation/templates/overview.md | 41 ++++++++++++++++--- 1 file changed, 36 insertions(+), 5 deletions(-) diff --git a/docs/content/documentation/templates/overview.md b/docs/content/documentation/templates/overview.md index 1d67e94..01810e6 100644 --- a/docs/content/documentation/templates/overview.md +++ b/docs/content/documentation/templates/overview.md @@ -10,11 +10,7 @@ As this documentation will only talk about how templates work in Gutenberg, plea the [Tera template documentation](https://tera.netlify.com/docs/templates/) if you want to learn more about it first. -All templates live in the `templates` directory and built-in or themes templates can -be overriden by creating a template with same name in the correct path. For example, -you can override the RSS template by creating a `templates/rss.xml` file. - -If you are not sure what variables are available in a template, you can just stick `{{ __tera_context }}` in it +All templates live in the `templates` directory. If you are not sure what variables are available in a template, you can just stick `{{ __tera_context }}` in it to print the whole context. A few variables are available on all templates minus RSS and sitemap: @@ -23,6 +19,41 @@ A few variables are available on all templates minus RSS and sitemap: - `current_path`: the path (full URL without the `base_url`) of the current page, never starting with a `/` - `current_url`: the full URL for that page +## Standard Templates +By default, Gutenberg will look for three templates: `index.html`, which is applied +to the site homepage; `section.html`, which is applied to all sections (any HTML +page generated by creating a directory within your `content` directory); and +`page.html`, which is applied to all pages (any HTML page generated by creating a +`.md` file within your `content` directory). + +The homepage is always a section (regardless of whether it contains other pages). +Thus, the `index.html` and `section.html` templates both have access to the +section variables. The `page.html` template has access to the page variables. +The page and section variables are described in more detail in the next section of this documentation. + +## Built-in Templates +Gutenberg comes with three built-in templates: `rss.xml`, `sitemap.xml`, and +`robots.txt` (each described in their own section of this documentation). +Additionally, themes can add their own templates, which will be applied if not +overridden. You can override built-in or theme templates by creating a template with +same name in the correct path. For example, you can override the RSS template by +creating a `templates/rss.xml` file. + +## Custom Templates +In addition to the standard `index.html`, `section.html`, and `page.html` templates, +you may also create custom templates by creating a `.html` file in the `templates` +directory. These custom templates will not be used by default. Instead, the custom template will _only_ be used if you apply it by setting the `template` front-matter variable to the path for that template (or if you `include` it in another template that is applied). For example, if you created a custom template for your site's About page called `about.html`, you could apply it to your `about.md` page by including the following front matter in your `about.md` page: + +```md ++++ +title = "About Us" +template = "about.html" ++++ +``` + +Custom templates are not required to live at the root of your `templates` directory. +For example, `product_pages/with_pictures.html` is a valid template. + ## Built-in filters Gutenberg adds a few filters, in addition of the ones already present in Tera. From ada606a4da57c1fc2422b17195328ddd6118917b Mon Sep 17 00:00:00 2001 From: Daniel Sockwell Date: Mon, 16 Jul 2018 02:54:28 -0400 Subject: [PATCH 05/13] Update comparison in README for Hugo 0.43 (#334) * Update comparison in README for Hugo 0.43 --- README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/README.md b/README.md index 95bb0f5..9ac213f 100644 --- a/README.md +++ b/README.md @@ -14,7 +14,7 @@ in the `docs/content` folder of the repository. | Single binary | ✔ | ✔ | ✔ | ✕ | | Language | Rust | Rust | Go | Python | | Syntax highlighting | ✔ | ✔ | ✔ | ✔ | -| Sass compilation | ✔ | ✕ | ✕ | ✔ | +| Sass compilation | ✔ | ✕ | ✔ | ✔ | | Assets co-location | ✔ | ✔ | ✔ | ✔ | | i18n | ✕ | ✕ | ✔ | ✔ | | Image processing | ✕ | ✕ | ✔ | ✔ | From 8a23c539c72c519eb43134ca68156daa8c9feed3 Mon Sep 17 00:00:00 2001 From: Vincent Prouillet Date: Tue, 17 Jul 2018 12:41:13 +0200 Subject: [PATCH 06/13] Add build-packages to snapcraft (#322) --- snapcraft.yaml | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/snapcraft.yaml b/snapcraft.yaml index b51def4..9d9194a 100644 --- a/snapcraft.yaml +++ b/snapcraft.yaml @@ -19,3 +19,7 @@ parts: gutenberg: plugin: rust rust-channel: stable + build-packages: + - build-essential + - cmake + - git-core From c2d4561f052624d4e1d6df4c892090a354473f06 Mon Sep 17 00:00:00 2001 From: Daniel Sockwell Date: Fri, 20 Jul 2018 03:16:57 -0400 Subject: [PATCH 07/13] Edit docs to say that sections require an `_index.md` file (#341) --- docs/content/documentation/content/page.md | 16 ++++++++++++++ docs/content/documentation/content/section.md | 21 +++++++++++++------ 2 files changed, 31 insertions(+), 6 deletions(-) diff --git a/docs/content/documentation/content/page.md b/docs/content/documentation/content/page.md index 3e6b8df..048d5c6 100644 --- a/docs/content/documentation/content/page.md +++ b/docs/content/documentation/content/page.md @@ -6,6 +6,22 @@ weight = 30 A page is any file ending with `.md` in the `content` directory, except files named `_index.md`. +If a file ending with `.md` is named `index.md`, then it will generate a page +with the name of the containing folder (for example, `/content/about/index.md` would +create a page at `[base_url]/about`). (Note the lack of an underscore; if the file +were named `_index.md`, then it would create a **section** ad `[base_url]/about`, as +discussed in the prior part of this documentation. But naming the file `index.md` will +create a **page** at `[base_url]/about`). + +If the file is given any name *other* than `index.md` or `_index.md`, then it will +create a page with that name (without the `.md`). So naming a file in the root of your +content directory `about.md` would also create a page at `[base_url]/about`. + +As you can see, creating an `about.md` file is exactly equivalent to creating an +`about/index.md` file. The only difference between the two methods is that creating +the `about` folder allows you to use asset colocation, as discussed in the +[Overview](./documentation/content/overview.md) section of this documentation. + ## Front-matter The front-matter is a set of metadata embedded in a file. In Gutenberg, diff --git a/docs/content/documentation/content/section.md b/docs/content/documentation/content/section.md index 2228544..19ea0c4 100644 --- a/docs/content/documentation/content/section.md +++ b/docs/content/documentation/content/section.md @@ -3,19 +3,28 @@ title = "Section" weight = 20 +++ -A section is automatically created when a folder is found in the `content` section, unless it only -contains a `index.md` file and is actually a page with assets. +A section is created whenever a folder (or subfolder) in the `content` section contains an +`_index.md` file. If a folder does not contain an `_index.md` file, no section will be +created, but markdown files within that folder will still create pages (known as orphan pages). -You can add `_index.md` file to a folder to augment a section and give it some metadata and/or content. - -The index page is actually a section created automatically like any other: you can add metadata -and content by adding `_index.md` at the root of the `content` folder. +The index page (i.e., the page displayed when a user browses to your `base_url`) is a section, +which is created whether or not you add an `_index.md` file at the root of your `content` folder. +If you do not create an `_index.md` file in your content directory, this main content section will +not have any content or metadata. If you would like to add content or metadata, you can add an +`_index.md` file at the root of the `content` folder and edit it just as you would edit any other +`_index.md` file; your `index.html` template will then have access to that content and metadata. ## Front-matter +The `_index.md` file within a folder defines the content and metadata for that section. To set +the metadata, add front matter to the file. + The front-matter is a set of metadata embedded in a file. In Gutenberg, it is at the beginning of the file, surrounded by `+++` and uses TOML. +After the closing `+++`, you can add content that will be parsed as markdown and will be available +to your templates through the `section.content` variable. + While none of the front-matter variables are mandatory, the opening and closing `+++` are required. Here is an example `_index.md` with all the variables available: From 18989747da12d481e2303d15e9fa7d94926c424d Mon Sep 17 00:00:00 2001 From: Daniel Sockwell Date: Mon, 23 Jul 2018 17:10:50 -0400 Subject: [PATCH 08/13] Revise netlify.toml example This is extremely minor, but the initial `netlify.toml` example confused me a bit because I didn't realize that it was using a *netlify* variable; I thought I needed to replace something with a variable from my own configuration. I made a very minor edit to the docs to clarify. --- docs/content/documentation/deployment/netlify.md | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-) diff --git a/docs/content/documentation/deployment/netlify.md b/docs/content/documentation/deployment/netlify.md index e5fedc8..3474d71 100644 --- a/docs/content/documentation/deployment/netlify.md +++ b/docs/content/documentation/deployment/netlify.md @@ -31,11 +31,13 @@ command = "gutenberg build" [build.environment] # Set the version name that you want to use and Netlify will automatically use it -GUTENBERG_VERSION = "0.3.1" +GUTENBERG_VERSION = "0.3.3" # The magic for deploying previews of branches -# We need to override the base url with what the url of the preview is ($DEPLOY_PRIME_URL) -# otherwise links would not work properly +# We need to override the base url with whatever url Netlify assigns to our +# preview site. We do this using the Netlify environment variable +# `$DEPLOY_PRIME_URL`. + [context.deploy-preview] command = "gutenberg build --base-url $DEPLOY_PRIME_URL" From 4f757e3a12b9fe7868a3413415d2d4d746092963 Mon Sep 17 00:00:00 2001 From: Daniel Sockwell Date: Mon, 23 Jul 2018 17:19:58 -0400 Subject: [PATCH 09/13] Add codesections.com to EXAMPLES.md --- EXAMPLES.md | 1 + 1 file changed, 1 insertion(+) diff --git a/EXAMPLES.md b/EXAMPLES.md index 27cd2e2..74bf1cf 100644 --- a/EXAMPLES.md +++ b/EXAMPLES.md @@ -16,3 +16,4 @@ - [andrei.blue](https://andrei.blue): https://github.com/azah/personal-blog - [Axiomatic Semantics](https://axiomatic.neophilus.net): https://github.com/Libbum/AxiomaticSemantics - [Tinkering](https://tinkering.xyz) +- [Daniel Sockwell's codesections.com](https://www.codesections.com): https://gitlab.com/codesections/codesections-website From 6905fd03f595a5926d61d085c75887af3dedb0a4 Mon Sep 17 00:00:00 2001 From: Daniel Sockwell Date: Tue, 24 Jul 2018 03:44:17 -0400 Subject: [PATCH 10/13] Expand documentation about sorting pages (#343) --- docs/content/documentation/content/section.md | 101 ++++++++++++++++-- 1 file changed, 90 insertions(+), 11 deletions(-) diff --git a/docs/content/documentation/content/section.md b/docs/content/documentation/content/section.md index 19ea0c4..62d6e5f 100644 --- a/docs/content/documentation/content/section.md +++ b/docs/content/documentation/content/section.md @@ -92,22 +92,101 @@ You can also change the pagination path (the word displayed while paginated in t by setting the `paginate_path` variable, which defaults to `page`. ## Sorting -Sections' pages can be sorted three different ways, not counting the unsorted default and -is enabled by setting the `sort_by` front-matter variable. +It is very common for Gutenberg templates to iterate over pages or sections +to display all pages/sections a given directory. Consider a very simple +example: a `blog` directory with three files: `blog/Post_1.md`, +`blog/Post_2.md`, and `blog/Post_3.md`. To iterate over these posts and +create a list of links to the posts, a simple template might look like this: + +```j2 +{% for post in section.pages %} +

{{ post.title }}

+{% endfor %} +``` + +This would iterate over the posts, and would do so in a specific order +based on the `sort_by` variable set in the `_index.md` page for the +containing section. The `sort_by` variable can be given three values: `date`, +`weight`, and `order`. If no `sort_by` method is set, the pages will be +sorted in a default order that is not guaranteed to correspond to any of the +explicit orders. The value of `sort_by` will also determine which pages +are listed stored in the `page.next` and `page.previous` variables. The effects of these values is explained below. -Any page that cannot be sorted, for example if missing the date variable while sorting by `date`, will be ignored and -won't be rendered. The terminal will warn you if this is happening. +Any page that is missing the data it needs to be sorted will be ignored and +won't be rendered. For example, if a page is missing the date variable the +containing section sets `sort_by = "date"`, then that page will be ignored. The terminal will warn you if this is happening. -If several pages have the same date/weight/order, their permalink will be used to break the tie following -an alphabetical order. +If several pages have the same date/weight/order, their permalink will be used to break the tie following an alphabetical order. + +## Sorting Pages +The `sort_by` front-matter variable can have the following values: ### `date` -This will sort all pages by their `date` field, from the most recent to the oldest. +This will sort all pages by their `date` field, from the most recent (at the +top of the list) to the oldest (at the bottom of the list). Each page will +get a `page.next` variable that points *down* the list (to the page just +older than the current page) and a `page.previous` variable that points up +the list (to the just newer page). ### `weight` -This will be sort all pages by their `weight` field. Heavier weights fall at the bottom: 5 would be before 10. +This will be sort all pages by their `weight` field, from lightest weight +(at the top of the list) to heaviest (at the bottom of the list). Each +page gets a `page.next` variable that points *up* the list (to the page that +is just lighter than the current page) and a `page.previous` variable that +points down the list (to the page that is just heavier than the current page). ### `order` -This will be sort all pages by their `order` field. Order is the opposite of weight, think of it as enumerating -the content: this is my first post, my second, etc. A page with `order: 5` will appear after a page with `order: 10` in the sorted list. - +This will be sort all pages by their `order` field. Order is the opposite of weight; think of it as listing the order in which pages were posted, with the +oldest (first) at the bottom of the list. Each page also gets a +`page.next` variable that points *up* the list (to the page with a higher order +than the current page) and a `page.previous` variable that points down the list +(to the page just lower in order). + +To make this a bit more concrete, let's play out the simple example raised +above. Imagine that we set the `weight` and `order` both to 1 in `Post_1`, +both to 2 in `Post_2` and both to 3 in `Post_3`. (In practice, there would +typically be no reason to set *both* `order` and `weight`). + +If we then set `sort_by = "weight"` in the `blog/_index.md` file, we would +get the following order from a Tera for loop: + + * Page_1 [`page.next = null`, `page.previous = Page_2`] + * Page_2 [`page.next = Page_1`, `page.previous = Page_2`] + * Page_3 [`page.next = Page_2`, `page.previous = Page_2`] + +If, however, we set the `sort_by` front-matter variable to `order`, we +would get: + * Page_3 [`page.next = null`, `page.previous = Page_2`] + * Page_2 [`page.next = Page_3`, `page.previous = Page_1`] + * Page_1 [`page.next = Page_2`, `page.previous = null`] + +Note that the order is reversed but in *both* cases the `page.previous` is +pointing *up* the list, and `page.next` is pointing *down* the list. This +fits many common use cases, including when Gutenberg is used for a blog as +in this simple example. + +However, Gutenberg is flexible enough to accommodate alternate use cases as +well. If you would prefer the `page.next` and `page.previous` variables +to point in the opposite direction, you can use Tera's `reverse` filter. +`reverse` causes the order to be reversed but does *not* alter the behaviour +of `next` and `previous`. Thus, combining `sort_by = "weight"` with `reverse` +gives you the same sequence as using `sort_by = "order"` but with `next` +and `previous` pointing in the other direction. By combining `sort_by` and +`reverse`, you can achieve any combination of sorting order and +`next`/`previous` values. + +## Sorting Subsections +Sorting sections is a bit less flexible but also much simpler. This is +because sections do not have `next` or `previous` values. Further, they can +only be sorted by `weight`—thus, the `sort_by` value in the containing section +has no impact at all on any subsections (only on pages). + +Based on this, by default the lightest (lowest `weight`) subsections will be at +the top of the list and the heaviest (highest `weight`) will be at the top; +the `reverse` filter reverses this order. + +**Note**: If the `weight` variable for your section is not set (or if it +is set in a way that produces ties), then your sections will be sorted in +**random** order. Moreover, that order is determined at build time and will +change with each site rebuild. Thus, if there is any chance that you will +iterate over your sections, you should always assign them weight. From 6d4bb7140bdbfff2372017cff67ba575fa5b9f6a Mon Sep 17 00:00:00 2001 From: Daniel Sockwell Date: Tue, 24 Jul 2018 17:11:43 -0400 Subject: [PATCH 11/13] Reorganise EXAMPLES.md (#347) * Remove www.bharatkalluri.in from EXAMPLES.md The footer and source code at state that the site was made with Hugo, so it should be deleted as an example of a Gutenberg site. I considered also removing the link to https://adrien.is/, since the link appears to be dead. But I left it for now, since that could be a temporary outage. If you would like, I'd be happy to format EXAMPLES.md as a table, which might help keep it looking clean as it gets more entries. * Convert EXAMPLES.md to table --- EXAMPLES.md | 34 +++++++++++++++++----------------- 1 file changed, 17 insertions(+), 17 deletions(-) diff --git a/EXAMPLES.md b/EXAMPLES.md index 74bf1cf..a5fb60f 100644 --- a/EXAMPLES.md +++ b/EXAMPLES.md @@ -1,19 +1,19 @@ # Example sites -- [vincent.is](https://vincent.is): https://gitlab.com/Keats/vincent.is -- [code Date: Wed, 25 Jul 2018 13:42:46 -0400 Subject: [PATCH 12/13] Expand Netlify doc page This commit expands the Netlify documentation page to include a description of how to manually deploy a built Gutenberg site from the command line. --- .../documentation/deployment/netlify.md | 26 ++++++++++++++++--- 1 file changed, 23 insertions(+), 3 deletions(-) diff --git a/docs/content/documentation/deployment/netlify.md b/docs/content/documentation/deployment/netlify.md index e5fedc8..8b92680 100644 --- a/docs/content/documentation/deployment/netlify.md +++ b/docs/content/documentation/deployment/netlify.md @@ -8,13 +8,16 @@ with no effort. This very site is hosted by Netlify and automatically deployed o If you don't have an account with Netlify, you can [sign up](https://app.netlify.com) for one. +## Automatic Deploys Once you are in the admin interface, you can add a site from a Git provider (GitHub, GitLab or Bitbucket). At the end of this process, you can select the deploy settings for the project: - - build command: `GUTENBERG_VERSION=0.3.1 gutenberg build` (replace the version number in the variable by the version you want to use) + - build command: `GUTENBERG_VERSION=0.3.3 gutenberg build` (replace the version number in the variable by the version you want to use) - publish directory: the path to where the `public` directory is -With this setup, your site should be automatically deployed on every commit on master. +With this setup, your site should be automatically deployed on every commit on master. For `GUTENBERG_VERSION`, you may +use any of the tagged `release` versions in the GitHub repository—Netlify will automatically fetch the tagged version +and use it to build your site. However, if you want to use everything that Netlify gives you, you should also publish temporary sites for pull requests. @@ -31,7 +34,7 @@ command = "gutenberg build" [build.environment] # Set the version name that you want to use and Netlify will automatically use it -GUTENBERG_VERSION = "0.3.1" +GUTENBERG_VERSION = "0.3.3" # The magic for deploying previews of branches # We need to override the base url with what the url of the preview is ($DEPLOY_PRIME_URL) @@ -41,4 +44,21 @@ command = "gutenberg build --base-url $DEPLOY_PRIME_URL" ``` +## Manual Deploys +If you would prefer to use a version of Gutenberg that isn't a tagged release (for example, after having built Gutenberg from +source and made modifications), then you will need to manually deploy your `public` folder to Netlify. You can do this through +Netlify's web GUI or via the command line. +For a command-line manual deploy, follow these steps: + 1. Generate a `Personal Access Token` from the settings section of your Netlify account (*not* an OAuth Application) + 2. Build your site with `gutenberg build` + 3. Create a zip folder containing the `public` directory + 4. Run the `curl` command below, filling in your values for PERSONAL_ACCESS_TOKEN_FROM_STEP_1, FILE_NAME.zip and SITE_NAME + 5. (Optional) delete the zip folder + +```bash +curl -H "Content-Type: application/zip" \ + -H "Authorization: Bearer PERSONAL_ACCESS_TOKEN_FROM_STEP_1" \ + --data-binary "@FILE_NAME.zip" \ + https://api.netlify.com/api/v1/sites/SITE_NAME.netlify.com/deploys +``` From dc76e8c9a56fbd5a55c37794df1cdf28ec26b67e Mon Sep 17 00:00:00 2001 From: Nikita Puzankov Date: Fri, 27 Jul 2018 19:39:17 +0400 Subject: [PATCH 13/13] Fix typo in page.md doc Fixed typo from 'ad' to 'at'. --- docs/content/documentation/content/page.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/content/documentation/content/page.md b/docs/content/documentation/content/page.md index 048d5c6..71982de 100644 --- a/docs/content/documentation/content/page.md +++ b/docs/content/documentation/content/page.md @@ -9,7 +9,7 @@ named `_index.md`. If a file ending with `.md` is named `index.md`, then it will generate a page with the name of the containing folder (for example, `/content/about/index.md` would create a page at `[base_url]/about`). (Note the lack of an underscore; if the file -were named `_index.md`, then it would create a **section** ad `[base_url]/about`, as +were named `_index.md`, then it would create a **section** at `[base_url]/about`, as discussed in the prior part of this documentation. But naming the file `index.md` will create a **page** at `[base_url]/about`).