You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
@@ -145,27 +145,27 @@ Both posts and pages can have meta-data assigned on a per-page basis such as tit
145
145
146
146
### Working With Posts
147
147
148
-
**Creating a Post**
148
+
**Creating a Post**
149
149
Posts are created by properly formatting a file and placing it the `_posts` folder.
150
150
151
-
**Formatting**
152
-
A post must have a valid filename in the form `YEAR-MONTH-DATE-title.MARKUP` and be placed in the `_posts` directory.
151
+
**Formatting**
152
+
A post must have a valid filename in the form `YEAR-MONTH-DATE-title.MARKUP` and be placed in the `_posts` directory.
153
153
If the data format is invalid Jekyll will not recognize the file as a post. The date and title are automatically parsed from the filename of the post file.
154
154
Additionally, each file must have [YAML Front-Matter](https://github.com/mojombo/jekyll/wiki/YAML-Front-Matter) prepended to its content.
155
155
YAML Front-Matter is a valid YAML syntax specifying meta-data for the given file.
156
156
157
-
**Order**
157
+
**Order**
158
158
Ordering is an important part of Jekyll but it is hard to specify a custom ordering strategy.
159
159
Only reverse chronological and chronological ordering is supported in Jekyll.
160
160
161
161
Since the date is hard-coded into the filename format, to change the order, you must change the dates in the filenames.
162
162
163
-
**Tags**
163
+
**Tags**
164
164
Posts can have tags associated with them as part of their meta-data.
165
165
Tags may be placed on posts by providing them in the post's YAML front matter.
166
166
You have access to the post-specific tags in the templates. These tags also get added to the sitewide collection.
167
167
168
-
**Categories**
168
+
**Categories**
169
169
Posts may be categorized by providing one or more categories in the YAML front matter.
170
170
Categories offer more significance over tags in that they can be reflected in the URL path to the given post.
171
171
Note categories in Jekyll work in a specific way.
@@ -182,17 +182,17 @@ You won't find "lessons" and "beginner" as two separate categories unless you de
182
182
183
183
### Working With Pages
184
184
185
-
**Creating a Page**
185
+
**Creating a Page**
186
186
Pages are created by properly formatting a file and placing it anywhere in the root directory or subdirectories that do _not_ start with an underscore.
187
187
188
-
**Formatting**
188
+
**Formatting**
189
189
In order to register as a Jekyll page the file must contain [YAML Front-Matter](https://github.com/mojombo/jekyll/wiki/YAML-Front-Matter).
190
190
Registering a page means 1) that Jekyll will process the page and 2) that the page object will be available in the `site.pages` array for inclusion into your templates.
191
191
192
-
**Categories and Tags**
192
+
**Categories and Tags**
193
193
Pages do not compute categories nor tags so defining them will have no effect.
194
194
195
-
**Sub-Directories**
195
+
**Sub-Directories**
196
196
If pages are defined in sub-directories, the path to the page will be reflected in the url.
197
197
Example:
198
198
@@ -204,15 +204,15 @@ Example:
204
204
This page will be available at `http://yourdomain.com/people/bob/essay.html`
205
205
206
206
207
-
**Recommended Pages**
207
+
**Recommended Pages**
208
208
209
-
-**index.html**
209
+
-**index.html**
210
210
You will always want to define the root index.html page as this will display on your root URL.
211
-
-**404.html**
211
+
-**404.html**
212
212
Create a root 404.html page and GitHub Pages will serve it as your 404 response.
213
-
-**sitemap.html**
213
+
-**sitemap.html**
214
214
Generating a sitemap is good practice for SEO.
215
-
-**about.html**
215
+
-**about.html**
216
216
A nice about page is easy to do and gives the human perspective to your website.
217
217
218
218
@@ -223,14 +223,14 @@ All templates have access to a global site object variable: `site` as well as a
223
223
The site variable holds all accessible content and metadata relative to the site.
224
224
The page variable holds accessible data for the given page or post being rendered at that point.
225
225
226
-
**Create a Template**
226
+
**Create a Template**
227
227
Templates are created by properly formatting a file and placing it in the `_layouts` directory.
228
228
229
-
**Formatting**
230
-
Templates should be coded in HTML and contain YAML Front Matter.
229
+
**Formatting**
230
+
Templates should be coded in HTML and contain YAML Front Matter.
231
231
All templates can contain Liquid code to work with your site's data.
232
232
233
-
**Rending Page/Post Content in a Template**
233
+
**Rending Page/Post Content in a Template**
234
234
There is a special variable in all templates named : `content`.
235
235
The `content` variable holds the page/post content including any sub-template content previously defined.
236
236
Render the content variable wherever you want your main content to be injected into your template:
@@ -247,7 +247,7 @@ Render the content variable wherever you want your main content to be injected i
247
247
248
248
### Sub-Templates
249
249
250
-
Sub-templates are exactly templates with the only difference being they
250
+
Sub-templates are exactly templates with the only difference being they
251
251
define another "root" layout/template within their YAML Front Matter.
252
252
This essentially means a template will render inside of another template.
253
253
@@ -267,32 +267,32 @@ This is mainly due to the fact that Jekyll templates must use the Liquid Templat
267
267
### What is Liquid?
268
268
269
269
[Liquid](https://github.com/Shopify/liquid) is a secure templating language developed by [Shopify](http://shopify.com).
270
-
Liquid is designed for end-users to be able to execute logic within template files
270
+
Liquid is designed for end-users to be able to execute logic within template files
271
271
without imposing any security risk on the hosting server.
272
272
273
273
Jekyll uses Liquid to generate the post content within the final page layout structure and as the primary interface for working with
274
-
your site and post/page data.
274
+
your site and post/page data.
275
275
276
276
### Why Do We Have to Use Liquid?
277
277
278
-
GitHub uses Jekyll to power [GitHub Pages](http://pages.github.com/).
278
+
GitHub uses Jekyll to power [GitHub Pages](http://pages.github.com/).
279
279
GitHub cannot afford to run arbitrary code on their servers so they lock developers down via Liquid.
280
280
281
281
### Liquid is Not Programmer-Friendly.
282
282
283
283
The short story is liquid is not real code and its not intended to execute real code.
284
284
The point being you can't do jackshit in liquid that hasn't been allowed explicitly by the implementation.
285
-
What's more you can only access data-structures that have been explicitly passed to the template.
285
+
What's more you can only access data-structures that have been explicitly passed to the template.
286
286
287
-
In Jekyll's case it is not possible to alter what is passed to Liquid without hacking the gem or running custom plugins.
287
+
In Jekyll's case it is not possible to alter what is passed to Liquid without hacking the gem or running custom plugins.
288
288
Both of which cannot be supported by GitHub Pages.
289
289
290
290
As a programmer - this is very frustrating.
291
291
292
-
But rather than look a gift horse in the mouth we are going to
292
+
But rather than look a gift horse in the mouth we are going to
293
293
suck it up and view it as an opportunity to work around limitations and adopt client-side solutions when possible.
294
294
295
-
**Aside**
295
+
**Aside**
296
296
My personal stance is to not invest time trying to hack liquid. It's really unnecessary
297
297
_from a programmer's_ perspective. That is to say if you have the ability to run custom plugins (i.e. run arbitrary ruby code)
298
298
you are better off sticking with ruby. Toward that end I've built [Mustache-with-Jekyll](http://github.com/plusjade/mustache-with-jekyll)
@@ -303,7 +303,7 @@ you are better off sticking with ruby. Toward that end I've built [Mustache-with
303
303
Static assets are any file in the root or non-underscored subfolders that are not pages.
304
304
That is they have no valid YAML Front Matter and are thus not treated as Jekyll Pages.
305
305
306
-
Static assets should be used for images, css, and javascript files.
306
+
Static assets should be used for images, css, and javascript files.
307
307
308
308
309
309
@@ -312,21 +312,21 @@ Static assets should be used for images, css, and javascript files.
312
312
313
313
Remember Jekyll is a processing engine. There are two main types of parsing in Jekyll.
314
314
315
-
-**Content parsing.**
315
+
-**Content parsing.**
316
316
This is done with textile or markdown.
317
-
-**Template parsing.**
317
+
-**Template parsing.**
318
318
This is done with the liquid templating language.
319
319
320
320
And thus there are two main types of file formats needed for this parsing.
321
321
322
-
-**Post and Page files.**
322
+
-**Post and Page files.**
323
323
All content in Jekyll is either a post or a page so valid posts and pages are parsed with markdown or textile.
324
-
-**Template files.**
324
+
-**Template files.**
325
325
These files go in `_layouts` folder and contain your blogs **templates**. They should be made in HTML with the help of Liquid syntax.
326
326
Since include files are simply injected into templates they are essentially parsed as if they were native to the template.
327
327
328
-
**Arbitrary files and folders.**
329
-
Files that _are not_ valid pages are treated as static content and pass through
328
+
**Arbitrary files and folders.**
329
+
Files that _are not_ valid pages are treated as static content and pass through
330
330
Jekyll untouched and reside on your blog in the exact structure and format they originally existed in.
331
331
332
332
### Formatting Files for Parsing.
@@ -363,30 +363,30 @@ That is to say loading a post file into a template file that refers to another t
363
363
364
364
## How Jekyll Generates the Final Static Files.
365
365
366
-
Ultimately, Jekyll's job is to generate a static representation of your website.
366
+
Ultimately, Jekyll's job is to generate a static representation of your website.
367
367
The following is an outline of how that's done:
368
368
369
-
1.**Jekyll collects data.**
369
+
1.**Jekyll collects data.**
370
370
Jekyll scans the posts directory and collects all posts files as post objects. It then scans the layout assets and collects those and finally scans other directories in search of pages.
371
371
372
-
2.**Jekyll computes data.**
373
-
Jekyll takes these objects, computes metadata (permalinks, tags, categories, titles, dates) from them and constructs one
372
+
2.**Jekyll computes data.**
373
+
Jekyll takes these objects, computes metadata (permalinks, tags, categories, titles, dates) from them and constructs one
374
374
big `site` object that holds all the posts, pages, layouts, and respective metadata.
375
375
At this stage your site is one big computed ruby object.
376
376
377
-
3.**Jekyll liquifies posts and templates.**
377
+
3.**Jekyll liquifies posts and templates.**
378
378
Next jekyll loops through each post file and converts (through markdown or textile) and **liquifies** the post inside of its respective layout(s).
379
-
Once the post is parsed and liquified inside the the proper layout structure, the layout itself is "liquified".
379
+
Once the post is parsed and liquified inside the the proper layout structure, the layout itself is "liquified".
380
380
**Liquification** is defined as follows: Jekyll initiates a Liquid template, and passes a simpler hash representation of the ruby site object as well as a simpler
381
381
hash representation of the ruby post object. These simplified data structures are what you have access to in the templates.
382
-
383
-
3.**Jekyll generates output.**
382
+
383
+
3.**Jekyll generates output.**
384
384
Finally the liquid templates are "rendered", thereby processing any liquid syntax provided in the templates
385
385
and saving the final, static representation of the file.
386
-
387
-
**Notes.**
388
-
Because Jekyll computes the entire site in one fell swoop, each template is given access to
389
-
a global `site` hash that contains useful data. It is this data that you'll iterate through and format
386
+
387
+
**Notes.**
388
+
Because Jekyll computes the entire site in one fell swoop, each template is given access to
389
+
a global `site` hash that contains useful data. It is this data that you'll iterate through and format
390
390
using the Liquid tags and filters in order to render it onto a given page.
391
391
392
392
Remember, in Jekyll you are an end-user. Your API has only two components:
@@ -408,5 +408,5 @@ Jekyll-bootstrap is intended to provide helper methods and strategies aimed at m
408
408
409
409
## Next Steps
410
410
411
-
Please take a look at [{{ site.categories.api.first.title }}]({{ BASE_PATH }}{{ site.categories.api.first.url }})
411
+
Please take a look at [{{ site.categories.api.first.title }}]({{ BASE_PATH }}{{ site.categories.api.first.url }})
412
412
or jump right into [Usage]({{ BASE_PATH }}{{ site.categories.usage.first.url }}) if you'd like.
0 commit comments