Copied to clipboard

Flag this post as spam?

This post will be reported to the moderators as potential spam to be looked at


  • Jonathan L Folland 34 posts 196 karma points
    Dec 15, 2024 @ 20:29
    Jonathan L Folland
    0

    V15 Content Delivery API Omitting Language Prefix

    Umbraco version 15 seems to omit the language prefix for the default language in the route path. It did not do this in V14. This also seems to apply only to items contained in properties and only for default language (en-US in this case).

    Notice below the first route.path includes the language prefix. The properties.topLevelMenuItems[].content.properties.secondLevelLinks[].route.path does not include the language prefix. If the language was not en-US, it would be included.

    Is there a setting or means to assure that the language prefix is always included? I would definitely prefer to change this in a configuration rather than need to change the content delivery consumer to check if the language prefix is included.

    {
    "contentType": "header",
    "name": "Header",
    "createDate": "2024-01-28T12:40:51.1139694",
    "updateDate": "2024-08-15T12:59:50.7152203",
    "route": {
        "path": "/en-us/site-settings/header/",
        "startItem": {
            "id": "54034f33-7fb3-4862-b07d-7320cfd2e743",
            "path": "given-data"
        }
    },
    "id": "0620b0bb-3a91-4d86-a93d-0af296cdb454",
    "properties": {
        "topLevelMenuItems": {
            "items": [
                {
                    "content": {
                        "contentType": "topLevelMenuItem",
                        "id": "bb6c1925-0c64-43ef-8af3-97f663172d62",
                        "properties": {
                            "menuTitle": "Services",
                            "topLevelMenuLink": null,
                            "secondLevelLinks": [
                                {
                                    "url": null,
                                    "queryString": null,
                                    "title": "Umbraco",
                                    "target": null,
                                    "destinationId": "bb23473d-d07e-4eef-a84d-cb6f4a7d01d4",
                                    "destinationType": "detailPage",
                                    "route": {
                                        "path": "/services/umbraco/",
                                        "startItem": {
                                            "id": "54034f33-7fb3-4862-b07d-7320cfd2e743",
                                            "path": "given-data"
                                        }
                                    },
    
  • Jonathan L Folland 34 posts 196 karma points
    Jan 19, 2025 @ 19:08
    Jonathan L Folland
    0

    I believe the above issue was likely caused by a some exception during the upgrade process. I created a bug for this on github (https://github.com/umbraco/Umbraco-CMS/issues/17941)

    In the process of trying to identify the source cause, I created clean installations of umbraco version 14.3.1 and 15.1.1. I was able to run the upgrade and not reproduce the issue.

    As part of the debugging process, I was saving and publishing items as well as changing container document vary by culture settings. The problem started going away on its own to the point of it not being reproducible.

    So if you encounter this issue, my suggestion would be to start with a clean installation of umbraco, re-run the upgrade with the clean installation and see if you encounter any of the above issues. Then use your full upgraded code solution against the upgraded database.

  • Jonathan L Folland 34 posts 196 karma points
    21 days ago
    Jonathan L Folland
    100

    This issue returned in production. I moved the production data to my local. Running in debug mode, I was not able to reproduce. So same code, same data was able to produce different results. I noticed while debugging that if I passed "en-US" vs "en-us" in the Accept-Language header, the data returned correctly. So I assume the cause of this issue is an intermittent parsing of culture in a case sensitive manner.

    To address this, I created an AcceptLanguageMiddleware which sets Accept-Language request header case to lower language upper country code using the following code blocks. This I believe with resolve the issue, so I am marking this as the answer, although I cannot be 100% certain since this is an intermittent issue.

    CaseSensitiveCultureStringExtension:

    public static string CaseSensitiveCulture(this string? culture)
    {
        if (string.IsNullOrWhiteSpace(culture))
            return string.Empty;
    
        if (culture.Length == 5 && culture.Contains('-'))
        {
            var cultureParts = culture.Split('-');
    
            if (cultureParts.Length == 2)
                return cultureParts[0].ToLowerInvariant() + "-" +
                    cultureParts[1].ToUpperInvariant();
        }
    
        return culture;
    }
    

    AcceptLanguageMiddleware:

    public class AcceptLanguageMiddleware
    {
    private readonly RequestDelegate _next;
    
    public AcceptLanguageMiddleware(RequestDelegate next)
    {
        _next = next;
    }
    
    public async Task Invoke(HttpContext context)
    {
        if (context.Request.Headers.TryGetValue("Accept-Language", out var languages))
        {
            var correctedLanguages = languages.ToString()
                .Split(',')
                .Where(lang => !lang.IsNullOrWhiteSpace())
                .Select(lang =>
                {
                    // Trim any whitespace from each language entry
                    var trimmed = lang.Trim();
                    // If the language is "en-us" (case-insensitive), change it to "en-US"
                    return trimmed.CaseSensitiveCulture();
                });
    
            // Update the header with the corrected language values
            context.Request.Headers["Accept-Language"] = string.Join(", ", correctedLanguages);
        }
    
        // Continue processing the HTTP request pipeline
        await _next(context);
    }
    }
    

    Add middleware to Program.cs or Startup.cs

    app.UseMiddleware<AcceptLanguageMiddleware>();
    
Please Sign in or register to post replies

Write your reply to:

Draft