사이트코어 페이지 렌더링 최소화 하기 (Performance)

긴 휴가를 마치고 오랜만에 포스트를 작성해 본다. 이번 포스트에서는 웹개발 및 플랫폼 관리에 있어서 가장 기본적이면서도 놓치기 쉬운 요소에 대하여 알아보기로 하자. 알다시피, 사이트코어는 무궁무진(?)하게 플랫폼을 비지니스 컨셉 또는 사용자에 맞게 확장 및 개발 구조를 변경할 수가 있다. 예를 들어, 하나의 플래폼에 많은 개발 에이전시들이 이용하고 있으면 이에 맞게 개발 구조를 변경해야 할 뿐더러 관리자 입장에서는 각각 에이전시 개발자들이 플랫폼의 기준을 얼마나 잘 준수하며 개발을 하는지에 대하여 관리를 해야한다. 

개발 준수사항을 따르지 않고 웹사이트를 만들고 설계할 시 소수의 웹사이트 관리는 조그만한(?) 노력으로 충분히 보완하고 수정할 수 있지만, 사이트의 수 및 사이즈에 따라 보수하는데에 있어서 하나의 프로젝트로 진행할만큼의 시간, 노력, 그리고 비용이 든다. 특히나, 컴포넌트 및 모듈을 많은 웹사이트들과 공유하는데 있어서는 더욱 그러하다.

그 중의 또 하나의 가장 큰 문제점은 웹사이트 Performance 이다. 겉보기에는 웹사이트가 이쁘게 만들어졌고, 잘 돌아가는것처럼 보이나 그 뒤에 서버, 플랫폼, 데이타베이스 등은 개발 준수사항을 따르지 않음으로써 많은 리소스를 소비할뿐더러 요즘첨럼 클라우드를 기반으로 Infrastructure가 짜여져 있는 환경에서는 비용까지 고려해야한다. 또한, 고객 및 웹사이트 방문자의 입장에서도 웹사이트의 느린 렌더링 그리고 페이지를 이동하고 관련된 미디어를 노출하는데에도 시간이 소비되는 부분에 있어서 마케팅 및 비지니스에 영향을 끼친다.

필자는 지금까지의 경험을 토대로 어떻게 사이트코어의 Performance를 최적화 할 수 있는지에 대한 요소를 정리해 보았다.

• Roslyn Compiler - 로슬린 컴파일러  오픈소스 컴파일러이면서 API를 통하여 .NET 코드를 분석한다. 고로, 로슬린 .NET 코드 분석툴이라고 설명할 수가 있다. 먼저, Visual Studio에서 사이트코어 컴포넌트 작업을 할때 NuGet Compiler를 설치하고 개발을 하다보면 어디에서 코드 문제가 발생하는지 바로 알수있다. 로슬린 컴파일러는 사이트코어가 Views 로드하는데 미리 컴파일을 함으로써 로딩 시간을 더욱 빠르게 해준다. 사이트코어는 이미 DLLs파일을 포함하고 있으며, 이를 Web.Config 파일에서 활성화만 시켜주면 된다.
  
  

  <system.codedom>
      <compilers>
        <compiler language="c#;cs;csharp" extension=".cs" type="Microsoft.CodeDom.Providers.DotNetCompilerPlatform.CSharpCodeProvider, Microsoft.CodeDom.Providers.DotNetCompilerPlatform, Version=2.0.1.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" warningLevel="4" compilerOptions="/langversion:default /nowarn:1659;1699;1701" />
        <compiler language="vb;vbs;visualbasic;vbscript" extension=".vb" type="Microsoft.CodeDom.Providers.DotNetCompilerPlatform.VBCodeProvider, Microsoft.CodeDom.Providers.DotNetCompilerPlatform, Version=2.0.1.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" warningLevel="4" compilerOptions="/langversion:default /nowarn:41008 /define:_MYTYPE=\&quot;Web\&quot; /optionInfer+" />
      </compilers>
  </system.codedom>

  
  
• HTML Cache Setting - 이는 웹사이트 방문자 관점에서 페이지 렌더링 속도를 향상시킬수 있다. 특히나 SXA를 사용하고 있을때에는 각 사이트 세팅마다 컴포넌트에 대하여 HTML Cache 레이어를 쉽게 설정할 수가 있다.
  
  
• Data Cache - HTML Cache 처럼 사이트코어처럼 데이타소스를 많이 이용하는 플랫폼에서는 특히나 중요하다. 기본적으로 초기 세팅이 되어있는데 이는 새로운 사이트코어를 셋업할때의 기본 세팅이므로 사이트에 맞게 설정이 중요하다.
  
  
• Asset Optimizer - 이는 SXA의 기반의 웹사이트를 개발할때 특히나 중요하다. 만약 이를 세팅하지 않고 웹사이트를 렌더링할시 하나하나의 CSS/JS 파일을 Request/Response 하는데 있어서 많이 리소스가 필요하 수 있고, 이는 사이트 Performance에 영향을 미친다. Optimizer를 사용함으로써 Asset의 요소를 모두 모아 Minify 하여 리소스 소비를 간략 시킬수 있다.
  
  
• IIS Dynamic Content Compression - 이는 HTTP Compression으로써 IIS를 설치할때 추가적인 기능중의 하나다. 이 Compression은 IIS와 사용자 브라우져간에 Transmission 시간을 빠르게 해줌으로써 컨텐츠를 빠르게 렌더링하는데 도움이 된다.
  
  
• The Limited Number of Child Item - 싱글 노드 아래 많은 많은 Child 아이템이 있다면 CMS내에 에디팅을 하는데 Performance 문제가 있을 수 있다. 고로, 100개의 Child 아이템으로 제한하는것을 권한다.
  
  
• The Limited Number of Rendering Variants - SXA기반으로 웹사이트를 개발하다보면 기존의 SXA 컴포턴트를 이용하여 추가적으로 새로운 스타일 및 레이아웃의 렌더링 옵션을 만들수가 있다. 하지만, 너무 많은 옵셥은 오히려 Performance 또는 에디팅에 있어서 모듈을 렌터링하는데 시간이 걸린다. 고로, 15개의 옵션으로 제한을 두는것을 권한다.
  
  
• Image Parameter - 요즘은 데스크탑 및 모바일뷰를 Responsive Design으로 개발을 한다. 하나의 고정된 이미지를 사용하기 보단 모바일뷰일때는 Image Parameter를 이용하여 서버에서 이미지를 re-size할수가 있다. 또한, 수정된 이미지는 파일시스템내의 데이타 Cache 폴더에 저장되므로 다음 Request가 있을시 반복적인 렌터링 및 수정 작업을 필할수있다.
  
  
• The Limited Number of Components on Page - 한 페이지의 들어가 컴포넌트수는 제한을 두어 페이지 렌더링 및 수정작업을 하는데 리소스 소비를 줄일수 있다. SXA 기반의 웹사이트일 경우 일반적이며 많은 페이지에 반복적으로 들어가는 컴포넌트라면 Partial Design을 통하여 우선적으로 세팅을 하고, 각각의 페이지에는 그 페이지에 맞는 컴포넌트를 추가하도록 하자. 이는 CMS내의 작업뿐만 아니라, 서버의 CPU 및 메모리 소비에도 영향을 주므로 명심하자.

사이트코어 SXA 사이트 - 페이지 디자인 및 부분 디자인

사이트코어 SXA의 큰 장점중의 하나는 프리젠테이션 레이어를 분리하여 웹사이트/페이지 디자인을 재사용할 수 있도록 구분하였다. 그 뿐만 아니라, 디자인 레이어를 Page Design과 Partial Design으로 구분하여 Partial Design 아이템이 Page Design에 상속되는 구조로 Partial Design의 상속여부에따라 Page Design이 다양하게 변경될수가 있다.

아래의 사진처럼 SXA 사이트 루트에 Presentation 노드가 있으며, 그 안에는 사이트/페이지 스타일 및 렌더링 아이템 설정과 관련된 아이템이 존재한다. Page Design과 Partial Design 노드를 오픈하면 디자인을 구성하는 아이템이 포함되어있다.

디자인 아이템은 웹페이지 아이템처럼 컴포넌트를 추가하고 페이지 형식으로 디자인 할 수 있으며 아래의 그림으로 디자인 스트럭쳐를 좀 더 쉽게 이해할수 있다.

사진에서 보듯이 Partial Design은 페이지 형식으로 컴포넌트를 추가하여 고정 컨텐츠 및 Placeholder를 구성할여 Page Design에 상속을 시킨다. 페이지 디자인에서도 같은 형식으로 컴포넌트를 추가여 페이지 디자인 레벨의 고정 컨턴츠를 정의 할수 있는며 이는 본 웹페이지 아이템으로 상속이 된다. Page Design은 하나 이상의 Partial Design을 상속할수 있지만 웹페이지 아이템은 오직 하나만의 Page Design을 상속할수 있다.

Page Design 아이템에서 각각 SXA 사이트 웹페이지마다의 디자인을 정의할수 있으며, 또는 Experience Editor의 Experience Accelerator 탭의 "Site Page Designs" 메뉴에서 페이지 디자인을 정의 할수가 있다.

Sitecore Symposium 2019 올랜도 - 후기

사이트코어 심포지엄 2019 (Sitecore Symposium 2019)에서의 메인 Keynote는 Sitecore SaaS (Software as a Service) 발표이다. 공개적으로 어떻게 SaaS의 아키텍쳐 및 SaaS가 Microsoft Azure의 기준으로 개발되는지 아니면 AWS에서도 똑같은 기준으로 서포트를 하고 이용할 수 있는지는 발표되어지 않았다. 아래는 이번 Symposium에서의 Keynote 및 기준으로 리스트를 만들었다.

Sitecore 9.3 Winter 2019 Release

• ContentHub 3.3 새로운 버전 출시 및 CMP (Content Marketing Platform) 은 Salesforce Marketing Cloud와 연동되어 쉽게 마케팅 컨텐츠를 관리하고 매니지 할수있다.
• 3rd Party 서치엔진인 Coveo와 부분적으로 연동하기 시작한다.
• Horizon이라는 새로운 에디터 인터페이스를 적용한다. 이는 기존의 Content Editor와 Experience Editor의 구분없이 한 UI에서 컨테츠를 관리하며 디자인 뷰를 제공한다.
  
  
• SXA (Sitecore Experience Accelerator) 9.3 은 Front-End 개발 Workflow를 강화하는 동시에 추가적으로 새로운 2개의 Search Facet Filter를 추가한다.
• 기존 SXA Theme은 Sitecore의 UI로만 제공되었으나, SXA 9.3에서부터 SXA CLI를 이용하여 Site Theme을 생성할 수가 있다. 
• SXA 9.3는 Scriban 이라는 Text Templating Engine을 Rendering Variants를 적용하는데 이용할 수 있도록 한다.
  
  
• Auto Personalization이라는 새로운 옵션을 적용하여 개별적인 아이템 Personalization 설정없이 Sitecore AI가 컨테츠를 체크하고 자동으로 적용을 시킨다.
  
  

Summer 2020

• Sitecore SaaS 릴리즈 
• ContentHub – DAM (Digital Asset Management)에 Video AI 적용시키며 Open API도 제공한다.
• Experience Platform에 Container (예, Dockers)를 추가하고 쉽게 Instance 및 설정을 이미지화 할수있다. 이는 SaaS 이용과 동시에 큰 변화라 예상한다.
• 새로운 개발 및 컨텐츠 에디터의 환경 변화가 있을꺼라 예상한다.

내년 Sitecore Symposium 2020은 시카고에서 10월 26일부터 10월 29일까지 진행되며, Sitecore 9.3의 Update 버전과 동시에 SaaS대한 많은 설명이 있을거라 예상한다.

사이트코어 Federated Authentication - Azure AD Workflow

이전 포스트에서는 Sitecore Federated Authentication을 사용하여 어떻게 Azure AD를 컨넥하고 유저정보를 인증하는지 그리고 어떻게 Customize한 코드를 적용하는지에 대하여 알아보았다.
이번에는 조금 더 디테일하게 접근하기위하여 필자는 유저의 이벤트 Request부터 시작하여 어떻게 Azure AD를 통하여 사이트코어 로그인을 성공하는지에 대하여 Workflow를 그려보았다.

순서부터 설명하자면,

1. 유저는 Authentication 버튼이 생성되어진 로그인 페이지로 이동한다.
2. 개발자의 의해 Customize되어진 사이트코어 Pipleline을 통하여 등록되어진 Microsoft Identity Server로 이동한다.
3. MS 로그인페이지에서 유저 이메일 및 암호를 입력하고 로그인을 시도한다.
4. MS Identity Server는 사이트코어 Pipeline를 통하여 받은 정보와 유저의 로그인 정보를 통하여 Azure AD로 이동한다.
5. 유저정보가 Azure AD에 등록 또는 이용가능한 정보인지 검증한다.
6. 검증이 확인되면 다시 MS Identity Server로 이동 후, 유정정보를 이용하여 Unique한 Token을 생성한다.
7. 사이트코어는 생성된 Token과 함께 유저정보를 사이트코어 Pipeline에 보낸다.
8. 사이트코어 Pipeline 및 설정에 등록된 Claims에 따라 유저정보 및 프로파일을 업데이트 한다.
9. 유저는 사이트코어 Dashboard로 이동하여 사이트코어 CMS를 이용한다.
   

사이트코어의 새로운 MVC Route 적용하기

이번 블로그에서는 새로운 MVC Route를 사이트코어에 적용하는 방법을 알아보자.
사이트코어의 기본 MVC Route는 "/api/sitecore/{controller}/{action}"으로써 Sitecore 9 이상의 버전에서는 Sitecore.Mvc.config, 그리고 Sitecore 9 하위 버전에서는 Sitecore.Speak.Mvc.Config 파일에서 확인할 수가 있다.
Sitecore의 자체적인 MVC Application의 컨트롤는 "/sitecore/layout/controllers" 아이템 트리에 등록되어진 Application 렌더링 아이템을 작동시키지만, 간혹 아이템의 등록없이 새로운 API를 만들어 외부 소스를 Ajax Call로 불러들여 원하는 기능을 작동시킬수가 있다.

이를 위하여, 새로운 MVC Route를 만듬으로써 기본 API 경로에 구애받지 않고 사이트코어 내에 다른 어플리케이션을 독립적으로 수행할수가 있다. 지금부터 어플리케이션을 만들고 적용시키는 방법을 알아보자.

1. Visual Studio에서 새로운 Empty MVC 프로젝트를 만든다.
   
   
2. App_Start 폴더에 RouteConfig.cs을 새로운 Route를 레지스터하기 위하여 수정한다.
   
   

   1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32

   using System.Web.Mvc; using System.Web.Routing; namespace SitecoreSpaceNewRoute { public class RouteConfig { public static void RegisterRoutes(RouteCollection routes) { //// //// 기본 MVC Route //// //routes.IgnoreRoute("{resource}.axd/{*pathInfo}"); //routes.MapRoute( // name: "Default", // url: "{controller}/{action}/{id}", // defaults: new { controller = "Home", action = "Index", id = UrlParameter.Optional } //); //// //// 사이트코어 스페이스의 새로운 MVC Route //// routes.MapRoute( name: "SitecpreSpaceRouting", url: "new/sitecore/space/routing/{controller}/{action}/{id}", defaults: new { controller = "SitecoreSpace", action = "MyView", id = UrlParameter.Optional } ); } } }

   
   
   
3. 새로운 폴더 "CustomRouting" 이라는 폴더를 만들고, Sitecore.Kernel assembly를 Reference에 추가하고 사이트코어의 Bin 폴더의 System.Web.Mvc를 사용하도록 프로젝트에 업데이트한다. 레지스터한 Route를 Sitecore.Pipeline의 프로세스에 적용을 시킨다.
   
   

   1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17

   using System.Web.Routing; using Sitecore.Pipelines; namespace SitecoreSpaceNewRoute.CustomRouting { public class InitializeRoutes { /// <summary> /// 새로 등록한 Route는 Sitecore Pipeline에 적용시킨다. /// </summary> /// <param name="args"></param> public void Process(PipelineArgs args) { RouteConfig.RegisterRoutes(RouteTable.Routes); } } }

   
   
   
4. 간단하게 새로운 Route의 레지스트를 마쳤으며, 이젠 Simple MVC을 만들자.
   
   Controller (SitecoreSpaceController.cs)
   
   

   1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35

   using System; using System.Collections.Generic; using System.Linq; using System.Web; using System.Web.Mvc; namespace SitecoreSpaceNewRoute.Controllers { public class SitecoreSpaceController : Controller { // GET: SitecoreSpace public ActionResult MyView() { Models.SitecoreSpace ssnr = new Models.SitecoreSpace(); // Valuable 값을 다른 소스 (예, 데이타베이스)에서 불러들일수 있지만, // 이번은 예제이므로, Static 값을 메뉴얼로 적용하겠다. ssnr.Subject = "사이트코어의 새로운 MVC Routing"; ssnr.Description = "사이트코어 스페이스의 새로운 MVC Routing으로써, 기존 (Default)의 Routing 제한을 받지않고, 임의의 새로운 Route를 적용시켜 독립적인 MVC 어플리케이션을 Sitecore XP내에서 작동시킬수 있다."; ssnr.CurrentDateTime = DateTime.UtcNow; return View(ssnr); } // Redirect가 아니 다른 View rendering으로 사용할수가 있다. public ActionResult RedirectToBlog() { Models.SitecoreSpace ssnr = new Models.SitecoreSpace(); ssnr.BlogUrl = "https://SitecoreSpace.Blogspot.com"; return Redirect(ssnr.BlogUrl); } } }

   
   
   Model (SitecoreSpace.cs)
   

   1 2 3 4 5 6 7 8 9 10 11 12 13

   using System; namespace SitecoreSpaceNewRoute.Models { public class SitecoreSpace { public string FullBlogName { get; set; } public string BlogUrl { get; set; } public string Subject { get; set; } public string Description { get; set; } public DateTime CurrentDateTime { get; set; } } }

   
   
   View (MyView.cshtml)
   
   

   1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34

   @model SitecoreSpaceNewRoute.Models.SitecoreSpace <!DOCTYPE html> <html> <head> <meta name="viewport" content="width=device-width" /> <title>MyView</title> </head> <body> <div class="form-horizontal"> <h4>SitecoreSpace</h4> <hr /> <div class="col-md-10"> @Html.DisplayTextFor(model => model.Subject) </div> <br /> <div class="col-md-10"> @Html.DisplayTextFor(model => model.FullBlogName) </div> <br /> <div class="col-md-10"> @Html.DisplayTextFor(model => model.Description) </div> <br /> <div class="col-md-10"> 링크: @Html.ActionLink("Sitecore Space Blog", "RedirectToBlog", null, new { target = "_blank" }) </div> <br /> <div class="col-md-10"> 현재시간: @Model.CurrentDateTime.ToString("yyyy-MM-dd h:mm:ss tt") </div> </div> </body> </html>

   
   
   View (RedirectToBlog.cshtml)
   
   

   1 2 3 4 5 6 7 8 9 10 11 12

   <!DOCTYPE html> <html> <head> <meta name="viewport" content="width=device-width" /> <title>RedirectToBlog</title> </head> <body> <div> 추가 extra 페이지 </div> </body> </html>

   
   
   
5. 새로운 패치파일을 만들어 사이트코어 파일시스템의 "/App_config/Include/" 폴더에 z.Sitecore.Space.Route.config을 만든다.
   
   

   1 2 3 4 5 6 7 8 9 10 11

   <?xml version="1.0" encoding="utf-8"?> <configuration xmlns:patch="http://www.sitecore.net/xmlconfig/" xmlns:set="http://www.sitecore.net/xmlconfig/set/"> <sitecore> <pipelines> <initialize> <processor type="SitecoreSpaceNewRoute.CustomRouting.InitializeRoutes, SitecoreSpaceNewRoute" patch:after="processor[@type='Sitecore.Pipelines.Loader.EnsureAnonymousUsers, Sitecore.Kernel']" /> </initialize> </pipelines> </sitecore> </configuration>

이젠 브라우저에서 패치되어진 API 경로를 이동을 해본다.

Sitecore Migration - Data Migration Assistant 사용하기

이전에 포스트 하였던 Sitecore Migration의 두번째로 필자가 경험하였던 문제에 대하여 이야기를 하고자한다.

Sitecore Migration은 사이트코어의 새로운 버전이 나올때마다, 개발자 또는 설계자들은 "어떻게 하면 가장 쉽고 안정적인 방식으로 데이타의 손실없이 Migration을 할수가 있을까?"가 첫번째의 과제이다. 그 다음으로는 기존에 사용하였던 방식 또는 설정들이 얼마나 새로운 버전에서 잘 호환되고 작동되는지를 눈여겨 봐야한다.

이번 포스트는 필자가 생각하는 데이터의 손실없이 가장 손 쉬운 방법으로 Migration하는것에 대하여 알아보도록 하겠다.

먼저, 이전에 사용해보았던, Sitecore Azure ToolKit은 Sitecore Azure Deployment의 목정으로써, Sitecore On-Prem Instance를 Azure Cloud로 Deploy를 할수가 있다. 패키지를 Powershell Script을 통하여 만드는데, 작업 시스템의 환경에 땨라 제한이 있을수 있다. (필자의 경우, 시스템에서 2GB의 패키지 제한이 있어, 기존 데이타를 포함 약 6GB에 해당되는 Sitecore Instance를 패키지하기에는 한계가 있었다.) 이로, 새로운 방법으로 Sitecore에서 추천한 SSMS (SQL Server Management Studio)을 사용하는것이다. SSMS에서 Azure SQL를 컨넥하고, 백업된 DB를 Import하는 방식인데, 이 역시 기존 Master DB의 테이블들을 백업하는데 무리가 있었다.

그래서 결론은 Data Migration Assistant (DMA).

DMA는 Microsoft에서 오피셜로 제공하며, 이는 기존 DB (Source)를 다른 DB (Target)으로 분석 및 검증과 함께 데이타베이스를 Migration할수가 있다. 아래는 필자가 DMA를 사용하여 Sitecore Migration을 한 진행과정을 나열하였다.

1. 로컬머신에 Azure에 존재하는 같은 버전의 Sitecore Instance를 설치한다.
2. SSMS에서 Azure SQL의 Master DB를 컨넥하고, 아래의 Statement를 적용하여 해당 테이블의 데이터를 모두 삭제한다. (반드시, 기존의 데이터는 백업을 미리해둔다.)
   
   

   truncate table AccessControl;
   truncate table Archive;
   truncate table ArchivedFields;
   truncate table ArchivedVersions;
   truncate table ArchivedItems;
   truncate table Blobs;
   truncate table ClientData;
   truncate table Descendants;
   truncate table EventQueue;
   truncate table History;
   truncate table IDTable;
   truncate table Links;
   truncate table Notifications;
   truncate table Properties;
   truncate table PublishQueue;
   truncate table SharedFields;
   truncate table Tasks;
   truncate table UnversionedFields;
   truncate table VersionedFields;
   truncate table WorkflowHistory;
   truncate table Items;
   

3. DBA에서 소스/타켓 데이타베이스를 정하고, Migration을 시작한다.
   
   
   
   
   
   
4. FTP를 통하여 Azure App Service에 연결하고, Custom 어플리케이션 또는 Config 파일들을 매뉴얼로 복사한다. (CMS / CDS if needs)
5. Azure에서 App Service를 Restart한다.
6. Sitecore CMS에 로그인하여 잘 작동(?)되는지 확인한다.
7. Master DB만 Migration을 한 관계로, 혹 Core DB에서 Custom 업데이트가 있다면 사이트코어 CMS에서 패키지를 만들어 인스톨한다.
8. 사이트코어 컨트롤 패널에서 "Clean up Databases"를 실행한다.
9. 사이트코어 컨트롤 패널에서 "Rebuild Link DB"를 실행한다.
10. 사이트코어 컨트롤 패널에서 "Rebuild Indexes"를 실행한다.
11. 사이트코어 컨트롤 패널에서 "Deploy Marketing Definitions"을 실행한다.
12. 사이트코어 컨트롤 패널에서 "Rebuild Link DB"를 실행한다.
13. "Publish the site"를 통하여 Web DB로 컨텐츠를 Publish 한다.

DBA를 통하여 사이트코어 Migration을 하는데 아무런 문제없이 잘 진행될수있었다.

사이트코어 Copy vs Duplicate vs Clone

사이트코어를 사용하다보면 기본의 아이템 (item)과 그의 섭아이템 (subitem)을 복제하여야 하는경우가 많이 있다.
이번에는 사이트코어의 기본 기능중에 복사, 복제, 클론에 대하여 알아보도록 하자.

Copy (복사)

• 선택되어진 아이템 (Source "/sitecore/homepage/source-item-page")과 그의 섭아이템을 다른 경로 (Destination "/sitecore/anotherpage/copied-item-page")로 복사를 한다.
• Source경로에서 복사되어질 아이템의 프리젠테이션 레이아웃 디테일을 복사하고, 복사되어진 새로운 경로의 Datasource 경로는 업데이트 하지 않는다.

Source 경로: /sitecore/homepage/source-item-page/resource folder/body content
Destination 경로: /sitecore/anotherpage/copied-item-page/resource folder/body content

Duplicate (복제)

• 선택되어진 아이템(Source, "/sitecore/homepage/source-item-page")과 그의 섭아이템을 같은 경로(Destination, "/sitecore/homepage/duplicated-item-page")로 복제를 한다.
• Source경로에서 복사되어질 아이템의 프리젠테이션 레이아웃 디테일을 복사하고, 파이널 레이아웃의 Datasource 경로만 업데이트를 한다. Shared Layout의 컨트롤의 Datasource 경로는 변경하지 않는다.
• 복제되어진 아이템을 다른 경로로 이동을 하면 Final Layout의 Datasource 경로도 새로운 경로와 함께 업데이트 된다.

Source 경로: /sitecore/homepage/source-item-page/resource folder/body content
Destination 경로: /sitecore/homepage/duplicated-item-page/resource folder/body content

Clone (클론)

• 선택되어진 아이템(Source, "/sitecore/homepage/source-item-page")과 그의 섭아이템을 다른 경로(Destination, "/sitecore/anotherpage/cloned-item-page")로 복제를 한다.
• Final Layout의 정보를 Reset 한다.

Source 경로: /sitecore/homepage/source-item-page/resource folder/body content
Destination 경로: /sitecore/anotherpage/cloned-item-page/resource folder/body content

사이트코어 심포지엄 - Sitecore Symposium 2018, 올랜도 플리리다

지난 해의 Sitecore Symposium 처럼 이번해에도 Sitecore는 플로리다 올랜도에서 Sitecore Symposium을 개최한다. 이번에도 역시 새로 적용된 기술을 소개할것이고, 조금 더 집중적으로 Cortext/ML/AI 및 Horizon & Zenith (UI/UX)에 관련하여 설명할것으로 예상된다.

현재까지 사이트코어 최신버전 9.0 Update 2이지만, 이번 Symposium 이후, 버전 9.1을 릴리즈 할것으로 예상되며, 새로운 기술뿐만 아니라 Keynote 및 Customer Event를 통하여 참석자들에게 다양한 경험을 제공할것이다. 참고로, 이번에 게스트 스피커로써 헐리우드 배우 윌 스미스 (Will Smith)가 참석한다.

Sitecore Symposium: 2018년 10월 8일 ~ 11일

Location: Walt Disney World Swan & Dolphin Resort, 올랜도 플로리다

Registration: 100불 할인 및 등록하기

Rich Text Editor (RTE)에 YouTube 버튼 추가하기

사이트코어는 Telerik 에디터를 기본 Rich Text Editor (RTE)로 사용하며, Core DB에서 HTML Profile 세팅을 통하여 CMS Author들에게 툴 사용 제한을 둘수가 있다.

최근 회사에서 블로그 페이지 및 툴을 새롭게 만들었으며, 블로그 Author로부터 YouTube 링크를 RTE 디자인 모드에서 추가하고 싶어한다. 이번에는 어떻게 새로운 버턴을 만들고 커맨드를 형성 시키는지 알아보도록하자.

1. Core DB로 이동 후, 새로운 버턴을 추가하고 싶어하는 Tool에서 "__Html Editor Button"의 템플릿으로 새로운 아이템을 추가한다.
   
   
   
   
2. 새로운 아이템의의 속성을 아래와 같이 변경해주며, 아이템 아이콘, 디스플레이 이름도 변경한다.
   
   
   
   
3.  "/WebSite/sitecore/shell/Controls/Rich Text Editor/RichText Commands.js" 파일로 이동 후, 새로운 "RadEditorCommandList"를 추가하고, "Regular Expression"을 통하여, 유튜브 비디오 아이디만을 가져온다.
   
   

   1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27

   RadEditorCommandList["InsertYouTube"] = function (commandName, editor, args) { var d = Telerik.Web.UI.Editor.CommandList._getLinkArgument(editor); Telerik.Web.UI.Editor.CommandList._getDialogArguments(d, "A", editor, "DocumentManager"); // Highlight 되어진 텍스트만 가져온다. var html = editor.getSelectionHtml(); if (getId(html)) { var videoId = getId(html); scEditor = editor; scEditor.pasteHtml('<div class="blog-rte-youtube"><iframe width="560" height="315" src="//www.youtube.com/embed/' + videoId + '" frameborder="0" allow="autoplay; encrypted-media" allowfullscreen></iframe></div>'); } else { // Highlight 되어진 텍스트가 YouTube 아이디와 매치가 되지 않을 경우, 메세지를 보낸다. alert("Please highlight YouTube link URL."); } }; //Get YouTube video ID function getId(url) { var regExp = /^.*(youtu.be\/|v\/|u\/\w\/|embed\/|watch\?v=|\&v=)([^#\&\?]*).*/; var match = url.match(regExp); if (match && match[2].length == 11) { return match[2]; } else { return false; } }

   
   
   
4. Master DB로 이동 후, RichText Editor를 사용하고 페이지에서 Editor Popup을 실행한다.
   
   

YouTube 링크 버턴

Name Value List 타입을 이용하여 데이타소스 만들기

#HowTo #Datasource #GetItem

사이트코어에서 탬플릿을 만들다보면 다양한 템프릿 필드를 선택할수가 있다. 그 중에서 Key와 Value 개념인 "Name Value List" 타입에 대하여 알아보도록 하겠다.

간혹, 데이타소스를 만들는데 있어서, 똑같은 데이타 타입임에도 불구하여, 데이타의 수 만큼 데이타 이이템을 만들어야 하는경우가 있다.

사이트 이름	사이트 URL
구글	http://www.google.com
야후	http://www.yahoo.com
레딧	http://www.reddit.com
사이트코어	http://www.sitecore.com
...	...

이럴경우 사이트 각각의 아이템을 만들 필요없이, 템플릿의 "Name Value List"을 선택함으로로써 하나의 데이타소스 아이템에 여러게의 값을 저장할수가 있다. 프로그래밍에서 Array 또는 List와 똑같은 개념이라고 할수있다.

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26

var db = Sitecore.Configuration.Factory.GetDatabase("master"); // NameValueType의 필드를 가지고 있는 데이타소스 아이템의 ID 값을 입력하다. var item = db.GetItem("{8A8E427B-9162-4680-AE69-239217F5B9AB}"); //데이타를 초기화하고, var data = new NameValueCollection(); // 필요한만큼 데이타를 추가한다. data.Add("name1", "value1"); data.Add("name2", "value2"); data.Add("name3", "value3"); data.Add("name4", "value4"); using (new Sitecore.SecurityModel.SecurityDisabler()) { item.Editing.BeginEdit(); try { //데이타값은 필드 이름을 입력한다. //'&'는 값들의 Divider이다. item["NameList"] = StringUtil.NameValuesToString(data, "&"); } finally { item.Editing.EndEdit(); } }