IFTTTのサービスを使って、このWordpressサイトからTumblerに連携してみます。ついでに画像を貼り付けて、うまく画像も連携できるかをテストしてみます。
これはテスト画像です。
とある5丁目で活動する還暦を過ぎたWebプログラマーの覚え書きです。それとかかってくる迷惑電話や、家業のアパート経営について。
IFTTTのサービスを使って、このWordpressサイトからTumblerに連携してみます。ついでに画像を貼り付けて、うまく画像も連携できるかをテストしてみます。
これはテスト画像です。
IFTTTのサービスを使って、このWordpressサイトからBloggerに連携してみます。
IFTTTの設定はウィザードを使って、設定して「次へ」ボタンで進んで行くのでわかりやすい。
さて、うまく連携できますでしょうか。
とりあえずWordpressのサイトのAdminユーザーを削除しておいた。しかし、一般ユーザー名はわかるから効果はどうなのよ、と思うからパスワードをとても長いものに変えておいた。
なんやかんやでWordPressのサイト構築で躓くのは、PHPのプログラミングなのでした。
Embedded Link
WordPressのデフォルトユーザー設定(admin)を削除しましょう | ホームページの作り方, 構築 | ALL FINE ホームページ専門ガイド
WordPressの使い方(ユーザーの管理方法/adminアカウントの削除)に関する記事です。
Google+: View post on Google+
#WordPress を3.5にアップグレード
WordPress3.5の日本語版がリリースされたので、バージョンアップしました。ほんの少しの時間を待っただけで済みました。
今回は、大きなアップグレードなので慎重に対応します。マイナーなアップグレードの場合は、ボタン一発でアップグレードしていましたが、今回は念のためです。
まずはデータベースのバックアップです。あとはテーマなどの必要なファイルをバックアップを取っておきます。
つぎにブラグインをすべて無効にします。これでアップグレードの準備OKです。管理画面から行います。WordPressのアップグレードはボタンを押すだけで簡単です。
アップグレードができたら、まずはアクセスして正しくサイトが表示されるかを確認します。無事に表示されました。
次にプラグインを一つづつ有効にしながら確認です。特にキャッシュのプラグインは要注意です。
無事にアップデートができたようです。各プラグインの機能が正常に動作しているかを順次確認していきます。
Embedded Link
WordPress | 日本語 » WordPress 3.5 日本語版リリースのお知らせ
WordPress 3.5 日本語版リリースのお知らせ. 2012年12月12日, Takayuki Miyoshi. WordPress 3.5 日本語版をリリースしました。 ダウンロード: WordPress 3.5 日本語版をダウンロード. アップグレード: 「WordPress のアップグレード」を参照してください。 新機能・変更箇所: WordPress Codex 日本語版の「Vers…
Google+: View post on Google+
「#WordPress サイトの負荷分散の実験」と書きましたが、HyperDBで使ったときの運用で、その後思いついた疑問がいくつかあります。
マスターのサーバーの管理ページでアップデートの指示がありますので、おそらくマスターサーバーだけで、スレーブサーバーはアップデートされないのでないかと思いますが。
これも、マスターだけでスレーブサーバーのプラグインは実施されないのでは? おそらくHyperDBは、データベース関連しか面倒見てくれないので、ファイルは自分で何とかしないといけないかと思います。もっとHyperDBを調べてみる必要があります。 いずれにしても、メディアでアップデートされるファイル以外にも、/var/www/wp-content以下のファイルすべてを同期させれば解決されるのではないのか? こちらも試してみる必要があります。
なんやかんやでWordPressのサイト構築で躓くのは、PHPのプログラミングなのでした。
プラグインのアップロードは、マスターのサーバーに限らないので、マスターとスレーブともお互いにファイルの同期を取ってあげないといけないようです。したがって、ロードバランサで管理ページは、マスターサーバーに必ずアクセスさせるようなことが必要です。以下のサイトが参考になるかな?
HyperDBでWordpressのサイトを単純に分散させても、運用で問題になりそうです。HyperDBを紹介しているサイトでそこまで言及していないのはなぜかしら? 実際に使っていない?
KVMで2つ仮想サーバーを立ち上げて、Wordpressのサイトをリプリケーションして、サーバーの冗長化と負荷分散の実験してみました。
最初に1つのサーバーにWordpressをインストールして、それからKVMのクローンでサーバーをもう一つ作ってしまいます。IPアドレスを別にして2つWordpressのサイトが動く状態にします。
次に、MySQLのリプリケーションの設定をします。設定方法は、
辺りを参考にしました。Wordpressの負荷分散は、HyperDBというプラグインを使用します。これもまた、
辺りを参考に設定します。
これで、片方のサーバーのMySQLを停止してもWordpressのサイトを参照できるかを確認します。
よく考えれば当たり前なのですが、MySQLをマスターにリプリケーションに設定したほうのMySQLを停止したら、参照ができるが更新ができないようになっていました。これで成功なのです。マスターのMySQLに障害が発生したら、スレーブのMySQLからDBを復旧する手順になるのでしょう。
更新は、強制的にマスターサーバーになります。これはHypeDBの機能なのでしょう。スレーブサーバーで更新してしまったら、MySQLのリプリケーションのトラブルになってしまいます。
記事を追加したら、すぐにスレーブサーバーでも参照できるようになります。こちらはMySQLのリプリケーションが正常に動作してしているからです。
マスターとスレーブの切り替えは、DNSのラウンドロビンの機能で実現できそうです。必ず管理ページからはマスターのMySQLのデータベースに格納されるかが確認する必要がありますが、こちらはローカルにDNSを置いていないので未確認です。
以上でWordpressの二重化の実験は完了と言いたいところですが、一つ忘れていました。Wordpressのメディア機能でアップロードしたファイルは、マスターに存在することになります。スレーブのサーバーにアクセスした場合は、存在しないことになります。そこで、/var/www/wp-content/uploads/以下のファイルをマスターからスレーブサーバーに同期を取ってあげないといけません。
cronでrsyncを実行していいのですが、ここではlsyncdでサーバー間をリアルタイム(数秒の遅延はありますが)で同期を取ってしまいます。
を参考に設定しました。これでマスターとスレーブのWordpressのサイトで、アップロードされた画像が正しく参照できるを確認します。
WordPressのサイトをテストサーバー(移行元サーバー)から本番サーバー(移行先サーバー)に移行したときのメモ。テストサーバーと本番サーバーでドメインが違っているときの、どのように作業したかをメモしておきます。
最初に本番サーバーにWordpressをインストールしてしまいます。これは通常通りのインストールでOKです。正しくWordpressのサイトにアクセスできることを確認しておきます。
WordPressで用意されているエクスポート/インポートを使ってもデータの移行はできませんでした。こういうときは何も考えずにMySQLでダンプしてリストアしてしまいます。インストールしたテーブルは一旦削除してからリストアします。エクスポート/インポートはphpMyAdminでもデータサイズが小さければ可能です。
リストアする前にダンプしたSQLファイルを、テストサーバーのURLから本番サーバーのURLにテキストエディタで置換してしまいます。これはリンクのhrefやメディアからの画像のsrcでhttp://~のドメインを直接書いて格納されているからです。
本番サーバーにプラグインをテストサーバーと同様なものをインストールしておきます。使用しているテーマもイントールします。これで準備OKです。
おそらく、このままではアクセスも画像が出てきません。画像が表示されていてもテストサーバーから持ってきてしまいます。リンクをクリックするとテストサーバーに行ってしまいます。サイトの設定がテストサーバーのままです。
管理ページにもアクセスできませんので、テーブルを編集してしまいます。wp_optionsテーブルのoption_name項目がsiteurlとhomeを本番サーバーのURLに修正します。これで画像とリンクが本番サーバーになります。
テーマに直接テストサーバーのURLが格納されていれば、これもテストサーバーに修正してしまいます。あとはブラグイン(バックアッププラグインなど)の設定によっては、パスが違っているかもしれませんので、これも本番サーバーに合わせておきます。
以上で無事に本番サーバーに移行できました。
なんやかんやでWordPressのサイト構築で躓くのは、PHPのプログラミングなのでした。
PHPカンファレンス2012に参加しました。 #phpcon2012
昨日はPHPカンファレンス2012に行ってきました。会場は蒲田の大田区産業プラザです。
今年は、WordPressのWord Campと同じ会場です。同時開催とは聞いていいたけど、本当に同じスペース内でやっているのね。同じ会場で別のところだと思っていた。
セミナーはクローズの教室ではなくて、まるで展示会で企業が会場で講演会をするようなオープンなところでやっていた。Word Campのほうでじゃんじゃん音を鳴らしていたので、これはどうも落ち着かない。プロジェクタでプレゼンをするのだけど、スクリーンが小さいので見えない。前のほうの席を確保する。
それにWord Campが同時開催となると、PHPカンファレンスかいずれかを捨てなければいけない。来年は、別々にやって欲しいな。そうすれば、どちらも参加できるのに。
今回は名刺を忘れて大失敗。懇親会は参加しませんでした。懇親会だけでも価値があるかな。
Embedded Link
PHPカンファレンス2012
日本最大のPHPの祭典
Google+: View post on Google+
OSC2012で紹介されていたbaserCMSをインストールしてみました。
まずはローカルのPCにインストール。インストール自体は簡単ですが、残念ながら管理者ダッシュボードの中で固まります。
PCではXAMPPの上でbaserCMSを動かしているのですが、もしやと思って古いバージョンのXAMPPで動かしてみると、今度は問題なく動きます。baserCMSはCakePHPの上で動いています。一緒にインストールされるCakePHPのバージョンを見たら1.2でした。これは古い・・・。
baserCMSのサイトでシステム要件を見たら、PHP5.2.17以降となっていますが、経験上CakePHPの1.2ではPHP5.3以降は、エラーが出て面倒なことになりそうです。
今使っているXAMPPのバージョンは、1.7.7で一つ古いのですが、動いているPHPが5.3.8なので、それが問題かもしれません。最新版のXAMPP1.8.0はPHP5.4.4なので、そこまで新しいと本番サーバーが間に合わないので使っていません。baserCMSが動くXAMPPのバージョンは1.6.8でPHPは5.2.6でした。PHPが5.2系なら大丈夫なのでしょう。本番サーバーでよく使うRedhat系のCentOSも6だと、PHPは5.3系がインストールされるので、このままだとbaserCMSは本番サーバーにインストールしたときに問題になるでしょう。
以上、出鼻をくじかれたので、今日はbaserCMSはインストールしただけで終わってしまいました。baserCMSが新しいCakePHPに対応するまで待ったほうがいいかもしれません。それとも今まで通りWordPressでサイトを作ったほうがいいかもしれません。
WordPressが3.4になったぞ、という記事を見かけて、WordPressで運用しているサイトのダッシュボードにアクセスしたら、アップデートがあった。その他多数プラグインも。
サクッとアップデートしてみる。見た目はどこが変わったの? と思うけど、確実に応答がよくなっている。SQLの見直しを行っているようだ。
アップデートする前にデータベースのバックアップをしましょう。
Google+: View post on Google+