Grav-plugin-admin: Save Failed: Array to string conversion error

[PraserX]

Hi, I have a problem with page save action. On every attempt I permanently get Save Failed: Array to string conversion at any page (config, page, account, etc.). I can see nothing in log nor in debug console. So is there any way how to debug this error? Thanks.

Grav v1.7.0-rc.11 - Admin v1.10.0-rc.11

[PraserX]

The problem seems to be in file system/src/Grav/Common/Data/Validation.php:

$name = ucfirst($field['label'] ?? $field['name']);
        $message = (string) isset($field['validate']['message'])
            ? $language->translate($field['validate']['message'])
            : $language->translate('GRAV.FORM.INVALID_INPUT', null, true) . ' "' . $language->translate($name) . '"';

The $language->translate('GRAV.FORM.INVALID_INPUT', null, true) returns empty array. The function translate can return empty array so the construct above doesn't seem to be right. When the system.languages.translations is false, then array is returned (due to third argument $array_support = true).

It looks like that it is an issue for Grav itself, not for Admin plugin.

[mahagr]

Might be issue in the language file? Does it work with English?

[PraserX]

Everything is working if I set system.languages.translations to true. I don't remember the situation well, but I think that I changed the language and it caused the problem. But if I look at the language file, it seems to be valid (and GRAV.FORM.INVALID_INPUT is configured).

But I don't understand why we try to concatenate string with array. We do not have any implicit array to string conversion, do we? Because the method translate can return array.

[paulmassen]

Same problem here, and I confirm switching system.languages.translations to true make it work.

[mahagr]

If I recall it right, the setting is to display the untranslated keys instead of the translations (or English language). In this case, it may fail to return an array as there are no translations found.

[sg-ll]

I've encountered this same issue and thankfully am on an install that's only a few days old. That being said, I've pushed a lot of buttons and levers in the past couple days, so taking the advice to test the release candidate, I didn't expect this kind of bug as the RC number was in the double digits. I'm honestly surprised this kind of bug could even make it out of alpha.

At this point, without direct, manual modification of a file out of the way for new people like myself, this bug blocks ALL settings changes through the UI (at least from what I've seen). I'm actually amazed over half a year has gone by and apparently nothing has been done about it. Is _everyone_ who uses Grav already using translations? Or is Translations originally turned on and I turned it off as I was going through the dozens of options, learning where everything was, as I set up my install?

[rhukster]

the default is languages.translations: true and it's not something we really use because it has limited use, ie to not do any translation at all, and simply show the keys. This is only useful when you are trying to track down an untranslated string, but as we always do this kinda thing in code, we never use it ourselves.

it is an issue, but probably not that common because people don't usually change this value.

[mahagr]

We should probably say in the system.yaml and admin that it is for translators/developers only.

[sg-ll]

So, I can assume that I saw it turned on, thought to myself, "I'm not using any translations, so I should turn it off to save resources," and thus set myself up for this bug.

[mahagr]

Yeah, translations also means English language. Did you see it in admin or did you just edit the field?

[sg-ll]

Until now I had made all changes in the Admin/Dashboard interface. This is the first time I edited one of the YAML files.

[rhukster]

i fixed this btw in Grav 1.7.. it should never of been using the array_support option, but it did expose a bug which we are going to fix in various places.

[mahagr]

@sg-ll Yeah, I know the name is misleading in the configuration, which is why I always look system/config/system.yaml as it has descriptions on all the fields. The name was chosen for long time ago and it ended up not being very good name in the end.

[sg-ll]

@mahagr Somewhere I saw it mentioned to stay out of the system/ directory because that's what user/ was for, otherwise I could break things. But since you mentioned descriptions in a .yaml file, that also sounds a bit familiar...

[mahagr]

Well, I always look at the code and source files for reference. :) You should just not change those files as updater deletes everything in the system/ folder.

[mahagr]

Fixed in https://github.com/getgrav/grav/issues/3191