Deleting/reverting not working on `site.yml`

[owzim]

First of all: It is working as expected on regular page blueprints.

If I use it as a section in the site.yml:

---

Delete EN results in:

in the route flokosiol/translations/delete

get('id') returns null

---

Revert EN makes the panel reload, but the reverting does not take place.

in the route flokosiol/translations/revert does not seem to be called at all

---

• The indicator of a translation exist or not is working as expected.
• The creation of a not yet existing translation is also working.

Kirby: v3.5.7

[flokosiol]

Thanks for the detailed reporting. The plugin uses the page id to identify the correct textfile. Obviously the site has no page id …

I think I can fix this pretty easily.

[flokosiol]

I pushed a possible solution to a new branch https://github.com/flokosiol/kirby-translations/tree/issue/20 – would be awesome, if you could give it try @owzim

The plugin now assumes that if no page id is given, it's all about the site.txt file. But this solution might be dangerous, if someone uses the field for file blueprints …

[owzim]

@flokosiol sorry for not responding. Just tested it, working great, thanks.

But this solution might be dangerous, if someone uses the field for file blueprints …

Can you please elaborate?

[flokosiol]

The field is intended to be used with pages only. If no page id is given, the plugin checks out the site.txt file (as requested here).

While I was commenting on this issue, it occurred to me that someone might be using the plugin for fields as well - even though that's not its intended purpose. I just wanted to inform that I haven't tested this case and don't know if it will cause any problems.

@Daandelange Please check out this commit 4938a5266b6a7be1727e2e87ce577f4bd37df967 – you may want to include this change as well.

[Daandelange]

@flokosiol Thanks for the notice but I've created a fallback where it uses the id from the panel view, which probably fixed this issue indirectly. (I still need to do some more extensive testing though!)
I'm also replicating the Kirby API's field&section routing to resolve the corresponding section in any fields/sections blueprint usage which might affect usage in "non-page-fields" (file fields, site fields, etc.). And one last thing that might be related : I'm using a more native way to resolve the content file name.