Q & A

販売パートナー各社から、または、弊社からご購入いただけます。ご要望に応じてパートナーをご紹介させていただくことも可能です。お気軽に info@frameworks.co.jp までお問い合わせください。

WebRelease Enterprise Edition と Workgroup Edition は、どちらも機能的には全く同一です。Enterprise Edition で利用可能な機能は、すべて、Workgroup Edition でもご利用いただけます。

ただ１点 Workgroup Edition は管理可能なページ数に上限が設定されています。Enterprise Edition は管理可能なページ数に制限がありませんが Workgroup Edition では、それが 500 ページに制限されています。Workgroup Edition はページ数が 400 ページを超えるとページ作成時に警告メッセージが表示されるようになります。また、ページ数が 500 ページに達するとそれ以上ページを作成することができなくなります。

Workgroup Edition でも複数ドメインの管理が可能です。

ページ数はテンプレートを使用して作成したコンテンツの数で数えます。

• WebRelease では、普通 html となるコンテンツを作成する時にはテンプレートを選択し、そのテンプレートの定義に従ってコンテンツを入力して行きます。このように、テンプレートを選択して作成するコンテンツをページとしてカウントします。
• PDF や画像類はページにはカウントされません。これらは WebRelease の管理下に置かれますが、テンプレートを使って生成するわけではないので、ページにはカウントされません。
• WebRelease は、テンプレートを使って CSS や JavaScript ファイルなどを生成することができます。こういったファイルをテンプレートを使って生成する場合、html ではありませんが、やはりページとしてカウントされます。
• 公開サーバに転送して公開していなくても、テンプレートを使ってコンテンツを作成していれば、それはページとしてカウントされます。
• WebRelease のテンプレートでは、複数のページから１枚の html を生成することも可能です。例えば、この QA のページは、一枚の html として公開されていますが、WebRelease 上では QA ごとに分割してページが作成されています。従って、この QA は WebRelease 上では QA の数だけページを使っています。
• あるページが複数のリビジョンを持っていても、ページ数としては 1 ページです。リビジョンの作成や削除はページ数には影響しません。
• Workgroup Edition で複数サイトを運用管理している場合、管理している全サイトのページ数の合計が 500 ページまでとなります。

大雑把には、公開サーバにアップロードする html の数と考えていただいてよいでしょう。

はい、できます。

Workgroup Edition と Enterprise Edition は機能は同一です。Workgroup Edition は管理可能なページ数が 500 ページに制限されている点だけが Enterprise Edition との違いです。

はい、ございます。

WebRelease2 Developer Edition をご用意しております。詳しくは下記ページをご参照ください。

必要ありません。

WebReleaseは、公開サーバに対してはライセンス費用は発生しません。

必要です。

WebRelease は、一つのライセンスで1台のサーバにインストールできます。WebRelease サーバを冗長化する場合には、追加のライセンスをご購入いただく必要がございます。

主系が Enterprise Edition の場合は、待機系用途に限定した Standby Lisence をご購入いただくことで、1台ないし2台の待機系サーバ（主系を含めて合計３台まで）に Enterprise Edition をインストールして運用することができるようになります。

主系が Workgroup Editionの場合は、待機系のサーバ用にもWorkgroup Editionをご購入ください。

変わりません。ユーザ数はライセンス料に影響しません。

変わりません。CPU 数やコア数が増えても価格は変わりません。

変わりません。

ASP サービスはできません。詳細は直接弊社までお問い合わせください。

WebRelease は静的コンテンツを生成するタイプの CMS です。静的コンテンツを生成するタイプの CMS は、動的コンテンツ生成型よりも、下記の点で優れていると言えます。

• セキュリティ面で有利です。公開 Web サーバ側にコンテンツ管理のための複雑なシステムを設置する必要がないため外部からの攻撃に対して堅牢です。また、公開サーバと CMS サーバを完全に分離できるため、公開 Web サーバ側から CMS に不正侵入される危険がありません。
• より小さな公開サーバでより大きなピークトラフィックに対応することが可能です。従って、低コストでレスポンスの良いサーバを構築可能です。
• 技術的にシンプルなため、構築が比較的に容易です。構築コストを小さく抑えることが可能です。
• CMS が停止しても公開サーバが停止しなければコンテンツ提供が停止することはありません。単純な Web サーバについてのみ可用性を高めれば良いため、構築後のランニングコストを小さく維持することが可能です。高コスト化しがちな DBMS のノンストップ化も不要です。
• 公開サーバを止めなければサービスへの影響は発生しないため、必要に応じて CMS を止めてメンテナンスやアップグレードができます。
• 検索エンジンがインデクシングしやすいため、SEO 対策上、有利であると言われています。

はい、できます。

WebRelease は静的コンテンツ生成型の CMS ですので、他のコンテンツとの融合がとても簡単で制約を受けにくいのです。

サイト全体は WebRelease で運用しながら、その一部分に Web アプリケーションが組込まれている（例えば EC システムでサービスを提供している部分）場合などにも対応可能です。

逆に、現行のサイトに対して、更新頻度の高い部分の CMS 化のために WebRelease を導入することも可能です。

導入できるかどうかご心配がございましたら、弊社販売代理店または弊社までお気軽にご相談ください。

できます。

WebRelease は 1 ライセンスで複数のサイトを管理することができます。WebRelease は静的コンテンツ生成型の CMS ですので、生成されたコンテンツを公開サーバに配信して公開するのですが、この時、配信先の公開サーバのドメインには制限がありません。FTP または SFTP でコンテンツを配信可能な公開サーバであれば何処にでも配信可能です。

はい、できます。

WebRelease は入力されたコンテンツを HTML に限らず様々なフォーマットのテキストデータに加工して出力することができます。CSV や XML などを生成管理する用途にご活用いただけます。サイネージ向けなどへの応用も可能です。

可能です。必ずしも弊社パートナーに作業をご発注いただく必要はございません。

ご不安に感じられる部分がございましたらお気軽にご相談ください。適切にアドバイスさせていただきます。また、ご要望いただければ、状況にマッチした弊社パートナーをご紹介させていただきます。

可能です。

WebRelease の運用には特に高い IT スキルは必要ありません。一般的なサーバの運用管理ができる状況であれば何も問題ありません。RDBMS のノンストップ運用も必要としていませんし、WebRelease の運用は公開サービスの運用とは完全に分離されていますので、サーバの運用としては最も簡単な部類に属すると思います。

尚、それでも、サーバを運用する限りにおいては、下記のような作業が随時必要になる点にご留意ください。

• サーバとして使用しているハードウェアの故障などに対応する必要があります。
• OS のメンテナンスが必要です。セキュリティパッチなどを、随時、適用し続ける必要があります。OS ベンダーからのアナウンスにも常に気を配る必要があります。
• WebRelease につきましても不具合修正版をリリースさせていただく場合があります。WebRelease のバージョンアップ作業は WebRelease の管理画面から GUI ベースで実行可能な簡単な物ですが、自動で実行されるわけではありませんので若干の作業が必要です。
• 原因不明の不具合が発生した場合、その原因を見つけ出して対応する必要があります。不具合の原因はサーバ、ネットワーク、クライアントPC、外部からの攻撃、WebRelease を含む CMS 環境を構成するいずれかのソフトウェアの不具合など、多岐にわたるため、原因特定に時間がかかる場合もあります。
• データのバックアップを確実に実行し続ける必要があります。

クラウドの利用をご検討いただくのも一案です。すべてを自社で運用管理される場合に比較し、はるかに容易に WebRelease の運用が可能になると思います。

提供されます。WebRelease をご利用いただいているお客様には、ご購入いただいた製品に対するバグフィックスや新機能の追加、また、周辺稼動環境(OS/プラットフォームなど)の変化へのキャッチアップなどを主な内容とした保守バージョンをご提供させていただいております。

保守はダウンロード型式でのご提供とさせていただいております。本サイトからアップデートファイルをダウンロードしていただき、ブラウザで WebRelease の管理画面にアクセスし、アップデートファイルをアップロードすることで WebRelease のバージョンアップを実行することができます。バージョンアップ作業にはサーバルームやデータセンタでの作業は必要ありません。

バージョン 2.70 以降の Enterprise Edition につきましては、有償にて保守をご提供いたします。それ以外の製品につきましては保守は無償での提供とさせていただいています。保守の詳細につきましては下記をご参照ください。

いつでもご購入いただけます。

ライセンスご購入時だけでなく、その後でも、また一旦保守が切れた後でも購入することができます。再度保守を購入したときに、保守が無かった期間に遡ってお支払いが発生することはありません。一旦保守が切れたらライセンスを買い直さないと保守契約を結べないといったこともありません。

上限はありません。また、ユーザ数がライセンス料に影響することはありません。

現実的には、画面構成上の理由で 2,000 〜 3,000ユーザ程度が上限となります。

必要ありません。

WebRelease を使用してコンテンツ管理を行なう場合、例えば HTML や CSS Javascript の知識がないとコンテンツの作成や公開／承認といった日々の作業ができないということはありません。普通に PC が使えれば大丈夫です。

カスタマイズはお受けしていません。また、ソースコードの開示もしておりません。ご了承ください。

ご要望の多い機能につきましては、随時、新バージョンに組み込む形でご提供させていただいています。新バージョンは保守の一環としてご提供いたします。

WebRelease はテンプレートの自由度が高いので、サイトの構造やテンプレートのデザイン実装などに関するご要望はテンプレートで吸収できる場合も多いようです。

弊社サイト「サポート」の各ページで、様々な技術情報を公開していますのでご活用ください。

ライセンスご購入後は、最新のバグフィックス版・機能追加版をダウンロードできます。バージョン 2.70 以降の Enterprise Edition につきましては保守が有償ですので「Enterprise Edition 年間保守」をご購入いただくことで新バージョンのダウンロードができるようになります。それ以外の Edition では保守は無償ですので「Enterprise Edition 年間保守」をご購入いただく必要なく新バージョンのダウンロードが可能です。

メールによる技術的な疑問および障害に関する個別のお問い合わせに対して、メールでお答えする別途有償のサポートサービスもご提供しています。

その他、ご要望がございましたらお気軽に info@frameworks.co.jp までお問い合わせください。

WebRelease に接続可能な IP アドレスを制限したい場合は、下記の記述を httpd.conf の末尾あたりに追記してください。追記場所は WebRelease のインストーラが書き込んだ ProxyPass ディレクティブの後ろあたりでよいでしょう。

# Following mod_proxy configuration is added by WebRelease2 Installer.
<IfModule mod_proxy.c>
  ProxyPass   /WebRelease2    http://127.0.0.1:50002/WebRelease2
  ProxyPassReverse   /WebRelease2    http://127.0.0.1:50002/WebRelease2
  ProxyTimeout          1800
</IfModule>
# 以下を追記してください。
<Location /WebRelease2>
  Order deny,allow
  Deny from all
  Allow from 192.168.1.0/24
</Location>

• アクセスを許可する IP アドレスまたはネットワークアドレスを Allow from の行に指定します。上記の例では 192.168.1.0/24 を指定していますが、要望に合わせたアドレスを指定してください。
• Apache 2.4 をお使いの環境では require ip ディレクティブなども利用できます。

Basic 認証などを導入したい場合は下記のような記述でよいでしょう。必要な htpasswd ファイルは作成してください。

<Location /WebRelease2>
  AuthType basic
  AuthName "Protected Area"
  AuthUserFile  /etc/httpd/conf/userfile
  require valid-user
</Location>

• 詳しくは apache http server のマニュアルをお読みください。

コンテンツを公開するための http サーバ、WebRelease を稼働させるための WebRelease サーバの 2 種類を用意してください。

通常は、公開サーバ 1 台、WebRelease サーバ 1 台の 2 台構成で構築します。WebReleaseサーバ上で WebRelease が稼働します。公開サーバ上では httpd サーバ (apache など)が稼働します。WebRelease は WebReleaseサーバで作成・管理するコンテンツを公開サーバに転送し公開します。

必要なサーバスペックは管理しようとしているページ数やテンプレートの作り方により多少変化します。以下が指針です。

• 5,000 ページあたり 2G Byte 程度のメモリを準備してください。
• 公開サーバ上で管理するコンテンツの 10 倍程度のディスクを準備してください。
• 10,000 ページ以上のサイトを運用管理される場合であれば 4 コア以上の CPU を準備してください。コア数の多いサーバを使うことで、コンテンツ生成と公開サーバへのアップロードの性能が向上します。

サーバの条件については、下記リンク先もご参照ください。

サーバのサイジングにつきましては導入事例もご参考にご利用ください。

WebRelease サーバにクラウド（VPS）をご利用いただけば運用規模の変化に応じて柔軟にサーバ設備をサイジングすることが可能です。

ご不明な点につきましては弊社または販売代理店までお問い合わせください。
ご導入規模に応じたサーバサイジングについて適切にアドバイスさせていただきます。

WebRelease で管理したいと考えているコンテンツ総量の 10 倍以上のディスク容量を確保してください。たとえば、公開サーバー上で 3G Byte 程度となるであろうコンテンツを WebRelease で運用管理したい場合には、 30G Byte 以上のディスク領域を確保してください。

この必要ディスク容量の値は目安です。この値はコンテンツ構成や更新頻度、各種ログの保存状況などにより変化します。

詳しくはインストールマニュアルをご参照ください。

対応 OS は Linux、OS-X (macOS) になります。詳しくは下記リンクをご参照ください。

OS にバンドルされている httpd があれば稼働環境が整います。

WebRelease は Java + Tomcat で稼働するアプリケーションですが、必要なミドルウェアは WebRelease のインストールメディアに同梱されており、統合インストーラで自動でインストール・設定されますので、別途ご用意いただく必要はありません。

任意です。

WebRelease には、各種通知メールを発送する機能があります。これらの機能をお使いになる場合には WebRelease からメールを発送するためのメールサーバが必要になります。WebRelease は一般的な port 25/465/587 を使ってメールの発信が可能な SMTP サーバに対応しています。また STARTTLS やパスワード認証にも対応しています。

各種の通知メールが必要でなければ、メールサーバを設定せずに WebRelease を利用することも可能です。

メールサーバの設定は WebRelease の管理画面から行えます。

WebRelease は DBMS（例えば MySQL や Oracle など）は使いません。WebRelease は内部に独自のストレージ管理システムを持っていますので外部の DBMS を必要としません。

問題ありません。

ご利用になる WebRelease のバージョンが必要としている動作環境を満たす VPS であれば、問題なく WebRelease をご利用いただけます。

最近では、Cloud での利用も増えています。Cloud を上手に使えば、比較的簡単に、安価に、高可用性のシステムが構築可能です。一方で、必要な性能をもったクラウドサーバを選択することも大切です。

公開 Web サーバを増強してください。WebRelease サーバの強化は不要です。

WebRelease は生成したコンテンツを公開サーバに転送して公開するタイプの静的 CMS ですので、ページビューの負荷がかかるのは公開サーバのみです。WebRelease サーバのサイジングにはページビューは関係しません。ページビューの大きなサイトを管理する場合でも、WebRelease サーバを強化する必要はありません。ごく一般的な方法で公開 Web サーバを増強すれば大丈夫です。

SNS 経由で到来する高いピークを持つトラフィックに対応するためにも、フロントの Web サーバのみの増強で対応できるシンプルなサーバ構成は魅力的ではないでしょうか。

できません。

• WebRelease はバージョンアップするときに Tomcat をアップデートする場合があります。 アップデートされた Tomcat と WebRelease 以外の Servlet との適合性が問題になる可能性があります。

• WebRelease はバージョンアップするときに Java Runtime Environment をアップデートする場合があります。 アップデートされた Java Runtime Environment と WebRelease 以外の Servlet との適合性が問題になる可能性があります。

• WebRelease をバージョンアップするときに Tomcat の設定ファイル類が更新される場合があります。他の Servlet 用に設定を入れてあっても、それが上書きされてしまいます。

以上のような理由から、他の Servlet 向けには別途アプリケーションサーバをご用意ください。

一つの OS 上で起動可能な WebRelease インスタンスの数は 1 つです。複数インスタンスの並行起動はできません。

一方、VM を使えば可能です。VM（例えば KVM や Xen、VMWare など）を使うことで物理的に 1 台のサーバ上に複数の OS を起動できるので、その上で WebRelease を起動すれば、１台の物理サーバ上で複数の WebRelease を起動することが可能です。

但し、１台の物理サーバ上に二つ OS を稼働させ、それぞれの上に WebRelease をインストールして使用する場合には、WebRelease のライセンスは二つ必要になります。

いかなる方法であれ、WebRelease インスタンスを複数起動して使用する場合には、起動するインスタンス数分の WebRelease ライセンスをご購入いただく必要がございます。

はい、可能です。下記ドキュメントを参考に作業を行なってください。

変更できません。

各コンポーネントの組み合わせミスマッチによるトラブルを回避するために、また、インストールプロシージャを簡単にするために、同梱とさせていただいています。ご了承ください。

いいえ、同じ物です。ひとつのメディアで Linux, OS X (macOS) のいずれの OS にもインストールできます。また、32 bit / 64 bit の区別もありません。

WebRelease は下記の TCP 接続を必要とします。

• port 80(http) への inbound 接続。WebRelease を SSL 下で運用する場合には port 80 の代わりに port 443(https) への inbound 接続が必要になります。
• port 25(smtp) または 465(smtp over SSL) または 587(submission) への outbound 接続。メール通知機能を使う場合に必要になります。尚、WebRelease は pop imap は使用していません。
• port 21(ftp) への outbound 接続。ftp でコンテンツをアップロードする場合に必要になります。
• port 22(ssh) への outbound 接続。sftp でコンテンツをアップロードする場合に必要になります。
• port 80(http) への outbound 接続。外部サーバから XML を http 経由で取り込む場合に必要になります。
• port 443(https) への outbound 接続。外部サーバから XML を https 経由で取り込む場合、及び、 AWS S3 へのコンテンツのダイレクトアップロードを行う場合に必要になります。
• ftp によるコンテンツのアップロードを行う場合は ftp 実行中に決まるデータコネクション用のポートへの接続。PASV の場合に outbound そうでない場合に inbound が必要となります。

詳しくは、下記インストールマニュアルをご参照ください。

WebRelease の稼働には Tomcat と Java が必要です。しかし、 WebRelease はどんなバージョンの Tomcat と Java の組み合わせ上でも稼働するわけではありません。WebRelease は、実際はかなり広い範囲の Tomcat と Java の組み合わせ上で稼働するのですが、それらの内でもテストが実施され動作が確認されているバージョンの組み合わせは限られています。

Tomcat や Java にセキュリティアップデートやバージョンアップがリリースされた場合、当社は、新しい Tomcat と Java の組み合わせ上で稼働可能な WebRelease を作成し、それを新バージョンの WebRelease としてリリースいたします。

新バージョンは本サイトから更新ファイルとしてダウンロードしていただけます。更新ファイルには WebRelease に同梱して Tomcat と Java (JDK) が含まれています。この更新ファイルをご利用いただくことで最新版の WebRelease を導入いただけると同時に Tomcat と Java も安全に新バージョンにバージョンアップしていただけます。つまり、常に最新版の WebRelease をお使いいただくことで、Tomcat と Java についても、最も安心できるバージョンをお使いいただけます。

更新ファイルのダウンロードとアップデートの適用手順については「最新版をダウンロード」のページをご覧ください。

セキュリティアップデートに関しては、アップデートされた Java や Tomcat 上での WebRelease の動作確認と新バージョンのリリースを最短で行えるよう努力いたしますが、技術的な理由から、少々日程を頂かなければならない場合も考えられます。また、セキュリティーアップデートを伴わない Java や Tomcat のバージョンアップについては、追随せずにスキップする場合もございます。基本的に WebRelease の稼働上メリットを期待できないリリースはスキップさせていただきます。ご了承いただきます様お願い申し上げます。

WebRelease のソフトウェア構成に関しましては下記をご参照ください。

現在の WebRelease は、アプリケーションサーバとして Tomcat を使用しています。

ごく初期の WebRelease は WebObjects (NeXT Computer 製、後に Apple 製品) を使用していましたが、2006年05月にリリースされた WebRelease 2.20 以降は Tomcat に切り替わりました。

WebRelease は Tomcat を内包しています。インストール時に Tomcat を別途にご用意いただく必要はありません。また、WebRelease を Tomcat 以外のアプリケーションサーバで動作させることはできません。

Apache と WebRelease の接続は mod_jk ではなく mod_proxy を使用しています。

WebRelease は、インストールされたマシンに割り当てられている全 IP アドレスについて port 50002 を Listen するように設定されています。

Apache から WebRelease への接続は port 50002 に向けて mod_proxy を使って行なわれています。

これらの設定は WebRelease のインストーラが行ないますので WebRelease のインストール作業中に手作業で設定をしていただく必要はございません。

Apache を経由せずにブラウザから直接 port 50002 に接続することでも WebRelease にアクセスすることは可能です。しかしながら、Apache の機能を併用することでより効果的に WebRelease の利用環境を構築していただけると考えておりまして、基本的には Apache と組み合わせて使用していただくこととさせていただいています。たとえば、アクセス制限、SSL、ロギング、など、Apache 側で設定を行なうことで、よりご要望に沿った WebRelease の利用環境を構築していただけるのではないでしょうか。

WebRelease が Listen するアドレスやポートをどうしても変更したい場合には WebRelease をインストールした時に作成される設定ファイル appserver.conf を手作業で編集することで変更は可能です。但し、セキュリティ上の懸念に関して変更をお考えでしたら、可能なかぎり FireWall 系のソリューションでの包括的な対応をお推めいたします。

インストーラの動作概要につきましては下記の別紙資料をご参照ください。

一般的な構成としましては、公開サーバと WebRelease サーバを別々のマシンで構築し、それぞれを異なるロケーション、つまり、公開サーバを公開ネットワークに接続し、WebRelease サーバをコンテンツ管理を行うスタッフが使用するネットワーク（イントラネット）に接続してご利用いただく形態を想定させていただいています。

ですが、公開サーバと WebRelease サーバを共存させることも可能です。その場合、普通に WebRelease サーバを構築した後で、Apache に対して公開コンテンツ用の設定(VirtualHost や DocumentRoot など公開コンテンツの管理に関する設定)を加えた上で、公開ネットワークに接続していただければ、公開サーバと WebRelease が共存した状態のサーバが構築できます。

この場合 WebRelease から公開サーバへのコンテンツ転送は localhost への FTP/SFTP となりますので FTP/SFTP サーバの設定も必要です。

公開サーバと WebRelease サーバが別のサーバとして見えるようにしたい場合には、Apache の VirtualHost 機能を使うか、公開サーバと WebRelease サーバに別々の IP アドレスを割り当て、それぞれのアドレス上で個別に Apache を起動するなどの方法を採ることができるでしょう。また、最近では VPS などを使う方式も可能です。

なお、セキュリティ面を考えた場合には、公開サーバと WebRelease サーバは分離していただいた方が安全ではあろうかと思います。それぞれに対して異なるポリシーでアクセス制限を加えることが可能です。また、最悪の場合でも被害の範囲を限定できる点も考慮しておく必要があります。分離できるのであれば分離していただくことをお推めいたします。

はい、できます。

WebRelease は Tomcat 上で稼働するアプリケーションですが、フロントに http サーバの apache を置く構成で稼働します。WebRelease の管理画面にアクセスするブラウザからのリクエストは、まず、フロントの apache が受け取ります。Apache は、そのリクエストを apache の組み込みモジュール mod_proxy を使って背後の Tomcat 上の WebRelease にリレーします。

フロントの apache に対して、ごく普通に SSL の設定を行なっていただければ WebRelease を SSL 経由でご利用いただける環境が構築できます。

公開サーバを無停止で運用できるように留意してください。

WebRelease は静的コンテンツを公開サーバに配信するタイプの静的 CMS です。従って、コンテンツの作成、更新、配信などの作業を行っている時以外は WebRelease を止めることができます。WebRelease のメンテナンスやアップグレードを行う場合でも公開サービスを止める必要はありません。

また、コンテンツの公開に DBMS を使用しないのでデータベースの無停止化も不要です。

はい、大丈夫です。ホスト名も変更しても大丈夫です。

一方、WebRelease がインストールされているサーバには apache もインストールされていると思いますが、その設定ファイル httpd.conf には、場合によっては IP アドレスに依存した設定が入っている場合があります。具体的には Listen ディレクティブなどです。問題がないかどうかチェックしていただいた方がよいでしょう。

WebRelease のデータは、WebRelease をインストールしたサーバ上の wr2 というユーザのホームディレクトリ下にある WebRelease2.storage というディレクトリ（例えば /home/wr2/WebRelease2.storage) に保管されています。全サイトのコンテンツデータとWebRelease2 の登録ユーザ情報の全てが、このディレクトリ下に保管されています。このディレクトリ以下を (tar などを使って) バックアップすれば WebRelease の全データをバックアップすることができます。

バックアップはなるべく毎日取得してください。取得したバックアップは、WebRelease サーバ上に保管せずに、外部メディア（テープやCD/DVDなど）に移すか、他のマシンに転送してください。サーバ上に保管したままにしておくと、例えばサーバの破損などでサーバが全損となった場合に、同時にバックアップも失ってしまいます。

ミラーディスク (RAID 1 や rsync など) はバックアップのためには役に立ちません。例えば WebRelease の不具合や、オペレーションミス、または、何者かによる破壊行為などによってデータを消失した場合など、ミラーでは、ミラー先も同時に更新されるため、消失したデータを取り戻すことはできなくなってしまいます。RAID などの設備は、部分的なディスク障害が発生してもサーバの運用を継続できるものであるという位置づけで導入していただけると良いでしょう。

バックアップしたファイルは、必ず何世代分かを保存してください。データの異常に気がつくのが遅れた場合、保存している世代が少ないと正常なデータを取り戻すことが出来ない可能性があります。最低でも１週間分程度（最新７ファイルとか）は保存し続けることをお勧めいたします。

サイト単位で個別にバックアップを取得する場合には、サイトのエキスポート機能が使えます。エキスポート機能により、特定のサイトのデータ全体を、手もとの PC にダウンロードすることができます。ダウンロードされたサイトは、同じ WebRelease または、他のサーバ上で稼動する WebRelease にインポートすることができます。この方法であれば、サイトごとにバックアップとリストアができます。

公開コンテンツ（WebRelease から生成された静的コンテンツで Web サーバ経由で公開されているコンテンツ）については、必要に応じてバックアップしてください。WebRelease は、いつでも、前回公開したときのコンテンツと同一のコンテンツを再生成して公開サーバに転送することが可能です。公開コンテンツについてはバックアップは作成せず、万が一公開コンテンツの復旧が必要になった場合には WebRelease からのコンテンツの再送で対応するという運用も可能です。

はい、ご購入いただけます。

いずれかの Edition の WebRelease をご購入いただいているお客様は、いつでも、ご要望のバージョンのインストールメディアをご購入いただけます。お持ちのバージョンとは異なるバージョンのインストールメディがが必要になりましたら　「WebRelease 2 インストールメディア（製品コード WR02IM）」をご購入ください。ご購入の際にご希望のバージョンをお知らせください。

サポートをご購入いただいているお客様には WR02IM はサポートの一環として無償にてお届けしています。弊社宛にご要望いただければ無償にてメディアをお送りいたします。（メール info@frameworks.co.jp 宛で承ります）

WebRelease を最新版にアップグレードする場合には、ダウンロードサービスをご利用ください。その場合はメディアをご購入いただく必要はありません。

古いバージョンの WebRelease は、最近の新しいサーバ環境にはインストールできない場合があります。WebRelease の動作環境にはご注意ください。

はい、移行できます。コンバージョン等は必要ありません。

WebRelease のコンテンツデータは、WebRelease サーバ上の WebRelease2.storage というディレクトリに保持されています。このディレクトリ以下のデータは OS の種類に依存していません。例えば OS X で使用していた WebRelease2.storage を Linux にコピーして使用することなども可能です。

移行手順については下記ドキュメントを参照してください。

残念ですが FreeBSD 上では稼働しません。

稼働しない理由は WebRelease が使用している Java Runtime Environment が FreeBSD をサポートしていない為です。

稼働プラットフォームにつきましては下記ページを参照してください。

可能です。

マルチチャネルと呼んでいる機能があります。この機能を利用すると 1 件（1 ページ）の入力データから PC 向けとスマートフォン向けの異なるコンテンツ（html）を生成し、別々のサーバ（または、同一のサーバの異なるディレクトリ）に配信することができます。チャネルはいくつでも定義できるので、PC、スマートフォン、フィーチャーフォン、タブレットなど、いろいろなデバイスに向けてコンテンツを出し分けることができます。

レスポンシブデザインとの併用も可能です。

可能です。

ワンソースマルチユースができるので 1 件の入力からスマートフォンと PC など、複数のデバイスへのコンテンツ配信が可能です。ですが、必ずしもワンソースでなければならないわけではありません。テンプレート作成時にスマートフォン向けと PC 向けに別々の画像を登録できるようにしておけば、それぞれに対して異なる画像を配信することが可能になります。別々に画像が登録できればサイズだけでなくトリミングやフォーマット等も異なる画像を配信可能です。いずれか一方しか入力されなかった場合には、全デバイスに同じ画像を配信するようなテンプレートも作成可能です。

WebRelease の操作に使用可能なブラウザにつきましては下記をご参照ください。

WebRelease で管理されている Web サイトを閲覧するオーディエンスが利用するブラウザには制限はありません。テンプレート作成時にどのブラウザをターゲットにコンテンツを公開するか（例えば IE8 以降 + Modern Browsers）を決定し、それに応じた HTML コーディングのテンプレートを準備してください。

基本的にできません。

普段のサイトの運用では、全てのコンテンツはテンプレートを使用して作成する流れになります。コンテンツを管理するための仕組み、例えばリビジョン管理、公開期間管理、承認フローなどは、いずれもページを対象にしています。そして、ページを作成するためにはテンプレートが必要です。

テンプレートについて考える時、つい、コンテンツを生成する機能ばかりに目が向かいがちですが、実は、テンプレートには管理に関わる仕組みもたくさん備わっています。例えば、ユーザによって使えるテンプレートを制限することができたり、フォルダによって使用可能なテンプレートを制限するなどができます。また、トップページのテンプレートなどは 1 ページしか作成しない場合が多いでしょうから、一度ページを作成してしまったら、新たなページの作成を禁止しておく設定ができたりします。そういった背景があるため、CMS でコンテンツを管理するということと、テンプレートを利用するということは切り離せないものになっています。

一方で、javascript や css など、サイト構築段階でその内容がほぼ決定されてしまうコンテンツ（リソースと呼んでいます）の場合には、公開サーバにそのまま配信するファイルとして WebRelease に登録しておくことができます。

可能です。

任意の時点で、編集中のページのリビジョンを保存することができます。一旦公開したページのリビジョンは自動的に書き込み禁止のリビジョンとして保全されます。保全されているリビジョンを取り出して再公開（復旧）することができます。リビジョンごとに公開履歴(公開時刻、公開終了時刻)が記録されますので、いつどのリビジョンが公開されていたかを知ることができます。

可能です。

ページには、公開開始指定時刻と公開終了指定時刻を指定しておくことができます。また、FTP/SFTP の起動モードと組み合わせることで、指定されている時刻に自動でページの公開や公開終了を実行することができます。

はい、調べられます。

全ページについて、いつ、どのリビジョンが公開されていたか、また、いつ誰によりページに修正や公開などの操作が加えられたかなどをすぐに調べることができます。

可能です。

WebRelease では

• WebRelease にログインを許可するためのユーザ登録
• ユーザ登録されているユーザをどのサイトの管理者（スタッフ）にするかの指定（複数可）
• スタッフに与える権限をサイトごとに指定

といった権限および役割の設定が可能です。あるユーザは同時に複数のサイトのスタッフになることができますし、そのユーザはサイトごとに異なる権限と役割でサイトの運営に参画できます。

はい、記録されます。

ユーザのログイン/ログアウトの履歴や、ページ、テンプレート、その他各種設定変更に関しても操作履歴が記録されます。ユーザは随時これらの履歴を管理画面で参照することができます。特定のページ、特定のテンプレートに対する操作の履歴も簡単に見ることができます。操作履歴に対しては、操作したユーザ、時期、キーワード等で検索することができます。

履歴は月単位でダウンロードと削除が可能です。

操作履歴を部分的に削除することはできません。また、操作履歴は書き換えることもできません。

可能です。ページ作成後の承認を最大5段階まで設定することができます。

ありません。

できます。

WebRelease 上で作成したコンテンツ（ページ）はフォルダを使って管理しますが、そのフォルダごとに、フォルダ以下に作成されたページに適用する承認フローを一つ、または複数指定することができます。

フォルダに承認フローが一つだけ指定されている場合、ページ作成者がページを承認依頼すると、自動で指定されている承認フローが開始されます。

フォルダに複数の承認フローが指定されている場合、ページ作成者が承認フローを選択して承認フローを開始することになります。

できます。チェックボックスでページを複数選び承認を依頼する、一括承認依頼機能が用意されています。

できます。

できます。

可能です。WebRelease のテンプレートは HTML に限定されることなくテキストで表現可能なコンテンツをかなり自由に生成可能です。RSS についても、テンプレートを作成するだけで RSS 1.0 / RSS 2.0 / Atom など、ご希望のフィードを生成することが可能です。

本サイトから配信させていただいている RSS 1.0 も WebRelease を使って生成したものです。

WebRelease には、フィード生成機能が直接システムにプログラムとして組み込まれているわけではありません。WebRelease の提供する柔軟なテンプレートシステムを使用してフィードを生成するテンプレートを作成していただくことで、ご希望のフィードを生成することが可能となっています。将来、フィード仕様が変更になった場合にも、CMS システムの対応を待つことなく、テンプレートを修正するだけですぐに新しい規格に対応いただけます。

可能です。

WebRelease は HTML に限らずテキストで表現可能なコンテンツをかなり自由にテンプレート化可能です。何らかの規格に準拠したコンテンツを生成する必要があれば、そのようにテンプレートを作成することで規格への対応が可能です。

いいえ。 FTP または SFTP が使用できます。

あります。未来時刻を指定して指定時刻にコンテンツをアップロードすることができます。

可能です。

IR 情報などを含むサイトでは、サイトの運営管理に関わる制作スタッフ全員が、制作途中の未発表の IR 情報にアクセスできてしまうことが問題になる場合があります。新製品情報などを扱うサイトでも、同様の配慮が必要になる場合があります。

WebRelease ではサイト内のコンテンツを任意のフォルダ階層で管理します。各フォルダでは、そのフォルダ内のコンテンツにアクセスできるスタッフを限定することができます。さらに、そのフォルダにアクセスができないスタッフ（フォルダ以下のコンテンツに対する更新操作が制限されているスタッフ）がフォルダ内のコンテンツを Preview することを許すかどうかも指定することが可能です。

Preview が許されているスタッフの場合には、他のページの Preview からリンクを辿るなどしてそのフォルダ内のコンテンツに到達することができる場合には、アクセスが制限されているページ内のコンテンツを Preview することができます。Preview も許されていないユーザは、そのフォルダ内の公開されていないコンテンツにはアクセスできません。

U/I （操作画面）の言語には、日本語または英語が選べます。言語の切り替えはブラウザの言語設定で行ないます。言語の設定はユーザごとに可能です。

U/I 言語に加えて WebRelease で管理する各サイトにはデフォルトの言語の設定があります。この設定はそのサイトの運用管理に伴って発生する各種通知メール（各種の承認や監視メール類）の言語を指定するものです。例えば、WebRelease で、日本語サイトと英語サイトを管理している場合、それぞれのサイトのデフォルト言語は、それぞれを日本語、英語に設定可能です。

言語指定以外にも、サイト単位または、ユーザ単位で、時刻表時のタイムゾーンを切り替えることができます。例えば、東京に設置して運用管理している WebRelease を海外の拠点から利用する場合など、現地で運用管理するサイトについては、現地時刻を使って各種時刻表時を行なうことができるようになっています。

WebRelease のユーザーズマニュアルは日本語のみです。

管理対象コンテンツについては言語の制限はありません。中国語、韓国語、ロシア語などのサイトを運用管理することが可能です。

WebRelease は静的コンテンツを生成するタイプの CMS です。WebRelease が管理するコンテンツはすべて静的な HTML や CSS ファイルに変換され、公開サーバに転送されて公開されます。

コンテンツを公開するときには、保持しているコンテンツデータとそのコンテンツデータを定義しているテンプレートから、公開すべきコンテンツを生成し、それを公開サーバに FTP/SFTP で転送します。既存コンテンツの変更や新規コンテンツの追加を行った場合には、公開サーバへは差分のみが転送されます。(もちろん、全コンテンツの再転送も可能です)

差分の抽出とコンテンツの転送にかかる時間は、例えば、5000 ページ程度のコンテンツを持つサイトの場合でも、１分以内〜数分程度です。

所要時間は参考値です。所要時間は、サーバや回線性能、発生する差分量やテンプレートの複雑さ、画像や PDF などをどの程度含んでいるかなど、様々な要因により変化します。当社および当社パートナ各社はこの所要時間を保証するものではありませんことをご了承ください。

尚、作成中のコンテンツの Preview をするために静的コンテンツの生成完了を待つ必要はありません。Preview は、全ページについて即座に可能です。Preview 機能は静的コンテンツの生成に使用されているコンテンツ生成エンジンを使用して Preview を要求されたページのコンテンツを動的に生成し Preview Window に表示することで実現されています。

WebRelease から配信される通知メールの種類は下記の通りです。

• 承認依頼通知メール／承認完了通知メール／差戻通知メール／承認遅延警告メール
• FTP 実行通知メール／FTP エラー通知メール
• ディスク残量警告メール
• メモリ使用量警告メール

必要ありません。

WebRelease 利用者(コンテンツ管理者)環境は下記の条件を満たすブラウザです。

• Microsoft Internet Explorer 8 以降（Internet Explorer 10 以降を推奨）
• Google Chrome 4 以降
• Apple Safari 4 以降
• Mozilla Firefox 4 以降

いずれのブラウザを使用する場合でも、JavaScript が使用できる設定になっている必要があります。

それ以外のプラグイン類、例えば、Flash Player や Java Applet 実行環境などは必要ありません。

一方、WebRelease は、Flash などを前提としたコンテンツの管理も可能です。そういったコンテンツを管理する場合には、必要に応じてプラグインを導入したブラウザで操作していただく方がよいでしょう。プラグインが導入されていないと、プラグインを必要とするコンテンツの完全な preview ができず、不便を感じるでしょう。

WebRelease 利用者(コンテンツ管理者)環境は、将来の WebRelease やブラウザのバージョンアップ等により変更になる場合があります。最新の情報については下記ページを参照してください。

アクセス解析機能は組込まれていません。

一般のアクセス解析ツールと組み合わせてご利用ください。組み合わせる上での制約はありません。解析の目的に応じて複数の解析ツールを組み合わせてご利用になられているケースも多いようです。

使えます。

WebReleaseは静的コンテンツ生成型のCMSですので、Googleユニバーサル アナリティクスをはじめとする各種のアクセス解析ツールを広くお使いいただくことができます。ログ取得型だけではなくWebビーコン型の利用も容易です。テンプレートにトラッキングコードを書いておけば、そのテンプレートから生成される全てのページにトラッキングコードが自動で埋込まれます。

可能です。

WebRelease は静的コンテンツを生成するタイプの CMS であるため SEO 対策を自由に行うことが可能です。

• SEO を継続的に実施し続けるということは、実は小規模なサイトリニューアルを細かくくり返すということでもあります。そのためには、リニューアルへの対応能力の高い CMS を導入しておくことがどうしても必要となります。CMS を導入していないと、SEO 対策を繰り返す過程でページを個々に修正して対応する必要が生じてしまい大変なコストがかかってしまいます。WebRelease を導入してコンテンツのテンプレート化を進めておけば、テンプレートを修正するだけで全ページを一括更新できるなど、SEO の作業効率を大幅に改善できます。
• SEO の観点から見た時に、その効果が期待できるパターンをテンプレート化することで、効果パターンの再利用が可能となります。WebRelease の自由度の高いテンプレートがさまざまな効果パターンのテンプレート化を支援します。
• WebRelease の目次の機能を効果的に使うことで、多軸のインデクシングを簡単に実現することができます。

SEO において良い結果を得るためには、適切なテクニックを応用することも大切ですが、同時に、テーマに沿った良いコンテンツを潤沢に保有すること、そして、そういった良いコンテンツを開発し、ブラッシュアップしてゆける環境を CMS によりサポートしておくことも重要なのではないでしょうか。

ありません。

メルマガの原稿を生成する用途にはご利用いただけるかもしれません。

ありません。

WebRelease を使うと 10,000 ページ規模のサイトでも数名から十数名程度で運用管理できるようになるため、あまり大勢で WebRelease を利用するモデルは想定していません。

ありません。

テンプレートとは、コンテンツを作成する時に使用する雛形のことです。

多くの場合、サイトは「プレスリリース」や「製品情報」など、それぞれが一定のスタイルを持ったコンテンツ群の集まりとして構成されています。コンテンツのパターンごとにテンプレートを用意し、コンテンツを作成する時には、適切なテンプレートを選び、テンプレートの定義に従って必要な情報を入力してゆく方法を採れば、コンテンツのスタイルの統一を保ちながら、効率的にコンテンツを作成できるようになります。WebRelease では、基本的にすべてのコンテンツはテンプレートから生成されます。一方で javascript や css 等のような固定的なコンテンツはテンプレートを使わずに直接公開サーバに配信することも可能です。

ありません。

テンプレートはいくつでも作成できます。また、テンプレートを作成する時に使用する部品としてコンポーネントもいくつでも作成できます。テンプレート数やコンポーネント数がライセンス料に影響することはありません。

ある程度必要です。

PHP や Java のコードを記述したりする必要ありませんが Javascript が記述できる程度の基本的なプログラミングの知識は必要です。具体的には、条件文やループなどの WebRelease 独自の拡張タグと関数を利用して作成していきます。

最近の実践的な Web サイトのコンテンツにはスクリプトが多用されている場合が多いのではないでしょうか。そういう意味では、ある程度のプログラミングスキルを持っていないと Web サイトの構築自体が難しい時代であるとも言えそうです。

テンプレートの開発には、そういった知識が必要ですが、一旦作成されたテンプレートを使ってコンテンツを制作する段階では、プログラミングの知識はまったく必要ありません。

HTML、スタイルシート、Javascript などで制作できる方であればある程度は対応可能です。

アクセシビリティ基準などへの準拠を考える場合、テンプレートの作成者はアクセシビリティに準拠するための HTML コーディングについて理解している必要があります。

テンプレートの作成や修正には、やはり、ある程度の試行錯誤が付き物です。計画していたテンプレートで目標が達成できるかどうかは、テンプレートを作成して使ってみてはじめてわかる場合もあるでしょう。そういった作業を安全に効率よく行うためには、本番環境とは独立した開発環境 (Developer Edition) をご用意いただくのが安心ではないかと思います。

WebRelease の拡張タグを使用します。下記のタグが使用できます。普通は、これらのタグを HTML の中に織り交ぜて使います。生成するコンテンツが HTML ではない場合にもこれらのタグが利用できます。

• wr-if wr-then wr-else
• wr-conditional wr-cond
• wr-switch wr-case, wr-default
• wr-for
• wr-break
• wr-variable wr-append wr-clear
• wr-return
• wr-error
• wr-- wr-comment

上記タグの他に 80 種類以上の組込み関数、10 種類以上の組み込みオブジェクトが使用できます。

テンプレートやコンポーネントにはユーザ定義のメソッドを定義することができます。ユーザ定義メソッドは組み込み関数と同様に呼び出して使用することができます。

使えます。WebRelease では HTML に限定されることなく、テキストで表現可能なコンテンツを自由に作成することができます。

CSS の場合にも、それを普通のページとして作成して使用するのが一般的です。CSS を必要としている HTML ページから CSS を参照する部分の作り方は、普通の HTMLページから他の HTML ページへのリンクを作成する場合と基本的に同じです。WebRelease では、リンク関係は目次と呼ばれる関連を定義する要素を使用すれば簡単に作成することができます。

できます。WebRelease のテンプレートに用意されている「目次」という要素を使うことで柔軟に実現できます。

• 目次を使って記事一覧（新着ニュース一覧など）を作成します。
• 一覧に掲載したいページは、対応する目次に掲載します。テンプレート側の指定により、特定の目次に自動的に掲載することができます。または、ページ作成時に掲載する目次を指定することもできます。
• 一覧ページ側では、目次に掲載されているページのタイトル、抄訳、サムネイルなどを、自由表示できます。もちろん、ページへのリンクも生成できます。
• 一覧ページ側では、wr-if などの拡張タグを使えば、目次に掲載されているページから、一覧表示する対象を細かくコントロールすることができます。
• ひとつのページは複数の目次に掲載することができます。例えば、ひとつのページを、新着一覧とカテゴリ別の一覧の両方に掲載することができます。
• どのページにも、任意個の目次を持たせることができます。

この仕組みをうまく利用してテンプレートを作成しておけば、ページ作成の度に、毎回、一覧ページ側の変更を行なう必要はなくなります。

一覧ページは後から作ることもできますので、コンテンツが溜まってきた段階で、新しい切り口の一覧ページを作るなども簡単に可能です。

可能です。

WebRelease には「目次」と呼ばれる要素があります。この要素は、具体的には WebRelease で管理されているページへのリンクの列（順序付き集まり）です。WebRelease では、必要な数だけ「目次」を作成し、それぞれに掲載するページをコントロールすることで、新着ニュース一覧や、カテゴリ別の製品一覧などを作成します。

ある目次にどのページを掲載するかは自由に決めることが可能です。基本的な方法は下記の二つです。

• 指定したテンプレート（複数指定可）で作られたページを全て掲載する。
• 各ページ側で、掲載したい目次をチェックボックスで個別に指定する。

さらに、目次に掲載されているもののなかから、実際にページ中で使用するものを条件により細かく選別することが可能です。例えば、掲載されているページ中に定義されている「カテゴリ」という項目（項目の定義はテンプレート作成時に自由に行えます）の値によって掲載をコントロールしたり、掲載を５件に限定する、また、１ヶ月以内の新着情報のみ掲載するなどの選別が可能です。選別は wr-for タグと wr-if タグの組み合わせで行えます。

選別を終えて目次の内容が確定したら、その目次を使って、目次に掲載されているページへのリンクを生成したり、目次に掲載されているページの一部分（例えばタイトルや概要、サムネール画像など）を引用してページ中に埋め込むなどの処理を行うことで選別結果に応じたページコンテンツの生成が行えます。

各ページは、同時に複数の目次に掲載された状態にしておくことが可能です。例えばあるページを「新着情報一覧」という目次と「製品一覧」という二つの目次に同時に掲載された状態にしておくことが可能です。この仕組みを使うことで、単純な階層構造では不可能なマルチインデクス（多軸インデクス）構成のサイトを効率的に運営管理することが可能になっています。

「ページID」は、WebRelease で作成された各ページに自動的に割り振られる、ページを識別するための ID です。

WebRelease で作成された各ぺージはそれぞれ異なる「ページID」を持っています。あるページの「ページID」は、ページが作成された時に割り当てられ、以後変わることはありません。また、「ページID」はサイト内では必ずユニークです。

削除されたページの「ページID」は永久欠番となり、再利用されることはありません。「ページID」は１６桁の３６進数となっていますので、枯渇する心配はありません。

テンプレートをダウンロードしてもそのテンプレートの中で参照しているサイトリソースはテンプレートと一緒にはダウンロードされません。

サイトリソースを参照しているテンプレートをダウンロードして他のサイトや他の WebRelease システムにアップロードする場合には、テンプレートをアップロードするだけでなく、そのテンプレートが参照しているサイトリソースをアップロード先のサイトにサイトリソースとして別途に登録してください。

テンプレートの展開の中に % 記号を書くとそれは要素の展開（埋め込み）の開始記号として解釈されてしまいます。テンプレートの展開の中で '%' を使う場合には、'%' 文字を２つ続けて '%%' と記述してください。たとえば、

<span style="font-size: 90%%;">....

といった書き方になります。
JavaScript の中で '%' を使う場合も同様の方法でエスケープしてください。

WebRelease には会員管理の仕組みはありません。会員サイトの構築には会員管理を行なうシステムとの連携が必要です。

会員サイト（会員だけが閲覧できるコンテンツと、会員以外でも閲覧できるコンテンツの両方を保有しているサイトで、会員のログインにより会員だけが閲覧できるコンテンツが閲覧できるようになるサイト）の実現には、会員管理を行なうための「会員データベース」が必要になります。この会員データベースの周辺にはさまざまなアプリケーションが必要になります。

• サインナップのためのアプリ
• パスワードを忘れてしまった会員をサポートするためのアプリ
• 会員の登録情報を、会員自身が確認したり、変更したりするためのアプリ
• 退会のためのアプリ
• 多くの場合、メルマガを配信するためのアプリも必要
• サイト運営側が会員情報を参照／更新／訂正するためのアプリ
• 会員情報を保護するためのセキュリティ上の仕組み（成りすまし検知／不正ログイン検知／アカウント自動閉塞など）
• 会員データベースを安全に運用管理するための仕組み（バックアップ、稼働監視、災害対策系、など）
• その他

さらに、よりきめ細かな会員管理が必要になる場合は、下記のような情報も扱う必要が生じてきます。マーケティングオートメーションと呼ばれる領域に接近する方向性と考えてよいでしょう。

• 会員のサイトの閲覧履歴などの情報の管理
• 会員とのあらゆる接点に関する記録の管理
• 会員のオフラインでの行動履歴の管理
• 会員のサイト外での行動履歴の管理
• その他、会員にまつわるあらゆる情報の管理

WebRelease にはこういった会員管理機能はありませんので、会員サイトを構築するには、何らかの、できるならば、しっかりとした会員管理システムと連携する必要があります。

会員管理システムとの連携が前提となれば、会員サイトの構築はそれほど難しくはないでしょう。一般的には、ページ内の細かいパーソナライズを必要としないのであれば、比較的簡単に会員サイトを構築できると考えてよいと思います。ページ単位での見える／見えないの制御の範囲であれば制御が簡単な場合が多いようです。但し、会員サイトのニーズはさまざまなので、実装のコストや難易度もさまざまと言わざるを得ない面があります。個別に検討する必要があります。

• 会員管理を SNS に委ねる、いわゆるソーシャルログインを利用できるかもしれません。制限もありますが簡単さには魅力もあります。この方式を採用すれば会員データベースの運用管理を SNS 側に委ねることができます。
• 会員管理のシステムを開発することはあまり簡単なことではありません。安易に開発に着手することは避けた方が良いかと思います。
• WebRelease は html だけでなく、例えば php などのスクリプトを含むページの管理も可能です。（但し php タグの部分はプレビューできません）会員サイトの構築で必要になる動的ページを WebRelease で管理することができる場合があります。
• サイトを効率よく運営するためにはしっかりとした CMS を導入することが重要です。CMS としての機能・性能・安定性が不十分な状況では会員サイトの運営は上手く行かないでしょう。

WebRelease は静的コンテンツ生成型の CMS なので、店舗検索やイベント検索などのページの作成には一工夫必要です。

普通は javascript を上手く利用するのが一番簡単でしょう。サーバ側に php などの簡単なスクリプトを設置する方法も手軽な方法です。

ここでは、例として、イベント情報の検索ページを作成するケースをご紹介します。
典型的な方法を二つほどご紹介しますが、実装のバリエーションはいろいろありますので、ここでご紹介する方法をアレンジするなどしてニーズにあった方法で実装してください。

方法１：インデクスファイルを使う

検索用にインデクスファイルを生成しておき、それをブラウザ上の javascript またはサーバ上の php などで検索する。

(1) イベントごとに「イベント情報ページ」を作成します。

イベント情報ページ用のテンプレートを作成し、イベントごとにそのテンプレートを使用してページを作成します。イベント情報ページには、イベントの「日時」「場所」「イベント種類」など、公開したい情報を入力します。

必要があれば「イベント一覧ページ」も生成するようにします。イベント一覧ページを生成するテンプレートを作成しておくことで、個々のイベント情報ページの作成や更新に同期してイベント一覧ページを自動で生成・アップロードすることができるようになります。

(2) 検索用のインデクスファイルを json ファイルとして作成します。

すべての「イベント情報ページ」をベースにして、その「日時」「場所」「イベント種類」「イベント情報ページの URL」などからなるひとつの json ファイルを生成します。プログラム処理用のイベント一覧ページ（インデクス）を生成しておくというイメージです。

インデクスファイルは、そのフォーマットが json である点を除くと、閲覧者用のイベント一覧ページとほぼ同じ内容になると考えてよいでしょう。作り方もほぼ同じです。

インデクスファイルを生成するテンプレートを作成しておくことで、個々のイベント情報ページの作成や更新に同期してインデクスファイルを自動で生成・アップロードすることができるようになりますので、インデクスファイルのメンテナンスの作業は特に発生しません。

(3.1) 検索機能はブラウザ上で javascript で実装します。

検索スクリプトはサーバ上にある json ファイルを GET し、その中から入力された検索条件を満たす対象を抽出します。抽出結果から動的に html を生成して検索結果ページを描きます。

インデクスファイルのサイズが 1Mbyte 程度以下であればこの方式で十分ではないでしょうか。サーバ負荷も発生しませんし、サーバとのやりとりがないので検索は高速に動作します。

インデクスファイルのサイズが 1M byte を超えて大きくなってくると、それを GET するのに要する時間とトラフィックが無視できなくなってくるかもしれませんので、サーバ側での検索実装を考える必要がありそうです。

(3.2) 検索機能はサーバ側に設置した php などのスクリプトで実装します。

ブラウザに表示した検索フォームの検索条件データを php などのスクリプトで受け取り、json ファイルから検索結果を抽出し、結果に応じて動的に生成した html を返すようにします。この方式であれば javascript が動作しない設定になっているブラウザにも対応可能です。

検索リクエストを Ajax を使ってサーバに投げる方式を採用することも可能でしょう。その場合は、サーバ側のスクリプトは html ではなく json などを返せばよいので、html 生成をクライアント側に集約可能です。描画の自由度が高まる可能性があります。

ここでは json で説明しましたが xml でも同じように実装できるでしょう。

方法２：data- 属性を使用する

イベント一覧ページ中に表示する各イベントのエントリに data- 属性を付けておき、それを手がかりに javascript で検索を実行する。

(1) イベントごとに「イベント情報ページ」を作成します。この部分は「方法１」と同じです。

(2)「イベント一覧ページ」も生成します。

イベント一覧ページを作成するときに、イベントの各エントリ（例えば tr 要素に） data- 形式の属性（例えば data-event-kind="concert" など）を付けて html を生成しておきます。検索に使用したい属性に応じて複数の data- 属性を付けるぐらいで良いでしょう。

イベント一覧ページを生成するテンプレートを作成しておくことで、個々のイベント情報ページからイベント一覧ページを自動で生成・アップロードすることができます。

(3) 検索（絞り込み）機能は、イベント一覧ページに javascript として組み込みます。

検索スクリプトはページ中のイベントのエントリ（例えば tr 要素）の data- 属性の値を見ながら検索条件にマッチしているエントリを探します。条件にマッチしていないエントリには display: none ; などの css 指定をして画面から表示を消してしまいます。jquery などを使用すれば比較的簡単に実装できるでしょう。

検索対象の件数が 1,000 件程度未満であればこの方式で十分ではないでしょうか。サーバ側の負荷も発生しませんし、サーバとのやりとりが無いので検索は高速に動作します。

いずれの方法で実装するにせよ、検索機能をどういう使い心地にしておきたいのかによって、検索の実装方法をアレンジする必要はあるでしょう。

WebRelease は php を生成することができるので、検索用の php スクリプトは WebRelease から配信することができます。

10 万件を超えるアイテムを検索する必要がある場合であっても、必ずしも RDBMS を使った検索システムの導入が必要とは限りません。インデクスファイルを使う方式でも I/O を抑制するキャッシュなどを適切に実装すれば、簡単なスクリプトでの検索実装も十分に実用的です。

はい、ロック機構があります。

あるスタッフが編集中のページは、そのスタッフによってロックされるので、他のスタッフは編集できません。

システム管理者権限を持つスタッフは、このロックにかかわらずページの編集が可能です。また、不都合なロックを解除することができます。

テンプレートの修正も、同様のロック機構で保護されています。

システム的な制限はありません。階層構造は自由に策定してください。

ページを作成し、それを公開した後で、そのページを修正しなければならない状況を迎えた場合を想定してみます。そのページの編集作業中に、他のページを公開するために FTP などの処理を起動した場合の WebRelease の動作について簡単に説明します。

WebRelease は、いったんあるページを公開すると、そのページの公開されたリビジョンを変更が加えられない書き込み禁止のリビジョンとして保全します。

公開中のページを再編集している最中に、他のページを公開するためなどの理由で FTP 等の処理を起動した場合には、WebRelease は、全てのページについて内部的にコンテンツの再生成を行います。これは、コンテンツ自体に修正が加えられていなくても、ページの追加や削除、更新にともなって、インデクス（目次要素）に間接的に変更が発生している可能性があるためです。この時、既に公開されているページに関しては、編集中のリビジョンではなく、前回公開を行った時のリビジョンを使用してコンテンツ再生成が行われます。従って、編集中のコンテンツが公開されてしまったり、編集中のコンテンツがあることが原因で他のコンテンツの公開ができないといった様なことは起こりません。（公開中のリビジョンの削除はできません）

尚、実際に公開サーバに転送されるのは、内部的に再生成された全コンテンツではなく、前回転送からの差分のみです。 （全コンテンツを再転送することも可能です）

できます。

WebRelease では、作成中のコンテンツをいつでも Preview して出来映えをチェックすることができます。Preview はほぼ完全な形で行えます。Preview は編集画面とは独立した、ブラウザの別ウインドウ（別タブ）で行なうことができますので、作成中のコンテンツと WebRelease の CSS やスクリプトが干渉を起こすような問題は発生しません。Preview しているページ内のリンクも全て動作ますので、他のページへのリンクをクリックすれば、リンク先のページを Preview することができます。

Preview する時に時刻指定をして未来時点でのコンテンツの状態をチェックすることができます。記事一覧などで時刻指定すれば、未来のいつの時点でどの記事がリスティングされるか、などもチェックすることができます。

Preview のために事前にステージングサーバへの転送を行う等の作業は必要ありません。コンテンツの作成途中に、いつでもすぐに Preview 可能です。

はい。できます。

コンテンツ作成の作業を PC で行っている状況で、ターゲットとなるスマートフォンなどのデバイスでの表示状態を実デバイスで Preview したいことは多いと思います。 WebRelease には Preview のための URL を QRCode に変換して表示する機能がありますので、それをデバイスのカメラで撮影するなどして簡単に実デバイスで Preview することができます。

QR コードを使わなくても、スマートフォンで直接 WebRelease にログインして Preview することも可能です。また、Preview だけが可能な one time の短縮 URL を生成できますので、それをお手元のスマートデバイスに手入力することで、実端末で Preview をすることもできます。

あります。

現在のバージョンでは、あまり大きな画像や添付ファイルはうまく扱えません。1 件あたり 100M Byte 程度が上限の一つの目安となります。

添付ファイルの個数と総量には特に上限はございません。

設定できます。

テンプレート側で、入力フィールドごとに、入力可能なファイルのサイズの上限を設定することができます。上限が設定されている場合、コンテンツ作成（入力）時には、指定されている値より大きな画像や添付ファイルを入力することができなくなります。

できます。

テンプレート側で、入力フィールドごとに、入力可能な画像サイズについて、ピクセル単位で幅と高さの上限と下限を設定することができます。制限を設定すると、コンテンツ作成時には、この上限と下限に合致しないサイズの画像は登録できなくなります。

配置できます。

WebRelease は WebRelease で管理しているコンテンツ以外には触れません。ですから、WebRelease の管理外のコンテンツを公開サーバ上に別途アップロードしておいても、WebRelease がそれを削除したり、上書きしてしまうことはありません。

但し、別アプロードしたコンテンツのファイル名が WebRelease で管理しているコンテンツのファイル名と衝突しないように注意してください。衝突していると WebRelease はそのファイルを上書きしたり、削除したりすることになります。

はい、ページのリビジョンを残しておくとストレージ容量も増えます。充分なディスク容量を確保していただくか、適宜、不要になったリビジョンを削除しながら運用していただくのが良いと思います。

尚、リビジョンの削除によりディスクの残量が回復するのは、いわゆる、ガーベッジコレクションが実行されたあとになります。リビジョン削除直後ではありませんのでご注意ください。

可能です。一般的にはシステムが自動で設定するユニークなファイル名をそのままお使いいただければことたりると思います。自動設定されるファイル名はページIDとテンプレートで指定したサフィックス (.html や .xml など) を連接したものとなります。

しかしながら、もし必要があるならば、ページごとにファイル名を直接指定することも可能です。

index.html や rss.xml など、意図的なファイル名を使用したい場合には、そのページ（コンテンツ）に対してファイル名を明示的に指定することができるようになっています。

ファイル名を明示的に指定する場合にはファイル名の衝突にご注意ください。ファイル名の衝突はコンテンツ公開時点 (FTP時) にチェックされます。衝突がある場合にはコンテンツのアップロードは行なわれません。(チェックをバイパスしてアップロードを強行することも可能です)

使えません。コンンツ入力時には WebRelease の拡張タグや関数は使えません。

これらの記法を使用できるのはテンプレートやコンポーネントの定義内に限られます。コンテンツ入力時には、WebRelease の拡張タグ等の知識は必要ないということでもあります。

はい。

アクセシビリティの規準に則りページを制作することが可能です。

はい、可能です。

WebRelease のアップグレードを行なう場合であれば、動作検証の為に、30日間に限り 2 台のサーバに WebRelease をインストールし、新しい WebRelease の機能や操作性、性能等を検証いただけます。

それ以上の期間が必要になる場合は Developer Edition 等のご購入をご検討ください。

保たれます。

WebRelease をバージョンアップしても、お使いの WebRelease 上で作成されたデータは、そのまま後継バージョンでお使いいただけます。

WebRelease は 2003 年の Version 1.0 発売以来、これまでに 2.0 → 2.1 → 2.2 → 2.3 → 2.4 → 2.5 → 2.6 → 2.7 とバージョンアップを繰り返してきましたが、バージョン間でのデータの互換性を維持し続けることに成功してきています。

システムの機能や効率を改善するために行われるバージョンアップにおいては、新バージョンのデプロイに伴ってデータのコンバージョンが必要になる場合が考えられますが、その場合でも、新バージョンに自動コンバータが組み込まれて出荷されますので、面倒なコンバージョン手順を実施していただく必要はありません。

尚、コンバージョンに伴って、一時的に大きなコンピュータリソース（メモリ、ディスクなど）が必要になる場合が考えられなくもありませんが、もし、そのような状況でお困りの場合には弊社までご相談ください。

保たれます。

WebRelease では、WTL (WebRelease Template Language) という言語　(wr-for, wr-if などのタグ群と関数群から構成される簡単なテンプレート記述言語）を使ってテンプレートを定義します。WebRelease をバージョンアップすると WTL のバージョンも上がる場合があります。WTL のバージョンが上がると WTL の動作仕様も変化します。

WebRelease のテンプレートは、内部に「WTL バージョン」を保持しています。ある WTL でテンプレートを作成すると、その WTL バージョンがテンプレートに記録されます。テンプレートは、いつも、そのテンプレートに記録されている WTL バージョンに準じたテンプレートプロセッサで処理されます。つまり、あるバージョンの WebRelease は、それまでにリリースされた全ての WTL バージョンに対応可能なテンプレートプロセッサを有しています。

WebRelease をバージョンアップし、それに伴って WTL バージョンが上がっても、既存の各テンプレートは、それぞれのテンプレートに記録されている WTL バージョンに準じた WTL プロセッサで処理され続けます。従って WebRelease のバージョンアップによりコンテンツの生成結果が予期せずして変化してしまうことはありません。

ユーザは WebRelease のユーザインタフェースを使って、各テンプレートの WTL バージョンを必要に応じて最新のものに指定しなおすことができます。最新の WTL バージョンに指定しなおせば、そのテンプレートで最新の WTL の機能が使えるようになります。

新バージョンがリリースされると必ずリリースノートが作成されます。リリースノートには、新機能の説明や修正された不具合、動作環境等、リリースされた新バージョンについての情報が記載されます。

リリースノートは RSS で配信されます。また、本サイトの「サポート」→「リリースノート」及び「トップページ」に掲載されます。

できます。

新バージョンは保守の一環としてご提供させていただきます。保守の内容および価格等につきましては下記ページをご参照ください。

バージョンアップしても、コンテンツデータやテンプレートの互換性は保たれますし、旧バージョンの機能が使えなくなるということもありません。

可能です。コンテンツデータもそのまま引き継ぐことができます。

バージョンアップ前に最新バージョンの稼働環境を必ずご確認ください。お手元のメディアでインストールできない場合には、お手数ですが、最新版のインストールメディア WR02IM をご購入ください。

尚、可能な場合にはダウンロードによるバージョンアップを実施してください。

できません。

WebRelease 2.70 からエキスポートしたファイル（サイトアーカイブファイルやダウンロードしたテンプレートなど）は、2.70 固有の機能をサポートするためのデータ構造を持っています。従って、それを 2.60 にインポートしても正常に動作しません。例えば、テンプレート中で 2.70 にしかない関数や拡張タグを使用している場合、それを 2.60 にインポートしても該当する関数や拡張タグがないため、正常に動作しません。もし動作したとしても、作成時に意図した動作にはならないでしょう。

2.70 から 2.60 へインポートする場合に限らず、一般に、エキスポートしたファイルは、エキスポートした時のバージョンより古いバージョンの WebRelease にインポートしても正常に動作しません。

反対に、あるバージョンの WebRelease からエキスポートしたファイルは、エキスポート時と同じか、より新しいバージョンの WebRelease にインポートして使うことができます。

WebRelease 2.20 以降をお使いの場合には WebRelease Workgroup Edition から Enterprise Edition へのアップグレードにおいては WebRelease の再インストール作業は必要ありません。作成されていたコンテンツデータもそのまま引き継いでお使いいただけます。

WebRelease 2.20 以降では WebRelease Workgroup Edition から Enterprise Edition へのアップグレードは WebRelease の「アップグレード」機能で行うことが可能です。アップグレードをご購入いただいた後で「最新版をダウンロード」からアップデートファイルをダウンロードしていただくと、アップグレード後のエディションに合致した更新ファイルがダウンロードできます。ダウンロードした更新ファイルでお使いの WebRelease Workgroup Edition をアップデートしていただくことで Workgroup Edition から Enterprise Edition へのアップグレードが完了します。

WebRelease 2.1 以前には「アップグレード」の機能がありません。従って WebRelease 2.1 以前の Workgroup Edition から最新版の Enterprise Edition へのアップグレードを行う場合には WebRelease を CD から再インストールする作業が必要です。この作業はアップグレードをご購入いただいた際に、弊社パートナー各社を通じて、または弊社から直接お届けする WebRelease Enterprise Edition (WR02E) の製品パッケージ(CD)に同梱されているインストールマニュアルに従って行ってください。この場合でも、すでに作成されているコンテンツデータは引き続きご利用いただけます。

なお、Workgroup Edition と Enterprise Edition は異なるソフトウェアとして提供させていただいております。Workgroup Edition を Enterprise Edition としてアクティベートする方法はありません。

はい、できます。

WebRelease は、管理しているサイトを export し、手元の PC にダウンロードすることができます。WebRelease から export したサイトデータの形式は WebRelease のエディションには依存していません。また、OS の種類にも依存していません。従って、export されたデータは、任意の WebRelease に import (upload) することができます。

但し、サイトを Workgroup Edition に import する場合には、import 後のトータルのページ数が Workgroup Edition の上限である 500 ページ以下である必要があります。500 ページを超えてしまう場合には import はできません。

Let's Encrypt で取得した正規の SSL 証明書は、下記の WebRelease 以降から正しく認識されるようになります。

• WebRelease 2.70C 以降 (JRE 8u111)
• WebRelease 2.60Q 以降 (JRE 8u111)

• 外部リンクチェック先のサイトが Let's Encrypt の証明書を使用している場合にリンク切れとして判定される
• XMLリーダを使って xml ファイルを取得する時に、取得先のサーバが Let's Encrypt の証明書を使用していると xml ファイルを取得できない。

ページの編集には「ライター」権限が必要ですが、場合によっては、「ライター」権限を持つスタッフに対してもページ一覧画面上でページの「編集」ボタンが表示されない場合があります。表示されない理由としては、下記の場合が考えられます。

そのページの編集が「デザイナー」権限を持つスタッフに制限されている

ページ編集画面で「変更を禁止」の欄で「編集」を禁止している場合には、そのページの編集には「デザイナー」権限が必要になります。css などのためのページではこのような設定がなされている場合がありそうです。

他のユーザが編集中

他のユーザが編集中のページについては、編集しているスタッフ以外には編集ボタンは表示されません。この場合、ページの状態は「編集中」になっています。「最終更新者」の欄にはそのページを編集しているスタッフが表示されています。

公開待ちのページの編集

公開待ちのページを編集するには、一旦「公開待ち」をキャンセルし、編集中にする必要があります。公開待ちをキャンセルすることができる「エディター」権限を併せ持っているユーザでなければ公開待ちのページは編集できません。

承認フローを経由して公開待ちとなっているページの編集

承認フローによる公開管理が必須と指定されているフォルダに置かれているページの場合は、公開待ちをキャンセルしてページを編集するためには「エディター」権限に加え、承認結果を覆すための「マネージャー」権限が必要になります。

テンプレートの利用権限がないページの編集

そのページの作成に使用されているテンプレートの利用権限がないスタッフは、そのページを編集することはできません。

WebRelease を稼働させているサーバのディスクの残量が不足している可能性があります。または、ディスク装置周辺にハード的な故障が発生している可能性があります。確認してみてください。

いずれの問題もないと考えられる場合には、弊社サポートまでご連絡ください。

FTP を実行すると FTP ログに empty path というエラーメッセージが記録され FTP が失敗する場合があります。

このエラーは、いずれかのページ、添付ファイル、画像に、アップロード先の公開サーバ上でのファイル名が指定されていない場合に発生します。エラーメッセージが empty path というだけの不親切な物であるため、該当するページ、添付ファイル、画像の特定が難しくなっています。

2.60M 以降にバージョンアップしていただければ、どのファイルに問題があるのかわかるようなメッセージになりますので、それを手がかりにファイル名が指定されていない箇所を特定し、適切にファイル名を指定していただければ解決することができるでしょう。

2.60M 以降にすぐにバージョンアップできない場合は、最近修正したページとそのページ中にある画像や添付ファイルについて、ファイル名が指定されていないものを目視にて探していただき、ファイル名を適切に指定していただければ解決できるでしょう。サイトの操作履歴を参考にしていただければ、最近修正したページをすぐに見つけることができるでしょう。

WebRelease に接続しようとすると、ブラウザに「Not Supported」と表示され、接続できない場合があります。下記のケースが考えられますので、ご確認ください。

• Version 2.60M 以降の WebRelease (含む 2.70 以降) には、IE 7 以前のブラウザからは接続することができなくなりました。接続を試みると「Not Supported」のメッセージが表示されます。お使いのブラウザが IE である場合には、そのバージョンが 8 以降であることをご確認ください。
• IE 8 以降を使用している場合でも、ブラウザが旧 IE のエミュレーションモードで動作している場合に、やはり「Not Supported」が表示され接続することができません。IE のモードをご確認ください。IE のモードは「F12 開発者ツール」の「エミュレーション」画面で確認・設定変更できます。
• IE のモードには「ドキュメントモード」の設定と「ユーザーエージェント文字列」の設定がありますが、WebRelease は接続しているブラウザを「ユーザーエージェント文字列」に指定されている文字列で判定します。この文字列には「Internet Explorer 8」（以降）を指定してご利用ください。
• IE には「互換表示設定」という設定項目があります。（IE11 の場合 ツール → 互換表示設定) この設定で、WebRelease サーバが互換表示の対象に指定されている場合「Not Supported」の対象となります。
• IE には「イントラネットサイトを互換表示で表示する」という設定項目があります。(IE11 の場合、ツール → 互換表示設定)この設定が ON になっていている場合に「Not Supported」の対象となる場合があります。この設定を OFF にして使用していただくか、または、WebRelease サーバがお使いの IE のイントラネットに該当しないように IE を設定してお使いください。イントラネット該当の指定は、IE11 の場合、ツール → インターネットオプション → セキュリティ → ローカルインターネット → サイト で設定できるようです。
• IE の設定につきましては Microsoft 社からの情報を参照して実施してください。
• WebRelease は IE のバージョンの判定には User-Agent を使用しています。User-Agent の値を変更しているブラウザや proxy サーバ経由でのアクセスでも「Not Supported」になる場合があります。

各ユーザのパスワードは、ユーザ本人、または、「システム管理ユーザ」権限を持つユーザによって設定可能です。パスワードを忘れてしまった場合には、システム管理ユーザ権限をもつユーザに、パスワードの再設定を依頼してください。

WebReleaseシステムに登録されているシステム管理ユーザが、全員、パスワードを忘れてしまい、だれもシステム管理ユーザとして振る舞えなくなってしまったら、残念ながら、パスワードを復活する方法はありません。くれぐれも、システム管理ユーザのパスワードを忘却しないように注意してください。

万が一の場合に備えて、常に２人以上のユーザにシステム管理ユーザ権限を付与しておくことをお勧めします。もし一方のユーザがパスワードを忘却してしまったり、なんらかの事情で WebRelease を利用できなくなってしまった場合にも、システムの運用を続けることができます。

WebRelease にログインしていたユーザのセッションがタイムアウトしている状態で Preview 画面をリロードすると NotFound が表示されます。再度ログインしなおしてから作業を再開してください。

典型的に予想される原因はメモリの割り当てパラメタの指定不良です。

WebRelease に割り当てているメモリの量を確認してください。この割り当て量が、サーバに搭載されているメモリ量に対して大きすぎるとこのような症状になる場合があります。このケースでは、仮想記憶が激しく動作することが原因でシステム全体のパフォーマンスが劣化します。

この状態であると考えられるならば、WebRelease に対するメモリ割り当て量を少し減らしてみてください。

もう一つの可能性は、WebRelease に対するメモリ割り当て量が少なすぎる場合です。WebRelease をインストールして使いはじめたころには、コンテンツ量も少なかったために必要メモリ量も少なく、WebRelease も快調に稼働していたのに、コンテンツ量が増えて来たために、メモリ量が不足しはじめていてパフォーマンスが劣化しているのかもしれません。このケースでは、メモリ不足が原因で WebRelease の実行環境である java のガーベッジコレクションと呼ばれる機能が過多に稼働するため、WebRelease のパフォーマンスが低下してしまいます。

もし、この症状が起きていると思われるのであれば、オペレーティングシステムと、サーバ上で稼働する WebRelease 以外のアプリケーションが必要としているメモリ量を侵蝕しない範囲で、可能な限りのメモリを WebRelease に割り当ててみてください。

もし、メモリ不足であると感じたならば、メモリの増設を検討してください。または、不要なプロセスを起動しないようにオペレーティングシステムの設定を変更して(例えば、runlevel を 5 から 3 に変更するなどして Window System を起動しない状態にするなど)空きメモリをつくり出すことで対応できる場合もあります。

お手数をおかけしますが、お問い合わせは info@frameworks.co.jp 宛にメールにてお願いいたします。

ご使用の WebRelease のバージョンはログイン画面に表示されています。ユーザID入力フィールドの右上に書かれている記号がお使いの WebRelease のバージョンです。

WebRelease2 のバージョン番号は、以下のような形式をしています。（この例は Version 2.60A のケースです）

メジャーバージョン番号

大きな機能変更・機能追加が行われた場合には、このメジャーバージョン番号が更新されます。バージョン番号の違うバージョンは機能に違いがあります。また、稼働環境なども異なる場合があります。

マイナーバージョン番号

マイナーバージョン番号は 0 から採番され 9 まで更新されます。マイナーバージョン番号の違うバージョンは機能に違いがあります。大きな機能変更ではなく、比較的小さな機能追加が行われた場合には、メジャーバージョン番号ではなく、マイナーバージョン番号を更新してバージョンの違いを表現しています。マイナーバージョン番号が異なる WebRelease は稼働環境なども異なる場合があります。

Bug Fix レベル

あるバージョンの WebRelease にどこまでバグフィックスが適用されたバージョンであるかがわかる記号です。A から順にアルファベット順に設定されます。Bug Fix レベルだけが異なるバージョン間には機能の違いはありません。例えば 2.60A と 2.60B は機能面では同一です。一方、Bug Fix レベルが異なるバージョンは動作環境等が変更になっている場合があります。

そのようなことは起こりません。それらのファイルもページに設定したタイミングで公開／公開終了します。

ありません。

WebRelease は公開サーバ上のコンテンツを更新する際、不要になったファイル（例えば、公開終了となったページや削除された画像など）を自動で削除します。古くなった不要ファイルがサーバ上に残ることはありません。

WebRelease を稼働させているサーバにログインし、下記のコマンドを実行することで WebRelease の起動・停止をコントロールすることができます。

# systemctl start webrelease2.service

# systemctl stop webrelease2.service

# systemctl restart webrelease2.service

# cd /etc/init.d
# ./webrelease2 start

# cd /etc/init.d
# ./webrelease2 stop

# cd /etc/init.d
# ./webrelease2 restart

# launchctl load /Library/LaunchDaemons/jp.co.frameworks.WebRelease2.plist

# launchctl unload /Library/LaunchDaemons/jp.co.frameworks.WebRelease2.plist

# cd /Library/StartupItems/WebRelease2
# ./WebRelease2 start

# cd /Library/StartupItems/WebRelease2
# ./WebRelease2 stop

# cd /Library/StartupItems/WebRelease2
# ./WebRelease2 restart

いいえ、使用していません。Struts / Struts2 に起因する脆弱性についてご心配いただく必要はありません。

いいえ、使用していません。Spring Framework に起因する脆弱性についてご心配いただく必要はありません。