New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Archetype fields are parsed/sorted upon instantiations #452

Closed
yacoob opened this Issue Aug 29, 2014 · 17 comments

Comments

Projects
None yet
@yacoob
Contributor

yacoob commented Aug 29, 2014

I've created archetypes/post.md containing some fields. Most of them are just there to remind me that I should fill them in:

---
zyzio: url
hg:
  - foo
aliases:
  - bar
cover_img: url
social_img: url

---

After hugo new post/foo.md, it turned out that hugo unhelpfully sorted all of the fields:

---
aliases:
- bar
cover_img: url
date: 2014-08-29T23:18:10+01:00
hg:
- foo
social_img: url
title: foo
zyzio: url

---

Not really helpful :(

@natefinch

This comment has been minimized.

Show comment
Hide comment
@natefinch

natefinch Aug 29, 2014

Contributor

Yeah, the problem is that Hugo isn't just copying the contents of the
fields, it's parsing them and then spitting them back out along with a
couple default values. It's nontrivial to fix, because it's not that we're
sorting them on purpose, that's just hire the underlying libraries work.

You're not the first person to complain about it, and I think you're right,
Hugo should maintain the order. I'll take a look at the code and see how
hard that would be.
On Aug 29, 2014 6:20 PM, "Jakub Turski" notifications@github.com wrote:

I've created archetypes/post.md containing some fields. Most of them are
just there to remind me that I should fill them in:

---zyzio: urlhg:

  • fooaliases:
  • barcover_img: urlsocial_img: url---

After hugo new post/foo.md, it turned out that hugo unhelpfully sorted
all of the fields:

---aliases:- barcover_img: urldate: 2014-08-29T23:18:10+01:00hg:- foosocial_img: urltitle: foozyzio: url---

Not really helpful :(


Reply to this email directly or view it on GitHub
#452.

Contributor

natefinch commented Aug 29, 2014

Yeah, the problem is that Hugo isn't just copying the contents of the
fields, it's parsing them and then spitting them back out along with a
couple default values. It's nontrivial to fix, because it's not that we're
sorting them on purpose, that's just hire the underlying libraries work.

You're not the first person to complain about it, and I think you're right,
Hugo should maintain the order. I'll take a look at the code and see how
hard that would be.
On Aug 29, 2014 6:20 PM, "Jakub Turski" notifications@github.com wrote:

I've created archetypes/post.md containing some fields. Most of them are
just there to remind me that I should fill them in:

---zyzio: urlhg:

  • fooaliases:
  • barcover_img: urlsocial_img: url---

After hugo new post/foo.md, it turned out that hugo unhelpfully sorted
all of the fields:

---aliases:- barcover_img: urldate: 2014-08-29T23:18:10+01:00hg:- foosocial_img: urltitle: foozyzio: url---

Not really helpful :(


Reply to this email directly or view it on GitHub
#452.

@spf13 spf13 added this to the v0.13 milestone Aug 30, 2014

@spf13 spf13 added the Enhancement label Oct 19, 2014

@halostatue

This comment has been minimized.

Show comment
Hide comment
@halostatue

halostatue Oct 28, 2014

Contributor

I’ve just been looking at this for the last hour or so, and I’m not sure it’s going to be easy to do. The order of keys is determined by the front matter creator.

If the front matter were a specific type rather than map[string]interface {}, it might be possible to implement this, but it would mean that there would have to be custom encoders/decoders written for that type for each of the parsers (and that may not be easy to do).

Strictly speaking, this isn’t even a matter of the underlying libraries, it’s a deliberate design decision of Go itself for map[] iterating in a pseudorandom matter (it’s explicitly unordered iteration).

Contributor

halostatue commented Oct 28, 2014

I’ve just been looking at this for the last hour or so, and I’m not sure it’s going to be easy to do. The order of keys is determined by the front matter creator.

If the front matter were a specific type rather than map[string]interface {}, it might be possible to implement this, but it would mean that there would have to be custom encoders/decoders written for that type for each of the parsers (and that may not be easy to do).

Strictly speaking, this isn’t even a matter of the underlying libraries, it’s a deliberate design decision of Go itself for map[] iterating in a pseudorandom matter (it’s explicitly unordered iteration).

@mohae

This comment has been minimized.

Show comment
Hide comment
@mohae

mohae Nov 2, 2014

Contributor

It's not surprising that no solution was found as that is the proper behavior and not a bug, according to YAML specs. To do otherwise would be to not follow the specs. In these situations, a sequence is to be used. http://yaml.org/spec/1.2/spec.html#id2765608

I also feel I need to address the 'blaming' of Go for this as this is a misunderstanding of maps and hashes, from a technical perspective. Since maps are hash backed and hashes have no order themselves and it's impossible to infer order from hashes, e.g. sorting files by checksums would not produce anything useful. This is not something unique to Go, which is why YAML specs say the same thing.

Go not supporting ordering of map entries and their solution, to use a more appropriate data-strucuture(s) when ordering is required, or provide methods to provide ordered output, seems reasonable.

I much prefer it to the way other languages allow developers to rely on a side-effect that they shouldn't, ordering of hashes. It leads to numerous problems; Chef's re-ordering of recipes and Salt's re-ordering of their state files, both to the bane of developers writing those files who expect that the code they write will have their order preserved, are two examples that have occurred in recent years.

This bug-report is in the same class, imo, and a result of the same misunderstanding of maps as data strucutures.

Contributor

mohae commented Nov 2, 2014

It's not surprising that no solution was found as that is the proper behavior and not a bug, according to YAML specs. To do otherwise would be to not follow the specs. In these situations, a sequence is to be used. http://yaml.org/spec/1.2/spec.html#id2765608

I also feel I need to address the 'blaming' of Go for this as this is a misunderstanding of maps and hashes, from a technical perspective. Since maps are hash backed and hashes have no order themselves and it's impossible to infer order from hashes, e.g. sorting files by checksums would not produce anything useful. This is not something unique to Go, which is why YAML specs say the same thing.

Go not supporting ordering of map entries and their solution, to use a more appropriate data-strucuture(s) when ordering is required, or provide methods to provide ordered output, seems reasonable.

I much prefer it to the way other languages allow developers to rely on a side-effect that they shouldn't, ordering of hashes. It leads to numerous problems; Chef's re-ordering of recipes and Salt's re-ordering of their state files, both to the bane of developers writing those files who expect that the code they write will have their order preserved, are two examples that have occurred in recent years.

This bug-report is in the same class, imo, and a result of the same misunderstanding of maps as data strucutures.

@halostatue

This comment has been minimized.

Show comment
Hide comment
@halostatue

halostatue Nov 3, 2014

Contributor

@mohae Go originally supported insertion-ordered maps, but the core language designers changed that and changed map iteration to always use a pseudorandom starting hash for iteration so that it would be impossible to depend on that.

You’re right that hashtables are inherently unordered, but it is possible to spec your maps such that they support insertion ordering. The folks behind Go simply chose not to do so (and to make it that much harder to do so). I don’t blame them—it’s a perfectly cromulent decision to make. It’s just an observation that even if the YAML spec said nothing about ordering, Go makes it very difficult to do otherwise.

When I was looking at the solution, I was looking from the perspective of writing an OrderedMap structure that would act like map[string]interface{} but also work with insertion ordering—but I decided that I don’t know enough Go to be able to implement that…and it wouldn’t help in any case because we are using parsers that insert into map[string]interface{} so I would lose the sorting battle before it even got started.

All that clear, I think that this just has to be closed because it is pathologically unfixable from a Go perspective (unless, again, Hugo were to switch to streaming parsers and perform the bulk of the parsing itself into an OrderedMap type of structure; I have no interest in implementing something like that).

Contributor

halostatue commented Nov 3, 2014

@mohae Go originally supported insertion-ordered maps, but the core language designers changed that and changed map iteration to always use a pseudorandom starting hash for iteration so that it would be impossible to depend on that.

You’re right that hashtables are inherently unordered, but it is possible to spec your maps such that they support insertion ordering. The folks behind Go simply chose not to do so (and to make it that much harder to do so). I don’t blame them—it’s a perfectly cromulent decision to make. It’s just an observation that even if the YAML spec said nothing about ordering, Go makes it very difficult to do otherwise.

When I was looking at the solution, I was looking from the perspective of writing an OrderedMap structure that would act like map[string]interface{} but also work with insertion ordering—but I decided that I don’t know enough Go to be able to implement that…and it wouldn’t help in any case because we are using parsers that insert into map[string]interface{} so I would lose the sorting battle before it even got started.

All that clear, I think that this just has to be closed because it is pathologically unfixable from a Go perspective (unless, again, Hugo were to switch to streaming parsers and perform the bulk of the parsing itself into an OrderedMap type of structure; I have no interest in implementing something like that).

@bep

This comment has been minimized.

Show comment
Hide comment
@bep

bep Nov 15, 2014

Member

What I could like a little better than the current situation, and should be easy to implement, is to add some kind of sorting prior to writing the front matter to file. Even alphabetic would be better than today's shuffle.

But also maybe weigh some fields higher than others, title, date? I have been a little bit annoyed about this when browsing my content on GitHub.

EDIT IN: I notice Hugo uses a string map also internally, which makes the above NOT so easy to implement. But there are sorted map implementations out there.

Member

bep commented Nov 15, 2014

What I could like a little better than the current situation, and should be easy to implement, is to add some kind of sorting prior to writing the front matter to file. Even alphabetic would be better than today's shuffle.

But also maybe weigh some fields higher than others, title, date? I have been a little bit annoyed about this when browsing my content on GitHub.

EDIT IN: I notice Hugo uses a string map also internally, which makes the above NOT so easy to implement. But there are sorted map implementations out there.

@derekperkins

This comment has been minimized.

Show comment
Hide comment
@derekperkins

derekperkins Nov 20, 2014

Contributor

Does it really need to parse the parameters at that point? Couldn't it just parse them to ensure validity, then copy the original into the new post? It shouldn't be too hard to do a simple string insertion of the date or any other auto-injected parameters.

Contributor

derekperkins commented Nov 20, 2014

Does it really need to parse the parameters at that point? Couldn't it just parse them to ensure validity, then copy the original into the new post? It shouldn't be too hard to do a simple string insertion of the date or any other auto-injected parameters.

@bep

This comment has been minimized.

Show comment
Hide comment
@bep

bep Nov 20, 2014

Member

@derekperkins I haven't looked closely into this one, but the parsing is delegated to different frameworks (YAML, TOML, JSON) -- when Hugo gets the data it is a Go map, and there has been no guaranteed iteration order in those maps since Go 1.

Member

bep commented Nov 20, 2014

@derekperkins I haven't looked closely into this one, but the parsing is delegated to different frameworks (YAML, TOML, JSON) -- when Hugo gets the data it is a Go map, and there has been no guaranteed iteration order in those maps since Go 1.

@halostatue

This comment has been minimized.

Show comment
Hide comment
@halostatue

halostatue Nov 20, 2014

Contributor

@derekperkins, @bjornerik is correct and what I found with my quick investigation and where I noted that we would still need to write custom encoders and decoders to ensure an order to the map.

You also can’t not parse the archetype front matter, because the archetype may be coming from the theme that you’re using and you may have indicated that you prefer a different front matter format than what the archetype indicated (with the MetaDataFormat option).

Contributor

halostatue commented Nov 20, 2014

@derekperkins, @bjornerik is correct and what I found with my quick investigation and where I noted that we would still need to write custom encoders and decoders to ensure an order to the map.

You also can’t not parse the archetype front matter, because the archetype may be coming from the theme that you’re using and you may have indicated that you prefer a different front matter format than what the archetype indicated (with the MetaDataFormat option).

@derekperkins

This comment has been minimized.

Show comment
Hide comment
@derekperkins

derekperkins Nov 21, 2014

Contributor

This is what I came up with to solve the problem.

// This is my archetype
+++
[Main]
    title               = "title"
    description         = "insert_description_here"
    author              = "Derek|Joe|Tanner"

[ID]
    slug                = "slug"
    disqus_identifier   = "this_needs_to_be_unchangeable_and_unique"

[Taxonomies]
    devtags             = ["tag1", "tag2"]
    personas            = ["cat1", "cat2"]
    series              = ["x", "y"]
+++

When I create a new post, this is what comes out. Comments are stripped out and the map is alphabetized, but the grouping solves most of my issues.

+++
date = "2014-11-20T18:01:54-07:00"
title = "newpost"

[ID]
  disqus_identifier = "this_needs_to_be_unchangeable_and_unique"
  slug = "mynewpost"

[Main]
  author = "Tanner"
  description = "insert_description_here"
  title = "title"

[Taxonomies]
  devtags = ["tag1", "tag2"]
  personas = ["cat1", "cat2"]
  series = ["x", "y"]
+++
Contributor

derekperkins commented Nov 21, 2014

This is what I came up with to solve the problem.

// This is my archetype
+++
[Main]
    title               = "title"
    description         = "insert_description_here"
    author              = "Derek|Joe|Tanner"

[ID]
    slug                = "slug"
    disqus_identifier   = "this_needs_to_be_unchangeable_and_unique"

[Taxonomies]
    devtags             = ["tag1", "tag2"]
    personas            = ["cat1", "cat2"]
    series              = ["x", "y"]
+++

When I create a new post, this is what comes out. Comments are stripped out and the map is alphabetized, but the grouping solves most of my issues.

+++
date = "2014-11-20T18:01:54-07:00"
title = "newpost"

[ID]
  disqus_identifier = "this_needs_to_be_unchangeable_and_unique"
  slug = "mynewpost"

[Main]
  author = "Tanner"
  description = "insert_description_here"
  title = "title"

[Taxonomies]
  devtags = ["tag1", "tag2"]
  personas = ["cat1", "cat2"]
  series = ["x", "y"]
+++

@anthonyfok anthonyfok added the Bug label Jan 14, 2015

@anthonyfok

This comment has been minimized.

Show comment
Hide comment
@anthonyfok

anthonyfok Jan 14, 2015

Contributor

I noticed this discrepancy while going through the documentation, and did some testing. With the example archetypes/default.md of:

+++
tags = ["x", "y"]
categories = ["x", "y"]
+++

Hugo v0.11 (hugo_0.11_amd64_linux new post/test.md) gives:

+++
categories = ["x", "y"]
tags = ["x", "y"]
title = "test"
date = 2015-01-14T02:26:19Z
+++

whereas Hugo v0.12 and above (up to HEAD of v0.13-DEV) gives:

+++
categories = ["x", "y"]
date = "2015-01-13T19:20:04-07:00"
tags = ["x", "y"]
title = "test"

+++

I couldn't get -f yaml to work with Hugo v0.11, but oh well... :-)

So, regardless of the root cause, to the end users, it is a regression: At least for TOML, It used to keep the proper order in v0.11, but now it sorts all the variables alphabetically and messes things up. I haven't looked into it any deeper, though I wonder if a commit in Hugo causes this, or whether an external library changed.

Just my 2 cents. :-)

Contributor

anthonyfok commented Jan 14, 2015

I noticed this discrepancy while going through the documentation, and did some testing. With the example archetypes/default.md of:

+++
tags = ["x", "y"]
categories = ["x", "y"]
+++

Hugo v0.11 (hugo_0.11_amd64_linux new post/test.md) gives:

+++
categories = ["x", "y"]
tags = ["x", "y"]
title = "test"
date = 2015-01-14T02:26:19Z
+++

whereas Hugo v0.12 and above (up to HEAD of v0.13-DEV) gives:

+++
categories = ["x", "y"]
date = "2015-01-13T19:20:04-07:00"
tags = ["x", "y"]
title = "test"

+++

I couldn't get -f yaml to work with Hugo v0.11, but oh well... :-)

So, regardless of the root cause, to the end users, it is a regression: At least for TOML, It used to keep the proper order in v0.11, but now it sorts all the variables alphabetically and messes things up. I haven't looked into it any deeper, though I wonder if a commit in Hugo causes this, or whether an external library changed.

Just my 2 cents. :-)

@halostatue

This comment has been minimized.

Show comment
Hide comment
@halostatue

halostatue Jan 14, 2015

Contributor

That doesn’t look right, @anthonyfok. As you indicated, if you have this archetype:

+++
tags = ["x", "y"]
categories = ["x", "y"]
+++

If Hugo v0.11 (hugo_0.11_amd64_linux new post/test.md) gives,

+++
categories = ["x", "y"]
tags = ["x", "y"]
title = "test"
date = 2015-01-14T02:26:19Z
+++

Notice that categories and tags are now sorted and not the same order as the archetype. The later versions also sort, but insert a few other fields.

As I indicated, this is something that the Go team has gone out of its way to ensure map structures do not iterate the same way every time (without providing an omap implementation that would make this work for us).

That said, I did a little more digging, and the folks behind YAML have possibly done us a favour if we use yaml.MapSlice instead of map[string]interface{}. It’s not perfect (you lose fast lookup…), but I don’t know of another way to have an ordered map in Go at this point.

Contributor

halostatue commented Jan 14, 2015

That doesn’t look right, @anthonyfok. As you indicated, if you have this archetype:

+++
tags = ["x", "y"]
categories = ["x", "y"]
+++

If Hugo v0.11 (hugo_0.11_amd64_linux new post/test.md) gives,

+++
categories = ["x", "y"]
tags = ["x", "y"]
title = "test"
date = 2015-01-14T02:26:19Z
+++

Notice that categories and tags are now sorted and not the same order as the archetype. The later versions also sort, but insert a few other fields.

As I indicated, this is something that the Go team has gone out of its way to ensure map structures do not iterate the same way every time (without providing an omap implementation that would make this work for us).

That said, I did a little more digging, and the folks behind YAML have possibly done us a favour if we use yaml.MapSlice instead of map[string]interface{}. It’s not perfect (you lose fast lookup…), but I don’t know of another way to have an ordered map in Go at this point.

@anthonyfok

This comment has been minimized.

Show comment
Hide comment
@anthonyfok

anthonyfok Jan 15, 2015

Contributor

I stand corrected. Thank you for your detailed explanation, @halostatue.

(I didn't even read my tests correctly. Note to self: Next time, read the whole thread before speaking.)

Thanks for digging deeper into this: the new yaml.MapSlice in yaml.v2 sounds interesting indeed.

Cheers,
Anthony

Contributor

anthonyfok commented Jan 15, 2015

I stand corrected. Thank you for your detailed explanation, @halostatue.

(I didn't even read my tests correctly. Note to self: Next time, read the whole thread before speaking.)

Thanks for digging deeper into this: the new yaml.MapSlice in yaml.v2 sounds interesting indeed.

Cheers,
Anthony

@spf13 spf13 modified the milestones: v0.13, v0.14 Feb 22, 2015

@anthonyfok anthonyfok modified the milestones: v0.15, v0.14 Sep 16, 2015

@dimo414

This comment has been minimized.

Show comment
Hide comment
@dimo414

dimo414 Oct 1, 2015

Contributor

Just to clarify, the reason Hugo needs to parse and re-write the archetype files is just to insert the date and title fields, correct? I know it's hack, but why not simply insert those strings into the file contents right after the ---/+++? While map data structures may not be ordered, data mappings often are, and if the parser available for Go can't support that use case, it seems like (for this specific task) it shouldn't be used at all.

Contributor

dimo414 commented Oct 1, 2015

Just to clarify, the reason Hugo needs to parse and re-write the archetype files is just to insert the date and title fields, correct? I know it's hack, but why not simply insert those strings into the file contents right after the ---/+++? While map data structures may not be ordered, data mappings often are, and if the parser available for Go can't support that use case, it seems like (for this specific task) it shouldn't be used at all.

@bep

This comment has been minimized.

Show comment
Hide comment
@bep

bep Oct 1, 2015

Member

@dimo414 you got a point. It would make the code a little more complex, but doable I guess. Well tested PRs are welcome.

Member

bep commented Oct 1, 2015

@dimo414 you got a point. It would make the code a little more complex, but doable I guess. Well tested PRs are welcome.

@mohae

This comment has been minimized.

Show comment
Hide comment
@mohae

mohae May 8, 2016

Contributor

The undraft command does something similar, except it is handling all of the supported frontmatter types. The commit is b487178.

It shouldn't be too hard to do something similar for this.

Contributor

mohae commented May 8, 2016

The undraft command does something similar, except it is handling all of the supported frontmatter types. The commit is b487178.

It shouldn't be too hard to do something similar for this.

@havron

This comment has been minimized.

Show comment
Hide comment
@havron

havron Jul 9, 2016

Hacky (1337 h4x0r worthy?) short-term solution that works: I prepend all of my archetype names with alphanumeric characters that exploit the ordering priority, then use a sed expression to filter them out of the frontmatter of the created post. A Makefile makes it simple to execute.

For instance, if archetypes/default.md looks like this:

+++
a-tags = ["x", "y"]
b-categories = ["x", "y"]
+++

then a-tags comes before b-categories in the frontmatter of a new post, despite the word 'tags' being after 'categories' alphabetically.
digits 0-9 have higher priority than alphabet characters, so using 0-*, 1-* etcetera would probably be a bit cleaner (or z0-*,z1-* etc if you wanted to place them after title and date...you can be very flexible with assigning priorities). After running hugo new section/filename.md, I could run
sed -i '/^date/!s/^.*-//' content/section/filename.md to remove the prepended text and exclude the date frontmatter from getting overwritten.

To wrap it up cleanly, I can include a new target in a Makefile:

# Makefile
N=default.md
new:
    hugo new ${N}
    sed -i '/^date/!s/^.*-//' content/${N}

and run make new N="section/filename.md" rather than directly calling
hugo new section/filename.md. Known side effect: hugo server --watch won't like what it's watching. You have to complete make on its own before starting (or resuming) a development server.

Ultimately, I sacrifice typing 4 more characters to create a new post, and have to populate my archetypes/default.md appropriately with the priorities I want. It works, though! Actually, if you find you generally only use one section (I typically only use post for my blog), you could make an S section variable and code it into the target. Saves me from typing those 4 characters and makes up for the extra 4 I need to type to run the Makefile anyway, so it comes out even! Of course, the sed expression will have to change if you are using hyphens in your frontmatter naming.

To make the input/enumeration side of the process even faster, you could name the target n, not use quotes when defining N, live-it-up Windows-style and hardcode the .md extension into the target, and call vi or some other editor as the last line in the target (since you were probably planning on editing it after going to the trouble of creating it).

I was inspired to use prepending because it's how I get around the weird way that the (unrelated) OCaml compiler resolves file dependencies when calling ocamlopt *.ml.

havron commented Jul 9, 2016

Hacky (1337 h4x0r worthy?) short-term solution that works: I prepend all of my archetype names with alphanumeric characters that exploit the ordering priority, then use a sed expression to filter them out of the frontmatter of the created post. A Makefile makes it simple to execute.

For instance, if archetypes/default.md looks like this:

+++
a-tags = ["x", "y"]
b-categories = ["x", "y"]
+++

then a-tags comes before b-categories in the frontmatter of a new post, despite the word 'tags' being after 'categories' alphabetically.
digits 0-9 have higher priority than alphabet characters, so using 0-*, 1-* etcetera would probably be a bit cleaner (or z0-*,z1-* etc if you wanted to place them after title and date...you can be very flexible with assigning priorities). After running hugo new section/filename.md, I could run
sed -i '/^date/!s/^.*-//' content/section/filename.md to remove the prepended text and exclude the date frontmatter from getting overwritten.

To wrap it up cleanly, I can include a new target in a Makefile:

# Makefile
N=default.md
new:
    hugo new ${N}
    sed -i '/^date/!s/^.*-//' content/${N}

and run make new N="section/filename.md" rather than directly calling
hugo new section/filename.md. Known side effect: hugo server --watch won't like what it's watching. You have to complete make on its own before starting (or resuming) a development server.

Ultimately, I sacrifice typing 4 more characters to create a new post, and have to populate my archetypes/default.md appropriately with the priorities I want. It works, though! Actually, if you find you generally only use one section (I typically only use post for my blog), you could make an S section variable and code it into the target. Saves me from typing those 4 characters and makes up for the extra 4 I need to type to run the Makefile anyway, so it comes out even! Of course, the sed expression will have to change if you are using hyphens in your frontmatter naming.

To make the input/enumeration side of the process even faster, you could name the target n, not use quotes when defining N, live-it-up Windows-style and hardcode the .md extension into the target, and call vi or some other editor as the last line in the target (since you were probably planning on editing it after going to the trouble of creating it).

I was inspired to use prepending because it's how I get around the weird way that the (unrelated) OCaml compiler resolves file dependencies when calling ocamlopt *.ml.

@moorereason moorereason modified the milestones: future, v0.17 Sep 16, 2016

@kaushalmodi

This comment has been minimized.

Show comment
Hide comment
@kaushalmodi

kaushalmodi Oct 5, 2016

Member

Came here to say that on Hugo v0.17-DEV built today,

with the following in archetypes/default.md:

+++
tags = ["x", "y"]
categories = ["x", "y"]
+++

, doing hugo new post/foo.md gives:

+++
tags = [
  "x",
  "y",
]
categories = [
  "x",
  "y",
]
date = "2016-10-05T18:02:24-04:00"
title = "foo"

+++

Update: It looks like the frontmatter order is random. I tried the same thing again and now I got:

+++
date = "2016-10-05T18:14:05-04:00"
title = "foo2"
tags = [
  "x",
  "y",
]
categories = [
  "x",
  "y",
]

+++
Member

kaushalmodi commented Oct 5, 2016

Came here to say that on Hugo v0.17-DEV built today,

with the following in archetypes/default.md:

+++
tags = ["x", "y"]
categories = ["x", "y"]
+++

, doing hugo new post/foo.md gives:

+++
tags = [
  "x",
  "y",
]
categories = [
  "x",
  "y",
]
date = "2016-10-05T18:02:24-04:00"
title = "foo"

+++

Update: It looks like the frontmatter order is random. I tried the same thing again and now I got:

+++
date = "2016-10-05T18:14:05-04:00"
title = "foo2"
tags = [
  "x",
  "y",
]
categories = [
  "x",
  "y",
]

+++

@bep bep changed the title from Archetype fields are sorted upon instantiations with yaml metadata to Archetype fields are sorted upon instantiations Feb 15, 2017

@bep bep changed the title from Archetype fields are sorted upon instantiations to Archetype fields are parsed/sorted upon instantiations Feb 28, 2017

@bep bep modified the milestones: v0.21, future Apr 13, 2017

@bep bep modified the milestones: v0.22, v0.21 May 9, 2017

@bep bep modified the milestones: v0.22, v0.23 Jun 7, 2017

@bep bep modified the milestones: v0.23, v0.24 Jun 16, 2017

@bep bep self-assigned this Jun 16, 2017

@bep bep added the InProgress label Jun 16, 2017

bep added a commit to bep/hugo that referenced this issue Jun 16, 2017

bep added a commit to bep/hugo that referenced this issue Jun 18, 2017

create: Use archetype template as-is as a Go template
This commit removes the fragile front matter decoding, and takes the provided archetype file as-is and processes it as a template.

This also means that we no longer will attempt to fill in default values for `title` and `date`.

The upside is that it is now easy to create these values in a dynamic way:

```toml
+++
title = {{ .Name | title }}
date = {{ .Date }}
draft = true
+++
```

You can currently use all of Hugo's template funcs, but the data context is currently very shallow:

* `.Type` gives the archetype kind provided
* `.Name` gives the target file name without extension.
* `.Path` gives the target file name
* `.Date` gives the current time as RFC3339 formatted string

The above  will probably be extended in #1629.

Fixes #452
Updates #1629

@bep bep closed this in #3605 Jun 18, 2017

bep added a commit that referenced this issue Jun 18, 2017

create: Use archetype template as-is as a Go template
This commit removes the fragile front matter decoding, and takes the provided archetype file as-is and processes it as a template.

This also means that we no longer will attempt to fill in default values for `title` and `date`.

The upside is that it is now easy to create these values in a dynamic way:

```toml
+++
title = {{ .BaseFileName | title }}
date = {{ .Date }}
draft = true
+++
```

You can currently use all of Hugo's template funcs, but the data context is currently very shallow:

* `.Type` gives the archetype kind provided
* `.Name` gives the target file name without extension.
* `.Path` gives the target file name
* `.Date` gives the current time as RFC3339 formatted string

The above  will probably be extended in #1629.

Fixes #452
Updates #1629
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment