[Sitecore][ツール]リンク切れチェックツールレポートのエクスポート

概要: Sitecore のツールのうち、サイト内のリンク切れをチェックすることができるリンク切れチェックツールがあります。これはそのレポートをエクセルへ保存する方法のメモ書きです。 背景: サイトのアップグレードや、コンテンツのインポート、また、スクリプトを使って既存のアイテムのクリーニングされる際に、リンク切れの警告がなく、リンク切れを発生することがあります。その際によく使われているのはこのリンク切れチェックレポートです。 *このツールの使い方はサイトコアのYoutube公式サイトにありますのでそちらを参考してください:リンク切れチェックツール 問題: サイト内のリンク切れをチェックをしてから、その結果が表示されます。しかし、その結果をエクスポートする機能がありません。 サイトコアPowerShell Extensions にあるShow-ListViewのエクスポートパーネルが有ってほしいところです。 サイトコアPowerShell Extensionsを使って、独自のリンク切れチェックツールを作ればいいじゃないのと思いました。 ネットで検索をすれば、SPEでリンク切れチェックツールがたくさんあります。メインで、アイテムのリンク切れか、もしくはアイテムのリファレンスがあるかどうかをチェックしています: $linkDb = [Sitecore.Globals]::LinkDatabase; if($linkDb.GetReferrerCount($item) -gt 0) しかし、サイトコアのバージョンによって、リンク切れチェックツールがこれ以外のチェックもしています。それについて、また別の機会で書きます。私の場合はサイトコアのバージョン8の際に、RTEフィールドにあるリファレンスはGUIDではなく、サイトコアのパスや、URLでリファレンスしているので、リンク切れが検索されなかった。 本題に戻り、この表示された結果をエクセルにてエクスポートするにはどうすればいいのかを話します。 一番よくつかわれているブラウザはChromeで、普通に思うなら、表示された結果で右クリックですべてを選択して、テキストへ貼り付けたいところ、 それは レポートの長さによって、ってしました。 そこで、FireFoxを代わりに使用すれば、すべてを選択し、コピーするのができます。 コピーした内容をテキストエディタに貼り付け、しして、tabをコンマを入れ替えます。 また、余分なスペースも削除し、csvとして保存します。 保存されたcsvファイルをエクセルに開けば、フィールタ利用してさらに見たい情報を簡単に探せます。 独自のPowerShellを使ってレポートをするには、ターゲットの環境へインストールする必要があります。また、スクリプトをそれぞれの環境にてある程度テストしなければなりません。 このツールはサイトコアのデフォルトツールなので、開発者でく手軽に使えますので、お勧めします。

[Sitecore][ツール]コードスニペットマネージャー

概要:サイトコアの開発に限らず、一般的にあなたのベストコードスニペットマネージャーってどれですか?今回私の一番お気に入りのコードスニペットを管理するツールを書いてみたいと思います。 要求:*開発者によって要求の順番が違いますが、私としては、下記の順番で:  1. 素早く検索 2. コードスニペットはよく使う言語のカラー表示をサポートする 3. コードだけではなく、画像、動画の管理も可能 4. テキストに限らず、画像、動画、ファイルの管理も可能   => フローチャート、環境設定   => ビデオでファイル   => PDF, Word   => サイトコアのパーケージやアップグレードパーケージ 5. ローカールの保存ではなく、どこでもアクセル可能 メモ:これまでに下記のコードエディターを使って来ましたが。   ■Visual Studio Code   ■ Notepad++   ■ Lepton   ■ Sublime Text   ■ Atom   ■ Brackets   ■ TextMate Visual Studio Code と Notepad++は、両方とも素早くテキストの検索ができます。ファイルやディレクトリ検索は素早くできます。よく使う言語のカラー表示をサポートします。Leptonは多言語対応の上で共有しやすいのでよく使っています。 しかし、これらはあくまでもコード管理に限って、画像や動画、ファイルの管理が難しい。そこで、これまでにこれらのコードエディターを並行して使用してきたのはOnenoteです。 なぜ、OneNoteなのか、チェックリスト ✔素早く検索、ディフォルトの検索が大変便利。多言語検索対応 さらに、絞り込んだ検索が可能: 例えば、カテゴリーごどに、ノートブックを作成して、絞った検索で手早く検索したい内容をヒット。下記の例では、SPEのノードブックにみ、検索をかけ、素早く再利用するコードを確定します。 ✔コードスニペットはよく使う言語のカラー表示をサポートする それぞれにプログラミング言語をサポートするプラグインもありますが、それを使用せずに、既存の貼り付けでも十分です。私はようく、Visual Studio Codeの言語ごとカラー表示を使います。 例えば、Visual Studio Code […]

[Sitecore][solrインデックス]ファイルフィールドがインデックスされない

概要: サイトコア9.2にアップグレードしてから、ファイルフィールドがインデックスされない問題のトラブルシューティングについてのクイックメモです。 ——————————————————————————————— 検証環境は次の通りです。 Sitecore 9.2.0 [space size=”10″] 問題 サイトコア9.2にアップグレード,PDFファイルをダウンロードするリンクが表示されなくなりました。テンプレートをみるには、サイトコアのファイルフィールドを使用し、PDFのファイルを指定し、ダウンロードするようになっています。 [space size=”10″] [space size=”10″] SolrAdminにてこの”Download PDF”ファイルをスキーマにて確認したところ、存在していないことをわかりました。 コードをみたところ、フィールドを追加する設定がちゃんと有りますし、 <fieldNames hint=”raw:AddFieldByFieldName”> <field fieldName=”download pdf” returnType=”string” emptyString=”emptyval” /> [space size=”10″] ”Raw values”にてフィールドの値を見るには、上記の設定で、テキストそしてインデックスされるはずです。 どこがの設定が間違っているのかなぁ戸惑ったところで、ディフォルトのサイトコア9.2にてどのようなの動作しているのかを比べればいいのではと思いました。  [space size=”10″] サンプルをアイテムのテンプレートにてテスト用のファイルフィールドを追加し、   [space size=”10″] テスト用の値を設定して、  [space size=”10″] ”Populate Solr Managed Schema” を使って、マスターデータベースのスキーマを更新してから、マスターデータベースを再構築して、そして、Solrのサービスを再起動します。これで、TestFileがスキーマに追加されることを期待してながら、SolrAdminにて確認したところ、やはり追加されていない。  [space size=”10″] 以前のサイトコアのバージョンで別のお客さんのサイトサーチする際に、PDFのファイルの内容をテキストとしてインデックスする作業があったことを思い出して、カスタムPDFのファイルリーダーが必要なのかなぁと思った。ディフォルトのサイトコア9.2にて、ファイルリーダーの設定を見ると、ディフォルトのファイルたタイプはSitecore.ContentSearch.FieldReaders.NullFieldReader, Sitecore.ContentSearchを使用しています。これじゃスキーマに追加されていないのもおかしくないです。     [space size=”10″] フィールタイプがファイルの場合はディフォルトのSitecore.ContentSearch.FieldReaders.DefaultFieldReaderを使うように変更して、”Populate Solr Managed Schema” を使って、マスターデータベースのスキーマを更新してから、マスターデータベースを再構築して、そして、Solrのサービスを再起動します。  [space […]

[Sitecore][クイックメモ]Solr 新しいサーチャーを開く際のエラー

概要: 新しいサーチャーを開く際のエラー “Error opening new searcher” のトラブルシューティングした際に取った、クイックメモです。  ——————————————————————————————— 検証環境は次の通りです。 Sitecore 9.2.0 [space size=”20″] きっかけ 今の会社では3年目で新しいPCを渡されることになっています。 先月新しいPCをもらって、サイトコア9.2の開発環境を整えっていました。しかし、昨日突然ローカルのサイトが立ち上がらなくなりました。 サイト名を変更すれば立ち上がりますがどこかでキャシューされています。社内のサポートに連絡すると、どうも、私のプロフィールに問題があり、システムリセットを勧められていました。 サイトコア9.2の開発環境を整えっていた時点でシステムリセットを作成していたので、助かったと思った。システムリセットし、ローカルのサイトも問題なく立ち上がり、ほっとした途端にサーチが動いていないことに気づいた。 [space size=”20″] 原因を探す サーチが動作しないですからきっとインデックスかなぁお持って、インディーズを再構築をしようとしました。しかし、インデックスを再構築しようとすると、いくつかのインデックスがなっています [space size=”20″] SC9のディフォルト設定と比較して、問題を持つかりませんでした。Showconfigで設定を見るにも、問題なし、Solrかなぁ思ってみてみるとやはり見たことのないエラーが問題となっているインディーズで発生しています  [space size=”10″] ”Error opening new searcher”とありますので、これはGoogleすれば、きっと参考になる記事が一杯だろうと思い、いろいろとサーチすると、どうも、インデックスディレクトリにwrite.lockファイルが問題のようです。 考えられるのはシステムリセット一部のインデックスのみ影響を与えたのかなぁ思った。  [space size=”20″] 直す 下記の手順で修正を行いました。 1.まず、Slorサービスを止める。 2.Solrのインデックスフォルダへ行き、問題があるインデックスのフォルダへいき、すべてのファイルの削除。   例えば、C:\Program Files\solr-7.5.0\server\solr\neb_local_sitecore_web_index\data\index   [space size=”10″] 3.Slorサービスを起動し、SolrAdminにて、エラーがなくなったことを確認。   [space size=”10″] 4.サイトをアプリケーションリサイクルを実行します。   [space size=”10″] 5.再度インデックスマネージャーを立ち上がりると、亡くなっていたインデックスが表示されました。   [space size=”10″] 6.インデックスの再構築を行います。

[Sitecore][クイックメモ]Multilist with Searchフィールドのデーターソース設定メモ

概要: サイトコア9に切り替えてから、検索付きマルチリストを使用しているフィールドが表示されなくりましたところがありました。表示されるように修正した手順のクイックメモです。[space size=”10″] 検証環境はSitecore 9.2.0です。 [space size=”10″] 既存のサイトコア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][Script]素早くサイトファイルをバックアップ

概要: 日々ウィブサイトがAzureへ移行している日々、従来各自のサーバーにて使うお客さんもいます。 サーバーの数によって、デプロイメントする際にウェブサイトをバックアップするのは一般的です。 バックアップに関するツールはたくさんありますが、簡単なバックアップスクリプトをメモ書きとして書きます。 [space size=”10″] きっかけ: デプロイメントをする方がいちいち、ターゲットサーバーへ行き、日付を使ってバックアップのフォルダを作成します。 そして、Websiteフォルダを手動でコピーします。その際に、App_dataとtempフォルダを除きます。 この手順をそれぞれのサーバーで行います。それを見て、PowershellのScriptを書いて、 クリックするだけでやればいいじゃないの聞いたら、スクリプトを書いてくれとといわれた。 [space size=”10″] スクリプト: $src = Read-Host -Prompt ‘ソースパスを入力してください:(ディフォルト:C:\inetpub\wwwroot\Sitecore\Website\)’ $dst = Read-Host -Prompt ‘バックアップされるドライブを入力してください:(ディフォルトは:D:\)’ #ディフォルトのソースパスを設定 if($null -eq $src) { $src = “C:\inetpub\wwwroot\SC9.local\Website\xsl\system\WebEdit”; } #今日の日付を使ってバックアップフォルダを作成 $today = get-date -f yyyy-MM-dd; if($null -eq $dst) { $dst += [string]::Format(“D:\{0}_backup\”,$today); } else { $dst += [string]::Format(“:\{0}_backup\”,$today); } Write-Host “`r`n […]

[Sitecore][TIPs]素早くアイテムIDを探す。

概要: テンプレートにてリストフィールドがよく使われています。 [space size=”10″] 例えば、製品のカタログなどではれば、リストが何百以上なったりするのは普通です。 開発中またトラブルシューティングにて特定な選択されているアイテムを探すのが場合によって時間がかかります。 今回、案外知られていない簡単かつ早く選択さてているアイテムを特定するここを紹介します。 [space size=”10″] 選択されているアイテムを探すには、よく表示されている選択したアイテム名を使うのが一般的です。 [space size=”10″] ただ、製品のカタログのような、アイテム名が長い場合、また、似たような製品名などを検索をすると、 検索結果一覧がかなりな長くなったり、また検索時間もかかります。 [space size=”20″] 次によく使われている検索方法はGUIDを表示し、GUIDを使って検索し、確実ターゲットを見つけます。 [space size=”20″] ただ、サイトの大きさによって、またネットワークの速度によって、画面切り替えそのものに時間がかかることがよくあります。RAW Value表示されてから、アイテムテンプレートによって、何百のフィードがある場合、フィードを先に検索しなければなりません。それがまた時間がかかります。 [space size=”20″] ここで案外使われていないテクニックが chrome DevTools です。 検索したいアイテムを選択し、右クリックで、Inspectをすれば、GUIDを素早くコピーすることができます。 [space size=”25″] 簡単なことですけど、これで、画面のリロードやフィード検索を待つ時間を節約することができ、もっと、スムーズに 快く開発ができます。😎

[Sitecore][SPE] SPE 使って、素早くアイテムを削除

検証環境は次の通りです。 Sitecore Experience Platform 9.0 rev. 180604 (9.0 Update-2) Sitecore PowerShell Extensions 5.0 [space size=”20″] 概要: ローカルの環境にて開発中、時にはデバッグでコードをステップしてい行くことがよくあります。 ただ、もし、コンテンツにあまりにもたくさんのアイテムがある場合はこの作業が時間がかかります。 特に製品のカタログのような、万以上のアイテムがある場合は、たくさんのアイテムをSPEを使って いかに早く削除するメモ書きです。 [space size=”10″] よく使われているのは下記の三つです。 [space size=”10″] 1.SQLデーターベースクエリ http://sitecoreexperiences.blogspot.com/2017/11/deleting-sitecore-items-in-sql-proceed.html これは同僚の先輩が書いたクエリです。直接データーベースにてアイテムを削除するので早いです。これは私はプロダクションの環境にて使用することを極めて勧めません。ローカルの環境でディバグの際に便利です。基本的にデータベース内のアイテムデータを直接操作することはお勧めできません。これは走る前にバックアップを取りましょう。また完了後、リンクデータベースの再構築をしましょう。 [space size=”10″] 2.アドメインツールのデーターベースブラウザー http://sc902.local/sitecore/admin/dbbrowser.aspx これは、コンテントエディタトラベルと早です。ただ、同じく直接データーベースにてアイテムを削除するので使用する際に要注意です。同じく、走る前にバックアップを取りましょう。また完了後、リンクデータベースの再構築をしましょう。 [space size=”10″] 3.SPE [space size=”10″] SPEにてアイテムを削除を簡単にできます。使用するコードによって速度も多少違ってきます。 [space size=”10″] テストで2000のサブアイテムを削除します。91秒かかります。 [space size=”10″] コード:[space size=”10″] Measure-Command { $items = Get-ChildItem -Path “master:/sitecore/content/Home/TestB” -Recurse | Where-Object […]

[Sitecore][MongoDB] MongoDBサーバーが利用できない場合のSitecore サイトがフリーズしてしまう。

概要: つい最近、MongoDBサーバーが利用できない場合にSitecore サイトがフリーズしてしてしまったことがあった。 その際に習ったことを共有したいです。[space size=”10″] まず、下記のKB記事にてこれまでに出会った問題がすべてカバーしてきましたが、 MongoDBサーバーが利用できない場合のSitecore XPの動作 https://kb.sitecore.net/articles/930657 特に、この提供されているパッチが一番有効でした。 [space size=”10″] 私が出会ったエラーはサイトがロードし続き何も更新されないもんだだった。 サイトコアのログをみるとと、タイムアウトとあり、てっきり MongoDBサーバーがダウンかと思いました。[space size=”5″] [space size=”10″] MongoDBサーバーをみると特にエラーなどがなく、サービス自体も走っています。[space size=”5″] [space size=”10″] 次にサイトコアのサイトを走っているサーバーのIIS ログを見る限り、サイトがフリーズではなく、リクエストを通常に受け取り、 ただ、タイムアウトされているのでプロセスができていない状態です。[space size=”10″] これだとやはり、MongoDBサーバーに問題があるのではと思い、最後MongoDBサーバーにていろいろとトラブルシューティングを試していました。その際にRoboMongoを使ってローカルのMongoDBサーバーへの接続ができなかった。 パブリックのサイトなのでこれ以上待つことができなかったので、MongoDBサーバーを再起動し、問題を解決しました。 [space size=”10″] さてなんでMongoDBサービスがはしっているので、リクエストをプロセスしないのか、また、なぜ、RoboMongoを 使って接続できないのかがを知りたかった。いろいろと検索したろころで、MongoDB のドキュメントにて https://docs.mongodb.com/manual/core/index-creation/[space size=”10″] [space size=”10″] デフォルトのせていにて、インデックスが実行されている間で、データベースへのすべての操作がブロックされるとありました。 さらに、MongoDBのログをみる、インデックスが実行されていたことが判明。。。[space size=”10″] また、MongoDBが再起動する際にインデックスが環境されていないことも確認を取った。 [space size=”10″] 発生原因を突き詰めたところで解決策としてどうすればいいかサイトコアサポートへ連絡しました。 勧められたのはMongoDB のドキュメントにあるバックグラウンドで実行する設定でした。 [space size=”5″]  xDB Migration Toolにてインデックスをバックグラウンドで実行すれば、MongoDBサービスが通常に動作することを確認しました。[space size=”10″]