Remove stale references to language_content_type variable

I take for review

+++ b/core/modules/language/lib/Drupal/language/Tests/LanguageNegotiationInfoTest.phpundefined
@@ -42,8 +42,12 @@ function setUp() {
-    variable_set('language_test_language_types', TRUE);
-    variable_set('language_test_language_negotiation_info', TRUE);
+    config('language.test')
+      ->set('types', TRUE)
+      ->save();
+    config('language.test')
+      ->set('negotiation', TRUE)

Should be config()->set()->set()->save().

+++ b/core/modules/language/lib/Drupal/language/Tests/LanguageUILanguageNegotiationTest.phpundefined
@@ -382,7 +393,9 @@ protected function runTest($test) {
-      variable_set('language_test_domain', $test['language_test_domain']);
+      config('language.test')
+        ->set('domain', $test['language_test_domain'])

I haven't check what exactly this is doing but temporary variables which are only in test modules shoud use state(), not config().

Corrected some typo and a few vars not being corrected by the initial patch.
Corrected a "Call to undefined function theme()" error when doing clean install.

Thanks for your review, Berdir. I've added the changes that you suggest.

Anyway, I'm running in troubles with the installation, when it's installing the modules at field module it stops with a 500 server error. After debugging this, I can't figure why its happening, so y upload the last patch if someone can help me to find the error.

More corrections to the patch and finally I found where is crashing at install, but don't understand why.

Problem is at this function, on bootstrap.inc

 function language_multilingual() {
-  // The "language_count" variable stores the number of enabled languages to
-  // avoid unnecessarily querying the database when building the list of
-  // enabled languages on monolingual sites.
-  return variable_get('language_count', 1) > 1;
+  // The "language.detection.count" variable stores the number of enabled
+  // languages to avoid unnecessarily querying the database when building the
+  // list of enabled languages on monolingual sites.
+  // Must use config instead of state to get the value because with state
+  // drupal install will not work.
+  return config('language.detection')->get('count') > 1;
 }

If revert the changes, using again the variable_get() function, installation goes right. If I use state() instead of config() function, it crashes when accessing /core/install.php, and if I leave as is on the patch, it works for the 4-5 first modules.

Can someone explain me what I'm doing wrong?

@japicoder: I had the same problem during #1799440: Convert Filter variables to Configuration System.

The issue here is, make language.detection.count should not be part of the language module but system module. In fact maybe it can be a state instead of a config. See http://drupal.org/node/1790518

@dagmar: thank you for your suggestions, after seeing http://drupal.org/node/1799440 I think it's now more clear to me and I have to try some improvements on the patch and see if now everything works as expected

New revision, I've corrected some state calls and changed all the language.detection.count to state, but fails on install. This still needs work.

Could the install fails be related to the issues with the installer being worked on here? #1798732: Convert install_task, install_time and install_current_batch to use the state system

Indeed, there is a call to drupal_language_initialize() in install.core.inc which calls language_multilingual(). That function is converted to use the state() system in the patch which is not available yet. We'll have to wait for that other one to land to get this one forward.

This is just a rerole.

#18: drupal-1827038-18.patch queued for re-testing.

#18: drupal-1827038-18.patch queued for re-testing.

Re-rolling...

#25: 1827038-language-cmi-25.patch queued for re-testing.

#25: 1827038-language-cmi-25.patch queued for re-testing.

Tagging up with some tags.

The patch does not need a reroll, but some Language Negotiation tests are failing. I will try to find why.

Restore lost tags.

Debugged the issue and found that there were some missing variable_get not changed. Trying to do that, I hit the #1862202: Objectify the language system wall, so maybe this should be postponed on that issue.

Totally useless, but here is my patch, interdiff, and the exception I finally got:

[Sun Mar 10 17:53:23 2013] [error] [client 127.0.0.1] PHP Fatal error:  Call to a member function get() on a non-object in [...]core/includes/bootstrap.inc on line 2545
[Sun Mar 10 17:53:23 2013] [error] [client 127.0.0.1] PHP Stack trace:
[Sun Mar 10 17:53:23 2013] [error] [client 127.0.0.1] PHP   1. {main}() [...]index.php:0
[Sun Mar 10 17:53:23 2013] [error] [client 127.0.0.1] PHP   2. drupal_handle_request() [...]index.php:17
[Sun Mar 10 17:53:23 2013] [error] [client 127.0.0.1] PHP   3. Drupal\\Core\\DrupalKernel->boot() [...]core/includes/bootstrap.inc:2196
[Sun Mar 10 17:53:23 2013] [error] [client 127.0.0.1] PHP   4. Drupal\\Core\\DrupalKernel->initializeContainer() [...]core/lib/Drupal/Core/DrupalKernel.php:145
[Sun Mar 10 17:53:23 2013] [error] [client 127.0.0.1] PHP   5. Symfony\\Component\\DependencyInjection\\Container->get() [...]core/lib/Drupal/Core/DrupalKernel.php:302
[Sun Mar 10 17:53:23 2013] [error] [client 127.0.0.1] PHP   6. service_container_prod_->getConfig_FactoryService() [...]core/vendor/symfony/dependency-injection/Symfony/Component/DependencyInjection/Container.php:262
[Sun Mar 10 17:53:23 2013] [error] [client 127.0.0.1] PHP   7. Drupal\\Core\\Config\\ConfigFactory->__construct() [...]sites/default/files/php/service_container/service_container_prod_.php/faa37bd9338534cc942bc3cde5958900b8a3f630ccf915056fe9c929d58762ee.php:291
[Sun Mar 10 17:53:23 2013] [error] [client 127.0.0.1] PHP   8. Drupal\\Core\\Config\\ConfigFactory->enterContext() [...]core/lib/Drupal/Core/Config/ConfigFactory.php:64
[Sun Mar 10 17:53:23 2013] [error] [client 127.0.0.1] PHP   9. Drupal\\Core\\Config\\Context\\ConfigContext->init() [...]core/lib/Drupal/Core/Config/ConfigFactory.php:144
[Sun Mar 10 17:53:23 2013] [error] [client 127.0.0.1] PHP  10. Drupal\\Core\\Config\\Context\\ConfigContext->notify() [...]core/lib/Drupal/Core/Config/Context/ConfigContext.php:68
[Sun Mar 10 17:53:23 2013] [error] [client 127.0.0.1] PHP  11. Symfony\\Component\\EventDispatcher\\ContainerAwareEventDispatcher->dispatch() [...]core/lib/Drupal/Core/Config/Context/ConfigContext.php:105
[Sun Mar 10 17:53:23 2013] [error] [client 127.0.0.1] PHP  12. Symfony\\Component\\EventDispatcher\\EventDispatcher->dispatch() [...]core/vendor/symfony/event-dispatcher/Symfony/Component/EventDispatcher/ContainerAwareEventDispatcher.php:167
[Sun Mar 10 17:53:23 2013] [error] [client 127.0.0.1] PHP  13. Symfony\\Component\\EventDispatcher\\EventDispatcher->doDispatch() [...]core/vendor/symfony/event-dispatcher/Symfony/Component/EventDispatcher/EventDispatcher.php:53
[Sun Mar 10 17:53:23 2013] [error] [client 127.0.0.1] PHP  14. call_user_func() [...]core/vendor/symfony/event-dispatcher/Symfony/Component/EventDispatcher/EventDispatcher.php:164
[Sun Mar 10 17:53:23 2013] [error] [client 127.0.0.1] PHP  15. Drupal\\locale\\LocaleConfigSubscriber->configContext() [...]core/vendor/symfony/event-dispatcher/Symfony/Component/EventDispatcher/EventDispatcher.php:0
[Sun Mar 10 17:53:23 2013] [error] [client 127.0.0.1] PHP  16. Drupal\\Core\\Language\\LanguageManager->getLanguage() [...]core/modules/locale/lib/Drupal/locale/LocaleConfigSubscriber.php:71
[Sun Mar 10 17:53:23 2013] [error] [client 127.0.0.1] PHP  17. Drupal\\Core\\Language\\LanguageManager->isMultilingual() [...]core/lib/Drupal/Core/Language/LanguageManager.php:89
[Sun Mar 10 17:53:23 2013] [error] [client 127.0.0.1] PHP  18. state() [...]core/lib/Drupal/Core/Language/LanguageManager.php:138

lets run this

er #35 contains a completely different patch

also #1862202: Objectify the language system is going much further, so I think we can more or less close this one

- edit - rather wait until that one is done.

This is a release blocker as we can't have a half deployable multilingual system through CMI

Looking at the proposed patch, this is not actually an API change. Those who wanted to use the variables should have used the API functions to access them anyway.

Needs reroll

The last patch was from February 17th. A lot changed, so I'm just starting over. language_default is first.
The previous patch placed it into language.detection.yml, I'm not sure if that's correct.

+++ b/core/lib/Drupal/Core/Language/LanguageManager.php
@@ -177,14 +177,8 @@ protected function getLanguageTypes() {
+  public function getLanguageDefault() {

I think getDefaultLanguage() would be a more intuitive name.

Also, considering that the previous patch was 300 KB I would prefer if we could do this in batches, i.e. one variable at a time or something.

@tim.plunkett: well, the default language used to be a very integral part of language selection. Now that is configurable, so the detection may never consider the default language. Also, the default language may be applicable to other things, etc. all content/config entities created get that assigned when created unless configured otherwise. So the default language is applied to so many other things.

Part of the language variables are addressed in #1862202: Objectify the language system. There we are introducing getLanguageDefault(), however I agree getDefaultLanguage() would be better.

1. Created new issue #2078511: Rename getLanguageDefault() to getDefaultLanguage() for renaming method and postponed on this issue
2. Looks like getLanguageDefault() trying to get the default before static::$container is in place.

language_content_type variable is just cruft at this point since that was already converted. Here's an interim patch to clean that up.

Agreed. I can see these being upgraded in node_update_8001() and then re-upgraded in following hooks until they are added to \Drupal::config('language.settings'). Therefore we don't need to manually delete them on uninstall.

RTBC.

I should clarify my RTBC was for #49 for language_content_type_* only.

Many of the other variables have already been converted in other issues, the only remaining one that I could see that did not already have an open issue was language_default which I've split into #2108599: Convert language_default to CMI.

Tag on sprint for easier tracking.

Since Alex is away and it's my patch, assigning to webchick.

Oh, that's a far less scary patch than I was picturing from the title. :)

Committed and pushed to 8.x. Thanks!

Thanks!