いつかは来ると思っていたけど…

いつかはそんな問い合わせが来ると思っていました…

hi gqevu6bsiz,
does it support multisite?

プラグインに問い合わせが来ました。
gqevu6bsizはマルチサイトを普段使用することがないので、ほとんど使ったことが無かった機能。

 

「マルチサイトはサポートしていますか?」

ここでいうサポート = 使用できるか。という意味だと思うので、マルチサイトでも機能しますか?という意味かな。

does it use multisite? じゃないのか。”サポート”という言葉の意味の範囲が少し狭すぎました。

 

とりあえず「サポートしていませんよ、すいませんね。」と返事。

I'm sorry, currently does not support multisite.

ついでに、「検討してみますね。」と言ったのですが、この場合の英語、本当にこうなるのだろうか。

I'll think about it.

I’ll = I will (たぶん、この場合は前向き的な意味合いになると思う)

 

マルチサイト…う~ん。難しそう。一応いつかは対応しようとは考えていたけど。

どうやって設計したら、使いやすいんだろう。どんなUIがいいんだろう。

 

おそらくマルチサイトの機能を利用する方は、サービス等を運営していて、サイトやブログを持つことが出来るユーザーを登録させる。

で、gqevu6bsizのプラグインのほとんどが、管理画面のカスタマイズが中心なので…。

掛け合わせると、子サイト・子ブログの管理画面のカスタマイズを、
ネットワーク管理者ができるようにすること。かな。

今までは管理画面のカスタマイズを、サイト・ブログの管理者が出来るようにしていました。

 

ネットワーク用管理画面のフック、どれだけあるんだろうか。

do_action をひたすら検索….。かな 🙁

データベースへの格納形式の変更後

というか、それ以前にこのブログが表示されない事があり、焦りました。

とりあえずすぐに、データベースのバックアップだけを、なんとかおこない、
FTP経由でデータをダウンロードしようと思ったら…

FTP接続まで障害が及んでいる模様。。

4時間後には障害は復旧したらしいので、ブログを更新することにしました。

レンタルサーバ、安いだけじゃやっぱり不安ですね。。

 

さて、タイトルの本題です。

プラグインをひとつだけ、データベースへの保存方法を変更し(テーブルを用意してそこに保存)、
プラグインをアップデートしました。

 

驚いたことに、以前に3の評価をつけた外人からコメントがあり、その評価が5になっているじゃないですか。

えっ?評価って変更できるの??

レビューの内容はこう。

Since version 1.2, COPPI now uses its own database table, so the performance issue above has been fixed.

なになに、、

バージョン 1.2以降、コッピは現在、独自のデータベース·テーブルを使用しているので、上記のパフォーマンスの問題が修正されました。

あ、指摘していたのはこういう事なのかと実感しました。「コッピは現在…」変に違和感。

Google さん、無理やり”コッピ”として変換しなくても。。

 

とりあえず、返事として

thankyou review.I was able to develop better in your favor.

言いたいことは、

レビューありがとう。私はあなたのおかげでより良く開発することができました。

your favor あたりが本当にそんな意味なの。
for your thanks?
thanks to?

“おかげ”って、日本語、難しいです。

 

ただ、初めてテーブルを用意し、UPDATE文やINSERT文を用意してクエリを発行する形式にしたので、
不具合等が起きないかどうか心配でしたが、今のところは何の苦情も出てないので大丈夫そう。

 

プラグインで寄付の代わりとなる、いい方法ないかな

このブログの開設と、wordpress用のプラグインを開発・配布をしてきて、もうすぐ半年ぐらい経過するような、したような。うろ覚えです。

 

ブログ開設当初は、プラグインを作って配布して、
寄付をもらったり有料プラグインを作って買ってくれたらな~という軽い気持ちでスタートしました。

で、後から気づいたのですが、そもそも日本の法律が寄付がダメ(個人間の送金)らしいのです。

以前の記事はこちら

 

で、実際に開発・配布してみて思ったこと。

期間やプラグインの質・量にかなり左右はされますが、それは。

「うん、誰からも寄付されないなら、開発を続ける人はそりゃ少なくなるだろうな」

という事でした。(あくまでも私 gqevu6bsiz 自身の意見です)

 

そして、最近知ったのですが、

http://ideasilo.wordpress.com/2012/09/16/speech-at-wordcamp-tokyo-2012/

確かにオープンソースはいいと思います。

私も無料プラグインをダウンロードして、学習はしたので、オープンソースの恩恵はもちろん多々受けています。

 

ですが、日本の法律で寄付がダメってなっている以上日本人プラグインの開発者は、
無料配布で趣味で続けられる人だけ続けてねって事なのか?って思いました。

寄付が法律でダメならどうしたらいいんだよ~

有料販売でもして、少しでもお金が入ってくれないとモチベーションあがんないよ~

 

ちなみに人によっては嫌われますが、gqevu6bsiz は正直ちょっとしたお金が入ってくれることが、
モチベーションアップとなります。

詳しくはこのサイトについてを参照

 

という事で、私の場合はamazonのギフトカードをプリーズとしています。
が、全くの反応なし(ノ△・。)
※プラグインの質・量・ユーザー数及びダウンロード数とかはおいといて。
もちろんまずはがんばります。

 

色々考えたり調べたりしました。

Contact Form7が無料って、よく考えるとすごいですね。いや、よく考えなくてもすごいですね 😉
あ、寄付をお願いしているんですね。 え?日本の方ですよね?あれ?なんだろな~

ん?プラグインを無料で使用もできるけど有料で買うこともできる(値段も選べる)ような仕組みだと、
法律はOKなんでしょうか。

 

試しに、そういう仕組みを2つぐらい機会を見計らって、試してみようかな。

あ、寄付するつもりで、別のこのプラグインを買ってください。的な感じでもいけそうだな。

 

その前に、プラグインの質をあげねば。。
もっとその前に、この人のプラグインは大丈夫と信頼される人になる事と、
これがあって簡単にカスタマイズが出来たよー助かったよーというプラグインを作らないとな。。

おっと。。もっとその前に。。

paypalの口座を開設せねば :oops:

Custom Options Plus Post In バージョンアップ

このたび、CUSTOM OPTIONS PLUS POST IN のバージョンアップをおこないました。

最新バージョンは、1.2となります。
主にデータベース周りの格納方法の更新を行いました。

 

一度シリアライズしたデータを格納、取り出す際はシリアライズし、
ひとつのデータを取り出す形式について、おそらく処理を指摘されていたので変更しました。

 

今まで

wp_options 内に、キー coppi として格納

coppi1.2以前の格納方法
coppi1.2以前の格納方法

 

現在

テーブルを用意した格納方法

 

coppiテーブル
coppiテーブル
データ格納サンプル
データ格納サンプル

update_option 及び get_optionを使わずに、テーブルを用意するので、そもそも、

どうやってやるんだろう。。と色々思考錯誤しましたが、下記の記事に感謝です。

 

Creating_Tables_with_Plugins

http://codex.wordpress.org/Creating_Tables_with_Plugins

■ WordPressでデータベースを使ったプラグインを作成する

http://takahashifumiki.com/web/programing/1440/

 

テーブルを用意することでのメリットは、まずは ソート がかなり楽になりました。
今まではget_option全データをとにかく取得し、指定されたソートの順序になるようarray_multisortを行っていたのですが、sqlクエリとして投げるだけなので、返ってきたデータがソート済み。

次に、一つのデータを取り出すのも楽になりました。

 

プラグインが有効化された際に、テーブルを作成し、元のデータを取得しそこに複製された時は、
おぉーってなりましたねw

 

ただ、sqlクエリを直接書くことになるので、脆弱性が気になります。
(sqlに限った事じゃないですが)

試していて、よく分からなかった 「$wpdb->prepare」。

wordpress 3.4.2 のバージョンでテスト動作を繰り替えし、動作確認をして、
いざ wordpress 3.5 で動作をすると、

Warning: Missing argument 2 for wpdb::prepare()

が連発。んん??どういうエラーなんだろうと色々とぐぐってみました。

$wpdb->prepare() 自体の動作は、SQL インジェクション攻撃からクエリを保護する によると、
クエリを保護するためにエスケープするためのもの。らしいのですが、こんな記事もありました。

Warning: Missing argument 2 for wpdb::prepare()は危険!

正しい使い方をしないと、危ないよ。という事らしいです。

3.4ではエラーも出ないのか。。そもそも使い方を間違っていたと。

この記事の下のほうまで読んでいくと、akismetプラグインの場合の記述リンクがあったので見てみると、

 $remaining = $wpdb->get_var( $wpdb->prepare( "SELECT COUNT(*) FROM $wpdb->commentmeta WHERE meta_key = 'akismet_error'" ) );

$remaining = $wpdb->get_var( "SELECT COUNT(*) FROM $wpdb->commentmeta WHERE meta_key = 'akismet_error'" );

こうなっていました。

$wpdb->prepare を外したんですね。

今回はakismetプラグインを参考にして、$wpdb->prepare を外すと動作OK。3.4.2で試しもてもOK。

とりあえず、今回はこれでよしとして、アップデートしました。

 

こういう面を色々と考えると、難しいです。
出来る限り、使えるテーブルは使ったほうが、ありがたい。のかも。

 

ダウンロードはこちら http://wordpress.org/extend/plugins/custom-options-plus-post-in/

データベースへのオーバーヘッドを試してみた

ひとつのキーに、まとめてデータを入れるとオーバーヘッドがかかるかもしれないよ」

と教えられ、現在ひとつのキーに入れないような設計をしている最中で、

 

じゃあ、試しに、1,000の値 を、

  • ひとつのキーに全データをシリアライズして入れる
  • 1,000のキーとして入れる

というそれぞれの方法では、実際にどれだけオーバーヘッドの可能性があるかどうか。

 

ターゲットは wp_options

オーバーヘッドは一切ありません。

テーブル一覧
テーブル一覧

ここで挿入する値の定義

1,000個の1~10,000,000の乱数を作成して挿入

つまり、

array(
0 => 2384、093,
1 => 6923230,
2 => 8053892,
...
999 => 1034544
);

のようなデータです。

データには日本語や英文が入る場合が多いので、今回はデータ量が少ない気がして、

良いテストかどうかと聞かれれば、分かりません。としか答えられませんが、

少しぐらいは何か分かるのではないかと思い、やってみることにしました。

 

wp_options にまずは、ひとつのキーに1,000の配列を挿入することを仮定して、試してみました。

$SampleData = array();
 for( $i=0; $i<1000; $i++ ) {
 $SampleData[$i] = rand( 1 , 1000000 );
 }
 print_r($SampleData);

print_r で値を確認。1,000の配列が出来ています。

これを、wp_optionsへひとつのキーとして、シリアライズしたデータをupdate_optionで挿入してみると、

ひとつのキーに挿入
ひとつのキーに挿入

ぎっしりはいりました。結果…

オーバーヘッドはなし。

 

えっ? これじゃ検証にならない。。もっとデータ量を増やして試してみよう。

ということで、オーバーヘッドされるまで、データ量を増やしながら色々と試行錯誤…。

結果。どんなに頑張ってもオーバーヘッドしなかった。。

 

参ったなぁ。指摘されているから、オーバーヘッドするはずなんだけど…

実際にオーバーヘッドしているテーブルがあったので、そのテーブルとひたすらにらめっこ。

すると、気づきました…。

データ型
データ型

MyISAM

ん?「MyISAM」?私のイサム?メルティーラブ??

軽めにググってみました。

 

あ、データベースにも色々とデータの種類があるのね。全く知りませんでした。

で、さっそくテスト環境に使っているテーブルの型を、MyISAMに変更。

同じように1,000個の値を持つ乱数配列で再度update_optionでデータを挿入すると…

でました。オーバーヘッド。

ひとつのキーに挿入時
ひとつのキーに挿入時

ひとつのキーに、1,000個の、乱数で作成された値をもつ配列を、シリアライズして挿入すると、

29.5 KiB (KiBって何?キロバイトじゃなくて?)

計10回、挿入してみましたが、 29.5 KiBから変わらなかったです。

なるほど。何度も値を挿入しても、値は変わらないのか。配列の値も色々と変えてみる。

 

ここまでで分かったこと

× 1回のオーバーヘッド量 29.5 KiB × 10回updateすると = 295KiB になるわけではなく、

○ 挿入するデータ量に応じて、オーバーヘッドのサイズが変わる。何度更新しても。

 

そっか。

これじゃあ何度テーブルの最適化をしても、そのupdateをする限りいつまでもオーバーヘッドするじゃないか。

 

よし。

次の検証にうつります。その前に、オーバーヘッドの最適化。

 

次は、1,000のキーとして、値を挿入。の検証

挿入するデータは以下。

 for( $i=0; $i<1000; $i++ ) {
 update_option( 'sampledata' . $i , rand( 1 , 1000000 ) );
 }

結果は。オーバーヘッドなし

確かにこの方法がいいかもしれない。

ん?ちょっとここでもうひとつ試してみることにしました。

 

update_optionの値を、ただの配列にするとどうなるか

 for( $i=0; $i<1000; $i++ ) {
 update_option( 'sampledata' . $i , array( rand( 1 , 1000000 ) ) );
 }

結果はこちら。

値を配列に変更後
値を配列に変更後

20 バイト。配列にするだけで、オーバーヘッドが起こるのか。

 

wordpress の update_option()の流れとしては(ざっくり)、

  • update_option() の値に配列やオブジェクトをつっこむ
  • maybe_serialize()という処理が入る

この”たぶん、シリアライズ機能”のほうで、

if ( is_array( $data ) || is_object( $data ) )
 return serialize( $data );

シリアライズされたデータを返し、データベースのデータが更新されます。

 

 

じゃあ、配列でupdate_optionデータを更新する限り、シリアライズされる。

シリアライズされたデータで、 データベースの型が MyISAM なら、ほぼオーバーヘッドが起こる。

(データベースの環境も左右されるかもしれませんね)

 

いい勉強になりました。

オーバーヘッドを避ける為には、1キーに1つの値。

という事ですね。

 

今公開中のプラグインは、ほとんどがシリアライズされたデータなので、いくつかは変更する予定です。

>>追記

実際には、1キー に 1つの値 にしても、オーバーヘッドを避ける事はできませんでした。

どういう事かというと…

作成したキーを、削除するだけでもオーバーヘッドが出ました。

また、コメントでbloger323さんがおっしゃる通り、データの増減が激しい場合もオーバーヘッドが出るようです。

 

うーん、どういう構造がいいんでしょうね。。