Basic concepts & principles for building global multi-language and multi-country websites using Sitecore

Global multilanguage and multicountry websites with Sitecore - Teaser

Conceptual thoughts and recommendations for building globally focused websites based on the Sitecore Experience Platform with multiple languages and country cultures. Consider this a non conclusive compilation of learnings and recommendations from our experience building such web platforms since many years. (Part 1 of a series) Weiterlesen

Sitecore – History Facts

Developing with Sitecore means dealing with configurations. The variables like commands, events, agents, pipelines and its processors as well as usage of settings makes the CMS so flexible for all kind of projects.
It also demands deep understanding and knowledge from the developers to extend the product at the correct point without missconfiguring any other parts of the solution. (mehr …)

Adventtipp 5 – Locking und Unlocking von Items beim Bearbeiten von Seiten

Locking und Unlocking von Items in Sitecore – um was geht’s? Sitecore bietet von Haus aus seit Version 7.x die Möglichkeit, einen Sperr-Modus (Item locking) von Elementen zu aktivieren, damit mehrere Autoren beim Bearbeiten von Seiten und Komponenten nicht gleichzeitig … Weiterlesen

Urwald der Konfigurationen

Wie bereits in unserem Blog-Eintrag Sitecore Web.Config aufteilen beschrieben, ist es möglich die Konfiguration der Sitecore Solution in logisch-trennbare Dateien zu splitten. Dies verbessert zum einen den Überblick massiv und vereinfacht das Austauschen von einzelnen Konfigurations-Bereiche.

Neben der eigentlichen Web.Config und deren Bestandteile, besitzt Sitecore jedoch eine grosse Menge an weiteren Konfigurationsdateien. Im App_Config Verzeichnis verstecken sich nur schon in einer leeren Sitecore-Solution viele weitere Konfigurationsdateien. Zu all dem kann man als Entwickler relativ einfach und schnell, weitere Config’s erzeugen, welche es später dem Administrator der Webseite erlaubt – im vordefinierten Rahmen – die Lösung an die gewünschten Bedürfnisse anzupassen.

Nun ist es jedoch so, dass wir selten direkt auf der schlussendlichen Zielplattform entwickeln und bei jedem Speichern/Kompilieren dies direkt live haben wollen. So entstehen pro Plattform verschiedene Konfigurationen. Als Entwickler möchte ich beispielsweise alle Debug-Informationen im Log, ein visuelles Tracing auf der Dev-Webseite oder eine andere Ansicht für gewisse Informationen haben, welche spätestens in der Live-Webseite nicht mehr erscheinen sollten. Je nach Kritikalität des Projektes gibt es da noch Testing-, Quality-, Content-Plattformen dazwischen. All diese Umgebungen benötigen unter umständen verschiedene Einstellungen.

Damit dies nicht zu einem unübersichtlichem Urwald führt und bei jedem Deployment darauf geachtet werden muss, welche Configs überschrieben, angepasst oder gelöscht werden müssen, haben wir einen kleinen, simplen Skript dazu geschrieben:

 

@ECHO off

REM Title:          Set Environment Configuration

REM Description:    Recursively replaces all master files with the specific environment
REM                 files for a given suffix, starting at the defined path or the default
REM                 path if none given. The format for each environment file has to be as
REM                 follows: myfilename.config_SUFFIX, ex. sitecore.config_Q
REM Parameters:     %1 Environment Suffix, ex. Q (required)
REM                 %2 Start Path, ex. "C:\My Directory" (optional)
REM Example:        set_env_config.bat Q "C:\My Directory"

SETLOCAL ENABLEDELAYEDEXPANSION

ECHO.

REM Error handling - check parameters

IF (%1)==() (
    ECHO Parameter environment suffix missing, ex. Q
    GOTO END
)

IF NOT (%2)==() (
    IF NOT EXIST "%~2" (
        ECHO Specified path not found, check if the directory exists and make sure to use quotes, ex. "C:\My Directory"
        GOTO END
    )
)

REM Looks recursively for files following the pattern *.config_SUFFIX, starting at the

REM specified path or the default path if none given
FOR /r %2 %%f IN (*.config_*%1*) DO (
    REM environment path (with filename) and file
    SET env_path=%%f
    SET env_file=%%~nxf
    REM replace _SUFFIX in specific environment file to get the original filename
    SET orig_path=!env_path:_%1=%!
    REM copy and override the env file with the original one without confirmation
    xcopy "!env_path!" "!orig_path!" /Y
    REM check for errors after copy
    IF errorlevel 0 (
        ECHO -- Successfully copied file !env_file! to !orig_path!
    ) ELSE (
        ECHO -- Error while copying file !env_file! to !orig_path!
    )
    ECHO.
)

:END
REM PAUSE
REM EXIT

 

Dieses Script ersetzt also alle Config-Dateien mit einem bestimmten Dateinamen-Suffix.

So kann ich beispielsweise für die ConnectionsStrings, pro Umgebung eine Konfiguration vorbereiten:

  • ConnectionString.config_DEV
  • ConnectionString.config_TEST
  • ConnectionString.config_QUALITY
  • ConnectionString.config_LIVE

Im Deployment-Prozess kann ich dann lediglich das Batchfile ausführen & meine Umgebung ist bereits richtig konfiguriert:

D:\inetpup\myWebsite\SetEnvironmentConfig.bat QUALITY

 

Dies durchsucht nun alle Config-Dateien (ab Batch-Standort & Subfolder) und ersetzt alle bestehenden Konfigurationen mit den Quality-Einstellungen.