ここでは、その他の管理タスクと考慮事項について説明します。
Webページでコントリビューション・モードに切り替えるためのデフォルトのキーストローク組合せは、[Ctrl] + [Shift] + [F5]ですが、これは変更できます。このためには、Site Studioがインストールされているコンテンツ・サーバーのカスタム・ディレクトリにアクセスする必要があります。この値を変更する場合は、サイトのデザイナとコントリビュータに知らせる必要があります。
デフォルトのキーストローク組合せを変更するには、次の手順を実行します。
次のディレクトリを参照して表示します([CS-Dir]はコンテンツ・サーバーのインストール場所です)。
[CS-Dir]\custom\SiteStudio\publish\resources\wcm\sitestudio\
wcm.toggle.jsをテキスト・エディタで開きます。
関数OnKeyDown
を探します。
別のキーストローク組合せを使用してWCM.CONTRIBUTOR.Toggleを呼び出すように、この関数の実装を変更します。
この関数は仮想キー・コードを使用して、ユーザーが入力するキーの組合せを判別します。デフォルト値は、Ctrl+Shift+F5です。[F5]キーの仮想キー・コードは116 (16進数では0x74)です。他の一般的なファンクション・キー、[F1]〜[F12]のコードは112 (0x70)〜123 (0x7B)です。
wcm.toggle.jsを保存して閉じます。
注意: 次回Site Studioをアップグレードするかパッチをインストールする際に、場合によっては、キーストロークの組合せを維持するためにこの手順を再び実行する必要があります。 |
注意: コントリビュータが様々なオペレーティング・システムを使用する可能性がある場合、キーストロークの判別に使用するキー・コードに特に注意する注意があります。仮想キー・コードはオペレーティング・システムによって異なる場合があるためです。 |
コントリビュータがWebサイトのコンテンツにアクセスするには、キーストローク組合せを使用してコントリビューション・モードに切り替え、コントリビューション・アイコンをクリックしてコントリビュータ・アプリケーションを起動します。
Webサイトの構築に使用されるサーバーではこのようなアクセスが必要ですが、消費サーバー(公開Webサイトの実行に使用されるサーバー)では望ましくありません。消費サーバーへのコントリビュータのアクセスをブロックするため、次のサーバー構成変数をconfig.cfgに設定します。
DisableSiteStudioContribution=true
この変数が存在しない場合、またはfalse
に設定されている場合は、コントリビュータのアクセスが許可されます。
必ずコンテンツ・サーバーを再起動してください。
コントリビュータ・アプリケーションで使用されるデフォルト・エディタはFCKeditorですが、Ephoxに変更できます。どちらのエディタもSite Studioのコントリビューション編集環境として最適化されています。
コントリビューション・エディタとしてEphoxを使用する場合は、次のサーバー構成変数をconfig.cfgに設定します。
SSDefaultEditor=ephox
デフォルト・エディタをFCKeditorに戻す場合は、この変数を削除するか、次のように変更します。
SSDefaultEditor=fck
必ずコンテンツ・サーバーを再起動してください。
10gR3 (10.1.3.3.3)よりも前のSite Studioリリースを使用して作成されたカスタム要素フォームは、Site Studio 11gR1との互換性がありません。このようなフォームは手動でアップグレードするか再作成する必要があります。下位互換性が提供されない第1の理由は、以前のSite StudioがInternet Explorer独自のwindow.external機能に依存していたためです(コントリビュータ・アプリケーションで使用されるActiveXコントロールのため)。Site Studio 10gR3 (10.1.3.3.3)以上では、ブラウザに依存しないJavaScriptベースのコントリビュータ・アプリケーションが使用されるようになり、この機能はSite Studioから削除されました。詳細は、『Oracle WebCenter Content Site Studioテクニカル・リファレンス・ガイド』を参照してください。
Site StudioがEphoxをコントリビュータ・エディタとして使用するように設定した場合、コントリビュータ・アプリケーションは、1つ以上の署名付きプラグインがパッケージされた署名付きJavaアプレットを使用します。これらのアプレットがいずれかのシステムに最初にロードされるとき、ユーザーがセキュリティ証明書を受け入れることを求められます。複数の署名付きアプレットを同時にロードしようとすると、一部のJava仮想マシン(JVM)で問題が発生し、ブラウザがハングすることがあります。クライアント・コンピュータでこの問題が発生した場合、解決方法は2つあります。1つは、IT部門によってセキュリティ証明書をクライアント・コンピュータに送出する方法です。もう1つは、手動で一度に1つずつ証明書を受け入れる方法です。Site Studioによって、コンテンツ・サーバーに「Site Studio Certificate Validation」ページが表示されます。ユーザーはこのページで証明書を受け入れることができます。このページはユーザー・プロファイル・ページ(「My Profile」の下)からアクセスできます。
Site Studioコントリビュータのためにカスタム・プラグインを構築できるため、このページは、カスタム署名付きプラグインについても同じ方法で証明書を受け入れられるように拡張できます。このケースでは次のサーバー構成変数が使用されます。
このエントリは、証明書検証アプレットによってロードされるクラス・リストに顧客固有のエントリを追加します。値は、証明書検証プロセスでロードされるクラスをスペースで区切ったリストです。次に例を示します。
SSExtraCertificateClasses=com.xalco.XalcoEphoxPlugin com.zeng.TextGenerator
注意:
リストの各クラスには、SSExtraCertificateLabels
エントリを使用して、対応するラベルを設定する必要があります。
これは、SSExtraCertificateLabels
エントリおよびSSExtraCertificateJars
エントリと一緒に使用する必要があります。
このエントリは、証明書検証アプレットによってチェックされる証明書リストに顧客固有のラベルを追加します。値は、証明書検証プロセスで表示される証明書の説明をカレットで区切ったリストです。次に例を示します。
SSExtraCertificateLabels=Xalco Certificate^Ravenna Certificate
注意:
リストの各ラベルには、SSExtraCertificateClasses
エントリを使用して、対応するクラスを設定する必要があります。
これは、SSExtraCertificateClasses
エントリおよびSSExtraCertificateJars
エントリと一緒に使用する必要があります。
このエントリは、証明書検証アプレットによって使用されるクラスパスに顧客固有のエントリを追加します。JVMがこれを使用して、SSExtraCertificateClasses
エントリにリストされたクラスを見つけることができます。値は、証明書検証プロセスで表示される証明書の説明をカンマで区切ったリストです。次に例を示します。
SSExtraCertificateJars=<$HttpWebRoot$>resources/xalco/XalcoEphoxPlugin.jar,
<$HttpWebRoot$>groups/public/documents/adacct/HelloWorldPlugin.jar
注意:
エントリに埋め込まれたIdocスクリプト・タグは検証されます。
これは、SSExtraCertificateClasses
エントリおよびSSExtraCertificateLabels
エントリと一緒に使用する必要があります。
このエントリは、Ephoxエディタ内でのSunまたはデフォルトHttpLayerマネージャの使用を許可します。SSL環境で実行するときは、Sunレイヤーに変更すると結果が向上することがあります。指定できる値は次のとおりです。
SSHttpLayerManager=default
: Ephox内部のデフォルトHttpLayerマネージャを使用します。
SSHttpLayerManager=sun
: Sun HttpLayerマネージャを使用します。
これはEphoxのsetHttpLayerManager
構成エントリに対応します。詳細は、http://www.ephox.com/developers/editliveforjava/v50/html/prop_httpmanagerlayer.html
を参照してください。
Site Studio 11gR1は、フォームベース認証およびシングル・サインオン(SSO)環境で実行できます。次のHTMLコメントを、ユーザーの資格証明を求めるログイン・ページに追加する必要があります。
<!--IdcClientLoginForm=1-->
このトークンは、スペースや大文字と小文字も変更せずにそのまま使用する必要があります。ログイン・フォームにこのHTMLコメントが含まれない場合、Site Studioデザイナは、フォームベース・ログインによって保護されるWebサイトに正常に接続できないことに注意してください。このとき、Site Studioデザイナによって「200 OK」というメッセージが表示されますが、接続は失敗します。
フォームのHEADセクションには、多くのコード(多数のMETAタグまたはJavaScriptコードなど)を含めることができます。送信されるページは、レスポンスの最初の5,000文字にHTMLコメント(またはトークン)を含む必要があります。そうでない場合、サーバー接続が失敗することがあります。クライアント・コンピュータ上のソフトウェアは、<!--IdcClientLoginForm=1-->
トークンのレスポンスをスニッフィングし(厳密な文字列検索を使用)、見つかるとプロンプト元のコードを介してルーティングします。これはHTMLコメントとしてエンコーディングされるため、ログインが試行されるとき、通常のブラウザにトークンは表示されません。Idocスクリプトの場合は、送信されるページからパーサーがコードの該当ビットを削除します。クライアント側のブラウザではページに何も表示されません。
また、フォームベースのログイン・ソリューションが、Oracle Content ServerのExtranetLookコンポーネントの場合と同様に、リダイレクトを使用せずにログイン・フォームをクライアントに提供する場合は、次のサーバー構成変数をconfig.cfgファイルに追加する必要があります。
SSEnableExtranetLookCompatibility=1
config.cfgファイルを変更した後でコンテンツ・サーバーを再起動することを忘れないでください。この構成変数を追加しないと、Webサイトのコントリビューション・モードを開始した後で、パスベースのURLではなくCGIベースのURLがブラウザに表示されます。
Site Studio 11gR1には以前のリリースとの下位互換性があります。つまり、Site Studioデザイナ11gR1を使用して、以前のSite Studioリリースで作成されたプロジェクトを操作できます。アップグレードする必要はありません。ただし、これらのプロジェクトは引続きレガシー・モードで作動することに注意してください。つまり、10gR4よりも前のアーキテクチャを使用し、Site Studio 11gR1で導入された新しいアーキテクチャと機能は利用しません。
リリース7.5よりも前のデザイナで作成されたSite Studioプロジェクトを使用する場合は、まずプロジェクトをアップグレードする必要があります。このようなプロジェクトは、アップグレード後はレガシー・プロジェクトとして動作することに注意してください。
10gR4よりも前のプロジェクトのアップグレードの詳細は、『Oracle WebCenter Content Site Studioテクニカル・リファレンス・ガイド』を参照してください。