404 that is triggered without language prefix is not redirecting properly

[ankedsgn]

¡Hola!
When you request a page without the language prefix, you don't get the 404 that you defined in the Bolt config.

How to trigger

mydomain.com/en/nopagehere -> Gives the Bolt-defined 404 page * good! *
mydomain.com/nl/nopagehere -> Gives the Bolt-defined 404 page * good! *
mydomain.com/nopagehere -> Gives a 'whoops something went wrong' error * b0rk *

What I expected

mydomain.com/nopagehere -> Should give the configured 404 page

I already apologize in advance if this is fixed in a newer version! I am just plain lazy and like adding issues. And besides that, this is a great extension. Every time it is used, a kitten smiles. Did I say one? All kittens!

---

extension version: 4.0.6

[lenvanessen]

Hi Anke,

Ik heb het net met de nieuwste versie getest en daar lijkt het wel werken!

[lenvanessen]

@anketwokings does it work for you in the new version?

[SvanteRichter]

Also, If it doesn't, could you post your routing.yml and the translate config?

[ankedsgn]

@lenvanessen @SahAssar Sorry, not my project, but I have alerted my coworker to upgrade. I'll let you know if anything new comes up. (sorry, I know this is not really constructive, but i'll follow up on this) :)

[lenvanessen]

Hi @anketwokings,

Did you find anything?

[SvanteRichter]

Hmm, looking at this again (with slightly more ☕️ ) this is the expected behaviour. The homepage we redirect (and have a special controller for it), but any other pages just have their url and that's it. My thinking was that this is just like if you have /page/about in bolt where /about won't redirect to it, but I could definitely see the upside och having a config to turn on redirects to the default language, but then we sorta have the question of if we should also match the translated slug and so on, which is a whole other ballgame.

[SvanteRichter]

Wait, no, Someone give me reading lessons, cause apparently I can't read.

@anketwokings Sorry! In the above reply I was assuming that this issue was about the non-locale version was not redirecting to the default locale, when it was actually about it showing an error message instead of the 404, right? That problem I can't really reproduce on my test setup, would it be possible for you to get a debug trace on what led to the whoops?

[nestordedios]

Hi @SahAssar ,

just updated to Bolt 3.3.6 and Translate to 4.1.0 and what @anketwokings mentioned it's still happening. If we try to request a page like sitedomain.com/pageslug we will get the following error.

In the translate.animal.yml file we have set routing_override: true and here I think it's where it goes wrong. When the route does not match the requirements of /{_locale} (in our case en or nl).

Is there a possibility when having routing_override: true to bypass the requirements if _locale is not en or nl and render the Bolt 404 not found page? I still would like to keep the routing_override option set to true.

Backtrace of the error:

Here my translate.animal.yml:

locales:
    en_GB:
        label: EN
        slug: en
    nl_NL:
        label: NL
        slug: nl

# Enable/disable automatic routing override.
# Enabling this will prefix all routes with {_locale} which leads to links like
# /en/pages/yourpageslug It is recommended that you leave this on unless you
# want to build your own routing.
routing_override: true

# Enable/disable showing of flag icons next to language names.
show_flags: true

# Enable/disable the menubuilder override.
# Enabling this will make the menu output links in the format of the automatic
# routing. It is recommended that you leave this on unless you want to build
# your own localized menus.
menu_override: true

# Enable/disable the url_generator override.
# Enabling this will override the url generator to make sure that we don't
# generate links without a locale. This is highlig recommended to keep unless
# you also build your own override since it can cause WSOD on 404's otherwise.
url_generator_override: true

# Enable/disable translated slugs.
# Enabling this will use translated slugs instead of using the same slug for
# all languages. Only set to false if you also don't set your slugs to `is_translateable`.
translate_slugs: true

# Enable/disable using Accept-Language header to determine the locale for
# redirection on `/`.
# Enabling this will redirect visitors on `/` to the preferred locale based on
# the Accept-Language header. Disabling this will always redirect `/` to the
# first locale set in `locales` above.
use_accept_language_header: false

# Enable/disable translation of the dashboard.
translate_dashboard: false

Here the overriden routes (screenshoot of Symfopny Profiler Routing):

[ankedsgn]

@lenvanessen @SahAssar
As you can see, my colleague Nestor just updated and tested the project i was talking about. More info in his extensive post!

[SvanteRichter]

@nestordedios Does it not display the normal 404 when you are not logged in (and have debug_show_loggedoff: false)?

Because it really should just like you should get a 404 on /test/test/test/test/test/test on any bolt install even though it does not match any of the routes.

[nestordedios]

@SahAssar when I'm not logged in and I have debug_show_loggedoff: false I get this:

After setting debug: true and login in I still get NotFoundHttpException:

[lenvanessen]

@nestordedios I can't reproduce here, can you share your routes file as well? (If you've made any changes)

[nestordedios]

Hi @SahAssar and @lenvanessen ,

First of all my apologies for the wrong comments posted before. I've been using the wrong config.yml to reproduce the main issue 😟 which is "kind of" solved and it seems it has only something to do with having strict_variables set to either true or false.

When using the correct config.yml I get a different error than before. The notfound: option points to a Page Contenttype record page/page-not-found-404(uses notfound.twig). We do not use Blocks Contenttype to render a 404 page. I have also checked rendering the not found page the way Bolt Docs recommend https://docs.bolt.cm/3.3/howto/resource-contenttype#example-configuration-of-a-404-resource but the error is still there when I change to notfound: block/not-found in the config.yml.

I'm using the {{ localeswitcher() }} function

{{ localeswitcher(classes = 'menu menu-lang') }}

and for the search engines to find out about the site structure:

('_base.twig' line 17) where error is thrown having `strict_variables: true`
{% for key, locale in locales %}
    <link rel="alternate" hreflang="{{key|replace({'_': '-'})}}" href="{{locale.getUrl()}}">
{% endfor %}

When strict_variables: false there is no error thrown, but I still would like to make use of strict_variables: true. Is there I way to have this working?

Error screenshot:

config.yml:

notfound: page/page-not-found-404

config_local.yml debug settings:

# Debug settings
debug: true
debug_error_level: 8181
strict_variables: true
developer_notices: false
debug_show_loggedoff: false
debug_permission_audit_mode: false
debug_enable_whoops: false
debug_error_use_symfony: true      # When set to true, Symfony Profiler will be used for exception display when possible

routing.yml:

# The locales the site should be available in
locales:
    en_GB:
        label: EN
        slug: en
    nl_NL:
        label: NL
        slug: nl

# Enable/disable automatic routing override.
# Enabling this will prefix all routes with {_locale} which leads to links like
# /en/pages/yourpageslug It is recommended that you leave this on unless you
# want to build your own routing.
routing_override: true

# Enable/disable showing of flag icons next to language names.
show_flags: true

# Enable/disable the menubuilder override.
# Enabling this will make the menu output links in the format of the automatic
# routing. It is recommended that you leave this on unless you want to build
# your own localized menus.
menu_override: true

# Enable/disable the url_generator override.
# Enabling this will override the url generator to make sure that we don't
# generate links without a locale. This is highlig recommended to keep unless
# you also build your own override since it can cause WSOD on 404's otherwise.
url_generator_override: true

# Enable/disable translated slugs.
# Enabling this will use translated slugs instead of using the same slug for
# all languages. Only set to false if you also don't set your slugs to `is_translateable`.
translate_slugs: true

# Enable/disable using Accept-Language header to determine the locale for
# redirection on `/`.
# Enabling this will redirect visitors on `/` to the preferred locale based on
# the Accept-Language header. Disabling this will always redirect `/` to the
# first locale set in `locales` above.
use_accept_language_header: false

# Enable/disable translation of the dashboard.
translate_dashboard: false

[SvanteRichter]

@nestordedios {% for key, locale in locales|default([]) %} should work

[nestordedios]

Thanks @SahAssar that indeed fixes the issue, but still some customization for the _localeswitcher.twig base template needs to be done otherwise the same error is triggered when using {{ localeswitcher() }}.

I opened a PR #153 just in case it is possible to fix like that.

Thanks a lot! 👍