Problem/Motivation
The config translation module tries to add a translate link to all entities. This causes a white screen on adding and then any further listing of custom blocks.
Steps to reproduce:
Install config_translation module, go to admin/structure/block/custom-blocks, add a custom block and you get the following error:
Drupal\Core\Entity\Exception\UndefinedLinkTemplateException: No link template "drupal:config-translation-overview" found for the "custom_block" entity type in Drupal\Core\Entity\Entity->urlInfo() (line 176 of core/lib/Drupal/Core/Entity/Entity.php).
Any further reload results in the same error.
Proposed resolution
In config_translation_entity_operation(), check if the link template "drupal:config-translation-overview" exists for the given entity.
Remaining tasks
Commit.
User interface changes
None.
API changes
None.
Comment | File | Size | Author |
---|---|---|---|
#18 | 2256023-psr4-reroll.patch | 1.91 KB | xjm |
#15 | custom-block-translate-tab-2256023.2.patch | 1.99 KB | olli |
#12 | custom-block-translate-tab-2256023.2.patch | 1.99 KB | larowlan |
#5 | custom-block-translate-tab-2256023.pass_.patch | 1.92 KB | larowlan |
#5 | custom-block-translate-tab-2256023.fail_.patch | 1.09 KB | larowlan |
Comments
Comment #1
larowlanThese should be translatable, so we need to add the annotation
Comment #2
olli CreditAttribution: olli commentedWe already add the "drupal:content-translation-overview'" link template to custom_blocks in content_translation_entity_type_alter(), but the "translate" operation link is added only to nodes by content_translation_entity_operation_alter().
Comment #3
olli CreditAttribution: olli commentedComment #4
olli CreditAttribution: olli commentedFiled #2256023: Content translation operation is only available for nodes, not other entity types such as custom blocks.
Comment #5
larowlanThe real issue here is that we're using the config-entity-listing for content entities, so the fix is to make sure that the config_translation operation hook only fires on config-entities.
Should be red/green
Comment #7
tstoecklerOohh, that's a fairly bad oversight. Thanks for the fix.
The test changes could have used a comment so that we don't inadvertantly remove them later (to improve performance), but this is good to go nonetheless.
Comment #8
olli CreditAttribution: olli commentedThank you, @larowlan!
Is there a problem with OP's proposed resolution using $entity->hasLinkTemplate()? (just curious)
Comment #9
tstoecklerHmm.. re #8: Good question! I thought about this some, and I think we should actually have both checks. config_translation fundamentally only works with config entities, it wouldn't work with anything else, but we should allow config entities to now provide a config-translation-overview link template and then they don't participate in config translation.
Thoughts?
Comment #10
larowlanYeah plus one to both checks
Comment #11
tstoecklerOK, let's do that then.
Comment #12
larowlanFixed
Comment #13
tstoecklerAwesome, thanks!
Comment #15
olli CreditAttribution: olli commentedReuploading #12, filed #2273489: Random test failure 'Created time is correct.' in GenericCacheBackendUnitTestBase/ApcuBackendUnitTest.
Comment #16
olli CreditAttribution: olli commentedComment #17
ngocketit CreditAttribution: ngocketit commented5: custom-block-translate-tab-2256023.pass_.patch queued for re-testing.
Comment #18
xjmReroll for #2247991: [May 27] Move all module code from …/lib/Drupal/… to …/src/… for PSR-4.
Comment #19
vijaycs85+1 for RTBC. Thanks for fixing this issue. We got a duplicate already :) #2276477: WSOD on custom block creation / listing if config translation enabled
Comment #20
vijaycs85Adding tags...
Comment #21
Gábor HojtsyWSOD of core modules is critical. Reusing the title of the other issue to underline the problem and elevating to critical. Also I think the subclass check is superfluous since the link template will only exist if it was already a subclass, but we can keep it there, if people want the code to look super safe.
Comment #22
catchI think that's more explicit to have the subclass check.
To be honest I can't think of a module that's going to want to operate on both configuration and content entities identically - do we need to split that hook in two?
Committed/pushed to 8.x, thanks!
Comment #23
Gábor HojtsyYay, thanks. Not sure if we want to split that hook, but that is a possibility, yeah.