Issues with next v0.18+

[wold5]

Hi, Abridge works fine with v0.18, but breaks when testing the current next (up to and getzola/zola@4bf67af). Thought I'd give you a heads up.

1. Translation menus don't substitute dashes properly:
   instead of /nl/software/ its //nlsoftware/
   Changing

   abridge/templates/base.html

   Lines 76 to 77 in d45bc26

   	<a href="{{ current_url | replace(from=config.base_url, to=config.base_url ~ "/" ~ lcode) | safe }}{%- if uglyurls %}index.html{%- endif %}">{{ macros::translate(key="language_name", default="language_name", i18n=i18n_menu) }}</a>
   	{%- else -%}

   to use to=config.base_url ~ lcode ~ '/') fixes it for next, but breaks 0.18.

2. The logo gets a double // in next(the config base_url omits the dash, as recommended)
   It's fixable by removing the dash here

   abridge/templates/base.html

   Lines 37 to 38 in d45bc26

   	<img src="{{ config.base_url | safe }}/{{ config.extra.logo.file | safe }}"{%- if config.extra.logo.alt %} alt="{{ config.extra.logo.alt | safe }}"{%- endif %}{%- if config.extra.logo.width %} width="{{ config.extra.logo.width | safe }}"{%- endif %}{%- if config.extra.logo.height %} height="{{ config.extra.logo.height | safe }}"{%- endif %} />
   	{%- endif -%}

Of the recent commits these two come to mind:
getzola/zola@4bf67af (--base-url)
getzola/zola@73e06bd (get_page/get_section language argument)

[Jieiku]

excellent, thank you. I wonder if these are intended changes or not, will keep an eye on the zola release. (I have it watched on github)

[wold5]

You're welcome. Will keep building with 0.18 for now.

By chance, having just added a site translation, constructing a section path requires code similar to that linked in (1) 😛 So curious what you come up with. Might even fix it myself 😉

[Jieiku]

Zola 0.19 just dropped. I drafted a release of abridge to preserve a compatible version for 0.18.

It looks like your original bug report might have been resolved before 0.19 was released, I am not seeing those issue currently. I did however have to disable the feeds in config.toml:

generate_feeds = false

I believe it might be related to getzola/zola#2477

filed an issue report here: getzola/zola#2537

[wold5]

Tonight or tomorrow I'll check this out. Would have done so now, but the whole lot needs syncing and updating, etc.

[Jieiku]

I just updated abridge for 0.19.1 so far everything seems OK and the demo is functioning properly.

[wold5]

Confirmed, 0.19/0.19.1 works here too, on Windows, with the latest Abridge.

I did however have to disable the feeds in config.toml:

Same here, ==but for a different reason it seems== otherwise it throws this error, on multiple pages:

Error: Failed to serve the site
Error: Failed to render page '\\?\C:\Users\...\syncoda\content\pages\offline.md'
Error: Reason: Failed to render 'pages.html' (error happened in 'base.html').
Error: Reason: Test call 'containing' failed
Error: Reason: Tester `containing` was called on an undefined variable

PS C:\Users\...\syncoda> .\bin\zola-191.exe --version
zola 0.19.1

This seems a different issue?

Also had to remove

[languages.nl]
#language_name = "Nederlands" <---

which appears to be baked in now, it seems.

Thank you for your responses!

[Jieiku]

With the latest abridge you just need to update your config.toml and replace all occurrences of

generate_feed = true with generate_feeds = true

Then after updating Zola to 0.19.1 your Atom feed should work properly.

In the demo I also removed the language_name from config.toml back at 0.18.0 when the i18n folder was added.

[wold5]

It works now. The Abridge /themes/ submodule wasn't updated, still at the previous version or the long words commit (30dfea2). If you checkout 30dfea2 it will throw the same error. Using multiple machines here...

With the latest abridge you just need to update your config.toml and replace all occurrences of

generate_feed = true with generate_feeds = true

Then after updating Zola to 0.19.1 your Atom feed should work properly.

The 0.19 changelog mentioned that variable and feed_filenames, so I had changed those. Next I faultily assumed your remark was a WIP fix for the issue described. Good reminder to always check assumptions ;-)

As for Windows, the here used method is:

• the official Rust package from https://www.rust-lang.org/
• cargo build --target-dir #targetdir# for a debug build