SharePoint Designer によるページ カスタマイズを理解する

  • Article

こんにちは SharePoint サポートの森　健吾 (kenmori) です。

 2019.2.22 追記 : SharePoint Designer は、現在の SharePoint Online ならびに SharePoint Server 2019 において非推奨とされました。

タイトル : SharePoint Server 2019 で非推奨になった機能と削除された機能
アドレス : https://docs.microsoft.com/ja-jp/sharepoint/what-s-new/what-s-deprecated-or-removed-from-sharepoint-server-2019

タイトル : SharePoint Online ポータル ブランド化ガイダンス
アドレス : https://docs.microsoft.com/ja-jp/sharepoint/dev/solution-guidance/portal-branding

 

今回の投稿では、SharePoint Server におけるページについて理解した上で、SharePoint Designer (以下 SPD) を使用して標準のマスタ ページや、ASPX ページをカスタマイズした際の動きを説明します。

SPD は、FrontPage から派生した SharePoint 専用のページ編集ツールとして活躍してきた背景があります。その他にも、ワークフロー、外部コンテンツ タイプなど様々なカスタマイズが実施できるツールとして規模拡張してきました。
ただし、SPD 2013 ではデザイン ビューが削除され、ページ編集ツールとしては規模縮小してきている感覚もうかがえます。

今回の投稿では、このツールが実施していることを理解し、注意点等をあらかじめ確認できるようにしていきたいと考えています。

参考情報 : ダウンロード サイト

SPD は以下のダウンロード サイトから無料でダウンロードできます。製品バージョンと同じ SPD を入手して使用ください。また、最新の修正プログラムについても確認し、合わせて適用ください。

タイトル : SharePoint Designer 2013
アドレス : https://www.microsoft.com/ja-jp/download/details.aspx?id=35491

タイトル : Microsoft SharePoint Designer 2010 (32 ビット版)
アドレス : https://www.microsoft.com/ja-jp/download/details.aspx?id=16573

タイトル : Microsoft SharePoint Designer 2010 (64 ビット版)
アドレス : https://www.microsoft.com/ja-jp/download/details.aspx?id=24309

SPD は、Office ファミリーの製品となりますため、SharePoint Foundation サポートや Office 共通コンポーネントなどのモジュールがインストールされます。

クライアント PC にインストールする際に、異なるバージョンの Office と同一環境にインストールする際 (例. Office 2010 + SharePoint Designer 2013) には、コンポーネント間におけるバージョン差異により、細かな機能の動作に影響を及ぼす可能性も想定されます。この点につきましてもあらかじめご確認ください。

 

1.   SharePoint における標準のページについて

SharePoint 標準のページには、Web パーツ ページ、Wiki ページ、発行ページなどがあります。

ユーザーは[サイトの操作] – [ページの編集] (または [*] – [ページの編集] ) をクリックしてページを編集することができます。
SharePoint におけるページはページ上に配置された表示コントロールが動的に別途格納されたデータを参照して、表示を構成する動作となります。つまり、ページをカスタマイズしても標準ではテキスト
ファイルで保存されている ASPX ページの定義を直接書き変えない構造となります。

・Web パーツ ページは、コンテンツ DB 内 WebParts テーブル内に Web パーツの各種プロパティ情報をもとにページを構成します。
・Wiki ページは、ページ リスト アイテムの "WikiField" 列にリッチテキストで編集した情報をもとにページを構成します。
・発行ページは、アイテムが所属するコンテンツ タイプをもとに別途保存されたページ レイアウトにリダイレクトし、マスタ ページ (*.master) + ページレイアウト (*.aspx) でページを構成した後、アイテムが保持する列情報の値をページ上に動的に配置して表示を構成します。それに加えて Web パーツページと同様の動作も行います

このように SharePoint は、ASPX ページ定義を編集することなく、動的にユーザー操作によるページ設定の情報を保持するような仕組みを実装しています。

タイトル : Web ページを計画する
アドレス : https://technet.microsoft.com/ja-jp/library/cc263106(v=office.14).aspx

 

2.   SPD でページをカスタマイズする

SPD でページを標準モードでカスタマイズすると、ページの編集画面でカスタマイズするよりも少しだけ拡張したカスタマイズができます。
主な SPD 標準モードのページ カスタマイズ用途は、以下となります。

・リッチ テキスト上で、HTML コントロールを視覚的に挿入してデザインする。
・Web パーツのプロパティ等の設定を変更する
・リスト ビュー Web パーツのカスタマイズ
・ユーザー設定のリスト フォームのカスタマイズ

ページを開いた際に黄色く表示される箇所 (下図) は編集不可能ですので、カスタマイズする必要がある場合は詳細モードに切り替える必要があります。

ページを詳細モードで開くと一言でいえば、上記のブロックを解除し ASPX ページのコードを直接書き換えるカスタマイズが可能です。
つまり、上述した SharePoint 標準モードでは Wiki 編集コントロールや Web パーツなどの各種コントロールが変更内容を ASPX に保存することなく制御していましたが、ASPX を書き換えるようにすることでこの制限を超えたカスタマイズが可能となります。

 


ただし、この操作を実施して ASPX ページのコードを直接書き換えると、運用上のデメリットが生じます。この内容については、本投稿 4. にて詳細にご説明します。

 

3.  リスト ビュー Web パーツをカスタマイズする

サーバー レンダリング時におけるリスト ビュー (XsltListViewWebPart) のXSL カスタマイズは標準モード (詳細モードなし) での編集で実現可能です。

XsltListViewWebPart の XSL はこれまで記載した通り WebParts テーブルに保存することが可能です。
SPD 上で記述したコードは ASPX ページ上にコードとして保存されるのではなく、構文チェックされた上で WebParts テーブル側に格納される動作となります。SPD で再度ページを開くと ASPX 上にコードの実体があるように見えますが、これは SharePoint がページを取り出す際に様々な処理が動いています。改めてページを開いた際に、保存した通りに表示されてこない場合があるのは、このためだったりします。

(参考情報)
ASPX ページ上に実際に保存されている定義情報が何かを確認したい場合、Web フォルダ (\\MachineName\DavWWWRoot\) を開いて該当ページを開き ASPX などの定義を確認すれば一目瞭然です。

SPD で XSL を編集した場合、アプリケーション プール リサイクルをしなくても、動的に変更を適用することが可能です。カスタマイズが施されたページ表示処理では XSL の更新日時等を表示の度に毎回チェックし、必要に応じてキャッシュの更新タイミングをうかがうような処理となります。

しかし、これまでの情報を見る限り、詳細モードでカスタマイズしてないため問題ないように見えますが、柔軟に動作設計を変更できる反面、XSL 変更によりコンパイルとキャッシュの動作は標準処理から変更されるため、パフォーマンスは劣化します。

SPD で XSL をカスタマイズした際によくある事象としては、以前多田さんのブログ投稿に記載したような現象が報告されていますので、運用上注意が必要となります。

タイトル : Web パーツのエラーでページが表示できない場合のトラブルシューティング
アドレス : https://blogs.technet.com/b/sharepoint_support/archive/2013/10/10/a.aspx

 

4.   サイト定義ファイル ( ゴーストファイル ) をカスタマイズする

上記の通り SPD を使用して、標準モードが提供しているカスタマイズ範囲を超える大きな変更を加える場合、詳細モードでページをカスタマイズする必要があります。
しかしその場合、ASPX ページのサイト定義変更されたページが元となる定義ファイルから分離され、複製されたバイナリがコンテンツ DB に保存されて別途管理されます。

(補足)
上記のような動作を、弊社サイトでは、「ページのカスタマイズ」、「サイト定義の適用解除」、「実体化」、「ゴースト解除」といった様々な言葉で呼びます。この投稿では、他の意味に捉えられる危険性のない「ゴースト解除」という用語を選択します。

この種のカスタマイズを実施した際には以下のデメリットについて最初に考慮する必要があります。

ゴースト解除のデメリット

・修正プログラム等でサイト定義ファイルに変更を加えても、コンテンツ DB 内に分離してバイナリが保管されているため反映されない。
・コンテンツ アクセス毎に、データベースからバイナリ データを取り出す必要が生じるためパフォーマンスが劣化する。

つまり、ゴースト解除にならないように可能な限り調整した方が賢明です。

 

4-1. サイト定義ファイル (ゴースト ファイル) とは

サイト定義ファイルと呼ばれるページはゴースト ファイルとも呼ばれ、SharePoint ファイルは物理ファイルとして SharePoint Server 端末上に配置されたものを参照しており、要求された際にはワーカー
プロセス内でページ コンテンツをキャッシュして、以後高速にページを描画することができます。

(説明 : C:\Program Files\Common Files\Microsoft Shared\web server extensions\<ver>\TEMPLATE フォルダからの相対パスが AllDocs テーブル内に格納されています。)

サイト定義ファイルは、例えば以下のようなファイルを含みます。

・SharePoint 標準のマスタ ページ (例. default.master)
・フォーム (例. ListForm.aspx) などの ASPX　ページ
・ページ レイアウト
・スタイル ライブラリにある CSS, XSL および JavaScript 表示テンプレート
・ソリューション パッケージで展開されたカスタム サイト定義ファイル

これらのサイト定義ファイル (ゴースト ファイル) をテキスト エディター等で編集して、メモリ キャッシュをフラッシュするためにアプリケーション プールをリサイクルすると、このページを参照しているすべてのサイト コレクション上に配置された同一ファイル (ページやマスタ ページ等) に修正が反映されます。

一般的に製品の修正プログラムがサイト コンテンツを修正する場合は、この仕組みを利用して広範囲に修正を適用する動作となります。

タイトル : サイト定義と構成
アドレス : https://msdn.microsoft.com/ja-jp/library/aa978512(office.14).aspx?lc=ja-JP

(注意)
サイト定義ファイルのカスタマイズを行う際には、事前にバックアップを取り、問題があったら元のファイルと差し替えることを忘れないようしてください。カスタマイズされた後の状態では、弊社およびサードパーティ製製品開発元のサポートが受けられない可能性があります。
また、アーキテクチャの説明のため、データベースやテーブルに対する言及を行っておりますが、これらの設計は公開されておりません。そのため、今後同一の設計を維持するお約束はできず、予期せず変更される可能性があります。
特に直接 SQL を実行して更新系の処理を実行するようなシステムを作成した場合、該当コンテンツ データベース自体が弊社サポート対象外となりますため絶対にやめてください。

 

4-2. サイト定義ファイルのカスタマイズ ( ゴースト解除) とは

SPD によるゴースト解除は、通常以下のダイアログで [はい] を押した際に実施されます。SPD 2007 まではページ編集によって無条件でゴースト解除されていましたが、SPD 2010 以降ではページを詳細モードで開いて保存した場合に、以下のダイアログが表示されゴースト解除されます。

SPD を使用する以外でも、該当コンテンツをローカルに [エクスポート]、[コピーのダウンロード] し、そのファイルを編集してアップロードして上書きしてもゴースト解除となります。
または、バージョン管理画面から、旧バージョンのファイルに戻しても別途ストアされたファイルが新しいバージョンのファイルとして上書きされるので同じ状況になります。

ゴースト解除された状態では、コンテンツのバイナリ コピーがコンテンツ データベース(AllDocStream, DocStream) に格納されます。サイト定義ファイルに元に戻すことは可能ですが、基本的にサイト定義ファイルとはファイルの内容が分離され別のファイルとして管理されるという点と、個別にカスタマイズされた内容をメモリ内にキャッシュできる余裕はありませんので毎回読み込まれる動作となり、上述に記載したデメリットにつながる結果となります。

技術的な詳細はさておき、結果的に上記の通り、運用面において以下のような影響を生じさせることを把握しておく必要があり、重要ですので再度記載します。

・修正プログラム等でサイト定義ファイルに変更を加えても、コンテンツ DB 内に分離してバイナリが保管されているため反映されない。
・コンテンツ アクセス毎に、データベースからバイナリ データを取り出す必要が生じるためパフォーマンスが劣化する。

なお、このような相違があることを考慮し、必要性もなくとりあえず [詳細モード] で開くなど、むやみにゴースト解除するような操作は避けた方が良いでしょう。

 

4-3. カスタマイズ状態 ( ゴースト解除 ) を確認する方法

以下は、指定されたページがカスタマイズされているかどうかを確認するための PowerShell コマンド例です。

$web = Get-SPWeb https://sharepoint/sites/site/
$file = $web.GetFile("https://sharepoint/sites/site/_catalogs/masterpage/v4.master")
$file.CustomizedPageStatus

(結果)
Uncustomized ・・・ ゴースト ファイルのまま
Customized ・・・　ゴースト解除されたファイル
None ・・・　単なるコンテンツ ファイル (例. ユーザーが任意にアップロードしたファイル等)

なお、サイト定義ファイルに戻すには以下の 4 つの方法があります。

方法 1)  PowerShell を続けて実行します。

$file.RevertContentStream()

 

方法 2) SPD で [ サイト定義にリセット] をクリックします。

上記のコマンドはSPD でファイルを選択し、[サイト定義にリセット] をクリックすることと同等です。

(補足 : ファイル名の左に情報アイコンがついているものは、ゴースト解除されたファイルです。)

 

方法 3) サイトの操作からサイト定義にリセット操作を行います。

ブラウザー操作からは、ゴースト解除されている状況は確認できませんが、リセットは可能です。

以下の画面で対象のファイルを指定し、サイト定義にリセットします。


5.   意図せぬサイト定義ファイルのカスタマイズ ( ゴースト解除 ) を防ぐ

非常によくあるお問い合わせとして Wiki ページのサイト定義ファイルをカスタマイズ (ゴースト解除) すると以下の画面 (現在のページは、元のテンプレートからカスタマイズされています。[テンプレートの状態に戻します。]) が表示されます。Wiki ページは、ゴースト解除しなくてもかなりの幅のソリューションを提供可能です。

この現象でお問い合わせいただくほとんどの場合が、SPD で意図せず詳細モードでページを開いて保存した場合や、バージョン履歴の画面から旧バージョンの Wiki ページに戻した結果、旧 ASPX ページが現在の ASPX ページを上書きしゴースト解除された場合となります。

ゴースト解除を意図していない場合は、画面上のリンクをクリックするなどして元のテンプレートの状態に戻しておくことをお勧めします。

もしも、SPD で Web パーツや Wiki エリアを超える範囲にカスタマイズを加える等、意図してゴースト解除されている場合で、これを非表示にしたい場合は標準機能では実現できません。メッセージバー
コンテンツがページ ロード時のスクリプトで遅延ロードされることを考慮し、その処理の後でメッセージ バーに後付でスタイル (display: none) を指定して非表示にするくらいしか現実的な方法としてはないでしょう。

また、"SharePoint の全体管理サイト" の [SharePoint Designer 設定] 画面では、SPD の詳細モードなど、カスタマイズ範囲を制限する設定などもあります。
ご参考にしていただけますと幸いです。

タイトル : Sharepoint Designer 2010 を管理する
アドレス : https://office.microsoft.com/ja-jp/sharepoint-designer-help/HA101838275.aspx

まとめ

SPD によるページ編集は、局所的に、直感的に、スピーディにかつ柔軟にページ デザインを変更することに向いています。
ただし、規模を拡大して使用すれば、サイト定義ファイルから分離され、アップグレード面やパフォーマンス面のデメリットが生じます。

カスタマイズの対象は、特定のサイトやページといった局所的なシナリオに限定されます。SPD では、カスタマイズ操作の自動化や、多数のサイトに横展開する方法がない点等の制約事項があります。

このように、大規模なシステムで大量サイトに渡るコンテンツをカスタマイズするといった要件には現実的にそぐわない側面もあり、その際は開発工数が発生しますが Visual Studio を使用したソリューション等 (Web パーツやカスタム サイト、リスト定義等) を代替として検討した方が現実的ということになります。

これからも、SPD を使用した際の問題やトラブルシューティングに関する情報をご紹介していく予定ですが、本投稿についてはそれらのベースとなる情報となりますため、参考情報としていただけますと幸いです。