Really strange behavior that makes Kirby save to wrong content file

A website I’m developing is suffering from a really strange issue. Essentially it causes the panel to save a page in the wrong language file.

It’s rather complicated to reproduce and this doesn’t help debugging. But it’s definitely there and affects multiple installations and browsers. It affects at least 2.3.2 and 2.4.0.

Here’s a video of what happens:

Notice how kirby widly changes the language, saving the “english” text to the “german” page. (I’ve checked and it really saves the content to the wrong file).

It seems to happen somewhat consistently (but not everytime) on blueprints that use the “tabs” plugin (by @ahmetbora) together with an “image” field. But because of the difficulties with reproducing this bug I can’t be sure this really matters.

Anyway, here are the steps needed to reproduce it “most of the times”. I’ve put together a script to help setup a test environment.

If you are on an environment with the Kirby CLI, the “unzip” and “wget” command line utilities, you can use this script in an empty folder:

kirby install test --kit langkit
cd test
mkdir site/fields
mv Kirby-Tabs-Field-master/ site/fields/tabs

cat >site/blueprints/test.yml <<EOL
title: Test
pages: false
files: true
    label: General
    type:  tabs
    label: Title
    type:  text
    label: Details
    type:  tabs
    label: Image
    type:  image

mkdir content/test

cat >content/test/test.en.txt <<EOL
Title: test en



cat >content/test/ <<EOL
Title: test de



php -S localhost:3000

This just downloads a starterkit, installs the tabs plugin, creates a blueprint and starts a server.

Now go to http://localhost:3000/panel
Create user credentials and login
click on the page “test en”

follow exactly these steps:

  • save the page
  • change language to DE
  • save the page
  • change language to EN
  • change language to DE
  • save the page
    (notice that kirby switched language to EN, saving “test de” to the EN page)
  • correct the title field by writing “test en”
  • save the page
    (notice that kirby switched back, saving “test en” to the DE page, and leaving “test de” in EN)

It doesn’t f*uck up all the times, but when it happens it’s REALLY annoying.

Hm, I haven’t managed to reproduce this yet by following your steps. I’ll try again in the morning.

I could reproduce this when adding an image to the Details tab.

Yeah, it really seems like it’s something with the Tabs plugin and image fields. But I don’t know enough about the inner workings of the panel to even imagine what could be going wrong.

Another strange thing is that “the switched language” stays there only for a “moment”, you can try it out by refreshing the page (Ctrl+R) when you see that the panel is on the wrong language and it will switch back. It’s like the session keeps the right language, but somehow, sometimes, the panel doesn’t use the language provided from the session. Which is even stranger because the “ajax save calls” in the panel, do not seem to contain any info about which language is being saved.

I guess there’s probably some JavaScript/session storage interference problem.

Did this ever work correctly with any Kirby version?

Well, the image type was introduced in 2.3.0.

I’ve just tried this in 2.3.0 and it’s the same strange bug.

I think it’s related to this issue:

Oh, didn’t see that one!

Anyway, a fast to implement work-around for people having the bug related to Tabs + Image field is replacing the image with the “selector” field plugin. This seemed to help here, at least with my empiric testing methods.

Do you think that adding a hidden input with name language (via plugin) to the blueprints, that always has the “right / current” language would work around the problem? This should kind of “reset” to the right language on each save.

I’m aware that this is more a hack than a fix, but until 2.5 comes around it could be a solution…

Hi there,
we are experiencing the same problem and it drives our editors nuts. Questions about the CMS choice are also noticeable :confused: .
We are experiencing this bug constantly. I have not installed the Tabs plugin. But we have a image selection field in the blueprint. I would highly appreciate if you could look into this bug. So it is on the 2.5 milestones list. If you need a beta test, I am happy to help, of course!

Best – Martin


I still have this bug on my multilanguage websites (Kirby 2.5.5)
I’ve lost all my homepage traduction this morning :-/
This bug is very weird because it doesn’t happen every time we save a page.

I’ve read in the Kirby 2.5.6 changelog, in the Panel section (5th bullet point) :

  • “Ensure that content is saved in the correct language”

Is it related to this bug?

@gillesvauvarin I don’t have an answer, the related issues weren’t closed, @lukasbestle, @bastianallgeier ?

The fix was in this commit by Bastian. This should actually fix this issue.

Can you still reproduce the issue with Kirby 2.5.6 RC-1, @gillesvauvarin @jenstornell @martinthiemann @rasteiner?

I’ve switched from Kirby 2.5.5 to 2.5.6 RC-1 and until now, I haven’t been able to reproduce the bug, that’s good sign.

(We removed all file fields for now, so I can’t tell you. Sorry)
But good to know it was fixed. Thanks

My website is on Kirby 2.5.6 and this bug still happen sometimes :-/

The code that should have fixed this issue was removed again from the final release…because it caused another issue. As a temporary workaround you could apply the original fix, but prefix the special language field to avoid this issue.

I encounter a similar issue. Two language website, no plugin, editor have an unpredictable behaviour.

When trying to save in the main language, sometime it switch to the secondary language without saving. Sometime it save in the wrong language, erasing the translation. Kirby/Toolkit/Panel 2.5.6. Sometime it simply lost the fields that were intended to be saved.

Very, very annoying problem as I could not ship the website with such a problem.

I applied the temporary workaround suggested by texnixe. Seems to correct the problem for now.

Hi @mark,

Could you post an snippet of code to show us with a real example how to fix this problem?

Thanks :wink:

Thanks Sonja,

I didn’t understand what to do when you said " but prefix the special language field to avoid this issue" but now it’s clear :slight_smile:

I did not understood either for the prefix (i prefixed $languageField…).

Switching to a correctly prefixed version seems to bring back the problem.

As the issue that led to the removal of the code fixing this problem seems to be related to user edition, I would temporarily remove the code when editing users, but for the moment I’ll use the unprefixed version, as my problem for now is allowing the client to input data.