According to Jekyll Docs, you can add categories to the permalink like so: /:categories, but what if I want to use front matter that isn't categories? For example, I have a front matter named state. I tried adding /:state to no avail.
For example: state/:state is my permalink. In my front matter I have the following:
---
state: tx
---
So then my url will be state/tx.
I realize that I can create a custom permalink in the front matter of each page, but I am looking for something automatic as I am having less savvy users update the site. Also, categories isn't an obvious indicator that a state abbreviation should go there for my content managers.
as you may have already noticed. using a default front matter for states' page can achieve that. can achieve the automatic permalink generation.
by adding the following to _config.yml:
defaults:
-
scope:
path: "_states" # states' page location
values:
permalink: /state/:categories/:slug/
and in each page, using a yaml front matter like:
---
category: tx
---
But if you want to get ride of the "category" here, and you can use local plaguing with your website (for example github page doesn't support them by default) then add a generator that run before the site is generated, looks for the state value from the yaml front mater of each page, and put it in the appropriate folder.
That "act as a placeholder", you won't see /:categories in your URLs, it says that if a post you made belonging to a category, the name of the post category will go there.
For example: having a post with the following front matter :
---
categories: mycat
---
Then that post URL will start with /mycat/....
If you want custom variables included in the front matter to be replaced in perm a links, that can't be done. You can just add custom strings to the permalinks but not variables.
Related
I use Jekyll to create documentation for software products. I have 30 +
different products that have a common LIQUID template but different content. Every single product documentation has its own table of content.
For one project, everything is OK. I have a content folder as well as css/js folders. I run "jekyll serve" and publish a project.
The problem is that, I do not want to have 30 Jekyll projects stored one next to another with similar css, configs, js folders and will only differ in content part.
The question is: how can I organize the internal structure so I have a
single project with a common layout and 'x' different content folders inside the single project?
Like:
_product1/
some_subdir
'topic.md'
_product2/
some_subdir
'topic.md'
If it's possible, how can I then manage the output? I need to publish product 1 and product 2 ... product 'x' separately.
Thank you for the assistance.
UPD: Here is the demo project on GitHub: https://github.com/plywoods/JekyllDocumentationDemo
The way to have this content separation in Jekyll is through the use of Collections.
Here is an example of a Jekyll website using Collections:
https://github.com/netponto/netponto.github.io
_meetings, _members, and _sessions are different collections and analogous to your _product1, _product2, etc.
You can customize the output / how the URL is going to be in the _config.yml of your Jekyll site. For example:
collections:
meetings:
output: true
permalink: /reunioes/:path/
sessions:
output: true
permalink: /sessoes/:path/
To display the items of a collection, for example the "sessions" collection, you do something like this:
{% for session in site.sessions %}
<p>{{ session.title }}</p>
{% endfor %}
If you're having issues implementing the Collections, put together a reproducible example on GitHub, so that others can see what you've tried to do and point what's missing.
So the first thing I want to do with a new Polymer app is deploy to a directory on an existing website. The only thing that seems to work is deploying to root /.
Let's take the Shop example. I do:
polymer init and choose shop
polymer build
Robocopy.exe .\build\bundled\ C:\inetpub\wwwroot\p\ /MIR
start http://localhost/p/
You see I'm on Windows. I assume that using IIS is irrelevant, since I'm relying on the server just to serve static content.
What do I need to edit in the shop template to make it work at the url http://localhost/p/?
The polymer-cli created apps came with assumption of serving from root level '/'. In generated project index.html you will find two comments
<!--
The `<base>` tag below is present to support two advanced deployment options:
1) Differential serving. 2) Serving from a non-root path.
Instead of manually editing the `<base>` tag yourself, you should generally either:
a) Add a `basePath` property to the build configuration in your `polymer.json`.
b) Use the `--base-path` command-line option for `polymer build`.
Note: If you intend to serve from a non-root path, see [polymer-root-path] below.
-->
<base href="/">
<!-- ... -->
<script>
/**
* [polymer-root-path]
*
* By default, we set `Polymer.rootPath` to the server root path (`/`).
* Leave this line unchanged if you intend to serve your app from the root
* path (e.g., with URLs like `my.domain/` and `my.domain/view1`).
*
* If you intend to serve your app from a non-root path (e.g., with URLs
* like `my.domain/my-app/` and `my.domain/my-app/view1`), edit this line
* to indicate the path from which you'll be serving, including leading
* and trailing slashes (e.g., `/my-app/`).
*/
window.Polymer = {rootPath: '/'};
// ...
</script>
if in this index.html file you comment out base tag and set window.Polymer rootPath to something like '/0/polymer-test/build/es5-bundled/' you will be able to navigate in app on http://localhost/0/polymer-test/build/es5-bundled/
The Polymer shop-app assumes it will be deployed on the server root. Therefore it has all of the links and routes hard-coded to that assumption.
This means, that you will have to change all of the following:
all absolute links between the pages,
all pattern parameters in app-route elements (this is not necessary when useHashAsPath = true),
all absolute imports, including the lazy ones via importHref,
update the absolute locations within the service worker (use instructions from here) and
all references to static content (CSS, images, JS files)
I'm guessing your main goal isn't porting the shop-app, but rather future proofing your own app so that it can also be deployed to non-root locations on the server.
For this, I will mention two ways, depending on which value of useHashAsPath you use for the app-location element. This setting defaults to false, which means that you must use full URLs, instead of the hashbang equivalents.
Scenario 1: useHashAsPath = true
This is the easiest of both approaches, since you simply treat all URLs between the pages as absolute links. For example: Tabs.
The next step is to reference all static content and imports via relative links.
The last step is to update your service worker as shown here.
Scenario 2: useHashAsPath = false
If you dislike the hashbang URLs, go for this scenario. As you can figure out, this approach is a bit more difficult, but still manageable (especially when you start from scratch).
Firstly, you should still use absolute links, since relative links between a complex routing scheme can quickly cause problems (e.g. when not all pages are on the same directory level).
But since absolute links are a no-go, you will have to add some additional pre-processing upon build time. The point is to prefix all links with, say __ROOT__, and then replace all of those values with your actual document root. The links would then look like something this:
Some page
And you would use gulp-replace or something similar to replace __ROOT_ with /your-document-root across all of your source files in order to produce something like this:
Some page
At this point, you've got your links fixed. But this is only part of the problem. You must also apply the same fix to all of your app-route elements. For example:
<app-route pattern="__ROOT__/some/page" [...]></app-route> // Other parameters ommited
As with other resources, such as images and CSS files, you can also include them as absolute links and add the __ROOT__ prefix, but I would advise against this and would rather use relative paths.
The last step is to update your service worker as shown here.
Read more about routing: https://www.polymer-project.org/1.0/blog/routing
I'm trying to add a new 'project' category to a morea based site, where there will be a page similar to experiences page where I'll collect all course project related experiences and assignments, and maybe even modules.
Is it ok to look for pages with 'project' in their id or maybe better to tag with a new morea tag?
Do I need to also create a new entity type called 'project' or just reuse existing entities
In MoreaGeneraor.rb I couldn't find where module level page collections are prepared, like for example module_page.data['morea_experiences'].
I thought of preparing a similar collection of 'morea_project' pages and then traversing it in the new project page.
Is that done outside of this .rb file? by Jekyll? so how do I inject my collection.
Any simpler idea?...
Thank
p.s. I've also added the following (from line 3) to 'processMoreaFile()', but it does not seem to be visible at later stages:
elsif new_page.data['morea_type'] == "assessment"
site.config['morea_assessment_pages'] << new_page
if new_page.data['morea_id'].include?('project')
site.config['morea_project_pages'] << new_page
puts "--- project page #{new_page.data['morea_id']}\n "
end
but still do not know where to let each module page find out about it's 'project' pages
This is a cool idea. The simplest approach is to avoid making changes to MoreaGenerator.rb, and instead do it using normal Jekyll mechanisms. Here's a sketch:
Add a morea_label called "Project" to each associated module, reading, experience, and assessment.
In master/src, create a new directory called project, containing a file called index.md. This adds a new top-level page to your site (i.e. http://example.com/ics101/project/index.html)
Implement the index.md file with liquid tags to create the desired page layout for your project page. For inspiration, see the index.md files in the other top-level pages (readings, experiences, etc.). You can access YAML content in Liquid.
Once you've got your rocking project page done, you'll want a link to it in the navbar. See add a menu item for instructions.
Good luck! If you get it working to your satisfaction, please post its link as a followup to this question so we can see how it turned out!
So there should be a very basic way to do this, but unfortunately I don't seem to be able to find it.
How can one set an Href link to point to the 'base website url' + the 'link', rather than adding the link to the current page.
I.e. if I'm at www.example.com/content1/
I want the search function to go to www.example.com/search/
and not www.example.com/content1/search
I could just specify "www.example.com/search/" but then if it page is deployed locally I end up with a bunch of links to non-existent pages or vice versa. How can I specify the The Base hosting URL using DJango (whichever the server is running, whether the hostname, the current server ip, localhost etc.).
The best way to do this is the name your urls and then use the url template tag. Example below:
First, name your views. Use something like:
urlpatterns = [
...
url(r'^search/$', views.search_view, name="search"),
...
]
In this example, you've got your url for your example.com/search/ view. It is named 'search', which can be used url template tags and using the reverse() function.
Next, in your template, use the url tag with your url name:
Search
You shouldn't need to add 'base website url' to your href, it is implied. Make sure href is prefixed with '/' to set and absolute path and no '/' for relative.
home
is the same as
home
and will work no matter which sub directory you are in
If you are on the homepage and you use the link:
sample
it will effectively equal:
sample
but that same link used on the page http://www.mywebsite.com/sample will equate to:
sample
using:
sample
Will always equate to the following no matter where on the site it is used:
sample
If you are using django consider using the url template tag as Alex suggested:
https://docs.djangoproject.com/en/dev/ref/templates/builtins/#url
Make the link point to /search.
Any link that starts with / is relative to the domain root (say, http://example.com/) whereas any other relative link is relative to the current URL.
I would like to use Jekyll to create a site. not a blog. Is there a way to avoid to have the creation date specified in the url and in the page's file name?
I think that the idea behind Jekyll is brilliant, but it seems too tied to blog generation content while it could be useful also in a more general use case.
In the _config file you can change the permalink to anything you like, for example mine is
permalink: /blog/:title
As for the date you can choose your own date using the YAML front matter, again in mine i have
title: example
date: you can pick what ever date you want
What the docs say:
You configure permalinks in your _config.yml file like this:
permalink: /:categories/:year/:month/:day/:title.html
If you don’t specify any permalink setting, Jekyll uses the above pattern as the default. The permalink can also be set using a built-in permalink style:
permalink: date
Although you can specify a custom permalink pattern using template variables, Jekyll also provides the following built-in styles for convenience.
date = /:categories/:year/:month/:day/:title.html
pretty = /:categories/:year/:month/:day/:title/
ordinal = /:categories/:year/:y_day/:title.html
none = /:categories/:title.html
Source: https://jekyllrb.com/docs/permalinks/
This is the basic setting I use:
permalink: pretty
This sets pages to the pretty permalink style. Thus '/contact.md' will become '/contact/'.
How I use it for blog posts:
permalink: /blog/:title/
This makes sure the path contains the (sluggified) title.
How I use it for collections:
permalink: /desiredpath/:name/
This makes sure the path contains the filename.
If you aren't producing blog pages, you can create files in the directory structure mapping to certain URLs. Running on localhost, if your directory has the structure
- _layouts/
- config.yml
- index.html
- some_other_page.html
- some_directory/
- index.html
- some_sub_page.html
You'll have content at the following locations after jekyll has processed the files:
0.0.0.0:4000 (index.html)
0.0.0.0:4000/some_other_page.html (some_other_page.html)
0.0.0.0:4000/some_directory (some_directory/index.html)
0.0.0.0:4000/some_directory/some_sub_page.html (some_directory/some_sub_page.html)
You can also use the permalink attribute on each post to set one manually, or set a different default in config.yml Permalinks only have a small subset of variables available to use and need to be defined in every single file you want to put in a non-standard location.
This directory structure will automatically categorize your posts too. So you can have:
- some_category (defined in the yaml front matter or the _config.yml
- index.html
- _posts/
- some_post.md
- some_other_post.md
And posts will automatically have the category 'some category', and index.html will appear at 0.0.0.0:4000/some-category, with the default permalink format. The category variable is available as :category in the permalink format string.
I came across this old question while looking for a way to organize jekyll pages in a _pages directory, similarly to _posts. then access this pages without displaying the whole path in the url.
The approach that worked better for me, is to use jekyll collections as follows:
1 - Add a pages collection in _config.yml :
collections:
pages:
output: true
permalink: /:path/
2 - create a new directory named _pages (it should have the same collection name, prefixed by _)
3 - add the pages in the _pages folder, as .md or .html files starting with YAML Front Matter.
eg. /_pages/about.md will looks like:
---
layout: page
---
<!-- about page content -->
after building that, the URL of the about page will be <your-web-site>/about .
Alternatively, to display a collection name, you have to define its permalink as:
permalink: /:collection/:path/