AWSからエックスサーバーの「wpXクラウド」に乗り換えました(比較あり)

2017年2月3日
Web制作, WordPress

このブログはWordPressを使って作られています。これまではAWSでホストしていましたが、何だか割に合わなくて… 普通のレンタルサーバーに乗り換えました(笑)。 ちなみに、AWSでは、EC2(t2.micro) + RDS(db.t2.micro)、とほぼほぼ最小構成で、月額3000円くらいかかってました。 新たに契約したのは、エックスサーバーさんが提供している「wpX」というWordPressに特化したレンタルサーバー&クラウドサービスです。ニーズに応じて「wpXレンタルサーバー」と「wpXクラウド」が選択できるらしいです。 今回は「wpXクラウド」にしました。個人的に感じたメリットは「初期費用0、月額500円~、今後PV数が増えた時にグレードアップできる」といったところでしょうか。 2つのサービスの比較表はこちらです。 せっかくなので、パフォーマンスを比較してみました PV数はそれこそ雀の涙よりも少ないので… wpXクラウドのほうでもやはり最安プラン(グレードA)にしました。 AWSと比較して、コストパフォマンスがどうなのか、比較してみたいと思います。 テストプラン テストするのに JMeter を使いました。 毎秒同時接続数50 × 5回 でテストした結果です(Nginxによるページキャッシュなし)。

LaravelベースのWordPressテーマフレームワーク「Laraish」のご紹介

2017年1月19日
Web制作, WordPress

一言まとめ WordPressのフレームワークはいろいろあるけど、MVCを取り入れたものがほとんどない。あってもフレームワーク自体がしょぼい。 それならフルスタックフレームワークのLaravelをWordPressで使いましょう! 仕事でよく企業様のコーポレートサイト制作にWordPressを利用しています。当然ですが、企業のHPですから、デザインは独自のものになります。なので、スクラッチから作成するのが常です。 スクラッチとは言っても、ゼロからではさすがにナンセンスですので、何かしらのフレームワークは使いたいものです。選択肢は実にたくさんあります。 ページビルダー機能を提供しているフレームワークもありますが、常にごりごりにカスタマイズする必要があるので、まだ仕事で使ったことがありません。個人的には機能がシンプルなものが一番合います。 ただ、最大の問題はそこではなく… ページビルダー機能がいいとか、シンプルがいいとか以前に、WordPressのテーマの作り方自体にあまり好感が持てません。そう、オーソドックスなMVC方式で作りたいのです! そこで1つアイディアが浮かびました。「Laravel (PHP界隈で最も人気なフルスタックフレームワーク)をWordPressテーマの中でも使えるようにできないのか?」と。 そして作ったのが表題の「Laraish」です。 WordPressテーマの中で動くLaravel Laravel はPHP用のWebアピリケーションフレームワークです。「美しいコード、洗練された文法、そして表現力の高さ」として知られています。一度使ってみれば確実に恋に落ちるやつですw Laraish は そんな Laravel を WordPress でも使えるようにするテーマです。目的は、もっと楽に、もっと楽しく

WordPressの「メディアライブラリ」のインポートが上手く行かない時の解決法

2016年11月22日
Web制作, WordPress

一言まとめ [ツール]→[エクスポート/インポート]で「メディアライブラリ」のインポートが上手くいかない。 ならば、メディアライブラリ関連のデータをデータベースから直接 エクスポート & インポート すればいい。 サイトリニュアルの際など、WordPressのデータ移行(引越し)が必要なときがありますよね。古いデータベースをそのまま利用できれば、そうしたほうが一番手っ取り早くてトラブルも圧倒的に少ないです。 しかし、古いサイトでプラグインを多用してると、新しいサイトにとっては不要なデータがデータベースに残存してしまうケースもあります。そういった場合は、記事やカテゴリなど、新しいサイトに必要最低限のデータのみを古いサイトから吸収して、いわば「クリーンインストール」で行きたいものです。 記事系とタクソノミー系なら [ツール]→[エクスポート/インポート] を使えば割りと簡単に移行できます。しかし、「メディアライブラリ」だけどうしても上手くいきません!これまでに一度も成功した試しがない… 画像データをサーバーにアップロードする 新しいサイトをホストするサーバーも変える場合、まずは古いサーバーの画像(wp-content/uploads)を新しいサーバーに上げておきましょう。 データベースから直接インポート&エクスポートする WordPressの「インポート/エクスポート」ツールが上手くいかないなら、最終手段として、データベース上にあるメディアライブラリ関連のデータをSQLとして直接エクスポート&インポートするのがいいでしょう。ちょいと面倒かもしれませんが、やはりこれが一番確実です。 phpMyAdmin でメディアライブラリ関連のデータをエクスポート ツールは何でも構いませんが、ここでは多くの人たちに親しまれている phpMyAdmin

Cloudflareを使ってWordPressサイトをHTTPS化する時の流れとポイント

2016年10月25日
Web制作, WordPress

GoogleがHTTPSに対応したサイトをランキングで優遇する方針を発表してから、Webサイトの常時SSL/TLS化がすごいスピードで進んでいるように感じられます。 今までは有料だったSSL/TLSは、今や let’s encrypt を筆頭に、CloudFlare や Amazon Certificate Managerなど、無料のSSL/TLS証明書を発行してくれるサービスが続出中。もはや常時SSL/TLS化が常識の時代です。 もっとも簡単かつおまけサービスもてんこ盛り(HTTP/2 やら 静的コンテンツのキャッシュやら)の CloudFlare を使ってサイトをHTTPSに対応してみました。 CloudFlare側の設定は最高に簡単なので、さらっと目を通しつつ、WordPressで使う時のポイントだけ紹介します。 ネームサーバーの変更 CloudFlareを使うためにはまず、利用しているレジストラ(お名前.comとかVALUE-DOMAINとか)の管理画面で、ネームサーバーをCloudFlare指定のネームサーバーに切り替える設定をする必要があります。 そうすると名前解決した時に、CloudFlareのプロキシサーバーを指すようになって、間で勝手にいろんな最適化してくれるというわけです。 最初にDNSレコードのスキャンが行われますが、DNSレコードをいじってない人にとっては基本的それで大丈夫だと思いますが、自分であれこれDNSレコードを追加したり変えたりしている人なら完全にスキャン結果を信用してはいけないです。なぜならスキャンされないレコードがあったり、あるはずもないレコードが出たりするので、自分の目で確認しておいたほうが良さそうです。 SSLのオプション

PHPを踏み台サーバー経由でRDSに接続させる方法

2016年8月10日
Web制作, WordPress

一言まとめ WordPress開発でリモートのデータベースを使いたい! 問題は、踏み台サーバー経由じゃないとデータベースにアクセスできない… SSHのLocal-Forward機能を使えば簡単にできる。 背景・問題点 何もWordPressに限ったことではないのですが、リモートにあるデータベースを開発者らが共有して使いたい場面は多々あると思います。多くの場合、セキュリティ上の理由でデータベースを外部(インタネット)からの接続ができないようになっていることが多いと思います。踏み台を経由しないとデータベースにアクセスできないような構成が定石ですよね。 この記事では、AWSの「EC2 + RDS」という構成を例に、ローカルマシンのPHP(WordPress)から、踏み台の向こうにあるRDSに接続させる方法を紹介できればと思います。 サーバー構成図 (本記事で使うIPアドレスなど、すべて架空のものです) SSHのLocal-Forward機能を使う MySQL Workbenchでは「TCP/IP over SSH」という接続方法があります。それを使えばたとえデータベースサーバーが踏み台サーバーの向こうにあるとしても一発で接続できて便利ですよね。PHPのSSH2拡張を使って似たようなことをPHP側で実装するのが理想ですが、WordPressを弄らないといけないし、デプロイするときに面倒そうだから、今回はSSHのLocal-Forward機能を使った方法を紹介します。 具体的には WordPress側でDBホストを127.0.0.1:3333に変更 ローカルマシンでSSHを使って、ローカルの3333ポートへのパケットを踏み台サーバーを経由してRDSに転送する という段取りです。

WordPressプラグイン「Advanced Custom Fields」のフィールド名を後から変更する方法

2016年7月27日
Web制作, WordPress

WordPressデベロッパーなら誰もが知っている便利なプラグイン「Advanced Custom Fields」ですが、使ってて不満に感じたのは「定義したフィールド名を後から変更する機能がない」ことです。 後からリファクタリングしていると、「やっぱり”book”じゃなくて、”books”にすればよかった… でも、もうデータが入っているしね…」って悩むことってありますよね? フィード名を後から変える方法 ACFではWordPressのメタデータを使ってフィードの値を保存しています。 例えばACF側でフィード名がbookのフィードを作成して、投稿ページ側でそのフィードを埋めて保存すると、データベースのwp_postmetaテーブルにmeta_keyカラムの値がbookと_bookのレコードが2つ挿入されます。bookには記事で埋めた値が入っていて、_bookにはACFが利用するフィードオブジェクトへの参照IDが入ってます。 このように、ごく普通のWordPressメタデータを使っていますので、フィード名を変えたかったら、まずACF管理画面でフィード名を変えて保存します。そのあと、以下のSQL文を実行すればOKです。 UPDATE wp_postmeta SET meta_key = '新しいフィード名' WHERE meta_key = '古いフィード名'; UPDATE