ドメインを新しいサーバーに向ける一般的な方法は〚aレコード〛か〚ネームサーバー〛の変更だと思います。

そして、wpxクラウドでメールを使いたい場合は〚aレコードの変更〛を使います。

例えば、お名前.comで取得したドメインと共用サーバーの組み合わせが簡単なので説明します。

例－－－－－－

・お名前.comで10個のドメインを取得したとします

まずは⇒すべてのドメインをお名前.comの共用サーバーに設定します（つまりネームサーバーが共用サーバーに設定された状態）

次に⇒そのうち５個のサイトのAレコードをwpxクラウドに向けます

この方法であれば・・・

サイトはWPXクラウドで表示！メールは共用サーバーで利用が可能！

－－－－－－

wpxクラウドでも共用サーバーでメールを使う設定

サーバーのコントロールパネルにログインし、独自ドメインの設定に移動します。

ここのDNS設定からAレコードをwpxクラウドのＩＰアドレスに変更するだけです。

お名前.comでのＤＮＳ設定の例

この方法ならメールの使えないwpxクラウドでサイトを表示しながら、メールだけはお名前.comの共用サーバーを利用できるのです。

ネームサーバーをwpxクラウドに向ける方法だとメールは使えません。

まとめ

説明が冗長だったかもしれませんね。

要はaレコードのみをwpxクラウドに設定しておけば、メールはお名前.comのサーバーで使えるということです。

よくwpxはメールが使えないから諦めるという声を耳にするので、方法をご紹介しました。

簡単なので情報が広まると良いですね。

それは、Multisite Language Switcherを使う為にマルチサイトを構築するときのことでした。

マルチサイトでサイトを追加しても参加サイトに表示されるはずのサイトが表示されなかったのです。

追加するサイトを同じユーザーで作らないと表示されない

メールアドレスを同じにしないと・・・

つまり管理者のメールアドレス毎に参加サイトが表示されるってことです。

※同じメールアドレスでサイトを作らないと、各サイトの管理者が別々に生成されてしまう

簡単すぎて悲しい。

ググったけど出てこなかったのは誰も躓かないからなのか・・・

次回予告：マルチ言語サイトを作るならマルチサイトが一番

※次回記事：【多言語サイト構築】簡単なのにプラグインに依存しない

本当は今回もWPXクラウドでのマルチ言語サイトの構築について記事を書くつもりでした。

マルチサイトの構築はスンナリと完了し、プラグインのインストールも【ネットワークで有効化】を完了・・・簡単にマルチ言語サイトを構築できるはずだったのですが。

投稿画面の右上にある【マルチサイト言語スイッチャー】の部分には以下の表示がされてしまう。

You should define at least another blog in a different language in order to have some benefit from this plugin!

日本語の方を見ても同じ内容・・・

このプラグインの機能を使用するため、一つ以上のブログを他言語に定義することをお勧めします。

 

理由は上記で説明した通り、マルチサイトを管理するユーザーを統一する必要があっただけでした。

サイトを追加する時の『管理者のメールアドレス』を揃えれば解決です。

変なところで躓いたため、【マルチ言語サイトを作るならマルチサイトが一番】の記事は次回にします。

今回は、Multisite Language Switcherをお勧めする理由を少し説明し締めくくろうと思います。

bogoも(m)qTranslateも試したが結局Multisite Language Switcher

bogoでは条件検索時のプログラム構築が複雑になり過ぎて断念。

qTranslateは悪くなかったのだけど少し重くて、今後の規模拡大には不安を感じた。

それにzTranslateやmqTranslateに分散されていて、今後の更新具合も不安になる。

いずれにせよ、プラグインに依存し過ぎるのは危険だと気が付いたのです。

マルチサイトなら簡単かつプラグインへの依存度も低い

マルチサイトと聞くと難しいイメージを持つ人もいるようですが、慣れれば１０分程度の簡単な作業です。

手順通りに作業をすれば大した作業ではありません。

なぜプラグインへの依存度が低いのかというと、プラグインを消してもサイトとして残るからです。

データベースが複雑化せず、プラグインがしている作業は異なる言語同士のリンクだけ。

Multisite Language Switcherの更新が止まっても別のプラグインへの移行は簡単そうだし、最悪リンクが切れても海外サイトとして置いておくことも可能になります。

マルチサイトではなく別のサーバーで運用する方が良い面も多そうですが、海外からのレスポンスについてはCloudFlare当のCDNで緩和できるし、費用や管理の面からもマルチサイトによる多言語サイトの構築は非常にオススメです。

それに他のプラグインを使って構築したところでコンテンツを各言語に翻訳する作業は大差はありません。

結論：Multisite Language Switcherを使う理由は3つ

・プラグインへの依存が少ない

・マルチサイトに分けた方がサイト全体のプログラムがシンプルで済む

・言語毎にテーマを改造した方がPHPがシンプルで簡単

では、次回はWPXクラウドサーバーにおけるMultisite Language Switcherの多言語サイト構築について説明します。

※次回記事：【多言語サイト構築】簡単なのにプラグインに依存しない

※当サイト以外での実例情報が見当たりません。自己責任で実行してください。

この方法はWordPressの【アップロードファイル拡張方法】と基本的な【BPG用JavaScript】の使用方法を組み合わせた、WordpressでもBPG【Better Portable Graphics】を使う方法になります。

webpについても、使用するjavascriptが異なるだけで、同じ要領で対応できます。

ＢＰＧ非表示モード

具体的には・・・

• header.phpのhead内に以下の記述をする。

<script type=”text/javascript” src=”<?php bloginfo(‘template_directory’); ?>/js/bpgdec8a.js”></script>

 

• サーバー内の正しい位置にbpgdec8a.jsを配置する
• /wp-includes内のfunctions.phpでBPGのアップロードを許可する
• マルチサイトの場合はネットワーク設定でもBPGを許可する

BPGを許可するのは簡単だけど自己責任

どちらもPHPを扱うプログラマー（あるいはhtmlに触れる程度でも可能？）なら朝飯前の作業ですが、いかんせん情報がありません。

WordPressにおけるBPGの扱い方について、国内には参考となるソースは見つかりませんでした。（２０１５年２月２２日現在）

実際にサムネイルやBPG画像の公開テストを行っきたのですが、需要が伸びないので停止しています。当サイトで配布しているフリー素材はすべてBPGで配布可能なので、興味のある方はぜひ一緒にBPGを盛り上げましょう。

最初に断わっておきたいことがあります・・・

この方法で如何なる不具合が起ころうと、一切の責任を負うことはできません。

ある程度PHPの扱いに慣れていて、不具合を自分で修復できる人に限り、自己責任で参考にしてください。

BPGをWordpressで使えるようにする

以下を行えば、とりあえず扱えるようになります。

まずBPGフォーマットの公式サイトにサンプルがあるのでダウンロードをします。

（公式サイトの中ほどにあるDownloadのbpg-0.9.5-win32.zip）

BPG公式のサンプルファイル

この中のｈｔｍｌ内にサンプルがあるので参考にしてください。（人によっては説明も不要にですね）

ちなみにbpgencにjpeg画像をドラッグ＆ドロップしてやればBPG形式に変換してくれるので便利です。

wordpressテーマのhead内でbpgdec8a.jsを読み込む

footer内でも良いかもしれませんが、サンプルのhead内を参考に以下を追記します。

<script type=”text/javascript” src=”<?php bloginfo(‘template_directory’); ?>/js/bpgdec8a.js”></script>

ディレクトリの場所は多少変わるかもしれません。BPGを使おうと思うような人なら大丈夫ですね（偏見）

（解らない場合は相談してくれれば力になれるかもしれません）

あとはサーバにbpgdec8a.jsをアップロードして、header.phpを上書きしてやるだけでBPG形式を扱えるようになります。

※ちなみに各jsには以下の特徴があるようです

1. bpgdec8.js は 8 bitのアニメーションなし
2. bpgdec.js は 14 bitまで対応したアニメーションなし
3. bpgdec8a.js は 8 bitのアニメーション対応

ここまでで直接PHPにBPGファイルを配置することが可能になりましたが、できれば投稿画面からアップロードしてサムネイルにも表示したいところです。

その為には、以下の手順でアップロードの許可をします。

BPG形式をワードプレスのアップロードで許可する

２０１５年２月２２日現在のWordpressではBPG形式は未対応です。そのため通常は弄らない部分を変更する必要があり、アップデートの度に上書きされる可能性もあります。

そもそもwordpress側で対応したなら不要な作業なので、BPGが普及して、この作業も一時的な処置になってほしいところ（期待できないけど）。

/wp-includes内のfunctions.phpを変更

まずはFFFTP等を使い/wp-includes内のfunctions.phpのバックアップを取りましょう。

※テーマ内のfunctions.phpではないので注意

次にfunctions.php内でjpgを検索します。おそらく３か所程度見つかるはずです。

私は以下の３か所にbpgを追加することで、アップロードを許可しています。

• 変更箇所１

‘image’ => array( ‘jpg’, ‘jpeg’, ‘jpe’, ‘gif’, ‘png’, ‘bmp’, ‘bpg’, ‘tif’, ‘tiff’, ‘ico’ ),

• 変更箇所２

$mime_to_ext = apply_filters( ‘getimagesize_mimes_to_exts’, array(
‘image/jpeg’ => ‘jpg’,
‘image/png’ => ‘png’,
‘image/gif’ => ‘gif’,
‘image/bmp’ => ‘bmp’,
‘image/bpg’ => ‘bpg’,
‘image/tiff’ => ‘tif’,
) );

• 変更箇所３

// Image formats.
‘jpg|jpeg|jpe’ => ‘image/jpeg’,
‘gif’ => ‘image/gif’,
‘png’ => ‘image/png’,
‘bmp’ => ‘image/bmp’,
‘bpg’ => ‘image/bpg’,
‘tif|tiff’ => ‘image/tiff’,
‘ico’ => ‘image/x-icon’,

 

追記：テーマフォルダ内のfunctions.phpにサムネイルに関する記述がある場合は削除（Stinger5等）

//アイキャッチサムネイル
if ( function_exists( ‘add_theme_support’ ) ) {
add_theme_support( ‘post-thumbnails’ );
}
add_image_size(‘thumb150’,150,150,true);

これらの記述があるとBPGのサムネイル表示が失敗します。削除するとサムネイルの自動生成に影響しますが、それでもBPGでのサムネイルを表示したい場合は削除してください。

マルチサイトならネットワーク設定からBPGを許可

マルチサイトを構築している場合は、サイトネットワーク管理者の画面から以下の追加が必要です。

設定⇒ネットワークの設定⇒アップロード可能なファイル形式

ここの末尾に半角スペースとbpgを追記します

ネットワークの設定でBPGを可能にする

さいごに

これらの作業でBPGファイルをwordpress上でも表示できたはずです。

まだ新しいフォーマットで何が起こるか解りませんが、BPGに魅力を感じている人は試してみても良いでしょう。（自己責任で）

私も画像形式を色々と比較したうえでBPGにはリスクを冒すだけの魅力があると感じた人間の一人です。

もしもBPGに期待を抱く同士がいたのなら、共にBPGを盛り上げられたら幸いです。

PrettyPressのご紹介です。

これはActive Previewと同様にwordpressの投稿画面でのリアルタイムプレビュー機能を追加するプラグインです。以下の動画のように動作します。

なぜか真っ白になったビジュアルエディターまで復元した

別のブログのことなのですが、はりきって１記事で１万文字を超える文章を執筆したところビジュアルエディターが壊れてしまいました。

そこで回復を試みたのですがうまくいきません。

とりあえずビジュアルエディターの一般的な復元方法は以下の３パターンだと認識しています。

• プラグインを全部停止して確認
• 【ユーザープロフィールの設定】で【ビジュアルリッチエディターを使用しない】のチェックを外したり付けたり
• 「wp-includes」内の「tinymce」差し替える

これはググると出てくるので誰もが行き着く方法なのですが、これで解決しなかった私はビジュアルエディターを一度諦めました。

ビジュアルエディターを使わなくたってActive Previewのようなプレビュープラグインで効率を上げられるからです。

しかし・・・

Active Previewは更新が止まっている

セキュリティ問題や最新バージョンのwordpressへの対応を考えると更新が続いているプラグインが望ましいです。

そこで見つけたのがPrettyPressです！

これにはスマホサイズでの確認機能等の今時な機能も加わっていて、Active Previewの進化形ともいえるプラグインなのです。

PrettyPressの操作は簡単

PrettyPressをインストールして有効化したら、新規投稿をしてみましょう。

あらかじめ下書き保存が必要なので下書き保存を行います。

あとは【エディターの枠内】を選択した状態で画面右上の【Launch PrettyPress】をクリックするだけです。

※エディター枠内の選択とは、記事を書いている状態のことです

prettypress

冒頭の動画でも軽く説明していますが、操作はシンプルで直感的なので勉強する必要もありません。

既存の記事でも試してみたことろ動作が重い記事もあったのですが、既存の記事をわざわざプレビュー表示することは少ないので問題ないですね。

私はこれで作業効率が向上しました。（なぜかビジュアルエディターまでも回復した）

ビジュアルエディターが真っ白になった方やActive Previewの替わりを探していた方にお勧めします。

WordPressにBasic認証

当サイトはwordpress（以下WP）で運営されています。

(2015/8時点でWP4.2.4)

当サイトでは管理画面のセキュリティ対策として以下を行っていました。

・海外からのアクセス制限

・ログイン回数の制限

・+α（最後の砦は秘密）

今まで運営してきたサイトでは、これで十分だったのですが当サイトでは・・・

毎回ログイン回数制限が発動している！

最初はヒヤヒヤしてパスワードを長くしたりＩＰ認証をガチガチにしたりと、気を引き締めて取り掛かっていたのですが・・・

もう！めんどくさいんだよ！！

パスワードを変更すると自分が覚えられないし、ＩＰ認証を本格的に工夫するのは私ごときにはハードルが高い！

なにより！毎回ログイン回数制限を解除してからログインさせられる敗北感！！

もうサクッとパスワード入れて管理画面に入りたい

ならサクッとBasic認証をかませておけば解決するんじゃない？

確かに管理画面のログイン情報を入力する前に、管理画面にアクセスするためのログイン情報が必要になるけど、

毎回毎回、ログイン回数制限の解除作業を行うよりは絶対にマシ！！

どうせ攻撃を仕掛けてるのってプログラムかなんかでしょ？

とりあえずBASIC認証を抜けられた痕跡がないようであれば、十分かな？って思います。

サクッとBasic認証を設置する方法

手順は簡単。お馴染の【.htaccess】と【.htpasswd】をメモ帳で作って管理画面のディレクトリに配置するだけです。

一点注意があるとすれば配置するディレクトリのフルパスを正しく入力することですね。

解らなければ、以下のPHPファイルを置いてアクセスすれば確認ができます。

<?php
echo __FILE__;
?>

上記のPHPファイルをwp-admin等の任意の場所に配置して、実際にアクセスすることでフルパスが確認できます。

例えば：www.サイトURL/wp-admin/sample.php

※サイトURLの後は構築した環境によって多少ことなります。

【.htaccess】を作って配置する

メモ帳等で以下を作成します。

－－－－－－－－－－－－－.htaccess

AuthType Basic
AuthName “なんでも良い（半角英数字）”
AuthUserFile /…さっき調べたフルパス…/wp-admin（認証させたい場所）/.htpasswd
require valid-user

－－－－－－－－－－－－－

【.htpasswd】の場所は任意なのですが、上記では【.htaccess】と同じ場所に配置しています。

１行目と４行目はコピペで大丈夫です。

【.htpasswd】を作って配置する

ここではユーザー名とパスワードを書き込むのですが、暗号化が必要になります。

難しく考えないで以下のサイトで生成したものを貼り付ければ大丈夫です。

暗号化したパスワードを生成してくれるサイト

これらをサーバーの任意の場所にアップロードすればBasic認証が設置出来ました。

簡単だから最低でもBasic認証は設置しておこう！

これでもログイン回数制限が発動するようなら、Basic認証を抜けられているということになります。

想像以上に攻撃されていることになるので、もっと真剣にセキュリティ対策が必要でしょう。

管理画面へのセキュリティ対策を行っていない人がどのぐらい居るかは解りませんが、wpは想像以上に攻撃を受けているようです。

攻撃されていることにすら気が付いていない可能性があるので、とりあえず以下のプラグインを入れてみましょう。

ログイン試行回数を加えるプラグイン

ログイン試行回数を制限すると、いかに悪意のある者達がログインに挑んでいるのかが解ります。

毎日のように攻撃されていることが判明したならば、いつ被害にあうか解らない状態にあると考えられますね。

とりあえずサクッとBasic認証を設置してみては如何でしょうか。

他にもセキュリティ対策については沢山の角度から考えるべきだと思いますが、全く対策しないよりは絶対にマシですよ(;’∀’)

中野シスターズの3Ｄモデルが凄いです！

このクオリティーで改変可の商用フリーとは・・・！凄い！

商用フリーの中野シスターズ

詳しい利用規約は探せなかったけど※追記あり

つまり商用フリーで改変も出来て報告不要・・・ほぼ自由ですか！？

さっそく自作ゲームに使わせていただきますぞ！！

このキャラを使ってフリーガの無料素材にも応用できますね。

ポーズをとらせてこんなのをサクッと作ったり・・・

こんな広告素材を作ったり

もしくはアレな感じなのもＯＫ？？

どこまでＯＫですか？？

とりあえずTwitterでフォローしときました！

さすがに詳細も調べずに好き勝手な使い方をする勇気はございません。

でもカナリのレベルで好き勝手に使える素材なのではと想像しています！！

これからも目が離せないです！中野シスターズ！

公式サイト：商用フリーの3Dモデル！中野シスターズ

追記：readmeに禁止事項がありました！

readmeには以下のような重要な内容が書かれていました。

【利用条件】

• どなたでも無料でお使いい ただけます。
• クレジット表記やライセンスロゴの表示も不要です。
• 利用申請や事後報告も必 要ありません。
• 改変データの再配布も可能です。
• 法人を含む商用利用の場合でも上記条件公序良俗に反するものでないこと。

【禁止事項】

• 公序良俗に反するものでないこと。
• 特定の信条、宗教、政治発言のために利用しないこと。
• 弊社もしくは第三者に不利益を与える行為に利用しないこと。
• 弊社もしくは第三者の信用や名誉を損なう行為に利用しないこと。
• 改変データや中野シスターズを利用した作品が、当社の公式商品であるかのような誤解を招く利用をしないこと。
• その他、当社が不適切と判断する行為に利用しないこと。

なるほど！気を付けます！

いかがわしい内容に使わなければ、ゲームのキャラに使ったりするのもクレジット表記なしの報告不要と解釈できますね！

素晴らしい無料データです！！

フリー素材アイドルってなんやねん？

読んで字のごとく、MIKAとRIKAの写真をフリー素材として使用できるグラビアアイドルです。

つまり以下のような広告を作るのも自由ということ！３秒で完成しちゃいます！！

早速FreeGAの広告を作ってみた

おぉ！ただ字を入れただけなのにイイ感じですね(^^)

やはり写真が良いものだと簡単に良いものが作れます。

ロゴを入れると永久に使用可能

公式サイトのHow toによるとダウンロード期間は２０１５年の１２月３１日まで

使用可能期間は２０１７年の１２月３１日までとなっております。

だがしかし！以下のロゴを付けた場合は永久に使用可能だとか

MIKA☆RIKAの公式ロゴ

これはもう今年中にガンガン作って永久に使い続けるしかないね。

ちなみにフリーガで再配布するとかはダメ！

ダウンロードの際には利用規約が表示されるので一読して理解しておく必要があります。

ビジネスや美容、体のパーツ等のカテゴリも充実

フリー素材を探すうえで重要なカテゴリ分けもサポート体制はばっちりでした。

折角なのでもう一つ作っちゃいましたよ～！

FreeGaの広告（MIKA☆RIKA）

やっぱり写真が良いと５分もかからずに出来ちゃいます。

記事を執筆しながらもMIKA☆RIKAの魅力にひきこまれ始めていますよ(*´▽｀*)

ちなみに音声素材も提供されているようなので、そちらを希望の方もMIKA☆RIKAを利用してみてはいかがでしょう。

MIKA☆RIKAの公式サイト

wordpressで画像を横並びにする方法は多数ありますが、stinger5を使用している私にとって〚最も簡単で管理もしやすい方法〛をご紹介します。

画像を横並びにする

※使用テーマによっては思い通りになりません。思い通りにならない場合、良ければテーマやサイトのＵＲＬを教えていただけると一緒に考えることができます。このような作業は好きなので気軽にご相談ください。

下準備としてメディアを追加で〚左寄せ〛

とりあえず横並びにしたい画像をすべて〚左寄せ〛にしてください。

画像を左寄せにする

この時点では横並びが失敗するはずです（ほとんどのテーマの場合）。

上の画像にのように横並びにならない場合も慌てる必要はありません。

また、今回紹介する方法では最後の画像を〚配置なし〛に指示する必要があります。

最後の画像だけ配置なし

これをしないと画像の後に続くテキストや意図しない画像まで横並びになってしまいます。

普段の作業はたったこれだけです。

なおcssの話ですが、ここで横並びを指示した画像には〚.alignleft 〛というクラスが付与され、最後の画像に使った配置なしの画像には〚.alignnone〛が付与されています。

あとは〚.alignleft{float:left}.alignnone{overflow: hidden}〛を追加するだけ

それだけです。シンプルかつ管理も簡単でしょ。

cssのどこかに以下の一行を追加すれば簡単横並びの完成です。

.alignleft{float:left}.alignnone{overflow: hidden}

もっと色々やりたいなら〚WP Canvas〛というプラグインを使うのも良いのですが、これだけのためにプラグインを導入して処理を重くしたくないという方には最適です。

最近は〚overflow: hidden〛によるfloatの解除が流行っているようなので便乗してアイディアをひねりました。

ぜひお試しあれ。

WPMLとBogoとqTranslate(mqTranslate,zTranslate)を試した結果、Multisite Language Switcherにした話。

今回言いたいこと：Multisite Language Switcher

・プラグインへの依存が少ない

・マルチサイト構築は驚くほど簡単

・マルチサイトにした方がシンプルで問題も発生しない

この記事はマルチ言語サイト構築での教訓から、心からMultisite Language Switcherをお勧めする内容です。

Multisite Language Switcher以外のプラグインを止めた理由

By: sboneham

上記で述べた３つのメリットがすべてですが、とにかくプラグインに依存したくなかったのが一番の理由です。

まずはそれぞれのプラグインが合わなかった理由を説明します。

WPMLやBogoを使うと他のシステムと干渉した

まずBogoやWPMLを止めた理由ですが、Bogoのような１言語１記事方式のプラグインはサイト内検索のプログラムを複雑化したためです。

通常であればget_postsのsuppress_filtersをfalseにすれば解決するようですが、該当サイトでは条件検索を構築していたため複雑になり過ぎました。

get_postsのsuppress_filtersで参考にしたサイト

凝ったシステムやプラグインを使う場合、多言語プラグインの多くは干渉しがちです。

それに１言語１記事方式でプラグインへの依存度も少ない（qTranslateと比較した場合）のだけど・・・大量に記事を書いた後にプラグインを外すと大変なことになります。

今後の値上げや更新の停止を思えば、プラグインへの依存は避けたいところです。

qTranslateは重い・・・それ以上に先が読めない

WPMLやBogoとの比較では動作が少し重かった。これから規模を拡大するには不安を感じます。

それ以上にqTranslateの更新は一年前で止まっており、今ではzTranslateやmqTranslateに移行しつつあります。

１記事複数言語方式のqTranslateではプラグインへの依存は非常に大きく、プラグインを外せばサイトが目茶苦茶になります。

qTranslate自体がどうなるのか解らないのだから、これではあまりにもプラグインに頼り過ぎていると思います。

Multisite Language Switcherなら全て解決できた

ここまでの批判的な意見はMultisite Language Switcherの特徴を引き立たせるためでもあります。他のサイトに当てはまるとは限りませんが説明します。

Multisite Language Switcherがプラグインに依存しない理由

By: Lenore Edman

それはプラグインを外しても問題ないからです。

Multisite Language Switcherが行っている作業は【異なる言語同士をリンクする】程度に留められているため、他のプラグインのような不具合は発生しません。

もしプラグインを外したとしても、今までマルチ言語サイトだったものが、『日本語のサイト』『英語のサイト』『中国語のサイト』・・・と分裂するだけで、サイトそのものは通常通り運用できるのです。

その状態であればプラグインに不具合が出ても、慌てて代替プラグインを探す必要がありません。

最悪のケースでも、Multisite Language Switcherを真似たシステムを組めそうなぐらいシンプルな仕組みといえます。

極端な話をすると、手作業でも主要部分のリンクを貼っていけば同じ状態まで持っていけるということです。

wordpressのマルチサイトは簡単に構築できる

Multisite Language Switcherと聞いて嫌悪感を抱いた人の中には、『マルチサイト』の構築を思い描いた人がいるかもしれません。

しかしマルチサイトの構築なんてものは、慣れれば１０分程度で出来る作業なので、『手順通り』に作業をすれば何も恐れることはありません。

Multisite Language Switcherほどのメリットを数十分の作業で得られるのだから、是非オススメします。

MULTISITE LANGUAGE SWITCHER 使い方 インストール

以下はマルチサイトの構築を含めたMultisite Language Switcherのインストール方法がまとめらた、非常に親切なサイトの引用です。

リンク先も載せておきますが、リンク切れになって情報を得られなくなるのは勿体無いので、文章も残しておくことにしました。

私もPHPが好きな方ではないし、パッと見ただけで拒絶したくなるものですが、手順通りに作業すれば直ぐに出来てしまうはず。

何も考えずにコピペで出来てしまうような、素晴らしい記事だと思うのですが如何でしょう。

MULTISITE LANGUAGE SWITCHER 使い方 インストール

作業はfunctions.phpの編集で行います。

この手の作業は使用プラグインとバージョンによって微妙に異なるのですが、ちょっとしたコツがあるので紹介します。

functions.phpでwp_enqueue_scriptsを使う

今回はDownload MonitorでCSSを止めるコードを例にしながら説明します。

Download MonitorのCSSを停止する

結論から言うと、以下をfunctions.phpに追記することでCSSは読まなくなるはずです。

// download monitorのCSSを停止
add_action( ‘wp_enqueue_scripts’, ‘plugin_css_stop’ );
function plugin_css_stop() {
wp_dequeue_style( ‘dlm-frontend’ );
}

かつてはwp_print_stylesが使われていたのですが、今はwp_enqueue_scriptsを使うのが正しいです（２０１５年２月）。

『プラグインのCSS』等でググると似たようなコードが見つかるし、適用したいプラグインのコードをピンポイントで発見できればコピペでもOKです。

しかしマニアックなプラグインでもCSSやjavascriptを停止したい場合があるでしょう。

コピペせずに理解する為にも、まずはCSSが呼び出されるhead内を参照してみましょう。

<link id=”dlm-frontend-css” href=”http://freega.net/wp-content/plugins/download-monitor/assets/css/frontend.css” rel=”stylesheet” type=”text/css” media=”all”>

どうやらfrontend.cssというスタイルシートを毎回呼び出してくれているようです・・・全く意味が無いのに！（←あくまで私の環境の話）

なにはともあれブラウザの『要素を検証』機能等を使い、消したいCSSを特定できたならidを覚えておきます。【id=”ココ“】

要となるハンドル名はidの場合が多い

今度はfunctions.phpに記述するコードを解説します。

add_action( ‘wp_enqueue_scripts’, ‘ここは任意で決める‘ );

function ここは任意で決める() {
wp_dequeue_style( ‘ここがidになることが多い‘ );
}

黒字部分は変わらないのでコピペで使用できる部分です。

【ここは任意で決める】は自分が理解し易いようにplugin_css_stopとしました。

【ここがidになることが多い】部分はプラグインのハンドル名と呼ばれる部分でDownload Monitorの場合はdlm-frontendでした。

head内で確認したid=”dlm-frontend-css”から-cssを削除したものがハンドル名だったわけです。

これは必ずと言い切れる部分ではないですが、多くのプラグインはidをハンドル名にしています。

Download Monitorもバージョンアップ時にハンドル名が変わってしまいましたが、このidを見ることで推測が可能だったのです。

これ以外の方法によるハンドル名の特定方法を知らないので非常に助かっています。

（もしもハンドル名の特定方法を知っている方がおられたら、是非教えていただけないでしょうか）

JavaScriptを停止したい時にはwp_dequeue_script

たとえばContact Form 7のCSSとJavaScriptをformページ以外で読み込ませたくない場合は、functions.php内に以下を追記します。

add_action( ‘wp_enqueue_scripts’, ‘contact7_stop’ );

function contact7_stop() {
	if ( ! is_page( 'form' ) ) {
		wp_dequeue_style( 'contact-form-7' );
		wp_dequeue_script( 'contact-form-7' );
	}
}

Download Monitorのときと違うのはif ( ! is_page( ‘form’ ) ) {～}で囲ってformのページだけ除外していることと、wp_dequeue_script（）を使ってjavascriptも読み込まなくしていることです。

ちなみにhead内のCSSは以下のようになっていました。

<link rel="stylesheet" id="contact-form-7-css" href="http://freega.net/wp-content/plugins/contact-form-7/includes/css/styles.css" type="text/css" media="all">


やはりidがハンドル名として使われていたようですね。

このハンドル名はjavascriptにも有効だったので、先ほどの例のように一纏めにできましたが、別のページを指定したい場合やハンドル名が異なる場合は分けて記述する必要があります。

※formはスラッグ名のこと。ID番号で指定したい場合は、 if ( ! is_page( 8) )のようにページのID番号で指定することも可能。

さいごに

この業界の進化は速いし、 wordpressもプラグインも更新の度に仕様が変わるので、今回の方法も長くは使えないかもしれません。

しかし、コードを眺める癖さえつけていれば些細な変更ぐらいは対応できるようになるし、グーグル先生に尋ねるよりも効率が良いと感じています。

そして誰かが発見したコツがネット上で共有されていき、少しずつ作業が簡単になっていくなら嬉しいことです。

それに・・・いつかはプログラムによるカスタマイズが不要になるほど、ツール側が進化するのでしょう。

それは寂しくも感じるのですが、便利な未来で自分は何を出来るのか、少し不安だけど凄く楽しみです。

Wp Custom Fields Searchで全角検索

ワードプレスで絞り込み検索を行う場合、絞り込み検索の方法/KOTORIが大変参考になり実践しています。

プラグインを導入するよりも素晴らしいシステムが構築できるし『いいことずくめ』です、が！！

拘らないのであればプラグインの方が１００倍楽です。

ちょうどよくWP Custom Fields Searchがアップデートしてくれたので使っちゃいました。（2015-07-27）

※ただしKOTORI様の方法で実際に組んだサイトは、文句のつけようがないぐらい理想的な検索システムになりました。改めてありがとうございます！

WP Custom Fields Searchで日本語のキーワード検索ができない

これは普通にできている人もいるようなのですが、今も制作中のフリーガというサイトでは検索できませんでした。

色々調べているうちに、プラグイン側でエラーが発生していることが原因だと判明しています。（決め手となったサイトを見失ってしまった(-_-;)）

解決：プラグインのextra_search_fields.phpを１行削除

プラグインフォルダ内にextra_search_fields.phpがあるはずなので、中の888行目を消すと解決です。（私は以下のようにコメントアウトしました）

※WP Custom Fields Search　ver0.3.27時

function getSuggestedFields(){
		return array(
			'all'=>__('All Fields','wp-custom-fields-search'),
			'post_content'=>__('Body Text','wp-custom-fields-search'),
			'post_title'=>__('Title','wp-custom-fields-search'),
			'post_author'=>__('Author','wp-custom-fields-search'),
/*'post_date'=>__('Date','wp-custom-fields-search'),コレを消す*/
		);
	}

コードを見てもわかるとおり、これを行うと日付をキーワードで検索できなくなります。（個人的にド～でもいいですわ）

はまってる人が少ないのか全然情報がないんですよね。
同じように困ってる人は試してみてください。

自分も忘れると詰みゲー状態になりかねないので、自分のためにメモメモ(..)

By: John Fischer

WordPressの4.3にアップデートしたところ、管理画面のサイドバーに表示崩れが発生してしまいました。

表示崩れの内容は、サイドバーの項目が消えたり、段がズレたりすることです。

Chrome45以降のバグだった

CSSやjsを弄り過ぎて壊してしまったものと勘違いしていたのですが、どうやらChromeによるBugのようです。

Chromeで以下を開いて〚スリミングペイントを無効にする〛を有効化し、再起動することで回避できます。

chrome://flags/#disable-slimming-paint 

※アドレスバーにコピペして移動してください

Chromeのバージョン45以降はスリミングペイントにバグが発生しているらしく、Wordpressには問題がないとのこと。

参照元

私が管理しているサイトは会員サイトなので、何か対策が必要ですね・・・めんどくさいので早くChrome側で対処してほしいです。

今も制作中のフリーガではカスタム投稿によって記事を分けています。

そこで問題になるのは関連記事の表示。

カスタム投稿の関連記事

私はコピペプログラマーなので『ちゃっちゃとググって』作業を進めようと思っていたのですが・・・ググっても見つからない！！

・・・とても嫌だけど自分で考えることにしました。

post_typeを使ってカスタム投稿を取得

もともとpost（通常の投稿記事）を使った関連記事を表示させていたので、極力改造が少なくてすむ方法を考えています。とりあえずコードは以下になります。

ベースは一般的な方法なので、3行目と7行目をコピペして、既存のコードに追加してご使用ください。

3行目

$names = esc_html(get_post_type_object(get_post_type())->name);//カスタム投稿を取得

7行目

'post_type' => $names,//取得したslugで絞り込み

※以下は使用例、全部コピペしても使えません

<?php
global $post;
$names = esc_html(get_post_type_object(get_post_type())->name);//カスタム投稿を取得

$args = array(
 'numberposts' => 6,
 'post_type' => $names,//取得したslugで絞り込み
 'orderby' => 'rand', 
 'post__not_in' => array($post->ID) 
 );
?>
<?php $myPosts = get_posts($args); if($myPosts) : ?>
<?php foreach($myPosts as $post) : setup_postdata($post); ?>
 <dl class="clearfix">
 <dt> <a href="<?php the_permalink() ?>" >
<?php $postImage = getPostImage($post);
if($postImage == null){
 echo '<img src="no-img.png" alt="no image" title="no image" width="200" height="" />';
}else{echo '<img alt="' . $postImage["alt"] . '" src="' . $postImage["url"] . '" width="250" />';
}?>
 </a> </dt>
 <dd>
 <h5><a href="<?php the_permalink(); ?>">
 <?php the_title(); ?>
 </a></h5>
 
 </dd>
 </dl>
 <?php endforeach; ?>
<?php else : ?>
 <p>まだありません</p>
<?php endif; wp_reset_postdata(); ?>

胆になるのは　$names　でカスタム投稿のスラッグを取得しておくこと。
取得しておいた $names　を ‘post_type’ で指示してやれば、カスタム投稿による絞り込みが可能です。

この方法のメリット

ググったときに出てきた情報では、カスタム投稿ごとに『投稿ページのテンプレート』を用意してやる必要がありました。

フリーガでは投稿ページを共通のテンプレートで制作しているので、ググって見つけた方法だと困るのです。

この方法は簡単だし需要もあるんじゃないかな。

今回はXサーバーでマルチサイトを構築したときのデータベース分割方法をご紹介します。

いや、紹介すると言うよりは恥を忍んで公開します。

もっとスマートな方法があれば教えて頂けると幸いです。

なにはともあれ!

マルチサイトでも１サイト１DBは実現されました

XサーバーではMySQLを50個（ｘ10プラン）も追加できるのですが、Wordpressのマルチサイトではデータベースを一つしか使えませんよね。

それはそれでメリットもあるのですが、管理やパフォーマンス（※使い方にもよる）を考えて複数のデータベースに分割することにしました。

サブサイトにも１DBを実現するSharDB

私の知る限りマルチサイトでのデータベース分割方法をネットで公開してくれている方は『ITかあさん』だけなのですが、ところどころで私との解釈に違いがあるためか（あるいはサーバーの仕様が違うためか）思い通りには進められませんでした。

そこで私なりの覚書を残しておこうと思います。

これから同じことを実現したい方は、『ITかあさん』と当サイトでの方法を噛み砕きながら理解することが出来るはずなので、それなりに需要があるのではないでしょうか。

参考になるサイト

ということで、『ITかあさん』のページを別タブで開きながら当サイトを読むことを推奨します。

当サイトでは詳細の説明を省きます。

wp-content内の作業は最後の最後に行うべきなのだけど・・・

本来はdb.phpをwp-contentに入れるのは、DBのマイグレーションが済んでからである、とreadmeに書かれています！英語でよく理解できないけど。

でも私の環境では無理でした。（db.phpを入れる前と後ではDBの割り振りが変更されてしまう※1：失敗例）

それとshardb-admin.phpをmu-pluginsに入れるとエラーが出るので入れることができませんでした。※なのでネットワークで有効化の状態にしているだけです

マルチサイトでもDBを分割した方法

まずはMySQLのjapan3d_wp3を使用しているとした場合、$shardb_prefix = ‘japan3d_wp3’;　をdb-settings.phpに追記します。（ITかあさんを参照）

更に$shardb_hash_length = 1;を1にしておき、あらかじめMySQLを追加しておきます。

$shardb_dataset = は何でも良いので２文字とか３文字の短めが良いと思います。

例. japan3d_wp3で分割する場合は、japan3d_wp30,japan3d_wp31,japan3d_wp32,・・・japan3d_wp39,japan3d_wp3a,japan3d_wp3b,japan3d_wp3c,japan3d_wp3d,japan3d_wp3e,japan3d_wp3fまでの計16個のDBを作成します。

$shardb_hash_length = 2;の場合は、japan3d_wp300から始まる256個のDB用なので、16個以内で収まるなら1にしましょう。

私は以下の手順で強引に成功しています。

1. ネットワーク上のプラグインをすべて停止（した方が良い）
2. SharDBをインストール
3. db-settings.phpに3行を追加、そしてwp-config.phpと同じフォルダに追加（ITかあさんを参照）
4. wp-config.phpにrequire(‘db-settings.php’);を追加（ITかあさんを参照）
5. あらかじめ16個のDBを作る（MySQLなら親サイトと同じユーザーに対して権限も追加しておく）
6. db.phpをwp-contentに追加※2：コツ
7. SharDBプラグインをネットワークで有効化
8. マルチサイトを追加していく※3：強引だけど
9. shardb-admin.phpは最後まで使わない（エラーが出て使えなかった）
10. 全作業が完了

強引だけど：あらかじめDBを16個用意してdb.phpを入れた状態で作業

db.phpを入れる時にも嵌りポイントがあったので、db.phpを入れられない場合は、下で説明しているコツを参考にしてください。

何故このような方法になったかについては、もう一つ下に失敗例も載せてあります。

そして、この方法が強引な理由ですが、サブサイトが割り振られるDBの予想ができません。

メインサイトはjapan3d_wp3globalに入るのは確実ですが、サブサイト1とサブサイト2が同じjapan3d_wp3bに割り振られたり、サブサイト3がjapan3d_wp31に割り振られたりするのです。

もしも全てのサイトを別々のDBに入れたい場合は、DBが重複するたびにサイトを削除して、再度サブサイトを追加する作業を繰り返します。

想像ですが、SharDBの仕様だと思います。

私は何度もサイトの削除と追加を繰り返すことで、１サイト１DBを実現しました。ほかに良い方法があれば教えてほしいです。

コツ：『db.php』をwp-contentにアップロードできない

これはXサーバーの仕様なのか・・・それは謎ですが、dp.phpをwp-contentフォルダにアップロードすることができませんでした。

その場合は適当な名前に変更してからアップロードしましょう。

例.ダウンロードしたdb.phpをdb-test.php等にリネームし、wp-contentにアップロードしてからdb.phpにリネームし直す

dbにリネームし直す

※失敗例：MySQLを追加する前にSharDBを実行してみた

あらかじめデータベースを作らずにSharDBを実行した場合、SharDBは実行されるのですがDBを書き込む先がないので空回りします。

つまり何もおきません。

ではなぜMySQLを追加する前にSharDBを実行したか？

それはSharDBが割り振るDBの法則を理解できなかったからです。

SharDBがPartitionに割り振る挙動

SharDBは指定したDB名を規則的に利用するらしいです。

なぜ『らしい』なのかというと、私の環境では不規則だったからです。

追記※検証の結果、$shardb_hash_length = 2;であればjapan3d_wp3のあとに2桁のランダム数値、10を入れれば10桁のランダム数値が入るようです。ランダムなのがSharDBの仕様なのかな

shardbの挙動がわからない

なのでMigrate Sitesボタンをクリックして、実行画面を確認してからDBを作成してみることにしたのですが・・・（以下失敗例）

確認してからMySQLを追加

それと追加したMySQLに対してアクセス所有ユーザーを追加するのを忘れずに。

親サイトと同じアクセス権

さぁ！ここからMigrate Sitesを実行することでサブサイト1のデータをjapan3d_wp31にコピーできました！

db.phpをwp-contentに追加して全てが順調に進むかと思っていたのですが・・・db.phpを追加するとサブサイト1の割り当て先がjapan3d_wp39になっています。どうやらdb.phpを追加する前と後ではDBの割り当てが変化してしまうようです。

この失敗を踏まえて『強引だけど：あらかじめDBを16個用意してdb.phpを入れた状態で作業』に至ります。

１サイト1DBを実現した結果

特に問題もなく思い通りの運用ができています。

しかし、SharDBでマルチサイトの１サイト1DBを実現できたものの、スマートな方法は解りませんでした。

英語に強くてプログラムにも長けている猛者がおりましたら、どうか助けてください。

今も製作中のサイトで、MySQLを5.1→5.5→5.78（RC）の変更をしました。

WordPressのデータも既存のものを引っ越して使っているのでベースはMyISAMです。

っで、何も考えないでMySQLのアップデート作業とかしてると、デフォルトがInnoDBになるのでMySQLとInnoDBの混在DBが出来上がります。

MyISAMとInnoDBの混在状態って気持ち悪いおね

別に問題なく動いているしベンチの結果も大差がなかったのですが、新しい方についていった方が後々のアップデートで楽ができるのでInnoDBに統一することにしました。

本来であれば、MySQLの中に入り以下のコマンドで変換していくだけでOKです。

alter table wp_hogehogehogehoge engine=innodb;

MyISAMへの変換も同じ要領っす。１０個ぐらいなら一つ一つ手作業で頑張ったほうが良さそうですよ。

まとめて変換する方法も頑張ればあるのですが、私の場合は『それ以前の問題』にぶつかりました。

『Invalid default value for ‘hogehoge’』が出て変換できない

これってMySQLのバージョンを跨いで引っ越しをしているから、新しいMySQLが放棄しちゃってるんだと思うんです。（あまり有力な情報を得られなかった）

このパターンも初めてじゃないしMySQLって、バージョンアップの度に喧嘩売ってくるから嫌いですよ。

例のごとくワイロを渡して通してもらいましょう。

SET sql_mode='ONLY_FULL_GROUP_BY';

このコマンドって曖昧なMySQLを正規な見方で厳しく取り締まるものだったと思うんだけど、なんで逆に通るんだよ・・・。

InnoDBの変換に困った私がググったところ、海外のエンジニア達が(^^♪ONLY_FULL_GROUP_BY！(; ･`д･´)ONLY_FULL_GROUP_BY( ;∀;)ONLY_FULL_GROUP_BY！！って教えてくれたのですが日本語で解説してくれている情報がないのでイマイチ解らねぇ！

まぁ、問題が出た時にログを見ながら解決していくのがサーバー運用の醍醐味じゃないですか！

それにMySQLってチューニングによる努力が性能アップの度合いと見合わないし、唯一InnoDBで勉強したいのが『クラッシュ時のリカバリに対応』って部分なんです。

壊れてみろよ！リカバリしてやるぜ(*‘∀‘)

だめならバックアップで元に戻してMyISAMに統一するまでです。

PHP7とNGINX1.9.5(https/2)をApacheのリバースプロキシで検証中

そうそう、今作ってるサイトってPHP7とNGINX1.9.5（https/2）をApacheのリバースプロキシで組んだドリームプロジェクトなんですよ。

どいつもこいつもRCバージョンなんで本番は少し先ですが、丸一日掛りのチューニングでRequests per second: 500/secぐらいを叩き出してくれました。

過疎サイトを育てながらメモリ1Gで何PVまで耐えられるかを観察していきたいと思います(^^♪ﾀﾉｼﾐﾀﾞﾅｰ

それがしはコピペプログラマーでござる。

信念は速く動き早く作る！
考える前に貼り付けることで数多のサイト制作をして参った！

つまり新しく製作したサイトも古いプログラムの使いまわしってことです・・・しかしWordPressのバージョンアップ時ぐらいは『どんなコードが廃止になるのか（可能性）』ぐらいのチェックはしておくべきだ！！っと経験者の私が忠告しましょう。

何故かというと、新しいコードと干渉する確率が高いからです。

マルチサイトで検索画面が真っ白な件

これはマルチサイトが原因というよりは、Wordpress4.3.1の文字コードとの相性が悪かった？（あるいはwp super cacheの影響）

まずはnginxのエラーログを調べてみると・・・wp-custom-fields-search.phpでエラー発生！

なぁ～んだ(^^♪　これを機にプラグインを外してしまえ！

ジャーン！検索結果も真っ白なままだし、今度はエラーも吐かねー（深刻）！！

検索結果ページのコードを見直す

問題の箇所はこちら

<?php
$allsearch =& new WP_Query("s=$s&posts_per_page=-1");
$key = wp_specialchars($s, 1);
$count = $allsearch->post_count;
echo '「'.$key.'」は'.$count.'件でござる';
?>

あぁ！？それがしが製作したサイトは全部このコードでござるぞ（ブチ切れ）！！

神の声　『wp_specialcharsはWordPress2.8の時点で終わっている』

(;´･ω･)ｿﾝﾅﾉ知ﾗﾅｲﾃﾞｺﾞｻﾞﾙｰ

とりあえず現代風に直すと以下になります(;´∀｀)

<?php echo esc_html($s, 1); ?>は<?php echo $wp_query->found_posts; ?>hitしました

まとめ

新しいコードに修正したところ無事に真っ白問題は解決しました。
しかし、日頃から確認を強化していれば無駄なバグ潰しは不要でしたね。

今抱えてるサイトたちについても自動アップデートを無効にしているので、突然真っ白！なんてことはないと思うのだけど、誰かが勝手にプラグイン入れたりするとアウトな状態です。

来週からは各サイトの修正です・・・なんだか嫌な休日になってしまったよ。

Conohaの900円プランにて

PHP7　+　NGINX1.9.5 + MySQL5.7.8　の組み合わせでコツコツと続けてきたwp super cache用のリバースプロキシカスタマイズ・・・

最終的にフリーガのトップページのabベンチが常時SSLだと500/sec止まり、SSLなしだと平均で1万/secぐらいになりました。

とても頑張って禿ました。

なのに最近加わったConohaのkusanagiだとアッサリと3万/secを超え！ときには4万/secまで( ﾟДﾟ)

私ごときがPHP7とfastcgiのリバースプロキシで頑張ってもkusanagiのデフォルトに勝てませんでしたよ( ;∀;)超一流の仕事ってスゲー・・・

ってことで本番では草薙の高速wordpressにnginx1.9.5を追加して使用することにします。

自前のPHP7カスタマイズではnginxとwp super cacheによるガチガチキャッシュだったのだけど、会員サイトであるフリーガとの相性が最悪で、その辺の問題は草薙の高速wordpessではイイ感じに仕上げてくれてるんです。私のカスタマイズが雑だったことで2万/sec以上の差をつけられてしまったのですが、SSLでは平均100/secぐらいPHP7の方が速かったのは興味深いところでした。　これはPHP7の特徴なのかもしれないですね。それにしても常時SSL化にしなきゃならない風潮なのはわかるけど、abベンチの結果ではSSLありが100倍近くCPU負荷が高いという現実。色々頑張っては見たのだけど月900円のメモリ1Gプランでは対処できない問題なんだろうか。

ちなみに私が頑張ってカスタマイズしたけど没になったPHP7の結果はこんなです（SSL時）

Document Length: 52535 bytes

Concurrency Level: 100
Time taken for tests: 0.242 seconds
Complete requests: 100
Failed requests: 0
Write errors: 0
Total transferred: 5292400 bytes
HTML transferred: 5253500 bytes
Requests per second: 412.71 [#/sec] (mean)
Time per request: 242.303 [ms] (mean)
Time per request: 2.423 [ms] (mean, across all concurrent requests)
Transfer rate: 21330.15 [Kbytes/sec] received

nginxを扱っていると40xや50ｘ系のアクセスに関するエラーを出してしまうことがあると思います。

特に注意が必要なのは『一見問題がないケース』ではないでしょうか。

管理画面が404程度なら直ちに気が付くのですが、今回はコメントできない等の『特定ページ』だけアクセスできないケースでした。

アクセスの問題は大抵がnginxの.confっぽい

これは経験上の話なので他の人はわかりませんが、わたしは9割が.confの設定ミスです。

私のようなコピペプログラマーは考える前に貼り付けて、ベンチマークの結果が良好ならOK！といった作業を繰り返してしまいがちですが、頭も働かせずに良いものを作れるわけがないのは当然っちゃー当然だわな(;´･ω･)

問題は草薙ではなく基本的なミス

まずJetpackの同期がとれないことが事の発端です。

原因はxmlrpc.phpにアクセスできないことでした。

高速wordpress草薙に変更した直後だったので・・・『これはセキュリティー系の問題だな(￣ー￣)』などと勝手な想像を働かせていたのですが、直後にコメントできない問題を発見！

いずれも404エラーだったことから『これはｈｔｔｐ.confだ！』と断定しました。

最終的にマルチサイト用に追記した設定が間違っていただけでした。

草薙のnginxをマルチサイトするには以下をhttp.conf(あるいはssl.conf)に貼り付けると上手くいくはずです。

# マルチサイト用追記
 
set $cachetest "$document_root/wp-content/cache/ms-filemap/${host}${uri}";
if ($uri ~ /$) {
 set $cachetest "";
}
if (-f $cachetest) {
 rewrite ^ /wp-content/cache/ms-filemap/${host}${uri} break;
}
if ($uri !~ wp-content/plugins) {
 rewrite /files/(.+)$ /wp-includes/ms-files.php?file=$1 last;
}
if (!-e $request_filename) {
 rewrite ^/[_0-9a-zA-Z-]+(/wp-.*) $1 last;
 rewrite ^/[_0-9a-zA-Z-]+.*(/wp-admin/.*\.php)$ $1 last;
 rewrite ^/[_0-9a-zA-Z-]+(/.*\.php)$ $1 last;
}

これはcodex.wordpress.orgのnginxページに書かれている内容です。

あまり彼方此方のサイトを参考にするよりはcodexを見ながら慎重に作業するのが得策のようです。

※追記：時間を優先して諦めました。まだ製作の初期段階なのでマルチサイトを止めてカスタム投稿で設計してみようと思います。

最近はFreeGA.netというサイトを趣味で作ってます。

そこではPHP7+nginx1.9.5+MySQL5.6のカスタマイズを頑張っていたのですが、ある日を境にピタリと止めました。

その原因はConoHaに加わったKUSANAGIに浮気したことにあります。

デフォルト状態でもabベンチの結果が3倍程度（3～4万/sec）も出てしまうし、キャッシュの管理も最初から整備されているし、頑張ってカスタマイズしても私の力が及ばないのかと思うと馬鹿馬鹿しくなってしまったのです。

マルチサイト化も順調のはずが

NGINXでの基本的なマルチサイト方法をconfに追加するだけで、これといった悪影響もなくマルチサイト化も完了！と思いきや。

3番目のサブサイトで『ConoHa Object Syncプラグイン』を使用したところ、オブジェクトストレージにアップロードができません。

『ConoHa Object Syncプラグイン』自体の設定は非常に簡単で、接続テストも問題がないのですが・・・

私のマルチサイト化に問題があるか、そもそもマルチサイトに対応していないのか、KUSANAGIでは使えないのか・・・謎。

実は2番目のサブサイトでも、アップロード時にサムネイルが表示されないときがあるという兆候もありました・・・困った(;´･ω･)

 仕方なくAmazon S3を試してみた

WP Read-Onlyというプラグインを使ってみたところ問題なさそうですね。凄く悩みます。

現時点では転送量も殆どないのでS３に軍配が上がるのですが、後からの移行は面倒な予感。

それだけConoHaのオブジェクトストレージの定額制は魅力的です。

それと私の環境だけなのか、仕様なのかは解りませんが、『ConoHa Object Syncプラグイン』はメディアを削除してもuploadsフォルダ内にゴミが残ります。

私の理想としてはWP Read-Onlyのようにwordpressのサーバーにアップロードしないのが好ましいです。

まとめ

あまりオブジェクトストレージの勉強に時間を掛けたくなかったのですが、FreeGA.netにとっては重要な部分になるので勉強時間が必要かもしれません。

そもそもWP Read-Onlyは直接S3にアップロードしているのか？（アップロード時のサーバー負荷が問題）

オブジェクトストレージのAPIで何が出来るのかが全く解らない状態では、何がなんだか解りませんでした。

しかしプラグインに頼らないとなると、どれだけ時間が掛かるんだろう。

・・・勉強の範囲を広げたくない。誰かがプラグインを公開してくれないかな(;´∀｀)

最近はFreeGA.netの製作が一番の楽しみなので、ここでのネタもフリーガばかりですね。

今回は動画投稿サービスに弾幕コメントを追加してみました。

ConoHaオブジェクトストレージの見せ所が来た

いよいよ動画のアップロードサービスが開始したので、ConoHaのオブジェクトストレージが如何なる性能であるかが見極められます！

WordPressへの実装にはConoHa Object Syncを使用しています。

まだ40MBぐらいの大きさしかアップロードしたことがないですが、ゆくゆくは最大1GBぐらいまで試すことができたなら、オブジェクトストレージに興味を持つ人たちにとって喜ばしい報告ができるのだと思います。

私の場合、900円のメモリ1Gプランなのですが、どうやらアップロード時にはWordpressのサーバーにもアップロードしているのでメモリ不足の問題が先に訪れる予定・・・直接オブジェクトストレージへアップロードする方法があれば誰か教えてください<m(__)m>

MukioPlayerからABPlayerに・・・最終的にはDanmuPlayerへ

私はコメントが動画上にないと何かが足りない気持ちになるほど弾幕が好き。

だったら趣味で作ってるサイトに弾幕を実装しないと『趣味を全う』したことにはならないぞ！・・っと天からの声が聞こえた気がしました。

厳しい道でしたが、HTML5＆SQLによって形にすることができました。

まずMukioPlayerから挑戦したのですが、Flashは先行きが不透明なのでやめました。

次に挑戦したABPlayerはHTML5とJsによりXMLでコメントを管理する理想的なシステムです。UIも中国の凄い人たちがGithub上に公開しており参考になります。が！私はXMLの扱いに躓いて断念しました。Xmlという不慣れなファイルを扱いたくなかったのです(;´･ω･)

その後はCommentCoreLibraryとVideo.jsで何とかできないか挑戦したり、Googleで色々調べたり・・・とても長い不毛な時間を経て、ついに見つけたのがDanmuPlayerです！

DanmuPlayerならSQLで実装出来た！

DanmuPlayerはABPlayerと似ていて、HTML5とJsによるコメント付きプレイヤーを実装可能です。

デフォルトではHTML上に記されたコメントが動いているだけですが、query.phpとstone.phpにはデータベースへ接続するための情報が含まれています。

理解できなかった部分は無視して色々と改造してしまいましたが、結果的にSQLとポストを結びつけることができました。

１記事に１テーブルを採用

本来であれば１テーブルにすべてのコメント情報を入れてIDで管理する？といったコードにも読み取れたのですが、SQLとPHPとJSが絡むと嵌りポイントも多く、最終的にたどり着いたのが１記事に１テーブル方式です。

当初はテーブル名の１部にGET_ID()の情報を入れたかったのですが、バックエンドで扱わなければならないPHP上でSQLを読み書きする仕様だと、PHPを使ってもJｓを使っても、なかなか変数の受け渡しがうまくいきません(; ･`д･´)500エラー500エラー・・・よくわからんけど、http/2で常時SSLにしたこともエラーから抜け出せない要因だったのかも。

まぁ、この段階までシステムが完成すれば何とでもなるのだけど、私はWordpressのURLでスラッグの変更を禁止して/video-(postID)/という形に統一することで、PHPからもJsからもポストIDをURLからゲットできるようにしたのが決め手になって、ユニークなテーブル名を作成しています。

なにはともあれConoHaに頑張ってもらいます

アップロード時のサーバー負荷を減らすためにConoHaオブジェクトストレージにのみアップロードしたかったのですが、データのバックアップも兼ねて諦める方針にしました。そもそもサーバー負荷や容量が心配なら課金しろって話だし、５万円の64Gメモリプランにロードバランサーを合わせても捌けないサービスを作ってから心配しろという話だよね。

ConoHaのVPSを使っていれば何の心配もない気がする。

製作中のフリーガではbuddypressやDanmuPlayerを中心に色々と勉強が出来ているので、その辺の話を酒でも呑みながら語り合いたいところです。

今は未完成で使い物にならないけれど気軽に会員登録をして仲良くしてくださいね<(_ _)>