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
- Install Drupal 8 beta 6 (with Standard profile for convenience, but the issue is reproducible with Minimal profile too)
- Activate the Content Translation modules
- Edit the Article content type
admin/structure/types/manage/article
- Go to the Language settings vertical tab
- Check "Enable translation" then save
- Go to the Uninstall module tab (
admin/modules/uninstall
). Fail - Go back to the Article content type
admin/structure/types/manage/article
and uncheck "Enable translation" then save. - 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]
Comment | File | Size | Author |
---|---|---|---|
#14 | ct-translation_enable-2419649-14.patch | 5.07 KB | plach |
#14 | ct-translation_enable-2419649-14-test.patch | 1.48 KB | plach |
Comments
Comment #1
David Latapie CreditAttribution: David Latapie commentedThe 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.
Comment #2
David Latapie CreditAttribution: David Latapie commentedUpdated to Critical because I believe the product cannot ship with this issue.
Comment #3
BerdirYou 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.
Comment #4
David Latapie CreditAttribution: David Latapie commentedApologies, 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
Comment #5
BerdirOh. 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.
Comment #6
plachAs Berdir noted, running the updates fixes the symptom, but we have two problems here:
I'm glad to work on the former, the latter deserves its own issue, I think.
@berdir:
What do you think?
Comment #7
plachI went ahead meanhwile.
Comment #10
plachUnrelated failure
Comment #12
Gábor HojtsyLooks good. It looks like a bad oversight indeed that the schema updates were only registered when using the UI.
Comment #13
alexpottThis 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.
Comment #14
plachHere it is
Comment #16
plachBack to RTBC
Comment #18
alexpottThis 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!
Comment #20
plachThanks!
Comment #21
plach