Slug field for default language in Kirby 3.6 not working

Kirby 3 Questions šŸ¤”
1

Hi, I just updated Kirby to 3.6 on my local server and found a problem with the website I am working on. I use a slug field also for the default language (Dutch), because I like to keep the structure in English, similar to the template names and code. I donā€™t like to mix languages. But after updating to 3.6, the slugs field in the Dutch files donā€™t work anymore. How could I solve this other than renaming all the folders?

2

The slug field for the default language is no longer supported in 3.6.

Slugs in multi-language setups

  • Slugs in content files of the default language will be ignored. The slugs for the default language are now only decided by the folder names.

To check if you are affected by this, you can use our migration plugin . Place it in site/plugins and visit any frontend page of your Kirby site to check if you need to migrate some of your pages. We have tested the plugin in Kirby 3.5 and 3.6, so you can use it before or after the upgrade.

3

Sad to see it removed. Any chance it is coming back? It also makes it really difficult to switch the main language in the future, less flexible.

4

I actually donā€™t know why it was removed, maybe it caused problems of some sort. But I agree, it was very useful.

5

Ok. Sorry to say, but then I need to keep using 3.5.x.

6

Hi Bart,

Sorry to hear that you miss this feature. To be completely honest, we didnā€™t expect that this undocumented behavior was actually used on purpose in projects ā€“ especially because the Panel doesnā€™t store pages with Slug fields in the default language.

The reason why we removed this behavior is that the removal increases page lookup performance. Large sites benefit a lot from this as the lookup time increases exponentially with large content trees. You can find our original discussion on the change on GitHub:

How do you manage your content and what does your workflow look like?

7

Thank you for your reply. Nice to see there is so much discussion about these kind of things. Just my 2 cents:

  1. This approach makes it almost impossible to switch the default language. For example if a Dutch website grows and wants to go more global and make English the default languageā€¦ :grimacing: I would expect Kirby to be more flexible. Flexibility is one of the reasons I use Kirby.

  2. The performance improvement only applies to the default language which makes other languages somehow second-class citizens :thinking:

1 Like
8

It should still be possible to reintroduce this feature via a custom route and url method.

Since itā€™s not possible to switch the default language via the Panel, switching the default language needs some more care, anyway. A script to change the slugs will help here as well should the need arise.

How did you add the slug to the default language, via a hook?

9

For now I use it without the panel, just in the txt files. For example, the client prepares a product based on the file structure of an example product and I do a final check (image format and sizes, missing SEO content, translations) before I publish it with the editor.

10

I agree with Sonja that switching default languages requires more care. Consider fields with translate: false that need to be moved to the new default language for example. So a migration script is needed in any case.

The question is always how much to prepare for the future and how much to build for the present moment. You never know what the future may bring, but IMO itā€˜s not useful to prepare for all sorts of scenarios as this will introduce a lot of complexity. And in the end the future may turn out completely different than expected anyway.

Which brings me toā€¦

Well, itā€˜s a bit like denying the pay rise of a coworker only because they will then get more than you. :sweat_smile:

Previously the default and secondary languages needed to make the lookup, which slows down all languages. Now the default language benefits, which is a lot better than keeping it slow just so itā€˜s ā€œfairā€ compared to the secondary languages. :wink:

For the default language itā€™s also more important as this language is used for page lookups e.g. in the pages field.

The issue is that this Slug setup can never work with the Panel as we would need to display two fields for the folder name and the slug. Users wonā€™t care about the folder name as itā€™s just an internal implementation detail of the filesystem storage, so exposing this field doesnā€™t make much sense from a UX perspective. But it would be needed as the folder name would no longer be equal to the default language slug.

11

@lukasbestle Fair points :slight_smile: You convinced me, although of course it was not needed to convince me :wink: For the second-class citizens I was more thinking about if this would postpone a solution for the other languages. But fair enough.

12

With the unique ID system on our roadmap it will be possible to index the page tree and access pages much faster. It is certainly a possibility to use the same system to optimize lookup times.