Stuck on a hierarchy problem

We’ve a hierarchy problem that we can’t quite tackle the right way.
We’ve been trying different solutions for hours, maybe someone else has an idea. :confused:

The setting is:

  1. There are multiple items in a page and each item has to be assigned a category out of three categories.
  2. The customers want to be able to change the individual names of the categories by themselves, so it can’t be a simple select field with preset category options.
  3. When creating a new item, there should be a radio or select field with the categories’ names to select from and to assign the newly created item a category.

If I create a page for each category and a subpage for each item, I can’t change the item’s category afterwards (for instance, if the item has been assigned the wrong category by accident.)

Of course each category could just be a separate template, but then it’s impossible for the clients to change a category’s name.

Also if the items are in a structure field instead of separate pages, the categories’ names can’t be changed.

You can make your categories dynamic, for example by defining them in the site object or the parent page, see the select field for examples.

These can also come from a structure field, in case you want to assign key-value pairs.

Why not?

But you’re only allowed a “set” (like pages etc) as options for a select field.
So if I have three text boxes, each for one category name, I can’t dynamically reference them in a select field, or?

(I’ve been reading the reference and examples for hours now :confused: )

Not sure I understand. The options don’t have to be pages, they can be any sort of values, e.g. from a tags field, or a structure field.

For example, in site.txt you have a set of category “tags” that the user can modify from the Panel:

tags: cat-a, cat-b, cat-c

Then you can query these categories from your select field.

The tags field is just an example, a structure field will work just as well.

Yeah, but in what kind of field do I put the options/values, so that the customers are able to change them AND so that they can be used as a select field?

See my edit above.

I also had this setup:

A tag field where the users can put their categories in and then I queried the tags into a select field, so users can change the category by select field.

However then, if a category’s name is changed (in this tag field), the item’s category doesn’t change afterwards, because it’s not updating/overwriting the previous value by default, or am I missing something?

Yes, that’s true. But that is a general problem if you change something. The question is what exactly you want to achieve.

The way to avoid that would be to define key-value pairs, so that the value that is stored remains the same, but what is shown for this value can be different. But as I said, I’m not quite sure what’s the purpose of changing categories.

For key-value pairs, you need a structure field, though.

Thanks for the help btw!

The purpose is:
The categories are publications, presentations and media. Each of the categories contains items, may they be pages or structure field entries, whatever works.
Changing categories would just be necessary if, by accident, a user puts an item into the wrong category and want’s to change it back.

Like you suggested, I tried the key-value pairs. That worked of course, however when changing a category’s name in the key-value pair structure field, you need to reload the whole page after saving, for the category select field to update it’s corresponding options. Meaning, the select field still displays the old option text.

Let’s get this straight:

Are the categories themselves fixed? Or do you want the categories themselves to be modifiable?

Assigning a category to an item is just a matter of selecting a new category from the select field.

Those category names sound very very broad. There can’t be that many of them. Can your really not sub page for each that acts as a category without needing to tag it?

Ok, thanks for your help!

So, there are three categories “Publications”, “Presentations” and “Media”.
The client however wants the option of being able to change the names, just in case.

Ok, if you set up a structure field somewhere with one field for the value, and one field for the display name. Then the editor can leave the value untouched and just changed the display name.

The same value is always stored for an item. But in your template you pick the corresponding display name from the structure field.

You just have to tell the user to leave the value field untouched. It should actually be possible to disable this field.

1 Like

Yeah, you’re right, there are just three categories.

Yeah, I tried to sub-page them, but then the client is not able to switch the subpage’s items from one category to another category.

Yeah, that’s exactly what I did, however if the structure field with the display name and the value is on the same page like the category items, the category names are only updating after a refresh. But I guess, I just have to accept that :smiley:

Right, moving pages will come in a future Kirby version, currently not possible.

1 Like

But you don’t have to put them on the same page, actually, that doesn’t make sense, at least not if you use subpages for your items. Put them in the parent page instead.

Well, if your items are structure items in a single page, that’s another story, of course. Then you have to refresh the page, yes.

Just thinking off the wall here… how many pages are we talking about here? What if you used a tag field and piped that into the Kirby’s router? So the category part of the url is dynamic based on the tag fields, rather then phyiscally put the page into a defined bucket. That way dont have to move the page if the tag changes. However there is a limit to the number of pages you can have in one subfolder, but i think its in the hundreds.

Select or tag field doesn’t really make a difference, but the point here is that there are three fixed categories whose display names can change. And we certainly don’t want to update all the pages again and again when the display name changes. Which would be a pain with many pages.

You mean:

First level – Page with the three categories as subpages plus the key-value pair structure field
Second level – Subsubpages as category items