Steps to reproduce:

  • Clean install of Drupal 8.0.0-beta6, use normal starter profile
  • Enable Content Translation module
  • Add a second language in Home»Administration»Configuration»Regional and language
  • Check off "Content" under "Custom language settings" in Home»Administration»Configuration»Regional and language
  • Check off the Translatable setting for "Basic page" content type
  • Save configuration

The resulting page says says:

Error
Settings successfully updated.
The website has encountered an error. Please try again later.

In spite of the message, the settings are not saved.

Looking up the error in Home»Administration»Reports»Recent log messages shows an entry type "php" severity "error" with this message:

Recoverable fatal error: Argument 1 passed to Drupal\locale\LocaleConfigManager::compareConfigData() must be of the type array, boolean given, called in /srv/http/drupal.protestan.org/core/modules/locale/src/LocaleConfigManager.php on line 115 and defined in Drupal\locale\LocaleConfigManager->compareConfigData() (line 136 of /srv/http/drupal.protestan.org/core/modules/locale/src/LocaleConfigManager.php).

Files: 
CommentFileSizeAuthor
#19 2426485-19.patch2.19 KBGábor Hojtsy
FAILED: [[SimpleTest]]: [PHP 5.4 MySQL] 87,077 pass(es), 159 fail(s), and 3 exception(s). View
#18 D8b6_multilanguage_settings_error.txt4.83 KBpepperstreet
#11 failing.txt3.2 KBalerque
#11 working.txt2.16 KBalerque

Comments

alerque’s picture

Issue summary: View changes

Two extra bits of information:

  • Accessing this functionality through a different admin page produces the same error. The switch can also be found through Home » Administration » Structure » Content types » » Language Settings » Enable Translation. Checking this off ends in the same error as first described.
  • Uninstalling the content_translation module allows the Region and Language page first described to be saved successfully (without of course the presence of the Translatable checkbox.
alerque’s picture

Component: language system » content_translation.module
alerque’s picture

Version: 8.0.0-beta6 » 8.0.x-dev
webchick’s picture

Issue tags: +Needs tests, +D8MI

This is pretty basic multilingual functionality. Surprised we don't have tests for this. Let's make sure we don't break it again. :)

alerque’s picture

@webchick I agree this is pretty serious. It put a dead end to my playing around with the beta! Pretty much the main reason I started using Drupal over other CMS systems was its multi-lingual prowess.

I have to wonder if maybe this functionality worked in earlier D8 betas or dev builds and continues to work in current builds for sites that had the functionality previously enabled for the various content types. I would be shocked and appalled if developers weren't running multi-lingual test sites out there already. It seems like maybe just the action of enabling it might be broken at this point. But either way, fixing it and making a test is beyond me and I'll wait for this issue to be resolved before taking the beta for another spin.

Berdir’s picture

Title: Fatal error when trying to make content translatable » Fatal error on Drupal\locale\LocaleConfigManager::compareConfigData() when trying to make content translatable
Status: Active » Postponed (maintainer needs more info)

I would be shocked and appalled

Uhm, that's a bit too much... emotion, as you said it yourself, this is still a beta.

We have lots of tests that cover enabling translation. This is either a) combination of modules/configuration that we are not testing yet or b) it is something that only happens on a specific system configuration.

I guess this is a duplicate of #2375963: Recoverable fatal error: Argument 1 passed to Drupal\locale\LocaleConfigManager::compareConfigData() must be of the type array, boolean given, so we should close that one. As @swentel already commented there, he was not able to reproduce this, so I suspect this is b), which means that we need more information about your system. OS, PHP version, anything that you think might be useful to know.

Including the class name in the issue title to make it easier to find this.

I also just tried this myself and was not able to reproduce this. So setting to needs more information.

Berdir’s picture

Also, are there any other errors, warnings or notices in the log right before this error? This might just be a follow-up problem of an earlier error.

alerque’s picture

Uhm, that's a bit too much... emotion

Not really. You would probably have even stronger feelings about it. If Drupal 8 had really gotten to and 8th beta rollup with a non-functional multilingual system an no developer to date had ever played around with it enough to notice a core feature was totally inoperable, you would be shocked and appalled too. Obviously that is not the case...I'm sure it's been played around with and at least various junctures it has been working. Obviously it's working now for you in some other environment so the issue is somehow more nuanced than total breakage. Obviously the next step is to figure out what factors play into that nuance, but the fact remains that _if_ it had never been tested by anybody you would get pretty emotional too. D8 would be a stillborn release _if_ that was the case.

So what makes triggers this issue? I don't know, but my system pretty consistently fails. I've nuked the DB and done the install from scratch a couple times and ended up with the same results every time.

We have lots of tests that cover enabling translation.

What exactly do these tests test? Is there a log of what commit levels / versions passed which tests somewhere?

This is either a) combination of modules/configuration that we are not testing yet or […]

This seems likely to me, but my combination of modules/configuration is not very complicated. In fact the last time I believe it failed on me with nothing but modules from core enabled on an otherwise clean install.

The one thing that stands out to me is that I'm using a non English site default language but enabling English as a secondary available language. My experience in playing around with the beta has turned up a number of cases where this produces strange results (e.g. the maintenance mode message is borked). Other cases I'm still trying to figure out if they are bugs or my failure to grok the UI or what (e.g. block content and menu times sometimes turn up localized while the block/menu heading does not and vise versa).

[…] b) it is something that only happens on a specific system configuration. […] which means that we need more information about your system. OS, PHP version, anything that you think might be useful to know.

* OS: Arch Linux (rolling release, up to date)
* Apache 2.4.12
* PHP 5.6.5
* MariaDB 10.0.16
* All tests done using Drupal code from the 8.0.0-beta6 tarball.

The only possibly unusual bit that comes to mind is that the file system is not owned by the http user, only the sites/default/files directory is owned by http and thus writable; everything else (including modules and themes directories) is owned by a deploy user and new modules can only be installed by adding them to the source repo, not through the admin interface.

alerque’s picture

Status: Postponed (maintainer needs more info) » Active

Also, are there any other errors, warnings or notices in the log right before this error? This might just be a follow-up problem of an earlier error.

No, there are no other errors showing up. If I clear the log and play around in the site nothing at all shows up until that one error when I try to enable "Translatable".

The only other thing I'm seeing is if I run the Status report self-check page from the Admin panel, I do get two php warnings, both of severity "notice":

Notice: Undefined index: name in system_requirements() (line 41 of /srv/http/drupal.protestan.org/core/modules/system/system.install).

Notice: Undefined index: version in system_requirements() (line 43 of /srv/http/drupal.protestan.org/core/modules/system/system.install).

alerque’s picture

FileSize
2.16 KB
3.2 KB

I'm not sure this will help much, but I've been trying to trace this a little more. I have production and devel environments that are very similar (nearly identical software wise). I've installed twice on each and gotten the same results each time: works on one and not the other. That would lead me to believe something is different in the env, but my gut is telling me something else is up here. Besides the env being nearly identical, D8 is acting differently and I can't explain why.

I started looking at the POST headers that are getting sent across on form submits from the admin panel on each and they are different.

For example, see the two attached POST var dump files. For best results diff them with each-other. The failing one has a bunch more values it is sending across—as if I'd checked off a bunch more things. But I didn't. The form states being submitted here are tit for tat identical. I meticulously went through on each server and setup the settings the same way (they already used the same code base), enabled the same modules, etc etc. Then I came to the content-types form and checked off exactly one option in each (the Basic Page type) as translatable. Every check box on the page is the same between posts, only the server and instance is different. Yet the one that is failing is sending over a bunch of extra values as if I'd checked off "Article" as well as "Basic page" etc.

Berdir’s picture

Can you try to take database dumps and basically switch the sites on the two systems? Which one is failing now?

Looks like the failing one has a lot more fields, I have no idea why they would be missing on the other one, if you compare the field list when you expand the bundles, do they look the same or are you missing some?

There's setting for post fields limit, but think that is much bigger, and if anything, is only a problem on the permissions page. And it wouldn't be missing fields so randomly I think.

larowlan’s picture

Status: Active » Postponed (maintainer needs more info)

I couldn't replicate this either.

Can you try with a clean browser cache - perhaps in an incognito window to rule that out.

Can you put a debugger on LocaleConfigManager::get() and break when $default is not an array and report back what $name is in that scope?

Can you clear your cache on the failing site and try again to rule out cached config storage?

larowlan’s picture

larowlan’s picture

I think we can bump this down to major and set back to active
Adding the tag

plach’s picture

Priority: Critical » Major
Issue tags: -Needs D8 critical triage

Definitely. According to the priority definitions, an issue that is not straightforward to reproduce is not critical. We can promote this again if we find a consistent way to reproduce the error and it turns out it's actually caused by a critical bug.

Gábor Hojtsy’s picture

Issue tags: -Needs tests

@alerque: looking at the difference between your failing and working list, the working one does not seem to have JS enabled. We have JS helpers to fill in some fields for you that you otherwise need to manually enable. Having JS on the site should not fail it of course.

I tried the following:

1. Went to http://simplytest.me/project/drupal/8.0.x-beta6 and installed Drupal in Hungarian (got a 30 minute free test site).
2. Added Afrikaans and reproduced the steps in the issue summary (JS worked well).

Could not reproduce a fatal error. The last messages in the log are about the Afrikaans translation import and the Hungarian JS translation regeneration.

Can you reproduce the bug on the same simplytest.me link? If we can eliminate your local environment then we can figure out if there is something with the settings or your local environment.

pepperstreet’s picture

Just wanted to add my confirmation. I have played with D8 beta6 on PANTHEON.io
I am most interested into the multi-language feature and how it has been improved/consolidated.

I had almost the same experiences and error(s) on my quick test with a basic setup for two languages (EN/DE) . On first sight I thought it was a server/local connection isue. I was able to check the respective multilingual checkboxes for simple page, article and taxonomy... but always got a blank white screen after hitting the save button. On first sight I thought it was a server/local connection issue... because the installation had some stalls. I had to delete and re-install 4-5 times.

Today I logged in again and found these error messages (complete message text in attachment):

Recoverable fatal error: Argument 1 passed to Drupal\locale\LocaleConfigManager::compareConfigData() must be of the type array, null given, called in /srv/bindings/f365a802c59f470c85c4c02fb5fa8dc2/code/core/modules/locale/src/LocaleConfigManager.php on line 115 and defined in Drupal\locale\LocaleConfigManager->compareConfigData() (line 136 of core/modules/locale/src/LocaleConfigManager.php).
... 

 

Recoverable fatal error: Argument 1 passed to Drupal\locale\LocaleConfigManager::compareConfigData() must be of the type array, null given, called in /srv/bindings/f365a802c59f470c85c4c02fb5fa8dc2/code/core/modules/locale/src/LocaleConfigManager.php on line 115 and defined in Drupal\locale\LocaleConfigManager->compareConfigData() (line 136 of core/modules/locale/src/LocaleConfigManager.php).
...

Hope this is of any help.
Happy drupaling!

Gábor Hojtsy’s picture

Status: Postponed (maintainer needs more info) » Needs review
Issue tags: +language-config
FileSize
2.19 KB
FAILED: [[SimpleTest]]: [PHP 5.4 MySQL] 87,077 pass(es), 159 fail(s), and 3 exception(s). View

That would happen if LocaleConfigManager::get() is called with a $name that is not shipped configuration. It would be useful to figure out when would that happen. Note that #2212069: Non-English Drupal sites get default configuration in English, edited in English, originals not actually used if translated among a whole lot of other things will also resolve this. It checks if there was a default config, an active config, etc. before attempting to do anything with them. Attached a simple patch that may now fail you elsewhere, because the get() return value is used as a typed configuration instance, so null would possibly cause problems there.

Status: Needs review » Needs work

The last submitted patch, 19: 2426485-19.patch, failed testing.

omar’s picture

Status: Needs work » Closed (fixed)

As far as I can tell, this is no longer reproducible (in beta10) and can be closed.

I was unable to produce errors while following the described procedures. Gabor's last comment, some 3 months ago, cited #2212069: Non-English Drupal sites get default configuration in English, edited in English, originals not actually used if translated as a potential solution, and this issue has now been resolved.

The only outstanding task would be to write a test for this. Issue already has the "Needs tests" tag. Closing.