getzola / zola

A fast static site generator in a single binary with everything built-in. https://www.getzola.org
https://www.getzola.org
MIT License
13.48k stars 943 forks source link

Custom URL templates. #635

Closed JadedBlueEyes closed 3 years ago

JadedBlueEyes commented 5 years ago

Feature

Problem

Some people are migrating from previos sites, and we want to make this as easy as possible for them. Other people want to future proof. A few just want to look different. All of those people could use custom URL templates. For example, if a user was migrating from a blogger blog, their url would look like /YYYY/MM/title-slug.html, or a Jekyll blog might look like /YYYY/MM/DD/title-slug.html. However, all Zola pages are forced to be /collection/title-slug/. This makes it hard to migrate, as the URL scheme is broken. This could be solved by allowing them to use a custom URL template, possibly stored in the format discussed in https://github.com/getzola/zola/issues/634. This also helps fture proof, as a club or a project may want to post multiple posts with a title like "this week's updates", but if there is no date, or hash, or some other thing that would change, then the URLs would clash, and they would be unable to post.

Keats commented 5 years ago

Is that a duplicate of #624 or are there patterns other than ones with dates?

JadedBlueEyes commented 5 years ago

This is barely related to https://github.com/getzola/zola/issues/624. Although it would be cool to be able to have a post at /2019/2/post.html and the archive for febuary be at /2019/2/index.html, this is about where the post's path is, not about archive generation. You should be able to inclue category, generated file extension, year, month, day, etc in the path template.

Keats commented 5 years ago

Adding date bits in the URL is probably not going to happen anytime soon (if it ever happens).

I don't really understand the docs for categories in that link though:

Jekyll will create a hierarchy (e.g. /category1/category2)

Zola doesn't have categories so how would that handle multiple taxonomies (multiple tags and an author for example)? Tons of duplicate content?

JadedBlueEyes commented 5 years ago

date bits in the URL is probably not going to happen anytime soon

Why? It’s quite an important feature, in my opinion. Nearly every other CMS has some way to do this.

Zola doesn't have categories so how would that handle multiple taxonomies

It’d be up to the user. They could decide what gets included and where. Tags,

I don't really understand the docs for categories in that link though:

Jekyll will create a hierarchy (e.g. /category1/category2)

This means that if it has the category jobs, :category would be replaced by jobs. If it has the categories jobs and work, in that order, it would replace it with jobs/work. In the yemplate /:category/:title:output_ext, this would be /jobs/work/title.html

ghost commented 5 years ago

So I've been reading all the related issues about the date in url format, and I'm wondering if there's a good reason to not add this feature? I'm not strongly inclined either way as I'm new to this, but it seems like a standard thing to have. @Keats, do you think the idea is inherently a bad one, or would you say it's just no one wants to implement it right now? If it's the former I'm curious as to the reasoning behind it.

Keats commented 5 years ago

I left a long comment explaining why there won't be date URLs parameters but I can't remember where I posted it - it was at least a year ago.

The main points were:

  1. I have no interest adding that myself
  2. Dates in URL don't take into account updates so I see eg a React guide with 2015 in the URL I'm not going to look at it even though it might have been updated yesterday
  3. Almost all implementations I've seen suck: if I have 2019/08/12, I expect to be able to go to 2019/08 or 2019/ and have an archive and being able to go to prev/next month/year. Not sure about the day level since that would create way too many files. This would be fixable in a Zola implementation but would require lots of work.

As for the other kinds URL template, the one I feel would be helpful is something like date-path to solve the issue of "this week's updates" mentioned at the beginning of the issue.

steveklabnik commented 4 years ago

I am not sure if this bug is the right place or not, feel free to tell me to open a different issue. I have an existing site I'm porting over, and I need pages to end in .html. Porting to Zola has gone great except for that it breaks all of my URLs. I think this feature request would enable me to say that the url should be /foo.html instead of /foo/?

Keats commented 4 years ago

Hugo has the concept of "pretty urls" for that: https://gohugo.io/content-management/urls/#pretty-urls and you can disable it by having uglyurls = true in your config. I don't believe it's a custom URL template as it changes the structure of the generated site by removing one layer of folder.

There is no way to do that in Zola currently but it shouldn't be too hard to add. If you can create another issue to track that specifically that would be great.

kellpossible commented 4 years ago

I thank that does deserve its own issue, I have run into the same issue trying to convert my blog

Geobert commented 4 years ago
  • I have no interest adding that myself

Fair enough, this is what PR are for ^^

  • Dates in URL don't take into account updates so I see eg a React guide with 2015 in the URL I'm not going to look at it even though it might have been updated yesterday

I've never though of this. Can't something be done by using aliases?

  • Almost all implementations I've seen suck: if I have 2019/08/12, I expect to be able to go to 2019/08 or 2019/ and have an archive and being able to go to prev/next month/year. Not sure about the day level since that would create way too many files. This would be fixable in a Zola implementation but would require lots of work.

I would expect this if I enter in the archive section of the site, not the live section. But I might be only me.

@Keats Shall someone tackle this anyway? If you agree, I'll have a look as I need it to migrate my blog over Zola :)

Geobert commented 4 years ago

After more thoughts on it, I don't need it ^^

Keats commented 3 years ago

Not going to support that, closing.

jplatte commented 2 years ago

@Keats I feel strongly that this should be supported. Is there any chance this could be re-opened (or a PR accepted, even if this issue is not re-opened)? I specifically want this because I have ported over a website with a lot of blog posts where some of the paths would clash if the date wasn't part of it. Currently, this is solved by every blog post having an explicit path property, but that's really annoying to maintain.

Keats commented 2 years ago

Honestly I think having an option to integrate the date in the path would suffice, no need for full blown custom url patterns.

ttys3 commented 2 years ago

I have Hugo config like:

permalinks:
  post: /post/:filename/

which /posts/cat1/cat2/my-post-name.md will produce static file: /post/my-post-name/index.html

people can access the URI /post/my-post-name/

seems zola does not support this, which block me from switch to it.

brmassa commented 1 year ago

Same here.

The basic requirement when porting a site is the maintance of the old URLs. A site that was not "fortunate" to adopt the default Zola URL pattern previously will break ALL URLs.

Of course, it could be achieved by implementing path on EACH and EVERY content. It's error-prone and difficult to maintain. If eventually the used variable (title, date, or filename) eventually changes (especially during draft phase), the URL may not follow. Another checklist item.

If the scope of the project is to create small sites, ok. If the selling proposition is to manage large content pools, it is a must, IMHO. A use case is the automatic content creator (like documentation a software API) that creates thousands of .md files and then delegates them to an SSG to build the site. With proper URL configuration, the pages could be presented in a flat structure like a wiki or very hierarchical.

Some advantages:

At least open the door for someone to implement it in a PR.