changed page url generation

[oscarotero]

@valtlai After a second thought, I've changed my mind about the possibility to define an url as an object and your idea of using the trailing slash to detect if the url is a pretty-html or a extension-less filename is better.

One of my goals with lume is building something easy to use and with predictable behavior, and the url variable that accepts so many formats (function, string, object) and different behaviors is far from being that.

With this change, the url can be defined using a function or a string:

• /about-me Generates a /about-me file (without extension)
• /about-me/ Generates a /about-me/index.html file
• /about-me.html Generates a /about-me.html file

prettyUrls setting is used only if the page has not the url variable. slugifyUrls is used everywhere.

[valtlai]

Looks good. I’m wondering how should be the _headers use case solved. Should one just add replace: { "_": "_" } to slugifyUrls? Should there possibly be a corresponding slugifyUrls variable in pages to disable the slugifier (or maybe to modify its configuration) on particular pages?

[oscarotero]

@valtlai Good question. I have some ideas:

• The variable slugifyUrls is good idea, but I'd like to avoid having too many configuration variables in the pages, because they are like global variables in the templates and this polution is not good.
• Other idea is recovering the url object for that. But instead path and ext, something like this:

  url:
    path: _headers
    slugify: false

The ext variable wouldn't exist. So, for a html page, the path value should contain also the extension. My only doubt is if we have an option to enable/disable slugify, why don't another to enable/disable pretty urls? In this case, what should do this?

url:
    path: /about-me/
    pretty: true

thoughts?

[valtlai]

I like this approach. Most of the time, a string will be enough, but an object allows disabling the slugifier when needed. And with an object, we can have the variable pretty as well.

I think your example should produce /about-me/index.html regardless of the value of pretty.

If there wasn’t a trailing slash in your example and pretty was set to false or omitted (because it defaults to false, right?), /about-me would be produced. Otherwise – in the case of pretty: true – /about-me/index.html would be produced.

[oscarotero]

Fair.
I would defaults pretty and slugify to the global config prettyUrls and slugifyUrls. This way, you can override one option without having to set the other.

[valtlai]

But a string would still work as you described in the first comment, right?

[oscarotero]

Yes. Strings would work like in the first comment.

[valtlai]

Okay, that’s nice. 🙂