Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix error pages in multilang #6608

Draft
wants to merge 3 commits into
base: develop-minor
Choose a base branch
from

Conversation

distantnative
Copy link
Member

Description

Summary of changes

  • If a language has no specific URL path, its pattern doesn't match anymore (:all). Instead it only matches all that does not start with the URL path prefix of any other page.
  • Because of that, a path without any matching page now renders as error page in the specific language. While before it was always considered as a path of the default language/language without any URL prefix.

Reasoning

  • To me it makes sense with specific prefixes for each language to treat anything within these namespace as only belonging to that particular language. Any other language, also if not defining itself any prefix, should not interfere here.
  • Error pages are correctly translated now.
  • As this is only used in the catch-all route for each language (https://github.com/getkirby/kirby/blob/main/src/Cms/LanguageRoutes.php#L28-L47), the effect is scoped to only protect the languages from each other, while custom routes etc. are not affected (or only those that apply a language scope - and there I'd say protecting those from each other make sense).

Additional context

Touching those routing basics etc. is always a delicate matter. I'd be fine with moving this to 5.0, if preferred.

Changelog

Fixes

Ready?

  • In-code documentation (wherever needed)
  • Unit tests for fixed bug/feature
  • Tests and CI checks all pass

For review team

  • Add changes & docs to release notes draft in Notion

@distantnative distantnative added the type: bug 🐛 Is a bug; fixes a bug label Aug 11, 2024
@distantnative distantnative self-assigned this Aug 11, 2024
Copy link
Member Author

@distantnative distantnative left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This probably could use another unit tests, that really checks the behavior in matching full paths in the router. Any Idea where to add this unit test?

@distantnative distantnative marked this pull request as ready for review August 11, 2024 18:44
@distantnative distantnative requested a review from a team August 11, 2024 18:44
@distantnative distantnative added this to the 4.4.0 milestone Aug 11, 2024
@bastianallgeier
Copy link
Member

@distantnative I think it's already covered in the LanguageRoutesTest::testFallback. To be sure, I added @afbora's test case from the issue. It all seems to be fine to me.

@distantnative
Copy link
Member Author

@bastianallgeier I can't follow quite. You just replaced the languages with different ones in the existing test, or? But the test is the same as before. Which then would mean that it doesn't test what this PR fixes, cause otherwise it couldn't have passed the checks before this PR.

@bastianallgeier
Copy link
Member

I thought that we had some weird edge case when en is the default language. That's why I changed the tests.

@distantnative
Copy link
Member Author

My point is: if those tests passed before this PR, they aren't testing the fix this PR provides.

@bastianallgeier
Copy link
Member

As far as I understood @afbora's comment, it worked for some reason with English before, but not with other languages. But I did not double-check if the new test case would have failed before the PR.

@distantnative
Copy link
Member Author

It doesn't fail before this PR either. Will need to look into how a test that really covers the issue needs to look like.

@distantnative distantnative added the needs: tests 🧪 Requires missing tests label Aug 13, 2024
@afbora
Copy link
Member

afbora commented Aug 13, 2024

I can able to test the PR tonight.

@distantnative
Copy link
Member Author

I hate this, cause I cannot find a unit test. Also it's no issue if English is the default language and I don't know why because with the fix in this PR it should also apply to English beforehand. Moving this to 4.5 so we can really be sure that this is the right fix.

@distantnative distantnative modified the milestones: 4.4.0, 4.5.0 Aug 13, 2024
@afbora
Copy link
Member

afbora commented Aug 13, 2024

@distantnative The PR fixes the issue. But I'm not sure about that. Something smells not good. I found a clue while trying to write a unit test for this case For ex:

Following both codes doesn't give same output (current state, not for this PR). I think loading language ways are different.

Set languages from root argument as default

$app = new Kirby([
    'roots' => [
        'index'     => __DIR__,
        'languages' => __DIR__ . '/site/languages',
        'templates' => __DIR__ . '/site/templates'
    ],
    'site' => [
        'children' => [
            [
                'slug'     	   => 'error',
                'template' 	   => 'error',
                'translations' => [
                    [
                        'code'    => 'fr',
                        'content' => [
                            'title' => 'Erreur'
                        ]
                    ],
                    [
                        'code'    => 'en',
                        'content' => [
                            'title' => 'Error'
                        ]
                    ]
                ]
            ]
        ]
    ]
]);

echo $app->render('en/not-exist');

Set languages from languages argument (for ex: for unit tests)

$app = new Kirby([
    'roots' => [
        'index' => __DIR__,
        'templates' => __DIR__ . '/site/templates'
    ],
    'languages' => [
        [
            'code'     => 'fr',
            'name'    => 'French',
            'default'  => true,
            'url'         => '/'
        ],
        [
            'code'   => 'en',
            'name'  => 'English',
            'url'       => null
        ],
    ],
    'site' => [
        'children' => [
            [
                'slug'     	   => 'error',
                'template' 	   => 'error',
                'translations' => [
                    [
                        'code'    => 'fr',
                        'content' => [
                            'title' => 'Erreur'
                        ]
                    ],
                    [
                        'code'    => 'en',
                        'content' => [
                            'title' => 'Error'
                        ]
                    ]
                ]
            ]
        ]
    ]
]);

echo $app->render('en/not-exist');

@afbora
Copy link
Member

afbora commented Aug 13, 2024

@distantnative Here you can able to test via 20c1a1b unit test.

@distantnative
Copy link
Member Author

@afbora thank you! I will have a closer look on the weekend. I agree that doesn't smell right at first at least.

@distantnative distantnative marked this pull request as draft August 15, 2024 09:55
@distantnative distantnative force-pushed the fix/4834-error-page-multilang branch from 20c1a1b to cbdd71e Compare September 12, 2024 18:33
@bastianallgeier bastianallgeier removed this from the 4.5.0 milestone Nov 12, 2024
@bastianallgeier bastianallgeier added this to the 4.6.0 milestone Nov 12, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
needs: tests 🧪 Requires missing tests type: bug 🐛 Is a bug; fixes a bug
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Error page always rendered in default language for some languages
3 participants