Tags get reordered in Admin upon saving?!

I have come across a thing that really stumps me. So I have two websites that use tags. On website A, when I post an article with tags, they appear on the article’s page in the order I posted them. Also, when I remove a tag in Admin and add it in a different place of the tags list, then save, they are saved like that and appear on the frontend page in the new sequence. So far so good, this is expected behaviour.

However, when I change the tag order in Admin for a post on website B and click save, the tags will reappear in the new order on the frontend, BUT the tags get reordered in Admin, back to the original order, so on the next save it’s reverted in the frontend as well.

I tried removing them all and saving and then readding the tags in a different sequence, but they still get reordered in the Admin tag field, after they’ve been saved correctly.

It seems to me that the tags’ ordering always follows the same sequence, regardless of which I add or on what article.

The only relevant difference between the two website I can see is that website A uses just the default “tags”, whereas website B uses six different custom types of tags. The problem is the same for all of these. However, I tried adding “tags” to that website, and those also get reordered upon saving.

Is this a bug? Should I put it in the Github issues? Does anybody have any ideas about this?

@Netzhexe, In general the same piece of software will always yield the same result…

Unless:

  • the sofware versions differ (Grav, Admin, Form, theme, plugins, custom Twig, etc)
  • configuration differs
  • OS, its type, version and/or config differs
  • input data differs

You’ve two different sites, which could mean any of the above applies… That makes it hard to pinpoint the issue.

Also comparing Admin with front-end values adds variability. The value saved in the page file would be more interesting to start with.

So, eliminate all variables and try to find a minimal reproducible case. Preferably using a skeleton we can download and test your reproducible script on.

That is a good point, though not easily done. I will confer with my client about how they want to handle this, so I may report back or not. Thank you for your input!

Okay I have news! The news being that apparently I didn’t look properly because this actually does happen on all sites. Super easy way to reproduce:

  1. Download the Future 21 skeleton with Admin plugin (any other should also work).
  2. Set it up and login to backend.
  3. Pick blog post six, which has tag4 already in the Options tab.
  4. Add tag3 and a new thing at the end of that, then click save.
  5. You will find that the post on the frontend has the tags applied in the sequence you saved them, and in the Admin Options tab they have swapped places so that the sequence is tag3tag4your new tag.
  6. Try reordering and saving – the new sequence gets saved but the tags revert to that sequence in Admin every time.

It seems to me that the Admin panel, for some reason, resorts the tags into the sequence they were originally created in. But how does it even know that? And whyever does it do that?

Like I said, in the case of this one client the sequence of the tags actually matters. It’s a weird bummer :person_shrugging:

@Netzhexe, A few things…

  • I can reproduce your observation.
  • IMHO, it is an abuse of Taxonomy to attach meaning to the order of categories/tags.

How the ordering works (I think)

  • Grav fetches all pages and collects the categories/tags defined in the header of each page.
  • The pages are fetched in alphabetic order, or using the numeric prefix.
  • From each page, the tags are fetched and put into an array. Then the array is deduped.
    This means that the array contains unique tags, ordered by folder, and ordering of tags in a page.
  • When showing a page in the browser, the tags are ordered as saved in the page’s header.
  • In Admin, the ordering shown is the order of all tags collected from all pages.
  • Unfortunately, upon saving the page again, the order of the tags will change in the header of the page.
  • Renaming the folder of any blog item, or adding a new blog item, can change the ordering of tags shown in Admin for other pages.

Here is how I tested my assumption:

  • Create posts as follows

    user/pages/blog/
    ├── 01.post-1
    │   └── item.md   -> with tag: [1]
    ├── 02.post-2
    │   └── item.md   -> with tag: [2]
    ├── 03.post-3
    │   └── item.md   -> with tag: [3]
    ├── 99.post-99
    │   └── item.md   -> with tag: [2,1,3]
    └── blog.md
    
  • Admin shows for post-99 the following tags

  • Rename the folders as follows:

    user/pages/blog/
    ├── 01.post-3
    │   └── item.md     with tag: [3]
    ├── 02.post-2
    │   └── item.md     with tag: [2]
    ├── 03.post-1
    │   └── item.md     with tag: [1]
    ├── 99.post-99
    │   └── item.md     with tag: [2,1,3]
    └── blog.md
    
  • Admin shows for post-99 the following tags:

Fascinating! Thank you for laying this out, could be really helpful for other people who aren’t quite sure how tags work or don’t work.

IMHO, it is an abuse of Taxonomy to attach meaning to the order of categories/tags.

I quite agree with you on this. This happened because I needed a field for authors and

  1. the autosuggest feature of the tags seemed really useful here,
  2. I was not initially made aware that these names needed to adhere to a sequence,
  3. I also didn’t realise that Grav might swap tags around.

If I need such a thing in the future I would probably go with a value-only Array field. However, I just spoke to the client and we’re leaving it, since the sequence stays correct as long as nobody re-saves those pages, and their use is mostly archival.