Problem/Motivation

If a content type has the "Enable translation" checkbox checked, then the page for uninstalling module won't load (not even the rest of the site). This doesn't affect the site itself, it continues to be accessible and everything else works.
This issue doesn't require an actual content to have been created with the said content type, let alone translated. This issues manifests itself when landing the uninstall page - no need to select a module to uninstall, this happens before.

Steps to reproduce

  1. Install Drupal 8 beta 6 (with Standard profile for convenience, but the issue is reproducible with Minimal profile too)
  2. Activate the Content Translation modules
  3. Edit the Article content type admin/structure/types/manage/article
  4. Go to the Language settings vertical tab
  5. Check "Enable translation" then save
  6. Go to the Uninstall module tab (admin/modules/uninstall). Fail
  7. Go back to the Article content type admin/structure/types/manage/article and uncheck "Enable translation" then save.
  8. Go back to Uninstall module (admin/modules/uninstall). It works again.

Proposed resolution

Workaround: uncheck "Enable translation" on any content type before uninstalling a module (and recheck it after)

Remaining tasks

User interface changes

API changes

Original report by [username]

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

David Latapie’s picture

The same operation (checking "Enable translation") also prevents creating or updating a content. I ran extensive tests: as long as one content type has enable translation checked, creating or editing any content type will be impossible.

The content being edited or updated doesn't even have to belong to the content type with "Enable translation" checked. In other words, if you have "Enable translation" checked on a Basic page, even your Articles won't be editable.

David Latapie’s picture

Priority: Major » Critical

Updated to Critical because I believe the product cannot ship with this issue.

Berdir’s picture

Version: 8.0.0-beta6 » 8.0.x-dev
Component: translation.module » content_translation.module
Priority: Critical » Major
Status: Active » Postponed (maintainer needs more info)

You need to enable error reporting and provide a screenshot of the actual error, that screenshot does not help.

We have lots of tests that are doing exactly this (not sure about uninstall but definitely create translated content).

We can always set it back to critical if this is in fact a general problem that affects everyone, but we need to know more first.

David Latapie’s picture

Apologies, will do in the future.

Tested with 8.0x-dev just 30 seconds ago (both with no additional language set or with an additional language set - in any case, no actual po language downloaded, just set)

Error message

Drupal\Core\Database\DatabaseExceptionWrapper: SQLSTATE[42S22]: Column not found: 1054 Unknown column 'content_translation_source' in 'where clause': SELECT DISTINCT t.nid AS nid FROM {node_field_data} t WHERE ( (content_translation_source IS NOT NULL ) ) LIMIT 1 OFFSET 0; Array ( ) in Drupal\Core\Entity\Sql\SqlContentEntityStorage->countFieldData() (line 1784 of core/lib/Drupal/Core/Entity/Sql/SqlContentEntityStorage.php).
Drupal\Core\Database\Statement->execute(Array, Array)
Drupal\Core\Database\Connection->query('SELECT DISTINCT t.nid AS nid
FROM 
{node_field_data} t
WHERE ( (content_translation_source IS NOT NULL ) )
LIMIT 1 OFFSET 0', Array, Array)
Drupal\Core\Database\Query\Select->execute()
Drupal\Core\Entity\Sql\SqlContentEntityStorage->countFieldData(Object, 1)
Drupal\Core\Field\FieldModuleUninstallValidator->validate('content_translation')
Drupal\Core\Extension\ModuleInstaller->validateUninstall(Array)
Drupal\system\Form\ModulesUninstallForm->buildForm(Array, Object)
call_user_func_array(Array, Array)
Drupal\Core\Form\FormBuilder->retrieveForm('system_modules_uninstall', Object)
Drupal\Core\Form\FormBuilder->buildForm(Object, Object)
Drupal\Core\Controller\FormController->getContentResult(Object, Object)
call_user_func_array(Array, Array)
Symfony\Component\HttpKernel\HttpKernel->handleRaw(Object, 1)
Symfony\Component\HttpKernel\HttpKernel->handle(Object, 1, 1)
Drupal\Core\StackMiddleware\KernelPreHandle->handle(Object, 1, 1)
Drupal\Core\StackMiddleware\PageCache->pass(Object, 1, 1)
Drupal\Core\StackMiddleware\PageCache->handle(Object, 1, 1)
Drupal\Core\StackMiddleware\ReverseProxyMiddleware->handle(Object, 1, 1)
Stack\StackedHttpKernel->handle(Object, 1, 1)
Drupal\Core\DrupalKernel->handle(Object)
Berdir’s picture

Assigned: Unassigned » plach

Oh. Try running update.php, that should fix that.

I guess that is by design, although we should do a better job at catching this. Assigning to plach for his opinion.

plach’s picture

Status: Postponed (maintainer needs more info) » Active

As Berdir noted, running the updates fixes the symptom, but we have two problems here:

  1. We are not applying updates automatically on the content type form as we do on the content language settings page, so we get an inconsistent behavior. The quick fix is running the updates on submit, a better fix would probably adding a subscriber for config events and apply them there consistently so this works even when translation is enabled via the API.
  2. We could do a better job at dealing with that exception when counting field data.

I'm glad to work on the former, the latter deserves its own issue, I think.

@berdir:

What do you think?

plach’s picture

Title: Translation-enabled content types will break the uninstall page » Content translation schema updates are not triggered consistently
Status: Active » Needs review
Issue tags: +D8MI, +language-content, +sprint
FileSize
1.03 KB
4.62 KB

I went ahead meanhwile.

The last submitted patch, 7: ct-translation_enable-2419649-7-test.patch, failed testing.

Status: Needs review » Needs work

The last submitted patch, 7: ct-translation_enable-2419649-7.patch, failed testing.

plach’s picture

Status: Needs work » Needs review

Unrelated failure

Gábor Hojtsy’s picture

Status: Needs review » Reviewed & tested by the community

Looks good. It looks like a bad oversight indeed that the schema updates were only registered when using the UI.

alexpott’s picture

Status: Reviewed & tested by the community » Needs work
+++ b/core/modules/content_translation/src/Tests/ContentTranslationSettingsTest.php
@@ -257,6 +257,17 @@ function testFieldTranslatableSettingsUI() {
   /**
+   * Tests that enabling translation via the API triggers schema updates.
+   */
+  function testSettingsApi() {
+    $this->container->get('content_translation.manager')->setEnabled('entity_test_mul', 'entity_test_mul', TRUE);
+    $result =
+      db_field_exists('entity_test_mul_property_data', 'content_translation_source') &&
+      db_field_exists('entity_test_mul_property_data', 'content_translation_outdated');
+    $this->assertTrue($result, 'Schema updates correctly performed.');
+  }
+

This is a webtest so each test method requires a complete re-install of Drupal - seems a waste for testing the API. We should either move to a KernelTest or into another method.

plach’s picture

Here it is

The last submitted patch, 14: ct-translation_enable-2419649-14-test.patch, failed testing.

plach’s picture

Status: Needs review » Reviewed & tested by the community

Back to RTBC

alexpott’s picture

Status: Reviewed & tested by the community » Fixed

This issue addresses a major bug and is allowed per https://www.drupal.org/core/beta-changes. Committed 34efb12 and pushed to 8.0.x. Thanks!

  • alexpott committed 34efb12 on 8.0.x
    Issue #2419649 by plach, David Latapie: Content translation schema...
plach’s picture

Assigned: plach » Unassigned

Thanks!

plach’s picture

Issue tags: -sprint

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.