WordPress」カテゴリーアーカイブ

WordPressの話題。

XREAでMainに独自ドメインでWordPressをインストールしていて無料SSLを適用できなかったのでSubに移動する

XREAで無料SSLが使用できるようになりました。昨今、GoogleChromeを皮切りに、入力フォームのあるウェブサイトでSSL/TLS(https)通信が有効になっていない場合、画面に警告が出るようになるらしいですね。この流行には乗るしかない! ということで、早速、調べてみたのですが……なんと、XREAで言う所のMainには無料SSLが適用できない制約事項があるではないですか。Mainとは、public_html直下にWordPressをインストールしている状態を指します。これを、何とかサブディレクトリ(Sub)に移設してみようと思います。因みに、私はMainに独自ドメインを設定しています。

公式Wikiに似たような手順はあるのですが、実際にはもっと単純です。手順では、サブディレクトリを手で作ることになっていますが、XREAではサブディレクトリ=ドメインとなるので、実質、WordPress自体の設定変更は不要です。(URL自体は変わらないため)

XREAのコンパネから、Mainを空白にして、SubへMainに設定されていた独自ドメインを設定して、反映してやります。そのあと、同じくコンパネから無料SSLを有効にしてやります。

ドメイン設定が反映されて、public_html/jikkenjo.netディレクトリが作成されたら、public_html直下にあったWordPressファイルをコピーしてやります。ftpでやると、1ファイルずつコピーする動きになるので、ssh接続してからcp -rで実施すると一瞬で終わって良いです。[cp -r wp-* jikkenjo.net/][cp index.php jikkenjo.net/][cp .htaccess jikkenjo.net/]で取り合えずOKだと思います。気になるファイルは個別に移動させてください。

後は、Really Simple SSLをインストールして終わりです。独自ドメインが変更差異を吸収してくれたので、意外に楽だった……。

と、忘れてた。GoogleAnalytics側の設定をhttp→httpsに変更しておかなければなりません。

WordPressの更新画面にアクセスするとMySQLのwp_optionsでオーバーヘッドが増大して全画面で500InternalServerErrorになる

前々から非常に困っていた事象がWordPressの手動アップデートで訳も分からず解消したので記しておきます。

発生していた事象

タイトルの通りです。WordPressの管理画面で「ダッシュボード>更新(update-core.php)」にアクセスした瞬間、MySQLのwp_optionsテーブルでオーバーヘッドが増大し、管理画面だけではなく、全画面で500 Internal Server Errorになってしまいます。WordPressのデバッグモード等で確認してみると、どうやら、Apache(PHP)からMySQLへクエリを投げた時にTimeoutに陥ってエラーとなっているようでした。phpMyAdmin等で「最適化」によりwp_optionsのオーバーヘッドを取り除いてやると、対症療法的には解消します。いくら調べても根本原因に辿り着かなかったことと、更新画面にアクセスしなければ発生しないことから、数年もの間(長い!)直視しないでおいた問題でした。

解消方法

冒頭でも触れたように、時代錯誤にもWordPressを手動更新してやれば解消します。自動更新機能が存在しなかった時代のWordPressから、自動更新が存在する時代のWordPressに更新する手順として、WordPressの公式ドキュメントに整理されています。手順の中で、旧ファイルを消すという点がポイントだったようです。

数年続いていた本事象により、全くWordPressが更新できなくなったことで、セキュリティ的に心配だったので、何度か手動での更新はしていました。その際、最新ファイルで上書きすることだけで対応していました。そのような、旧ファイルを消さない手順では解消しませんでした。

解決した今も、相変わらず原因は不明だったわけですが……。

XREAマイグレーションに伴う自前設置WordPressの障害対応

XREAがサーバ老朽化に伴うマイグレーションを行いました。s353サーバに収容されていた当ウェブサイトも今日当たりました。で、同時にWordpressが動かなくなっていました……。色々と面倒だったので記しておきます。

Sorry. We are under maintenance.

移行前のウェブ領域は残されるようです。そのため、VALUE-DOMAIN以外のドメインレンタルサービスを使用していて、DNSレコードのIPアドレス修正が漏れていた場合は上記メッセージが表示され続けます。当ウェブサイト(jikkenjo.net)はVALUE-DOMAIN(eNom)だったので自動切換えでしたが、一部、他社からレンタルしているドメインを修正し忘れていて、本事象に当たりました。

他にも、ページが途中までしか表示されない事象が発生しました。吐き出されたHTMLソースを見ると、何の前触れもなくぷっつり切れていました。原因不明だったので下記対処をしましたが、結果として、DBをphpMyAdminでanalyze/optimizeすれば解消しました。詳細は不明ですが、恐らくどこかのレイヤでタイムアウトに引っかかってしまったのではないかと思われます。マイグレーション作業として行われたであろうDB移行が、物理移行(ファイルシステムごとコピー)ではなく論理移行(MySQLのダンプ・リストア)だったため、統計情報が更新されなかったと考えられます。(MySQLのバージョンが上がったので、物理移行は無理だった? それにしても、初回のanalyzeくらいは実行しておいてほしかった。)

wp-config.php に下記文言を追記してやると、Wordpressの内部エラーが出力されるようになります。私の場合は、「DBサーバとの接続が確立できませんでした」的なメッセージが出ていました。(connection refusedだったかな……)

define('WP_DEBUG',true);

AmazonJSでアフィリエイトを始める

全く興味ありませんでしたが、知識として興味があったので試してみました。色々と大変でした。

AWSアカウントの準備

まずはamazon.comのアカウントを取得します。商品を購入するamazon.co.jpのアカウントではありません。襷に長し感は有りますが、ここで取得するアカウントはAWSのアカウントです。AWSで提供されるサービスが多すぎて意味が分からなくなります。

ルートユーザ(今取得したアカウント)でアフィリエイト用キーを発行しても良いのですが、「ルートユーザから払出した子ユーザから発行したアフィリエイト用キーを使うのが最近の流行りだよ!」とAmazonから勧められるので大人しく従います。サービスメニュー(サービスが山ほどあるので頑張って見つけてください)から「IAM(正式にはアイアムと発音)」を選択します。サイドメニュー(ダッシュボード)より「ユーザ」を選択します。新規ユーザを払出して、アクセスキーとシークレットキーを取得します。シークレットキーは後では2度と確認出来ないのでメモっておきましょう。

次に、払出した子ユーザに対して権限を付与します。ユーザ詳細ページの「アクセス許可」タブから、「ポリシーのアタッチ」をして、「AdministratorAccess」を付与します。(何の権限が最低限必要なのか、最後まで不明でした。色々組み合わせて試したのですが分からず。全権限付与しちゃうと、子ユーザを払出する意味は無いのかも。)権限が足りない場合は、後で実施するAmazonJSの使用中に下記エラーが発生します。後で分かったのですが「Amazon EC2 Container Service」権限さえあれば良いと思います。

Amazon Product Advertising APIのエラー
UnauthorizedOperation
Your AccessKeyId is not authorized to perform this operation. Please check IAM policies for the Access Key.

アソシエイトアカウントの準備

支払先等を設定するためのアカウントも個別に取得する必要があります。淡々とアカウント登録を進め、トラッキングID(日本アカウントの場合は、末尾が「-22」となります)を取得して完了です。ちなみに、銀行振替の設定だと面倒そうで、Amazonギフトとして受け取る設定だとワンクリックで設定完了しました。アカウントが正常に設定できていないと、後で実施するAmazonJSの使用中に下記エラーが発生します。

Amazon Product Advertising APIのエラー
AWS.MissingParameters
リクエストには、必要なパラメータが含まれていません。必要なパラメータには、AssociateTagなどがあります。

AmazonJSの準備

AmazonJSをインストールして設定ページで、アクセスキー、シークレットキー、アソシエイトタグを入力します。

記事の執筆画面のメニューにAmazonマークが現れており、URL入力等で簡単に記事へアフィリエイトリンクを挿入できてしまいます。折角なので、最後に最近読んで面白かった漫画のアフィリエイトを貼っておきます。

xreaアップデートに伴うDB移行手順メモ

xreaが大規模更改にあたり、各ソフトウェアのバージョンがドラスティックに変わりました。MySQLも大幅にバージョンアップするため、本ブログ(Wordpress)のデータがすべて削除されました。xrea運営が作業前に取得してくれていたdumpファイルを元に無事復旧できたのでメモしておきます。

蛇足ですが、XREA自体がそもそも上級者向けの低価格低サポートなサービスだっただけに、殆どの方は自分で解決されているようでした。また、公式サポートフォーラムでも技術者らしい冷静な対応をされている方ばかりだったので、なんだか安心しました。

[usename]や[dbname]やサーバ名やファイル名は適宜読み替えてください。

手順

xreaのコントロールパネルからDBを作成

xreaのコントロールパネルから、過去にWordpressで使用していた名前でDBを作成します。パスワードも過去(Hint:初期パスワードはFTPパスワードの前8文字)と同じにしてください。稀に、xreaの更改作業を乗り切ってしまうDBもあるそうですが、間違いなく中途半端にしか復元できていないため、一旦削除してから再作成(空のDBを用意)してください。

sshで接続してftp8変換とインポート

サーバにsshで接続します。xreaのコントロールパネルから「ホスト登録」をお忘れなく。出来ない場合は1~3分待ってください。

ssh -l [username] sXXX.xrea.com

公式からutf8への変換が必要とアナウンスがあるため、dumpファイルをutf8に変換します。nkfでいけます。

MySQL4以前などの古いデータベースからデータは完全には引き継げませんので、データベース内のデータが一旦空になります。
特に文字コードはUTF-8が標準となりますので、そのまま引き継ぐと不具合が出る可能性があります。
MySQL/PostgreSQL/Apache/PHPのバージョンアップメンテナンスについて

ll
cd _DB_BACKUP_XREA_UPGRADE/
ll
nkf -w mysql_[dbname].dump > mysql_[dbname].dump.nkf
ll
view mysql_[dbname].dump.nkf

中身を見て問題なさそうならインポートします。先ほど設定したDBのパスワードを聞かれます。

mysql -u [dbname] -D [dbname] -p < mysql_[dbname].dump.nkf

特にエラーが起きなければ以上となります。念のためレベルで、インポートしたDBを確認してみてください。

mysql -u [dbname] -D [dbname] -p
use [dbname]
show tables;

その他

phpMyAdminの再インストール(バージョンアップ)

phpMyAdminを使用する場合は再インストールが必要です。公式では下記のように説明されていますが、私はコントロールパネルで「インストール」を選択するだけでいけました。

1、ファイルマネージャーもしくは、ご利用のFTPクライアントから、現在のディレクトリ「./public_html /log /phpmyadmin_」等に名前を変更します。
2、XREAサーバー管理画面二ログインし、「データベース」メニューから
「■PhpMyAdmin自動インストール(MySQL管理) 」項目の「インストール」ボタンをクリックします。
3、「./public_html /log /phpmyadmin」が生成されたことを確認されましたら、ログインします。
【公式】XREAサーバー:最新の環境へのアップデートメンテナンス関連

新規投稿画面のツールバーが表示されない時はプラグインを疑う(wordpress-4.0–ja/wp-emmet-0.2.6)

wordpress-4.0–jaとwp-emmet-0.2.6の組み合わせで、新規投稿(執筆)画面のツールバーがまったく表示されなくなる事象が発生したのでメモしておきます。ひとまず、fixされるまではEmmetを無効化して乗り過ごすことにします。

また、今回のプラグインを導入していない場合でも、執筆時に動作する他のプラグインを疑ってみたほうが良いかもしれません。

ツールバーが表示されない事象

ツールバーが表示されない事象

Emmetを無効化すると表示される

Emmetを無効化すると表示される

それはそうと、Emmetが使用できないのはかなり痛い……(というか、ツールバーのほうがあんまり使わないし、非表示覚悟でEmmetを有効化したほうが個人的には良いかも。)

XREA+(PLUS)/CORESERVERでWordPressのWPTouchプラグインを使用した時に出るエラーの回避方法

XREA+(PLUS)/CORESERVERでWordPressのWPTouchプラグインを使用した時に出るエラー(ワーニング)メッセージの回避方法をメモしておきます。

WPTouchをインストール(wp-content/pluginsにput)して有効化後に、wordpressのコントロールパネルからWPTouchの設定画面を呼び出し、Core SettingsのSave Changeをしたとき、画面上部に下記ワーニングメッセージが出力される場合があります。中身を読んでみると、ディレクトリにアクセスできなくて怒られていることがわかります。

Warning: fopen() [function.fopen]: Unable to access /virtual/*****/public_html/wp-content/wptouch-data/backups/wptouch-backup-20131210-131850.txt in /virtual/*****/public_html/wp-content/plugins/wptouch/core/admin-backup-restore.php on line 51

Warning: fopen(/virtual/*****/public_html/wp-content/wptouch-data/backups/wptouch-backup-20131210-131850.txt) [function.fopen]: failed to open stream: No such file or directory in /virtual/*****/public_html/wp-content/plugins/wptouch/core/admin-backup-restore.php on line 51

Warning: fopen() [function.fopen]: Unable to access /virtual/*****/public_html/wp-content/wptouch-data/backups/wptouch-backup-20131210-131850.txt in /virtual/*****/public_html/wp-content/plugins/wptouch/core/admin-backup-restore.php on line 51

Warning: fopen(/virtual/*****/public_html/wp-content/wptouch-data/backups/wptouch-backup-20131210-131850.txt) [function.fopen]: failed to open stream: No such file or directory in /virtual/*****/public_html/wp-content/plugins/wptouch/core/admin-backup-restore.php on line 51

まずは、wp-contentsの権限を確認してください。777等で設定されている、かつ、wp-content/wptouch-dataが作成されている場合は問題ありません。当該ディレクトリ内に複数のディレクトリが作成されていることも併せて確認します。

一方、wp-contentが755で設定されている場合は、wp-content/wptouch-dataを手で作成して、777を与えてください。

ここで、再度wordpressのコントロールパネルからWPTouchの設定画面を呼び出します。すると、先ほど手で作成したwp-content/wptouch-data配下に複数のディレクトリが作成されます。ところが、これらのディレクトリは、所有者がapacheになっています。これは、XREA系列サーバでは回避しようがないようです。

※ モジュール版PHPから作成されたファイルの所有者は「apache」になります。これらのファイルの所有者を「*****」に、パーミッションを「707」に変更します。(XREAコントロールパネルより引用)

その場合は、下記ワーニングメッセージが出力されます。スクリプトと所有者の違うディレクトリが読めないと言っています。(適当)

Warning: fopen() [function.fopen]: SAFE MODE Restriction in effect. The script whose uid is 10852 is not allowed to access /virtual/*****/public_html/wp-content/wptouch-data/backups owned by uid 1000 in /virtual/*****/public_html/wp-content/plugins/wptouch/core/admin-backup-restore.php on line 51

Warning: fopen(/virtual/*****/public_html/wp-content/wptouch-data/backups/wptouch-backup-20131210-141529.txt) [function.fopen]: failed to open stream: No such file or directory in /virtual/*****/public_html/wp-content/plugins/wptouch/core/admin-backup-restore.php on line 51

Warning: fopen() [function.fopen]: SAFE MODE Restriction in effect. The script whose uid is 10852 is not allowed to access /virtual/*****/public_html/wp-content/wptouch-data/backups owned by uid 1000 in /virtual/*****/public_html/wp-content/plugins/wptouch/core/admin-backup-restore.php on line 51

Warning: fopen(/virtual/*****/public_html/wp-content/wptouch-data/backups/wptouch-backup-20131210-141529.txt) [function.fopen]: failed to open stream: No such file or directory in /virtual/*****/public_html/wp-content/plugins/wptouch/core/admin-backup-restore.php on line 51

この事象はXREAのコントロールパネルより、フォルダの所有者を変更することで解決することができます。コントロールパネルから「ツール」を選択し「ファイル所有者の変更」します。

これにて一旦落着。

comments-popup.phpが要らない子過ぎる

WordPressのテーマにはcomments-popup.phpというモジュールテンプレートファイル(と呼ぶらしいです)がありますが、余りにも要らない子過ぎるので、削除してみたいと思います。

私自身が余りよくわからずに改造しているので内容の信憑性は怪しいかもしれません。なるべく正確に書くよう配慮しますが、間違っているかもしれません。

続きを読む