Clearing cache deletes page uids?

Hi, I am building a site using Grav with Firebase and it is awesome. However, I am saving state information between users and specific pages, for which I am passing the uid of certain pages to the database. I noticed that when I did a full cache delete, the uids of those pages changed and my database started getting messed up. More specifically, if a user has marked a page as 'read' then that page gets a tick next to it and that tick will return next time the user logs in as well.

I am wondering if someone can enlighten me about the immutability of page uids. Will they be different every time the site is generated? Will they be different on different browsers, clients, computers? Will they change every time I flush the cache? Is my design pattern a terrible idea? (In comparison with WordPress, the page uids do not change at all and so this is not a concern.)

In Grav, a page has no fixed id. WP and generally other DB-driven CMS/applications have the ID generated by the database, so they use it.

But Grav does not, you could have it applied on a page automatically when saved through Admin, like this plugin does for dates https://github.com/getgrav/grav-plugin-auto-date, but otherwise that id method on the Page class is only used internally to determine if a page has changed, and will change every time the page is edited. It's not a page unique identifier, a concept that does not exist in Grav.

You could instead use the Page canonical or permalink or rawRoute methods to get the page URL, which will serve you as a unique ID, which you can md5() or process in any other way.

Thank you so much for the reply. Looks like I have misinterpreted page.id then. Actually, now I think about it, a page.uid doesn't make sense in Grav's flat file system.

Although the permalink is a nice solution, it doesn't quite serve my needs since I am using child.id in my html as attributes which really shouldn't be routes/paths. I think probably what I need to do is manually add child.header.something to all the affected pages and use something. Either that or recurse through the whole page directory and push the permalink to Firebase so it assigns a UID, and use that. But at this stage I might as well be using WordPress, which just no.