PleskのWordPress Toolkitを使い倒してみる。
こちらは、#CloudGarage Advent Calendar 16日目のブログです。
4日目のブログではPleskサーバにWordPressをマイグレーションし
11日目のブログではWordPressを5.0にアップデートしました。
今回は、細かいWordPressの管理の話をしていきたいと思います。
まず、WordPressをインストールしたらとりあえずやっておくべきなのは、PHPの追加ディレクティブ編集です。
何が言いたいのかというと、WordPressをただインストールしただけだとアップロード可能な画像サイズが小さく、スマートフォンで撮影した写真さえもそのままアップロードできません。
そこで、PHPにその記述を追加するのですが、PleskならこれもWebインターフェイスから追加するだけです。
管理しているドメインの画面から、PHP設定を選択します。
ウインドウが開いたら一番下までスクロールして追加情報を入力します。
これだけです。
通常だと、PHPのファイルか、.htaccessなどを書き換えるのですが、慣れてないと設定ファイルを直接いじるのはちょっと怖いですよね。
でも、Pleskならここに入力するだけなので、それほど不安に思う必要はありません。
余談ですが、PleskはPHPのバージョンをドメインごとに変更することができます。
前回、ステージングサイトを作ってアップデート検証をやる方法をご案内しましたが、PHPのアップデートをする時も同様にステージング機能が使えます。
staging.*****.***というサブドメインでステージング環境を作りますので、ステージング環境と本番環境でPHPのバージョンを別けられるからです。
本題に戻りましょう。
今日はこの画面の便利な機能を紹介していきます。
早速ですが、セキュリティが危険、アップデートは適用可能ということで、注意の色になっています。
この辺りの色は世界共通と言いましょうか、緑は安全、黄色は注意、赤は危険。という配分です。
まずは危険なセキュリティから見てみましょう。
表示をクリックします。
様々なセキュリティ上の問題点が指摘されていますが、その中でも危険なものについては、WordPress Toolkitが自動的に問題を解消してくれます。
具体的に何がダメでどうするべきなのかは、インフォメーションのアイコンをクリックすれば表示されます。
この辺りはほとんど日本語化されていますので、そのあたりの心配もありません。
確認せずにアップデートだけやるのはあまり良くないのですが、テストサーバの強みと言いましょうか、せっかくなので全部適用してみましょう。
セキュリティ措置の左にあるチェックボックスにチェックを入れれば全て適用になります。そのあと、セキュリティ強化をクリックすれば開始されます。
途中の画面をキャプチャしたかったのですが、10秒くらいで完了してしまいました。
ということで完了した状態。
もう安全です。
次はアップデートをみてみましょう。
プラグインとテーマにアップデートがあるようです。
テーマに関しては使用していないテーマでもインストールしてしまっているとアップデート警告が出ますので、使わなくなったテーマなどは削除した方が良いかもしれません。
これもサクッとアップデートします。
今度はキャプチャできました（笑
さて、アップデート中なので横道にそれますが、右上にSmart Updateというのがあるのがわかりますか？
これは、Pleskが独自に開発した機能で、AI Updateの機能です。
$マークが付いてますので、これは有償機能になりますが、AIがアップデート前後でのスタイルの崩れなどを自動判別してアップデートするべきかどうかを判別してくれる優れものです。（大丈夫ならもちろんアップデートもします）
ちなみに、これは今回のテストサーバとは別のものですが、問題があるからアップデート前後の比較をせよ。という事で警告がでました。
ちなみに、この画面はPleskに付いているメンテナンス画面なのです。
この画面が崩れるという事なんでしょうか．．．
元の話に戻りまして、アップデートもインストールしましたので、全て安全な状態になりました。
さて、次に便利機能、メンテナンスモードをご紹介します。
右側のボックスのスイッチをクリックするとメンテモードが起動し、先ほどのメンテナンス画面に切り替わります。
このメンテナンスモードは、当然ですがユーザーの任意の形に設定できます。
メンテナンス中のメッセージなども入れられるほか、カウントダウンタイマーでリリースを自動化する事も可能です。
リリースが深夜や週末の場合は便利な機能ですね。
次にBasic認証の設定。
これは言うまでもありません、パスワード入れないとWordPressが表示されない設定です。改変途中のサイトを外部の人に見られたくないけど、クライアントには見せたい。なんて時には便利ですね。
それからnginxの設定ですね。これはもう定番ですが、nginxによるキャッシング機能を使う事で、Webサイトの表示速度を高速化することが可能です。
他に高速化というと、LitespeedやSpeedKitなどのエクステンションで高速化する方法がありますが、こちらは一部有料になりますので、必要性に応じてご判断ください。
そして、Debugツールですが、こちらはWordPressのデバッグツールを管理できるものです。ここから設定してデバッグを行うことが可能です。
そろそろ画面を変えてみましょう。
次はプラグインの設定です。
インストールをクリックすると、WordPress Toolkit上でプラグインの検索とインストールが可能です。
テーマも同様に検索とインストールが可能です。
検索は日本語でも問題ないのですが、そうすると日本語で設定されているものしか検出されませんので、ご注意ください。
テーマの場合は、その場でテーマの変更が可能になります。
テーマの設定を変えると、サムネイルの表示も変わるのでわかりやすいですね。
さて、ここまでは単一のWordPressを管理してきましたが、お仕事で管理されている方は複数の場合もありますよね。
この場合は、管理画面最上部のタブとその下のボタンが便利です。
例えばアップデートをクリックすると
どのサイトがアップデート済みで、どのサイトが未対応か一目瞭然。
右側の期限切れというのをクリックすると、アップデートが放置されているサイトだけ表示させる事も可能です。
また、プラグインの表示をすれば、どのプラグインがどこのサイトに使われているのかも表示できます。
というように、WordPressサイト単体の管理にも便利ですが、複数になるとさらに管理機能が便利になるのが、PleskのWordPress Toolkitです。
WordPressの管理にぜひ使ってみてください。
という事で、使ってみたいと思ってもらえましたらぜひ
からお申し込みください。
CloudGarage + PleskOnyxでWordpressを5.0にしてみた。
こちらは、#CloudGarageアドベントカレンダー11日目のブログ記事です。
前回のブログでPleskはWordPressの管理機能に力を入れているんだよ。
という話と、今使っているサーバからマイグレーションしましょう。
というお話をさせていただきました。まだ記憶に新しい方が多いと非常に嬉しいですが、そんな話あったっけ？という方は↑のリンクからどうぞ。
今回のお話は、そのWordPressの管理機能にフォーカスしますが、時を同じくしてWordPress5.0がリリースという話がありますので、アップデートするときにステージング環境を作る話をしたいと思います。
ステージング環境とは？
という事で、ステージング環境は何か？という話ですが、簡単に言えばアップデート等を行う時にテストをするための環境を言います。
稼働中かつ外部に公開中のサーバに対していきなりアップデートを行うのは、何が起こるか判らないというリスクがありますので、そのリスクを減らすために稼働中の環境と同じ環境をもう一つ用意してそこでテストを行います。
これはWordPressなどに限らず、システムの運用をしている場合テスト環境を用意するケースは多々ありますが、システムの運用規模に応じては本番環境と全く同じ環境を常時維持しているという場合もあります。
トラブルが発生した際にその環境で再現し原因を突き止めるなどもできるため、特に大規模なシステムでは並行運用するケースもあるようです。
また、アップデートの際に新規にテスト環境を立ち上げるケースもあるようですが、この場合テストを始めるまでに時間がかかります。
当然、どちらも一長一短あります。常に並行して環境を持つのは単純にコストが掛かります。メンテナンスもそうですが、仮想環境だとしてもそのサーバ費用等です。
ただ、常にスタンバイされてますので、検証などへの時間が短いというメリットがあります。
テストの際にステージング環境を都度作る場合、ステージング環境を作る。という事に手間が掛かりますので、この手間＝デメリットです。ただ、その時だけあれば良いので、サーバ費用などは抑えられます。
さて、いいとこ取り出来るとしたら如何でしょうか？
ステージング環境を都度作る必要があるが、比較的短時間にかつ自動的にステージング環境が構築でき、さらに同じサーバ内に作るため新規にサーバ費用など必要ない。
そんなステージング環境があれば最適だと思いませんか？
という事で、Pleskなら可能です。
より正確には、PleskでWordPressの運用をするなら可能です。
という事で、みなさんまずはPlesk17.8をご用意ください。
まだご用意いただいていない方はこちらをご参照ください。
ここまで文字ばかりでしたね。という事で画像も交えながら解説していきます！
前回、unknown.cloudというサイトを移転しました。残念ですがドメインの移転はまだやっていませんので、ドメインはplesk04.siteのままです。
現在WordPress 4.9.8で運用されています。
これをアップデートする前提で、まずステージングサイトを作成します。
少しアイコン小さいですが、複製をクリックしましょう。
下記のような画面に遷移します。
特段設定をしなければ、staging.plesk04.siteというサブドメインを自動作成してサイトを立ち上げるという事なので、お任せしてみます。
という事でOKをクリックします。
早速複製が始まります。
今回もコンテンツがほぼないため、数秒で完了したのはいうまでもありません。
という事でステージングサイト出来ました。
このステージングサイトの特徴は、データベースなども含めて複製する事です。
そのため、本番の環境に一切影響ありません。
早速ですが、5.0が使用可能。という事です。
早速使ってみましょう。
アップデート画面が左からにょきっと出てきますので、5.0を選択してアップデートを始めます。
こんな感じで右下にウインドウが出てアップデートをしてくれます。
完了したみたいですね。
幸いな事にこのテーマは特に影響を受けていないようです。
という事で、影響なしと判断できましたので、本番サイトにもアップデートを行います。
今回の場合は、WordPressのアップデートのため、本番側でも同じアップデート作業を行えば良いですが、オリジナルのWordPressサイトなどでコードの変更が発生している場合、コードの変更を反映させる必要があります。
という事で、同期という機能を使います。
再びのこれですが、今度は左の"同期"です。
今回は、ターゲットのサイトを選択してあげる必要がありますが、ターゲットを選択して同期します。
警告として、相手のWordPressが古いからアップデートするよ。というのが出ていますが、それを望んでいますので今回は無視します。
コンテンツコピーに際しては、何をコピーするのか選択する事が可能です。
今回は全部コピーしてしまいますが、ここは任意で選択してください。
ステージングしてるので心配はないのですが、復元ポイントを作成しながらすすめます。これも自動ですのでご安心ください。
もうそろそろ皆さんも見慣れましたでしょうか？いつも通りこんな画面が出てきて作業が始まります。
という事で出来上がり。
という事で、ステージングサイトの作成と同期完了の手順をご覧いただきました。
とっても簡単でしたね。
Plesk Onyxのステージング環境作成機能の特徴は、同じサーバ内にステージング環境を作るという点です。
もしこれが外部のサーバであった場合、トラフィックが発生しますので時間がかかったり、クラウドサービスの場合転送量課金が発生する事も予想できます。
Pleskの場合サーバ内部の問題ですので、そういった心配がありません。
また、PleskのもつDNSの機能により"staging"のドメインを追加しますので、ステージングサイトを外部から閲覧するのも、難しい設定など不要です。
という事で、WordPress 5.0にする前にPleskでぜひテストしてから進めてもらえれば幸いです。
CloudGarageだとあっという間にPlesk入りのVMが立ち上がりますので、手軽に進めてもらえるかと思います。
くどいですが（笑）その詳細はこちらをご参照ください。
WordPressサイトを手軽に移設してみる。
こちらは、#CloudGarageアドベントカレンダー4日目のブログ記事です。
Pleskは世界中でも代表的なコントロールパネルソフトウェアの一つです。
日本のホスティング事業者各社でも、Pleskは非常に多く採用されております。
今回、CloudGarageアドベントカレンダーに参加させていただきましたが、もちろんCloudGarageでも利用いただくことが可能です。
そのお話はこちらをご参照ください。
さて、Pleskは元々レンタルサーバ向けのコントロールパネルでしたが、最近はVPSやクラウドなどでご利用いただくシーンが非常に多くなりました。
理由は非常にシンプルな物で、サーバ管理などの作業を簡素化したい。という物です。特にWebの制作などを中心にされている方の場合、インフラ管理は専門ではありませんし、かといって2~3台のVMの管理のためにインフラエンジニアを雇うというのも現実味がありません。
そこで、Pleskのようなソフトウェアを使ってサーバ管理やセキュリティ対策などの作業を簡素化し、本業たるWeb制作などに時間をより多く割く。という訳です。
という事で、Pleskを使ってWordPressを管理すると楽だよ。という話を何回かに渡ってお話ししたいと思います。
いきなり弊社のWapuuが出てきましたが、オリジナルWapuuを作っちゃうくらい、PleskはWordPress管理周りの機能強化に力を入れています。
さてさて、このお話は積極的にPleskを使ってみましょう。という話です。
しかし問題になるのは、今ご利用中のサーバに後からPleskを入れられない。という事です。
PleskはOS上で動作するソフトウェアですが、すでに運用中のサーバにPleskを入れると不具合を引き起こします。
そこで、Pleskは真っさらな状態のOSに導入して使いますが、そうなると面倒なのがマイグレーションです。
ここまで来ましたので何となく察していただけたかもしれませんが、PleskにはMigrationツールがありますのでそちらをご紹介しようと思います。
もし、「試してみよう」という方は、Plesk Onyx(version 17.8)が入ったサーバをご用意ください。
くどいですが、そのお話はこちらをご参照ください（笑
Pleskへのログインなどは今回のお話からはすっ飛ばします。
もし需要があれば後日、、、
Migrationには、まずSIte ImportというExtensionsをインストールする必要があります。
これは、無料でご利用いただけるExtensionsになります。
サイドバーの拡張をクリックし、"Site Import"と検索してもらえればすぐに見つかるかと思います。
このExtensionsがマイグレーションの要になります。
インストールをクリックするとこんなウインドウが出て勝手にインストールします。
完了したらSite Importを開くとこんな画面になります。
サイトをマイグレーションして持ち込む先のドメイン名をクリックします。
今回は、テストドメインとしてplesk04.siteというドメイン名を付けていますが、ここは皆さんの任意のドメインになりますのでご注意ください。
*アクセスしていただいてもいいですが何もありませんのでご了承の程。
今回ターゲットにするのは、unknown.cloudというWordPressサイトです。
ドメインを見てもらえればわかりますが、これはunknown.cloudというドメインで運用中です。なお、こちらもこういったデモなどに使うために持っていますので、ブログの中身はありません。ご了承ください。
さてさて、話を戻しましてSite Importの画面に戻ります。
戻ってきたら、以降元のドメイン名を入れ、FTPアクセスが可能なユーザー名とパスワード入れます。
うまくいかない場合は、アドバンスドモードに切り替えると、ドキュメントルートの指定などができるようになりますので、そちらをご利用ください。
という事でOKをクリックしてみます。
キャプチャが遅くてスキャンも完了してしまったのですが、こんな感じで対象サーバに接続し、状態をスキャンするところが最初のステップです。
この時点ではまだコンテンツの移動をしませんので、時間的にはそれほどかからないと思います。
終わるとこんな画面です。
unknown.cloudの中にはいくつかのサブドメインとWordPressサイトがあるため、3つ検出されました。
ちょっとアップにしてみましょう。
今回欲しいのは、unknown.cloud本体ですので、これを選択します。
チェックボックスにチェックを入れたら、インポート開始です。
こんな感じでインポートが始まります。
ここからは、コンテンツ量によってかかる時間が違いますので、コンテンツ山盛りの場合は少し時間をおいてください。
完了するとこんな画面になります。
あまり時間がかかると、Pleskからログアウトしてしまうことがありますが、再ログインすれば作業は進んでいますので問題ありません。
完了しているようですね。
確認のため、WordPress Toolkitの管理画面を開いてみましょう。
site04.pleskにunknown.cloudのコンテンツを移動できました。
URLの部分をみてもらえればわかるかと思いますが、ちゃんとplesk04.siteサーバです。
これでWordPressサイトのマイグレーションは完了です。
実際には、ここからドメインの付け替えや、DNSの切り替えなどが発生しますが、切り替えが完了するまでの間両方のサイトを残しておけば、アクセスが出来なくなる可能性は低く、比較的安全に移行完了できると思います。
そんな訳で今日の話はおしまいです。
どうですか？マイグレーションって思いの外簡単です。またマイグレーションはファイルをコピーしているだけですので、マイグレーションするだけなら元のサイトに影響を与える事はありませんので、まずは試しにマイグレーション。から如何でしょうか？
