ORG REPORT:
When a user navigates to a 404 page, all of the languages available on the site seem to show up in the drop down and create bad links. I suspect this has to do with the fact that the system doesn't treat the 404 page as an entity. I'll work on a patch to temporarily mitigate the issue, but I suspect this may need a more thorough solution involving core.
related postponed:
#3001021: Language Block disapears on Pages built using Page Manager
#3039085: Hide untranslated for View Pages.
| Comment | File | Size | Author |
|---|---|---|---|
| #5 | 3119474-1.patch | 706 bytes | jcourtice |
Comments
Comment #2
skaughttake the block off 404 pages..
depending on how you've setup your project, generally the 404 page is not a node.. autofilter feature does require 'to be on a node'
even rather: setup a translated node groups for you 404's..
Comment #3
skaughtComment #4
skaughtComment #5
jcourtice commentedHere's a patch that just exits the block creation early w/o returning the build array for the block if we get a 404 or a 403. I may be blind but I don't see a way to exclude the block on error pages via the UI. There's work in core going on but it doesn't seem to ready.
Comment #6
jcourtice commentedComment #7
jcourtice commentedComment #8
skaught(: ahh.. you're probably not blind -- i think i suggested that too offhand.
i see why/what your doing.. have not tested directly. i will look into this more. will consider this path toward next release.
i'm just not ready to act on merging here and now, even just to have it on dev line.. -- am NOT going to mark it as postponed. leaving status unchanged incase anyone else wants to review..
thanks!
Comment #9
skaughtnits:
\Drupal::request(). -- not using DI.Comment #12
skaughtcleanup of DI.
merged to dev
Comment #13
skaughtComment #14
skaught