Localizations objects in WebRequestContext.Localization.SiteLocalizations are partially loaded

[jhorsman]

The Localization objects in Localization.SiteLocalizations are partially loaded. Only the Localization id and Path properties are set. Other properties like Culture and Language are not set.

When the WebRequestContext.Localization itself is loaded there is logic in place to call Localization.EnsureInitialized() which loads all the Localization properties. This is not done for the Localization.SiteLocalizations.

The partially loaded Localization appears after a restart of the site. When all publications got a request, then all Localization objects are populated, including the ones in Localization.SiteLocalizations.

You can inspect the site Localization with this action and view: https://gist.github.com/jhorsman/679f6ab072c3896db41fcf893c3307b9

Edit: removed mention of /admin/refresh

[jhorsman]

There is a workaround to this issue. The action and view from https://gist.github.com/jhorsman/679f6ab072c3896db41fcf893c3307b9 as mentioned in the issue description implement it.

Before using a Localization objects from Localization.SiteLocalizations you can call Localization.EnsureInitialized() on ecah Localization object like so.

            foreach (Localization siteLocalization in WebRequestContext.Localization.SiteLocalizations)
            {
                try
                {
                    siteLocalization.EnsureInitialized();
                }
                catch (Exception e)
                {
                }
            }

Mind that if the _System\Publish Settings page of one of the publications is not published, the siteLocalization.EnsureInitialized() will thow a DxaItemNotFoundException.

[jhorsman]

The DxaItemNotFoundException thown by siteLocalization.EnsureInitialized() is described in #48

[jhorsman]

As a further improvement, and to avoid having to handle exceptions like described in #48, DXA could load all Localization.SiteLocalizations and remove the SiteLocalizations which cannot be loaded.

Localization objects which cannot be loaded because the settings are not loaded are removed from the Localization.SiteLocalizations. So we expect that a publication's System\Publish Settings page is not always published. I have seen two scenario's where the settings page is not published.

1. The publication is not published at all, it is a new publication which is in the works and the site is not published in to all targets (i.e. published to staging, not to live). The publication metadata has the Site Identifier set, and because of that the new publication is added to all sites's Localization.SiteLocalizations.
   In this case the other publications "know" about the SiteLocalization, but the settings are not published to all publications.

2. The master website publication is registered in the Localization.SiteLocalizations, but will never be published. Using a not-publishable master website publication which has publishable child-publications. To group the child-publications and have the Localization.SiteLocalizations populated the child-publications need to have the same Site Identifier in the publication metadata. When you accidently set the same site identifier on the master website publication (you should use Site Identifier multisite-master instead but this is not documented), then the master website is in the Localization.SiteLocalizations while the settings for this publication will never be published.

[rpannekoek]

I agree with the idea to suppress Localization for Publications which are not published from Localization.SiteLocalizations.

[jhorsman]

Can you also agree that the Localization objects in Localization.SiteLocalizations should be fully loaded so that we no longer need to call Localization.EnsureInitialized() on each of them?

[rpannekoek]

Yes and no. :-)
Fully loading a Localization is quite expensive. That is why the Localization is agressively cached, but it will have to be loaded after the AppPool is (re-)started. Currently, the Localization objects in Localizatiom.SiteLocalizations are intentionally not (always) fully loaded to minimize the startup delay.
I do agree with two things:

1. It should not be needed to explicitly call EnsureInitialized in your code; the DXA Framework could JIT initialize if needed (if you access something that requires loading the Localization).
2. Localization which can't be initialized/loaded (because the underlying Publication is not published) should be suppressed. That's tricky, because you would have to try loading the Localization to figure this out (but we could look into a more lightweight way to determine this)