Kirby.page is not future proof?

Kirby 3 Questions 🤔
1

Hi,
I’m currently making a portfolio and I give a look to the Portfolio Sample.

On the /site/blueprints/sections/projects.yml file, there is this line:
parent: kirby.page('projects').

Using kirby.page will break as soon as we change the page URL so is there a way to call the page by anything else than its own URL to be future proof, if me or the client rename the page and change its URL ?

Thanks!

2

You have two options:

  1. prevent renaming the page
  2. use a unique ID, by either providing it manually or using the AutoID plugin.
3

In this case you have another option because the projects page has a special template:

parent: site.index.findBy("template", "projects")

Swap template to intendedTemplate if you have a blueprint only.

4

Keep in mind that site.index is a potentially slow operation on bigger sites.

I really wish we had something like autoid baked in :eyes:

1 Like
5

That’s true, but you also have to make sure that the blueprint/template cannot be changed. But at least that is false by default.

6

Thanks, site.index.findBy("intendedTemplate", "projects") work pretty well in my case. I also take in consideration the comment from @bvdputte, and since i’m working on a small website I think this will be ok.
I also join him on the idea to a native autoid!

7

the idea of a core in autoid has been discussed during alpha/beta afaik and was rejected. while i agree that it has its usecases for managing relations i do not think it needs to be a core functionality for various reasons.

  • the page/file relations are stored as readable as possible using the slug. that makes learning kirby and debugging and editing plain text files easier.
  • adding something like autoid to core causes some code bloat for all projects that do not need that functionality. i understand that when using kirby headless its pretty handy. that is exactly why the plugin system exists.
  • based on my unittests i can assure you that the autoid plugin is pretty solid. it might not be as refined as core code but it should be ok. :wink: Build Status Coverage Status
  • making the autoid performant with large projects really requires some kind very good cache (sqlite in this case, i tried json file cache but they where less good) otherwise managing the index becomes a bottleneck. adding a db is something you can not do easily to a flat-file cms.
8

When using kirby.page() in blueprints or templates, we usually refer to pages that already exist, that are part of the structure, and that are likely to exist in the future, even if clients later rename the page. In all (or at least most) of these use cases, the number of pages that might be affected is pretty limited and a unique id can be added manually to a disabled field at the time of development.

The bigger problem are cross-references between pages, when links stored somewhere become outdated because pages are renamed. This is where the AutoID plugin is almost a must unless you use hooks or whatever to keep track of changing references.