Hugo: Add Content Bags

[bep]

This issue has been discussed before: #3462 etc.

• A content folder is identified as a bundle if it contains either a _index.* or a index.* file.
• For index.* files (i.e. single content pages) type of bundles, the bundle will also include any sub folders (i.e. images etc.).

Thinking in Go terms, we add a new Resource type (a Page is a Resource):

interface Resource {
   Permalink() string
   RelPermalink() string
}

• $funnyCatsPage.Pages => [even-more-content.md, more-content.md]
• $funnyCatsPage.Resources => [even-more-content.md, more-content.md, cat.jpg, another-cat.jpg]
• $funnyCatsPage.Resources.ByType "image" => [cat.jpg, another-cat.jpg]
• The sub-content-pages will not have Permalink, i.e they will not be rendered to disk on its own, but will typically be used to compose the "bag page".

A Page is a Resource, but we will need others, one example would be Image, which would have some additional image related properties, such as Width and Height, but also methods to generate alternate versions of that image:

$cat := $funnyCatsPage.GetResource "image" "cat.jpg"
$scaled := $cat.Scale "1000x600"

<img src="{{ $scaled.Permalink }}" width={{ $scaled.Width }} height={{ $scaled.Height }}>

The API above is just an example. But I think this "processing only when needed" will scale better than, say, create 5 different version of every image, even if only a small fraction is in actual use.

NOTE: This proposal is about how the bags in Hugo should look like at its core -- it is not about details in a future image scaling APIs etc. The only way to get this done is to define a fairly narrow scope.

TODO: Permalinking, ...

Related

• Galleries
• Image cropping, resizing and compression, see #3207 etc.
• Resource linking in markdown (with cropping, resizing etc.)
• ??

[lebarde]

When I hear about a bundle, I cannot prevent me from thinking about extending the software or having a specific software distribution/flavor. IMHO, as it is the case in other projects, a bundle in itself would sound as Hugo extensions. Why having a new term and not sticking with sections?

[bep]

Why having a new term and not sticking with sections?

Because a Section would contain 0:* bundles. I'm not married to that term, but it cannot be Section, because that is already taken.

[bep]

@thewebmastercom I put a NOTICE in bold above; what you talk about is interesting, but is far outside of the scope of this issue.

[MunifTanjim]

Bundle does sound like some kind of extension/plugin for Hugo. Possible suggestion:

• Collection
• Packet / Pack

I like the sound of Collection.

[bep]

I like the sound of Collection.

The sound is fine, but will be confused by Jekyll's collections: https://jekyllrb.com/docs/collections/

Pack sounds snappy, but what abut Bag? Even shorter.

[MunifTanjim]

Bag sounds great. It even describes itself perfectly. I like it!

[Jos512]

I've thoughtfully read the posts above, but is bag predicated on the coupling of content files with image files?

In other words, if we don't store our cat images in the same folder as in which cat-article.md defines that folder to be a funnyCatsPage bag, then the images and other files are not part of the bag, right?

I can see the appeal of adding non-content files (like .jpg) to a taxonomy collection (what bag basically seems to be), but from my standpoint it also seems quite complicated to explain to new users.

And it also feels limiting that defining a bag does not seem possible if one separates images (in /static/) from content files (/content/) -- which is what we all do now.

(Don't mean to be negative, just hope to help a bit in this way.)

[onedrawingperday]

Not quite sure about bag LOL! It reminds of leather goods (obviously). I prefer pack but it's your call @bep

Other than that I really like this blueprint and how it opens up the possibility for a whole new set of features to be developed in the future.

[MunifTanjim]

It's all about establishing community standards :stuck_out_tongue:
Plugin, Bundle, Package - each has their own well established meanings. Who knows, years from now, maybe there will be some project on GitHub looking for a name for their new feature and somebody would say, "We can't name this feature Bag! Hugo used this for a completely different thing!"
I've seen the term Pack being used here and there. But Bag! Nowhere :joy: Maybe it's a good thing :wink: @onedrawingperday

[bep]

We already have Scratch, which is also a little bit funky, and Bag fits nicely into that.

@Jos512 I think most people are familiar with grouping related files in the same folder, and this is just the foundation. But I'm not building a Swiss Army knife until I know I really need it -- and it is still possible to use Hugo as is.

[onedrawingperday]

@bep scratch the bag! LMAO!!

[bep]

But Bag! Nowhere

Hibernate (Java ORM library) uses Bag for one their collection types ...

[moorereason]

@bep,
First of all, this would be another fantastic step forward for Hugo. It's also another item on Steve's "Future of Hugo" brain dump.

Second, I suppose it doesn't really matter, but I like Bundle over Bag. I think Steve called them Bundles. The context here is "content." It's a content bundle, not a software bundle. "Bag" sounds like a bag of crap, which I hope my content is not. :wink:

Now, on to my main question:

└── blog
    └── funny-cats
        ├── anothercat.jpg
        ├── cat-article.md
        ├── cat.jpg
        ├── even-more-content.md
        └── more-content.md

Would the default URL for this be /blog/funny-cats/cat-article/ or /blog/funny-cats/. It's a little confusing to me either way. It would normally be created as /blog/funny-cats/cat-article/, but it feels odd to have all of the extra files in a path on disk that doesn't match the path of the output. However, creating /blog/funny-cats/ feels abnormal since the "bag" file is called cat-article.

Surprises and oddities create confusion, add to the cognitive load on the user, and make writing docs harder (and way more necessary).

Suggested Solution

Why not require the use of index.md to create a bag?

└── blog └── funny-cats ├── anothercat.jpg ├── index.md ├── cat.jpg ├── even-more-content.md └── more-content.md

If bag=false for index.md, we treat it as we do now and create three pages:

• /blog/funny-cats/
• /blog/funny-cats/even-more-content/
• /blog/funny-cats/more-content/

If bag=true for index.md, we create only:

• /blog/funny-cats/

Nothing about that feels surprising to me.

[bep]

/blog/funny-cats/

Yes, however we do it, the "file slug" for the bag will be the container, i.e. the folder, so it should in the URL department behave much like how the /myarticle/index.md works today. We can maybe get rid of the bag=true and continue with the index.md only, let's see how that unfolds.

[bep]

As to bundles, I think we should reserve that for "something else" in the future, like "shortcode bundles", plugins, theme bundles, whatever.

[budparr]

With apologies for being dense: Do "bags" stand next to Sections, or are Sections inside of "bags." And/or why can't "bags" just be Sections?

I think the concept of sections and subsections and types gives one quite a bit of flexibility and I fear another concept will cause ongoing confusion for users.

And, for what it's worth, I think "collections" is a much more meaningful word and I don't think it matters what Jekyll uses.

[bep]

A bag is a Page with some additional Resources. I think all of this would be easier if we just dropped the special name and just call it a Page.

[budparr]

I see, so it's an article. Your original proposal seems clearer now that you said that, because "bags" makes it seem like something else entirely.

[rdwatters]

pack = 👍
collection = 👍
article = 👍
bag = 👎
bundle = 👎

That said, pack: true is probably my favorite, since this is, from what I can tell, kind of the confluence between an article and list page with the assets packed along with it.

[lebarde]

For what I've understood for now, I assume we may not really need such a term. At least it could be transparent for the end user.
What we want to do is add resources to a content, whatever it be a section or a leaf page. It would simply sound natural to me to add a collection of resources inside the front matter, just like this:

resources:
  - res/
  - images/   # directory relative to the current post's location
  - /my-journey-throught-scotland/
  - my-beautiful-landscape.jpg

Note that I have mixed absolute directories, relative ones, and direct links to files. This may be discussed.

But why do we need more than a resource name? IMHO it would simply sound more natural. In the end, the Bag, Bundle or whatever would be transparent if this is a name that is implemented in the code. And inside the code we could use something more descriptive, such as ContentResources.

Do I have I missed something?

[Jos512]

What we want to do is add resources to a content, whatever it be a section or a leaf page. It would simply sound natural to me to add a collection of resources inside the front matter.

I like this approach. Also because it can be used to specify which files from /static/ belong to the bag (or what the name becomes). With that, people who like to put their static files in /content/ alongside the content file can do that (for the automatic generation of bag).

And people with 'legacy' websites made with Hugo don't have to restructure their content to use bags but can simply do so with the front matter. And with the imageConfig function we already have, Hugo can already read files on the system so it might probably not be that hard to implement.

[bep]

Do I have I missed something?

Yes. This is kind of what we have today, but with a less formal definition.

Have a look at this commit:

https://github.com/bep/bepsays.com/commit/994d0fec8475d98458268bfadd51a67026087ab8#diff-e6986871ee8d4815fbc2b3a88f636658R9

This is me announcing a new Hugo release. This announcement/pack/bag/article contains 1 markdown file and 1 image. The image is used both in markdown and in the template (Twitter image).

So I do this:

1) I copy the image to a path in /static
2) I carefully insert the path in the front matter
3) I carefully insert the path in a image link in markdown

This is for one image, and I already hate it.

So, currently, what people do is this, inside /myarticle:

index.md
myimage.jpg

This solves some of the pain, but the URL to /myarticle/myimage.jpg will be broken if I (or the editor I send this article to), decides to move it to /my-cool-article.

So how do I avoid the two pains described above?

I create a naming convention where I can "bundle" content and images etc. together with as little work as possible, and let Hugo handle all the URLs for me. So I can just drag-and-drop new resources into my article.

The folder or Zip file analogy is easy to understand for most people.

And then you will notice above that I have said that this "naming convention" most likely will be followed up with a configuration extension (front matter, bag.toml) where one can manually define resources (external?).

[bep]

[neeklamy]

I accidentally voted for ‘Rucksacks’ (I didn’t examine the URLs closely enough, I didn’t see the animation and I thought it was a plain image), and there’s currently no way to undo a vote (tj/gh-polls#8).

@bep, any reason why Page isn’t on the list? You said previously about dropping the special name, “I think all of this would be easier if we just dropped the special name and just call it a Page.” Seems like that would be better than adding new terminology.

[bep]

@neeklamy it was just a joke (and a test of the polls, see https://github.com/tj/gh-polls )... None of the options (other than the first one) make much sense...

[neeklamy]

Phew! You got me!

Are you not considering just naming them Page? Or does that not distinguish the idea enough? If not how about some modifier, not so catchy, for sure, but something like Self-contained Page?

[bep]

Are you not considering just naming them Page?

Yes, I will not give them a name. It will be a characteristic of a Page.

[vjeantet]

I accidentally voted for ‘Rucksacks’ (I didn’t examine the URLs closely enough, I didn’t see the animation and I thought it was a plain image), and there’s currently no way to undo a vote (tj/gh-polls#8).

I did the same :(

[rdwatters]

it was just a joke

Just when I was getting attached to "briefcases."

[digitalcraftsman]

Rucksacks would have been my favorite as a German :wink:

[DirtyF]

Norwegian humor is underrated.

[zjedi]

Thanks for taking this on, I intended to contribute myself but then I realized I have no capacity left to learn GO.

[bep]

Hey gang,

What do you say about my now simplified definition of "how to identify a bundle":

• A content folder is identified as a bundle if it contains either an _index.* or an index.* file.
• For index.* files (i.e. single content pages) type of bundles, the bundle will also include any sub folders (i.e. /mypost/images etc.).

We may add metadata in the future, and I'm just calling it bundle here to have a name to pin to the term.

[rdwatters]

I like it quite a lot. Simple and intuitive. Also, I think "bundle" is a pretty intuitive term, although used in other contexts for different purposes. Nothing wrong with a "Hugo bundle" meaning something very specific. Thanks, @bep!

[moorereason]

For index.* files (i.e. single content pages) type of bundles, the bundle will also include any sub folders (i.e. /mypost/images etc.).

I'm not yet sold on the bundle including any sub-folders idea, mainly because it's not clear to me what happens to the sub-folders. Does the parent bundle gobble up all of the sub-folders or can I continue to deal with the sub-folders individually if I want to?

For example, say I have a Products section on a site which includes sub-sections for Desktops & Servers. And let's say I want to bundle resources within the content folder.

├── desktops
│   ├── index.md
│   ├── product-1.png
│   ├── product-2.png
│   └── quotes.md
├── feature.md
├── index.md
├── products-1.png
├── products-2.png
└── servers
    ├── index.md
    ├── product-1.png
    ├── product-2.png
    └── quotes.md

Let's assume that I want to build a shared template for the product sub-sections (and I give them a special "section" in their front matter). When I'm building the sub-section template, I would expect to be able to use .Pages (as [quotes.md]) and .Resources (as [product-1.png, product-2.png, quotes.md]).

[middling]

This seems a similar idea to TextBundle which already has some support among Markdown clients.

[marcojakob]

I really like the idea of a bundle. It has always been my intuition to keep text content and assets together. Thank you for working on this!

On a lot of websites I already use it like @bep described above with index.md or _index.md:

├── content/
    └── _index.md
    └── home-image.jpg
    └── about/
    │   └── _index.md
    └── blog/
        ├── _index.md
        ├── firstpost/
        │   └── index.md
        │   └── post-image-1.jpg
        └── secondpost/
            └── index.md
            └── post-image-2.jpg

This works fine. See also Structure B in this Discussion: Content Organization Best Practice.

@bep, you write:

This solves some of the pain, but the URL to /myarticle/myimage.jpg will be broken if I (or the editor I send this article to), decides to move it to /my-cool-article.

This has not been a probem for me (except for multilingual sites - see below). I use relative paths in my front matter and markdown like ![My Image](myimage.jpg). With this I can rename the folder and the images still work.

Problem with Multilingual Sites

The relative paths to images as described above break in multilingual sites!

I know my example gets a bit complicated since it is nested and multilingual content. But I would like to use it in this form for a larger tutorial collection with translations in more than ten languages (see live example here which is not migrated to Hugo yet).

├── content/
    └── _index.md
    └── home-image.jpg
    └── library/
        ├── _index.md
        ├── html-tutorial/
            └── _index.de.md
            └── _index.en.md
            └── tutorial-overview-de.jpg
            └── tutorial-overview-en.jpg
            └── part1/
            │   └── _index.de.md
            │   └── _index.en.md
            │   └── part1-image-de.jpg
            │   └── part1-image-en.jpg
            └── part2/
            │   └── _index.de.md
            │   └── _index.en.md

In this form the relative images do not work any more. Hugo adds a language prefix, e.g. /de/ for German as the root path. The German page for part1 will be in /de/library/html-tutorial/part1/index.html while the images are under the path without language prefix, for example /library/html-tutorial/part1/part1-image-de.jpg.

To consider for Bags/Bundles

Sorry for the long post. I just hope to add some thoughts that might need to be considered for the Bag/Bundle implementation:

• They could help with bundling multilingual assets together with their text content (if done right!).
• Handling nested content with a bundle seems tricky: include subfolder or not as mentioned by @moorereason above. I would consider every folder a separate bundle. This way we can have nested bundles as would be needed in my example above.
• Another thing to consider is how bundles relate to assets stored in an external storage (necessary for large projects since you shouldn't have gigabytes of binaries in a Git repo). See Structure C in this discussion.
• I think bundles/bags would be an awesome Hugo feature!

[simonszu]

Hi, @all

Forgive my Lack of formatting this Mail, i am texting with shitty reception
on my old mobile.

All these posts talk about keeping pictures with hugo, so in most
deployment scenarios, in a git repo. I don't know but i am quite unhappy
with keeping large blobs in a git. Some Photos i take and want to publish
have around 5MB in file size.

I know there are imagemagick scripts for decreasing file size, but maybe it
could be possible to create some kind of subcommand into Hugo that can
compress images. I know that it is not easy, since deployment to a git Repo
and hugoing this Repo happens with almost no Hugo, just with git, but maybe
we can find a solution.

I just wanted to let you know that there are people like me who have large
(Image) blobs with Hugo, like this Directory Layout, but are wondering
about keeping These pictures (a Gallery has like 20x5MB) reasonably in a
git.

On Sun, Oct 8, 2017, 00:43 Marco Jakob [e-mail] wrote:

I really like the idea of a bundle. It has always been my intuition to
keep text content and assets together. Thank you for working on this!

On a lot of websites I already use it like @bep https://github.com/bep
described above with index.md or _index.md:

├── content/
└── _index.md
└── home-image.jpg
└── about/
│ └── _index.md
└── blog/
├── _index.md
├── firstpost/
│ └── index.md
│ └── post-image-1.jpg
└── secondpost/
└── index.md
└── post-image-2.jpg

This works fine. See also Structure B in this Discussion: Content
Organization Best Practice
https://discourse.gohugo.io/t/discussion-content-organization-best-practice/6360/3
.

@bep https://github.com/bep, you write:

This solves some of the pain, but the URL to /myarticle/myimage.jpg will
be broken if I (or the editor I send this article to), decides to move it
to /my-cool-article.

This has not been a probem for me (except for multilingual sites - see
below). I use relative paths in my front matter and markdown like `[image:
My Image] http://myimage.jpg. With this I can rename the folder and the
images still work.
Multilingual Sites

The relative paths to images as described above break in multilingual
sites!

I know my example gets a bit complicated since it is nested and
multilingual content. But I would like to use it in this form for a larger
tutorial collection with translations in more than ten languages (see live
example here http://code.makery.ch/library/javafx-8-tutorial/part1/
which is not migrated to Hugo yet).

├── content/
└── _index.md
└── home-image.jpg
└── library/
├── _index.md
├── html-tutorial/
└── _index.de.md
└── _index.en.md
└── tutorial-overview-de.jpg
└── tutorial-overview-en.jpg
└── part1/
│ └── _index.de.md
│ └── _index.en.md
│ └── part1-image-de.jpg
│ └── part1-image-en.jpg
└── part2/
│ └── _index.de.md
│ └── _index.en.md

In this form the relative images do not work any more. Hugo adds a
language prefix, e.g. /de/ for German as the root path. The German page
for part1 will be in /de/library/html-tutorial/part1/index.html while the
images are under the path without language prefix, for example
/library/html-tutorial/part1/part1-image-de.jpg.
To consider for Bags/Bundles

Sorry for the long post. I just hope to add some thoughts that might need
to be considered for the Bag/Bundle implementation:

• They could help with bundling multilingual assets together with
  their text content (if done right!).
• Handling nested content with a bundle seems tricky: include
  subfolder or not as mentioned by @moorereason
  https://github.com/moorereason above
  https://github.com/gohugoio/hugo/issues/3651#issuecomment-322300105.
  I would consider every folder a separate bundle. This way we can have
  nested bundles as would be needed in my example above.
• Another thing to consider is how bundles relate to assets stored in
  an external storage (necessary for large projects since you shouldn't have
  gigabytes of binaries in a Git repo). See Structure C in this
  discussion
  https://discourse.gohugo.io/t/discussion-content-organization-best-practice/6360/9
  .
• I think bundles/bags would be an awesome Hugo feature!

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/gohugoio/hugo/issues/3651#issuecomment-334970587, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAqxIxPrlsFmpa_umYF68noZh5_CpIwFks5sp_52gaJpZM4OGNPQ
.

>

Before printing this email, think if it is really needed.

[marcojakob]

@simonszu Yes, handling large blobs is what I was referring to with this:

Another thing to consider is how bundles relate to assets stored in an external storage (necessary for large projects since you shouldn't have gigabytes of binaries in a Git repo). See Structure C in this discussion.

[zjedi]

Let's leave the storage management to the users. In my opinion it's not HUGO mission to lay down restrictions in order to avoid GIT storage issues. I'd be surprised if it wasn't possible to remove history of the file and thus avoid taking up too much space due to versioning.

By the way, isn't the external storage supported already? Just just need to paste link to your images.

[ianbrandt]

@simonszu I use Git LFS for versioning images along with my content. Works great. Supported by GitHub and GitLab.

[moorereason]

Please move the discussions about your personal storage preferences to the forums. It's just noise here.

[bep]

I have move on with my bundles PR now ... For the curious:

A sample bundle page with both images and content files:

http://hugotest.bep.is/2017/11/bundle-1/

How it looks in the Hugo project:

https://github.com/bep/hugotest/commit/66f577c69ebe4da2e8db7181ca2dc8559bcf0cce

I have also decided to do the image "addon" for this: I.e. add width/height attributes + scaling.

[Jos512]

Responding to Bep's comment from yesterday:

I appreciate all the work put into this, but I'm concerned about how we're going to document this. Placing the bundles into the content directory (/content/bundles/) seems to have a couple of disadvantages:

• It changes the meaning of sections, which are now 'subdirectories of your content folder'. With the new behaviour there can also be a 'bundles' subdirectory, which may or may not count as a section.
• It may affect the meaning of content types, which are now derived from their section folder (or when set explicitly in the front matter). A bundle is likely not going to be a content type, however.
• It changes the meaning of the content directory, whose defining features include 'all content files that are processed by Hugo'. Now with the 'bundles' stored in /content/, the content folder also contains static assets (like images) that are not processed (like Hugo does with Markdown files).
• Hugo believes we organise our content in a manner that reflects the rendered website (source). By placing bundles in the content directory, we seem to move away from that point. Instead, we'll need to use permalink settings in the configuration file to turn non-descriptive /content/bundles/bundle1/ paths into actual URLs.

I like the idea of bundles and have tremendous respect for the all the work Bep does. But I'm quite concerned with how we're going to explain bundles when they're put in the content directory.

I think the bundle behaviour would be easier to explain and comprehend if bundles get their own directory. That way we have three distinct content directories: /content/ for everything that Hugo renders, /static/ for our truly static files, and /bundles/ for our custom content bundles (a mixture of static content and content that Hugo renders).

A specific /bundles/ directory at the root level also makes sense if we look at how we already treat the /data/ folder. The files we store in /data/ are static files, but Hugo doesn't treat them as regular static files (in /static/). And so they have their own folder, to set them apart from the other files Hugo uses.

I'd argue that the same applies to bundles too. Bundles are primarily content files (with a bit of static files too), but they aren't treated by Hugo in the same way as regular content. (Especially when image resizing and scaling also happens in a bundle.) So perhaps they also deserve their own directory.

When we give bundles their own directory, the meaning of the content directory, what sections are, and how content types work (see previous points) remains unaffected by bundles.

And so I think bundles would be much easier to explain when we can contrast them against regular content (/content/) and static (/static/) files, as opposed to treating bundles as a special /content/ subdirectory.

[bep]

@Jos512 I think you misunderstand my example. There is nothing special about the bundles section (I just named it that way to separate it from the other example sections). If you want to comment, you should read and understand the specification in my first post. In any case, you come late to the party.

[bep]

@Jos512 I have updated the example with less confusing names:

http://hugotest.bep.is/section3/2017/11/my-article-1/
https://github.com/bep/hugotest/commit/375ca10594827b1e7b4e7c3b1bba2593ea18dc40

[bep]

I have added some examples of my suggested Image API:

http://hugotest.bep.is/section3/2017/11/my-article-1/
https://github.com/bep/hugotest/commit/f014cda2ff7fbb331b6b111c829797b11bf1b71f

3 methods: Fit, Fill and Scale. There are more to it than the above, but that is the core.

[KevinGimbel]

@bep this looks amazing!

[Jos512]

I think you misunderstand my example. There is nothing special about the bundles section (I just named it that way to separate it from the other example sections).

Thanks for clarifying that, that wasn't clear to me. I misunderstood how you used bundles, and mistakenly assumed they had to be named /content/bundles/ with the URL path defined in the configuration file.

If you want to comment, you should read and understand the specification in my first post.

Point taken, and I'll keep watching the discussion. Although it does feel a bit of a shame if only people with the technical Go may give input. (But I understand it gives a lot of noise for you otherwise, and time is precious already.)

In any case, you come late to the party.

I already expressed a concern for how to document and explain the bundles feature to new users on June 27. So I'm not really late, just replying twice here. 😄

Good luck on finishing this feature.

(No need to reply to this post.)

[bep]

For the curious, I have updated the examples at

http://hugotest.bep.is/section3/2017/11/my-article-1/

This now shows a more diverse media types handling (including JSON, which I guess could open up a fair amount of use cases).

The implementation is mostly done, but there are still lots of TODOs sprinkled around. I think I implemented the bundle logic 4 times before I settled on this one. Mostly for performance reasons. Now it is slightly faster than the current Hugo. More for less.

I will try to wrap this up for X-mas. I will push this to a branch in the gohugoio repo in a couple of days asking people to take it for a spin.

[stp-ip]

So with a bundle/bag all content files are "merged" together and therefore all metadata is accessible by themes? Ordering is done alphabetically? With the single page theme github.com/okkur/syna we are currently using data files, but that makes multilingual themes a bit harder and it might be nicer to move that to content pages such as:
/team/
index.md
member1.md
member2.md
member3.md

Happy to jump in with suggestions from that usage perspective, when I grasped the whole context.

As always: Awesome work bep \o/

[bep]

@stp-ip you are a little late for suggestions and early for questions. I think you will be happy, I know I will. This is good stuff.

[stp-ip]

@bep was not so much thinking about implementation detail suggestions, but documentation and early testing, which might influence another iteration or bug fixes etc.
But me being happy seems like single pages might finally work without data files \o/.
Ping me, when the PR is ready and I might be able to take it for a spin.

[bep]

To the curious:

I plan to cut a release sometime next week, I want to get this out before the new year.

This is going to be really, really cool.

[achamess]

This looks great and just what I'm looking for. I really prefer to keep images and .md files together in a folder. Is this feature live yet?

[bep]

Is this feature live yet?

Yes.

[achamess]

@bep Thanks! I updated to v0.32. Is there anything special I should do? Any documentation? Sorry for the naive questions.

[bep]

Please use https://discourse.gohugo.io/ for questions/troubleshooting. Also see Hugo Documentation.

[achamess]

Got it. Thanks!

On Jan 2, 2018, at 4:20 PM, Bjørn Erik Pedersen [e-mail] wrote:

Please use https://discourse.gohugo.io/ https://discourse.gohugo.io/ for questions/troubleshooting. Also see Hugo Documentation http://gohugo.io/overview/introduction/.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub https://github.com/gohugoio/hugo/issues/3651#issuecomment-354877937, or mute the thread https://github.com/notifications/unsubscribe-auth/AHGbchRTEz2CJiQMkKKPspw2JJI6fSr1ks5tGp2EgaJpZM4OGNPQ.