The Needs Review Queue Bot β tested this issue. It either no longer applies to Drupal core, or fails the Drupal core commit checks. Therefore, this issue status is now "Needs work".
Apart from a re-roll or rebase, this issue may need more work to address feedback in the issue or MR comments. To progress an issue, incorporate this feedback as part of the process of updating the issue. This helps other contributors to know what is outstanding.
Consult the Drupal Contributor Guide β to find step-by-step guides for working with issues.
- π¨π¦Canada joseph.olstad
try this, changes to the automated tests as per the bot suggestions.
- Status changed to Needs review
almost 2 years ago 12:16am 31 January 2023 The last submitted patch, 58: drupal-fix_fallback-2951294-58.patch, failed testing. View results β
- Status changed to Needs work
almost 2 years ago 11:05am 31 January 2023 - π©πͺGermany Anybody Porta Westfalica
Added π ProcessedText filter doesn't pass in correct language when using language fallback Needs work
- π§πͺBelgium kristiaanvandeneynde Antwerp, Belgium
+1 for somehow making this configurable.
Currently we have a site where I would like to see @sdewitt's suggestion as explained by @plach in #9. I.e: No translation -> 404, unpublished translation -> 403
But I can definitely see websites where you want a fallback at all cost and then it would make more sense to have a fallback in both the above cases. The downside to a toggle is that if you flip it on a live website with existing data, all of a sudden your access logic gets turned upside down.
Query access seems to be fine, as missing or unpublished translations don't show up anyway (fulfulling scenario 1's desires) and the fallback always shows up for both scenarios.
- π§πͺBelgium kristiaanvandeneynde Antwerp, Belgium
We ran into another demand for disabling language fallbacks, adding that here to emphasize the need to be able to do this. Currently, entity repository adds the default language as a fallback and there is no way to stop it from doing so as it runs after the fallback hooks.
We are currently relying on the buggy behavior explained in #2978048-33: Unpublished translations should fallback to the original language β and #2978048-35: Unpublished translations should fallback to the original language β as at least it is some way to make Drupal not use fallbacks. All we have to do then is make sure that whenever a new content entity is published, we create unpublished translations for it.
It would be far superior for Drupal to be consistent across the board and to allow developers to choose whether or not they even want fallbacks to happen. It's perfectly valid to say: "Deny access to translated versions of a node until it's translated and ready". Especially in legal contexts where you are not allowed by law to show certain content outside or inside of certain countries.
Our current work-around doesn't work perfectly, because ER field, the entity_upcast operation and the default entity_view operation all behave differently.
- πͺπΈSpain rcodina Barcelona
Patch on #58 works like a charm on Drupal 10.3.5. In my case the problem was paragraph related: we have a paragraph published in Catalan and unpublished in English . However, before applying patch, it was still showing publicly in English.
- Merge request !9508Issue #2951294 by joseph.olstad, geek-merlin, joey-santiago, suresh prabhu... β (Open) created by joseph.olstad
- π¨π¦Canada joseph.olstad
Thanks @rdocina, only one fail now
https://git.drupalcode.org/issue/drupal-2951294/-/jobs/2767417