[Sitecore]使用されていないメディアアイテムを削除
検証環境:Sitecore 9.2.0
概要:
使用されていないメディアアイテムを削除する際に学んだことの心得です。
きっかけ:
私の日本語を忘れないように日本語でサイトコア情報をアメリカのボストンより共有します。
検証環境:Sitecore 9.2.0
概要:
使用されていないメディアアイテムを削除する際に学んだことの心得です。
きっかけ:
検証環境:Sitecore 9.2.0
概要:
概要:
Analyticsのtrackingが動作しなくなった際に行ったトラブルシューティングのメモ書きです。
検証環境:
Sitecore 9.2.0
概要:
サイトコア9.2にアップグレードしてから、ファイルフィールドがインデックスされない問題の
概要:
新しいサーチャーを開く際のエラー “Error opening new searcher” のトラブルシューティングした際に取った、クイックメモです。
サイトコア9に切り替えてから、検索付きマルチリストを使用しているフィールドが表示されなくりましたところがありました。表示されるように修正した手順のクイックメモです。
検証環境はSitecore 9.2.0です。
既存のサイトコア8には検索付きマルチリストを使用しているフィールドが使われています。
サイトコア8にて、問題なく表示されて、検索もできます。
サイトコア9に切り替えてから、検索付きマルチリストを使用しているフィールドが表示されなくりましたところがありました。
それに、すべての検索付きマルチリストを使用しているアテムが表示されなくなったのではなく、一部だけでした。問題となったデーターソースを見ていくなか、_pathを使用しているデーターソースが問題となっていることを気づきました。しかし、パスを確認したところ、コンテンツツリーに存在しており、なぜ検索できないのかをさっぱりでした。
例えば、変更前の設定はこのようになっています:
StartSearchLocation={3D6658D8-A0BF-4E75-B3E2-D050FABCF4E1}&Filter=_path:B805997BC59E49269292C396D1753A89|_path:747D4D7C1A3B468CB58ABE9DB4E51E81|-_template:fe5dd82648c6436db87a7c4210c7413b
_pathを除いたら期待通りの結果を得られます。いろいろとリサーチしていく内に、どうも、_pathが小文字の値を期待していることを判明、_pathをサイトコア9にて小文字へ変更したところ、期待とおり、リストが表示されました。
上記の例で行きますと_pathの値を小文字へ変更:
StartSearchLocation={3d6658d8-a0bf-4e75-b3e2-d050fabcf4e1}&filter=_path:b805997bc59e49269292c396d1753a89|_path:747d4d7c1a3b468cb58abe9db4e51e81|-_template:fe5dd82648c6436db87a7c4210c7413b
原因を分かったところで、スクリプトを作って、Multilist with Searchデーターソースにて_pathを使用しているテキストを小文字に変更し、この問題を解決しました。
もし、同じく、サイトコア9へ切り替えされて際に同じような問題があった場合は、これが参考になれば幸いです。
検証環境は次の通りです。
概要:
よく、お客さんからいろいろなレポートが要求されるので、Sitecore Fast Queryをメインで使っていました。
検証環境は次の通りです。
継続的インテグレーション(CI)を使用することで、アプリケーションに定期的な拡張機能やバグ修正を簡単かつ迅速かつ安全
検証環境は次の通りです。
タイトルのようにサイトコアのアドメインページにて、ジョブビューアのページがあります。
概要:ClayTabletのセットアップの手順まとめ。
[Sitecore][Azure]ゼロから始める
Azureにてサイトコアのサイトセットアップ 2/3 サイトセットアップの編
概要:Azureにてサイトコアのテストサイトをセットアップしてみる手順のまとめ。
検証環境
必要なもの
元気出せ!サイトコアジャパン!
ここでよく使われているいつくかをリストします。
StringUtil.Clip(string text, int length, bool ellipsis)
指定した位置でのテキストをクリップし、指定によって、…省略記号を追加します。
1 2 3 4 |
string s0 = StringUtil.Clip("Hello world", 5, false); // "Hello" string s1 = StringUtil.Clip("Hello world", 5, true); //"He..." |
StringUtil.Capitalize(string text) 最初の文字を大文字にします。
1 2 3 4 |
string text = MainUtil.Capitalize("HELLO WORLD."); // "Hello world" string text = MainUtil.Capitalize("HELLO. HOW ARE YOU?"); // "Hello. how are you?" |
URL関連
EnsurePostfix(char postfix, string value) 文字列が特定のPostfixを持っていることを保証します。
EnsurePrefix(char prefix, string value) 文字列が特定のPrefixを持っていることを保証します。.
RemovePostfix(string prefix, string value) 文字列からPostfixを削除します。
RemovePrefix(char prefix, string value) 文字列からPrefixを削除します。
string.Concat(StringUtil.EnsurePostfix(‘/’, strUrl.Path), StringUtil.RemovePrefix(‘/’, strPath));
その他
RemoveLineFeeds(string text)
text.Replace(“\r”, “”).Replace(“\n”, “”);
GetLastPart(string text, char delimiter, string defaultValue)
文字区切り文字を使用して区切られた文字列テキストの最後の部分を返します。
区切り記号が見つからない場合は既定値を返します。
1 2 |
string.Format("GetLastPart:{0}",Sitecore.StringUtil.GetLastPart("/sitecore/content/Home/test", '/', string.Empty)); "test" |
ExtractParameter(string name, string parameters) クエリ文字列フォーマットされた文字列からパラメータ文字列を抽出します。
1 2 3 4 5 6 7 |
string parameters = "print=1&target=/sitecore/content/home&test=false"; string print = StringUtil.ExtractParameter("print", parameters); // "1" string target = StringUtil.ExtractParameter("target", parameters); // "/sitecore/content/home" string dummy = StringUtil.ExtractParameter("dummy", parameters); // "" |
文字列のサイズを取得します。
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 |
GetSizeString(long size) string str = ""; if (size >= 1024L) { size /= 1024L; str = "KB"; if (size >= 1024L) { size /= 1024L; str = "MB"; if (size >= 1024L) { size /= 1024L; str = "GB"; } } } return size.ToString() + str; IsWhiteSpace(string s) return Regex.IsMatch(s, "^[\\s]*$"); |
文字列を分割し、トリミングのオプション付
1 2 3 4 5 |
Split(string text, char delimiter, bool trim) ArrayList list1 = StringUtil.Split("Hello | world", '|', true); /// "Hello", "world" ArrayList list2 = StringUtil.Split("Hello | world", '|', false); /// "Hello ", " world" |
文字列を均等なサイズにカットします。CutUp(string text, int chunkSize)
1 2 3 4 5 6 7 |
CutUp(string text, int chunkSize) string text = "Hello world"; ArrayList list = StringUtil.Cut(test, 3); // "Hel", "llo", " wo", "rld" string text = "ABCDEFGHIGKLMNOPQRSTUVWXYZ"; ArrayList list = StringUtil.Cut(test, 1); //"A", "B", "C",…. |
サイトの構築の際にコールアウトがよく使われます。
特定のページに同じコールアウトのサブレイアウトを使用し、データソースを変えたりするにはSitecoreのルールエンジンおよびコンディションによってレンダリング レンダリングのデータソースを設定したりします。ただ実際にこのルールエンジンを使うお客さんこれまでの作業でそれほど多くない。
よく、お客さんから、デフォルトのコールアウトを設定しれくれという要求があります。たとえば、サービスーというサイトコアのフォルトがあり、その下数重レベルのサブアイテムフォルダがあって、さらにその下に数千のアイテムがあります。スタンダード値にてデフォルトのデータソースを設定する方法もありますが、もし、既存アイテムにデーターソースがない場合は、もっとも近いアンセスターのアイテムのデーターソースを使用という方法があります。もし、近いアンセスターがデーターソースが設定されていないなら、ツリーを従って上の方へ繰り返しでデーターソースを探します。
コールアウトのデータソースの取得もGoogleで検索を書けば下記のように簡単に取得することができます。
1 2 3 4 5 |
Sublayout sublayout = this.Parent as Sublayout; if (sublayout != null) { Item item = Sitecore.Context.Database.GetItem(sublayout.DataSource); } |
ただ、レンダリングにてデーターソースを取得する記事があまり見つからなかったので、それをついて書いてみようと思った。
まず、下準備します。
1.三つのページと三つのコールアウトを用意します。
2.それぞれのページにそれぞれのデータソースを指定します。
3.ページを表示します。
ここで、もし、Levle3のデーターソースを削除します。
Level3のページにて、コールアウトが最も近いアンセスターがデーターソースが設定されているかどうかを確認し、この場合Level2にてデータースースが設定されているので、それを使用します。
もし、Level2もデーターソースが設定されていない場合、
Level3のページにて、コールアウトが最も近いアンセスターがデーターソースが設定されていないので、引き続き上のアイテムを確認し、
この場合Level1にてデータースースが設定されているので、それを使用します。
さて、コードを見てみましょう。
Callout.ascx
1 2 3 4 5 6 7 8 9 10 11 12 13 |
<%@ Control Language="c#" AutoEventWireup="true" TargetSchema="http://schemas.microsoft.com/intellisense/ie5" Inherits="local.sandbox.com.callout.CalloutSublayout" CodeBehind="Callout.ascx.cs" %> <%@ Register TagPrefix="sc" Namespace="Sitecore.Web.UI.WebControls" Assembly="Sitecore.Kernel" %> <asp:Panel ID="pnlCallout" runat="server" CssClass="callout"> <div class="reg-callout"> <h4> <sc:text id="scTitle" runat="server" field="Callout Title" /> </h4> <sc:text id="scCopy" runat="server" field="Callout Copy" /> <sc:link id="scLink" runat="server" field="Callout Link" /> </div> </asp:Panel> |
Callout.ascx.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 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 |
using System; using System.Linq; using System.Collections.Generic; using Sitecore.Data.Items; namespace local.sandbox.com.callout { public partial class CalloutSublayout : System.Web.UI.UserControl { private void Page_Load(object sender, EventArgs e) { BindControls(); } private void BindControls() { Item contextItem = Sitecore.Context.Item; Item dataSource = GetDataSourceWithLookUp(); if (contextItem != null && dataSource != null) { scTitle.Item = dataSource; scCopy.Item = dataSource; scLink.Item = dataSource; } } private Item GetDataSourceWithLookUp() { Item returnVal = GetDatasourceItem(Sitecore.Context.Item); if (returnVal == null) { List<Item> ancestors = Sitecore.Context.Item.Axes.GetAncestors().Where(a => a.TemplateName.Equals("YOUR Template Name Here")).Reverse().ToList(); foreach (Item ancestor in ancestors) { returnVal = GetDatasourceItem(ancestor); if(returnVal != null) break; } } return returnVal; } private Item GetDatasourceItem(Item item) { Item returnVal = null; item.Visualization.GetRenderings(Sitecore.Context.Device, false).ToList().ForEach(r => { if (r.RenderingItem.InnerItem.TemplateName.ToLower().Equals("sublayout") && r.RenderingItem.InnerItem.Name.Equals("Callout")) { if (!string.IsNullOrEmpty(r.Settings.DataSource)) { returnVal = Sitecore.Context.Database.GetItem(r.Settings.DataSource); } } }); return returnVal; } } } |
よくお客さんの要求で、既存のHTMLページを表示されたいという要求があります。
たとえば、下記のサンプルのHTMLページがあります。
お客さんがHTMLのページをメディアライブラリにてファイルとして追加します。
そして、コンテントにてリンクとして追加します。ただ、リンクをクリックすると、ページが表示される代わりにダウンロードされてします。
これはダウンロードせず、ページを表示させるようにする設定のメモ書きです。
Web.ConfigのmediaTypeをみれはforceDownloadという設定があります。
これをFalseに設定すればダウンロードせず、ページが表示されます。
HTMLだけではなく、PDFやイメージなどメディアタイプによって設定すればいいです。
今回の場合は”htm,html”の設定をすればいい。
1. /app_config/mimeType.xmlにて下記の設定を更新。
1 2 3 4 |
<mediaType extensions="htm,html,stm"> <mimeType>text/html</mimeType> <forceDownload>false</forceDownload> </mediaType> |
2./app_data/mediaCache にて、キャッシングをクリアします。
再度リンクをクリックすれば、ダウンロードせず、ページが表示されます。
もし特定なメディアタイプの設定をコードでしたいなら、MediaRequestHandler をカスタマイズすればいい。ここにサンプルコードがあります。
パブリッシュモード
1. インクリメンタルパブリッシュ(PublishMode.Incremental)
速度:
ロジック:パブリッシング·キューからターゲットのデーターベースへパブリッシュ
メモ:CMSユーザー·インタフェースをにて行った変更やコードでの変更なが発生する倍、その変更がパブリッシング·キューへ追加されます。ワークフローに関連付けられたアイテムが最終的なワークフローの状態に到達したときにそれらが発行キューに追加される。インクリメンタルパブリッシュはターゲットのデーターバースへ適切なバージョンをコピーします。SQLのdbo.PublishQueueテーブルにてまた、サイトコアロックを使っている場合はツール→パブリッシング→パブリッシング·キューにて一覧を見れます。
2. スマートパブリッシュ(PublishMode.Smart)
速度:
ロジック:マースターデーターベースとターゲットのデーターベースの比較
メモ:マースターデーターベースとターゲットのデーターベースの比較して、変更したアイテムのみパブリッシュします。Sitecoreのアイテムは、内部リビジョン識別子があります。アイテムに変更があった場合、それは更新され、スマートパブリッシュはこの内部リビジョン識別子を比較して、変更したアイテムのみパブリッシュ
3. りパブリッシュ(Publish.Full)
速度:
ロジック:マースターデーターベースからターゲットのデーターベースへと比較せず、パブリッシュします。ターゲット·データベース内のすべてのアイテムが上書きされます。
メモ:マースターデーターベースからターゲットのデーターベースへと比較せず、パブリッシュするので一番時間が掛かります。.マスターデータベースのバックアップからの復元や、通常のパブリッシュが正常に終了しない場合使います。
知ると便利なツール: アドバンスパブリッシュダイアログ, また [詳細とビデオデモ(英語)]
多数の編集者が同時に作業をする際によくパブリッシュが途中で止まってしますことがあります。Apppoolのリセットをしたりしざるえない時があります。その際にこのアドバンスパブリッシュダイアログが便利です。実行中のパブリッシュのタスクをキャンセルすることができます。
余談ですが、この前これをみて、サイトコア7.2から関連するアイテムをパブリッシュのオプションがあります。
手元の二つのプロジェクトはいまだに6.6ですので、この機能は待つ扱えないけど、これはサイトコアロックのアイテムと依存するアイテムのパブリッシュと同じ機能かどうはは不明です。時間を探して、両方を比較してみたいです。
いずれにせよ、これまでの経験からこの機能は本当に便利だと思うのは下記ケースです。
1. 例えばアイテムに関連付けられていたもの、(レイアウト、sublayouts、テンプレート)をパブリッシュするのを忘れてもかまいません。
2.イベントの使用で例えばOnsaveイベントで関連するアイテムを事前パブリッシュしなくでもよい。
3.インポートの作業で、関連されている、リフェレンスアイテムを事前パブリッシュしなくでもよい。
これをBRタグにけるには下記の設定をweb.config にて変更すればいい
初期設定:
<setting name="HtmlEditor.LineBreak" value="p" />
BRタグへの変更:
<setting name="HtmlEditor.LineBreak" value="br" />
*初期設定を変えずにBRタグを使いたい時は”Shift+改行”を使えばいいです。
一般的なもの
開発系ソフト
ReSharper (
今後新人の方にこの基本の基本であるサポートのチケットを開く際に心得を書き留めたい。
現在サイトコアのサポートは基本的に同じ日に返答をしてくれます。三年前にアメリカのオフェスにはAlexさんだけだった時、返答が二日がかかるのは普通だった。それでも、いかに問題と必要とされる情報を一発でサイトコアのサポートの方に届くのが大事です。
問題を詳しく説明する。
大学時代読んだ本で品質管理にて問題を報告する時3Wのフォーマットが有効だと覚えています。
What I saw,(見た問題)
What I did, (問題発生手順)
What I expected to see. (期待する結果)
例を挙げると:
問題:
弊社のCMサーバにて複数のユーザーがログインすると下記のエラーが発生しています。
例を挙げれば、サポーターの高志君がアイテムを更新し、お客さんに確認をするようにお願いする。お客さんの浩様が誤ってアイテムをパブリッシュする。ただ、コードの変更がまた更新していないのでサイトにてエラーとなった。浩様が自分がパブリッシュしたことも覚えていないので、もしかして、最終の更新者である高志君がサイトを壊したのではと思い始める。
誰があるアイテムをパブリシュを探すにはログファイルをみることです。 アイテムを検索すれば、最後に誰かパブリシュしたのは一目瞭然です。
ログファイルを見るには、サイトコアのログビューアーにてみればいいです。
もしサーバへのアクセスがあれが、だーターフォルダにあるログファイルフォルダにてログファイルをみればいい
1.テンプレートを追加します。
テンプレートを挿入したいフォルダにて右クリックで ”新しいテンプレート”をすれが、 ウィザードに従ってアイテムを作成すればいいです。今回SEOのテンプレートを例に作ってましょう。
番外編:
新人にメニュが切れているけどといわれてことがある。 れはIEの設定をしていないから。sdn.sitecore.netにて、IEの設定にて設定をすればいい。
2.SEOアイテムを作ったけど次はなに?
私は最初にするのはスタンダードバリューを作ることです。なぜなら、 サポートのタスクで、サイトを半年以上運営していたサイトでお客さんから 新しいフィールドを追加したいと。テンプレートをみるとスタンダードバリュー が設定していなかった。本当にテンプレートのスタンダードバリューで追加 すればいいの仕事が、結局コードでアイテムを更新するまでという手間が かかったタスクだった。このスタンダードバリューはアイテムの初期値のようなのものです。このスタンダードバリューにてフィールドだけではなく、プレゼンテーション、挿入オプション、セキュリティの設定ができるので非常 に便利です。さて、スタンダードバリューを追加しましょう。
3.わかりやすいようにアイコンを付けましょう。
お客さんに分かりやすいように、それぞれのアイテムに独自のアイコンを付けましょう。
スタンダードバリューのアイコンも更新しましょう。
一般的な開発環境との流れ
ソース管理およびデプロイメントツールについて
私が知っている限りでは、どのサイトコアを開発する会社にもサブバージョンまた、なんらかのデプロイメントツールを使っています。私がこれまでに実際に使ってきたツールを下記のように書き留めます。これ以外にほかのツールも沢山あると思います。このリストの比較はただ私自身が感じたものです。
1. TFS(Team Foundation Server ) これを最初に書くというのは私はTFSに関してそれほど経験がないです。お客さんのプロジェクトで約三ヶ月間使っていましたが、ほかのサブバージョンと比べてそれほど優れていると感じていなかった。自分で設定をしたことがないので何もいえないですが、客先でこのTFSを運営するチームまでいたということは気楽に設定して運営できるものでないと思います。”それはちょっと面倒だなぁ”と思ったこは、コードを編集する際に一々チェックアウトをしないといけない。それに編集はVSで行わないといけない。20,30のプロジェクトを含むソリューションを5分も待って開いてWeb.Configで一行の編集を行うのはあまり好きではない。
2.Teamcity CI(Continuous Integration) これは私のお気に入りのツールです。特に小さいなチームでの共同開発で効率をアップします。セットアップも簡単。私はTeamcityをダウンロードして、Development、QA、Stagingの三つの環境をセットアップするには一日もかからなかった。三つのサーバはすべて社内のサーバだったのでそれぞれのサーバへリモートして設定を簡単に変更ができたこともありますが、一つの環境が設定が出来てその設定を流用することができます。また、GoogleでTeamcityに関してのページが沢山あることも参考になれます。 基本的にソリューションファイルをもとに、それぞれの環境設定ファイルを基づいてコンパイルし、ターゲットの環境へコードをデブロイします。Teamcityを導入するまで、もし誰かがエラーを含むコードをチェックインし、他のメーバーがチェックアウトしたらみんなコンパイルができずいらいらしていました。SVNでその”犯人”を探そうとしたものです。Teamcityは誰からチェックインしてから、設定によってすぐにコンパイルをします。もしコンパイルが失敗すれば、すべてのメーバーにメールなりSMSなり、最新バージョンのコードに問題があるので、チェックアウトしないようにと知らせます。これは案外時間を節約します。それに、それぞれの環境へのデブロイメントをスケジュールで設定し、ネットワークの空いている夜で行ったりすることもできます。
3.Team Development for Sitecore (TDS) Teamcityを使用しサイトコアを開発する際にみんなそれぞれの環境において、データベースを共有することを前提としています。時にはすべての開発メーバーが同じデータベースへのアクセスがない場合があります。例えばデータベースサーバが社内のアクセスのみと設定され、いざ自宅で作業をしようと思ったら、その日に行ったサイトコアの変更は社内で他のメンバーの変更と同期をとれなくなります。サイトコアの変更を書き出して、サイトコアのパーケージを作るか、データベースの同期ツールを走らせるかで同期を取ります。TDSを使えばサイトコアの変更をサブバージョンで管理ができるので、サブバージョンへのアクセスさえあればみんなの変更の同期を取れるわけです。TDSを半年ぐらい使用してきて、私にとってこれはサイトコアの共同開発で一番便利なツールだと思っています。後ほど、私が日々使っている環境設定を書きます。
環境別のデプロイメントについて
基本的にローカル→ディヴェロップメント→品質保証までは社内向けでオートデブロイメントを使用する場合が多い。TDSを使ってすべての変更がサブバージョンで管理されているので、ターゲットの環境でチェックアウトをし、デブロイメントをすればいいです。品質保証からステージングまたブロダクションへのデブロイメントは手動で行う場合がほとんどです。特に品質保証からステージングへは、ブロダクションへのデブロイメントを想定し、できるだけ同じ手順でデブロイメントをします。また、多くの場合はお客さんがすでにステージングにてコンテントを入力されているわけで、それを上書きされないようにとの考慮をしなければなりません。次回はTDSを使ったそれぞれの環境へのデブロイメントを書きたいと思います。