外国人からWordPressプラグイン改変依頼を請けるのは可能?

現在私は、WordPressのプラグインを約10個ぐらいWordPress.orgに登録しています。

今回、そのWordPress.orgに登録しているプラグインのユーザーの方から、英語のメールが来ました。アメリカの方。

メールの文面を和訳すると、

「もし良かったらプラグインの改変をお願いしたい。興味があったら返事ちょうだい」

とありました。

 

「おぉ~すごい、海外から仕事の依頼が来るようになるなんて、なんてグローバル化の時代なんだろう!」

と思い、「興味あるよ!」と返事し、それからメールで色々とやりとりをしました。

 

ただ、依頼したい内容を聞いていくにつれて、今回の外国人からの依頼について疑問が出てきました。

 

今回依頼したい内容としては、

「別の作者のプラグインにフォームのフィールドを追加してもらえないだろうか」

と、いうものでした。

ようは、「プラグインを改変してもらえないだろうか」ということ。

なんと。私のプラグインではないのですね。 😯

ちなみに、そのプラグインとは全く無関係。

そんな私に改変のご相談をするとは、なんて冒険者なんだろう。それにしても、なんで私? 😕

そんなことはさておき、その依頼内容を詳しく見る限り、特に問題なく出来そうに感じました。

ただ、それをやるにあたって、

  • 報酬を受け取る事を前提としたプラグインの改変は何か問題はあるのだろうか。
  • プラグイン作者に許可なく改変することは作者に問題ないのだろうか。
  • アメリカ人から報酬をもらう際、税金ってどうなっているんだろう。どちらの国にどう支払えばいいのだろうか。

私にはこの3点が疑問でした。 😕

まず、勝手に他の作者のプラグインを改変する事は、正直、あまり気が進みませんでしたが、ライセンス的にOKだとするならば、特に問題ないと私は考えました。

また、税金に関しては正直、今回の報酬はそんなに多くないだろうな~と考え、気にしなくてもいいかな~知らんぷり~ :mrgreen: なんて頭によぎったりもしましたが、やっぱりここは気持ちよく依頼を受けたいと思いました。

後々依頼した方に面倒が掛かってもよくないですね。

それで、私なりに調べた結果を書いています。

 

* 私と同じように海外からの仕事の依頼があり、この記事の内容を参考にしようと考えた方へ *

申し訳ありませんが、内容について私は責任は持てません。

私はWordPress.orgにプラグインを登録しています。だからといってWordPressのライセンス等について詳しい訳ではありません。ほとんど無知に近い状態です。

私はこの機会をライセンスについて情報を得る、いい機会だと考え、色々な情報を調べました。

WordPressについて詳しそうな方に直接質問して、ご返事が全く無い…そんな事があったり。 😥

情報を調べるにあたり、様々な方のブログ等も参考にしています。

ただ、説明に関しては出来るだけおおもと(WordPressのライセンスについてなら、WordPressのライセンスについて書かれたページ)を参照して書いています。

もとの情報なら、他のブログと比較しても情報の正確さが高い点と、情報が変わった場合は、おおもとを見る必要がある為です。

責任は持てません。ただ、できるだけ「ここなら少しは安心できる情報だ」という情報を集めたつもりです。

 

ちなみに私自身は、海外の方との取引に関してはこのページに書いている内容通りの認識です。

お読みになり、「ここは違うと思うけど…」と思う事があれば、宜しければコメント・直接メールでもなんでもご連絡いただければ幸いです。

宜しければ間違いをご指摘ください。お願いします。 😮

 


 

疑問点1つめ。

報酬を受け取る事を前提としたプラグインの改変は問題は無いのだろうか

ちなみに私は、「WordPressとは商用利用OKなはずなの、なので多分、大丈夫だろう」というぐらいの認識でした。

その点も含めて今のうちに正しい知識を入手しておこうと思い、「WordPressとは商用もOKなはず」というこの部分を先に合っているのかどうか、解決させることにしました。

まずは、WordPress自体のライセンスについて説明しているページを探しました。

WordPress.org

ページの一番下、左部分、いいね付近に「License / GPL v2」というリンクがあります。ここがライセンスについて書かれていると思われる記載です。

ページはここ。

The WordPress License

このページに以下のように書かれています。

The license under which the WordPress software is released is the GPLv2 (or later) from the Free Software Foundation.

Google で翻訳すると、

WordPressのソフトウェアがリリースされている下にライセンスはフリーソフトウェア財団からGPLv2の(またはそれ以降)です。

これを読む限り「WordPressのソフトウェアは、フリーソフトウェア財団 の GPL v2 またはそれ以降のライセンス」という事だと思います。

なるほど、分かりました。GPL v2 を調べろって事ですね。 😳

お次はGPL v2 について。

GNU一般公衆ライセンス, バージョン2

ここのFAQを参考にしました。

GPLv2に関してよく聞かれる質問

ここに以下のように質問があります。

GPLは金銭目的でプログラムの複製を販売することを許可していますか?

この答えとして

「はい、GPLは、誰もが販売することを許可しています。」

と表記されています。なので、商用として利用・販売することは問題無いという事が分かりました。

これでとりあえず、WordPress本体を商用として利用することに問題があるかどうかは解消されました。

次に、WordPressで配布されている「プラグイン」についてですが、プラグインのライセンスも実はGPL v2 です。

プラグインのライセンスについてはここに記載されています。

Plugin Directory

このページに以下のように記載があります。

Your plugin must be compatible with the GNU General Public License v2, or any later version. We strongly recommend using the same license as WordPress — “GPLv2 or later.”

プラグインを登録する際に目を通した覚えがありましたので、ここは簡単に探す事ができました。

一部和訳すると「あなたのプラグインはGNU GPL v2 またはそれ以降のバージョンと互換性がなければいけません」

must be って、~しなければいけない。という意味なはず。

という事で、プラグインもGPL v2 になるはずなので販売することも問題は無さそうです。

ただ、プラグインがGPL v2ではなかった場合は、そのプラグインのライセンスに従うほかないと思います。プラグインのreadme.txtやプラグインファイル自体にライセンスについての記述が書かれています。

 

つづいては、プラグインの改変について。

これについては、こちらを参考にしました。

自由ソフトウェアとは?

このように記載されています。

プログラムがどのように動作しているか研究し、必要に応じて改造する自由 (第一の自由)。ソースコードへのアクセスは、この前提条件となります。

改変については「自由ソフトウェアの定義」を読む限り、自由に改変は可能なようです。

ただ調べていて、こちらのページも参考になりました。

テーマも GPL ライセンス

WordPressのテーマのライセンスについて書かれているのですが、画像やCSSについてはGPL v2ではないようです。

これは、WordPressプラグイン内の画像やCSSについても同じことがいえるのではないかと私は思います。

画像や CSS はそうではないと言えます。サードパーティのテーマ開発者は、希望するなら制限付きの著作権を適用することができます。

このように書かれています。ということは、プラグイン内のJS や CSSを改変する際は、そのJSやCSSのライセンス・著作権に従う必要があるようです。

読む限りでは、PHPファイルでもWordPressの機能を一切使用していないものは、独自のライセンスや独自の制限つき著作権を適用できるのではないかと私は思います。

ただ、WordPressの機能を利用しているJavascriptの場合は、おそらくGPLが適用されるのでは?と思います。
(wp.mediaとかを利用している場合)

 

そして今回の改変依頼を受ける為には、PHPだけでなく確実にJavascriptファイルを改変する必要がありました。 🙁

で、JSファイルのソースを見てみましたが、著作権の表記のみ。とくに「このファイルはGPL v2ですよー」的な表記は見当たりません。

まいったなー、いい解決方法ないかな。 😯

考えました。考えて、考えて、考えました。 😐

元のJSファイルと同じようなものをいちから作成したら、問題解決?

解決できるかもしれませんが、あまり気持ちよくないし、いかにもその場しのぎ。 🙁

何も答えは出なかったので、最終的な解決案を実行。

プラグイン作者の方に直接ご連絡しました。お返事いただけたら嬉しいですが。 😥

文面はこう送りました。
Plugin Name というは、改変依頼を受けたプラグインの名前です。

My name is gqevu6bsiz.
Sorry to bother you. I'd like to ask you something.
Is about the modification of the "Plugin Name" plugin.

--------------------------------------
Certain person,
"Can you add the custom field for Plugin Name?"
Requested to me.
--------------------------------------

For add the custom field.
I think no problem is that you are editing of plugin's PHP files.
This is because of GPL2.

The problem is JS file.
I think this is not GPL2.
I may want to ask to you.

May I modify this plugin?

Do you see my point?
If you have any questions, please feel free to ask.

(文面を参考にしたい方はご自由にどうぞ。名前は変えて下さいね。ちなみに、英語が確実に合っているとは限りませんのでご了承ください。ただ、相手に通じたことは確かです。)

すると、こう返事が返ってきました。

Hi!

It is all GPL2, js files too

Cheers...

くはっ!みじかっ!ラフっ! 😆

返事の和訳ですが、
それは全てGPL2 です、jsファイルも。
という意味だと思います。

文末に Cheers と書いているので、イギリス英語圏の方なのかな。

あれだけいい解決法が無いか考えていた時間が、とても無駄に思えました。 😳

ただの一人苦労。。初めから、聞いとけばよかった。。。

とりあえず、「ご返事ありがとう。感謝します」と返事しました。

次回からは、分からない時は直接作者に聞こうと思いました。

その際に、逆に作者が「私が対応するよ」と言うならそれはそれでいいと思います。

本来は作者の方が改変をされたほうが良いと思っています。

そのプラグイン特有の問題や、現状、今までの流れ全てを把握している為です。

ただ今回の依頼内容は、明らかにこの方だけに必要と思われる項目追加だったという点と、作者のサポートフォーラムで「対応しません」と記載があったので、今回は依頼の対応をすることにしました。

これで作者の許可もいただけたので、安心してプラグインの改変に取り組む事ができます。

これで、「報酬を受け取る事を前提としたプラグインの改変は問題は無いのだろうか」という疑問点ついては解決だと思います。

 

 

 

つづいて2番目の疑問点。

プラグイン作者に許可なく改変することは問題ないのだろうか

この疑問点については、1番目の疑問の際に直接作者に問い合わせをしたので解決しました。

また、自由ソフトウェア定義の中に、

プログラムがどのように動作しているか研究し、必要に応じて改造する自由 (第一の自由)。ソースコードへのアクセスは、この前提条件となります。

と記載されているので、許可が必要かどうかに関係なく、改変は自由におこなうことができると思います。
(改変OK = 著作権放棄ではないと思います。著作権やライセンスについての記載は削除しないように)

ただ1番目の疑問点でもふれたように、画像やCSSファイルについては作者がライセンスを決めている事があるので、そのライセンスに従う必要があるということですね。

「何を改変しようとしているのか」は大事な点だと思いました。

というか、分からなければ、直接作者に聞いたほうが早い。 😮

 

 

 

つづいて3番目の疑問点。

アメリカ人から報酬をもらう際、税金ってどうなっているんだろう。どの国にどう支払えばいいのだろうか

全く分かりません。ましてや私は英語もろくに分かりません。

「ソーリー、英語あんまり出来ないし、お金の仕組みがよくワカリマセン。 😉 」と断ることも考えました。

ただ、このままではいつまで経っても、英語も、海外の方との仕事のやりとりも出来ないまま。

なにより、せっかくご連絡を受けたこの機会、無駄にしたくありませんでした。

なので調べました。

 

まずは日本人同士の取引おさらい。

日本人同士の取引だと、売上に対して「所得税」や「個人事業税」があります。
法人だと「法人税」かな?すみません、法人については分かりません。

あとは消費税ですね。日本だと現在は5%。

確定申告をする個人事業主は、決められた納税地やE-taxで確定申告し、算出した税を納めます。
細かい部分を除くと、日本内の売上はこれくらいで税を申告・納める事ができます。

問題は、海外との取引の場合、どうやって税を申告・収めるのか。

済んでいる地域の税務署に「これ、アメリカ税です。」って払うの?
それとも何か先に申請しないといけないものがある??
というかアメリカの税率って何%??? 😕

しかも今回のような”物品”ではなく「デジタル商品」?となるものの場合。

どんなに調べても分からない。。気分転換にスマホでゲームをやっていました。 :mrgreen:

ふと、気づきました。

「ネコスカート、気持ちわるっw」

「スマホのアプリを海外に販売している人の行為と、今回のケースはあまり変わらないんじゃないかな?」

ということ。

WordPressのプラグインも、スマホのアプリも商品はデジタル。どちらも購入者は海外の人もありえます。

という事で、スマホのアプリを海外の方に販売するノウハウが書かれた本を探しました。
ただ、アプリは見つからなかったのですが、代わりに電子書籍についての本を見つけたので参考にしました。

電子書籍のつくり方・売り方

アップルストアでの電子書籍の販売方法について書かれていました。

この本を読んで、アップルストアで電子書籍を販売する場合、「W8-BEN」という「米国非居住者用の免税書類」という書類の存在が分かりました。
(日本で税を納め、アメリカで税を納めないという事をする場合は必要。アメリカに税を納める場合は不要)
(租税条約と呼ばれる条約と関係があるようです。)

「私は日本で税を支払うので、アメリカでは免税してください」

という申請をする為の書類のようです。

アップルストアで電子書籍を販売する際にはこの書類をアップルストアに送る必要があるようです。
(税関係だからアメリカの税務署的な所 IRS にではなく、お金を支払う側に送るようです)

ここまでは分かりましたが、まだ分からないことが。

「アメリカに住んでいない人は、全ての人が免税対象なのか?」

という事が分かりません。またまた色々と調べました。 😕

なんとかの知恵袋を見ると、ある人は、

“ドル”を受け取るのでアメリカでの売上はアメリカに税を納める必要がある。

またある人は、

住んでないので納める必要なし。日本に納める。

う~ん、はっきりしない。

なんだかきりの無い答えばっかりでした。。 😕
(様々な解釈がある場合、どの解釈を選択すべきが難しいですね。)

 

まだまだ調べてみましたが、これ以上は分かりませんでした。

今度は「国税庁」に電話して今回のケースをご相談しました。

税についての相談窓口

全く知りませんでした。税について電話で相談できるなんて。 😯

電話すると税の相談センターへのアナウンスが流るので、アナウンスに従い相談センターの方に相談。

担当者の方に、今回のケースを説明。
オープンソースやら、プログラムの開発とか、そんな事を知らない担当者になんとか説明出来たような、出来てないような感じで、ちょっと不安。 🙁

そして相談して分かったことは、

「二つの国に税金を納める必要はない」という事でした。

住んでいる国に税金を納めてください。

日本の方と取引しているような感覚で、いつも通り売上としてみなしてください。と。

他のブログの記事等も読んでいて、「本当なの?」と思ったりもしましたが。

相手は国税庁の税の相談センターです。
担当の方にきっぱりとそう説明されたので、今のところはそう解釈する事にしました。

今はこの事を信用することにしました。

 

ただ、また新たに小さな疑問がでました。

「じゃあなんで、アップルストアで電子書籍を販売する人はW8-BENの書類を必要とするのか」

という点。

ん?住んでいる国に税を納めればいいんでしょ?アップルストアは関係ないのでは? 😕

色々調べると、アメリカでは、報酬は源泉徴収されるようです。

なので、このW8-BENという書類は報酬を支払う側に「源泉徴収しないでね。徴収したら(なんて日だ!ってスパムメール送るからね)的な申請書類のようです。

 

源泉徴収という言葉の意味を自分への説明かねて。

例えばアメリカの方と取引があり、取引金額が$100だとします。

日本人がこの$100を受け取る。アメリカの方がこの$100を支払う。

取引成立。シンプルに税というものが存在しない場合はこうなります。

源泉徴収とは先に税金を差し引いて税金を納める事

源泉徴収

なので、上の例の続きだと、$100から税 -$10 した金額の$90が日本人に報酬として支払われると思います。(アップルストアで販売した電子書籍の売り上げもこうなるのはずだと思っています。)

もし、これで90$の支払いがあった場合、支払い者がアメリカに税金$10を納めます

さらに、日本でも税金を納める必要があるので、この$90からさらに日本に税 -$10 を後々支払い、実際の収入は$80 ということになるのではと思います。
(数字はあくまでも考え方の参考としてなので全て架空です。実際の税率・手数料等は一切無視しています。)

このようになると、二重課税された状態です。

本来は住んでいる国に税を納めればよいとの事なので、日本に納める$10だけで、アメリカに納める税は無し。

収入は$90

ただ、支払い者に「銀行口座はここですよ。こちらに支払ってね。」と伝えただけだと、アメリカに支払わなくてもよい、$10の税をアメリカに支払うことになると思います。
(支払っても還付は出来ると思いますが、どうやって還付請求するんでしょうね。。)

なので結論として、

アメリカの税の分の源泉徴収(-$10)しないでくださいね。私は日本で税を支払うので。

という意味合いの書類がW8-BENという書類ではないかと思います。

送らなくてはいけないという訳ではなく、送ったほうが二重に課税されないので、得をする
という認識です。

 

そして、海外の方に無事納品し、料金を送金してもらう際、支払い者に対して、W8-BENの書類を提出する必要があるのではないかと思います。

※今回の私のケースではPaypalで、相手の支払い予定もPaypalでした。じゃあPaypalにW8-BENの書類を送る必要があるの?って思い、Paypalへ問い合わせてみましたが、

あなたは海外の方と取引できる状態なので提出する必要がありません。

と返事がきました。

うーん、、。回答になっていないような。 🙁

Paypalでは源泉徴収はせず、手数料のみを取って送金をするはずなので、W8-BENは提出する必要が無いのかな?と思っています。

 


以上の認識に落ち着きました。

「外国人からWordPressプラグイン改変依頼を請けるのは可能?」についてですが、結論としては「ライセンスに気をつけることと、今のところアメリカの場合は可能」という結論に達しました。

 

この記事を書いた 2013年6月21日 での私の認識です。

お読みになり、「ここは違う!」と思われる点があれば、是非ご指摘ください。

もし何かを指摘される場合、出来るだけご確認をお願いします。(本当にそうなのか)

宜しくお願いします。 🙂

 

 

それと。

このアメリカの方と、その後の流れですが…

料金面のお話をした後に、ぱったりとご連絡が来なくなりました。。 😳

かなり残念です。せっかくの機会を逃してしまいました。

たぶん、相手の予想していた値段よりも高かったのだと思います。希望の値段は聞いてはいませんでした。

値段設定、どのようにする難しいですね。商売あまり得意ではありません。 😐

 

ちなみに安い値段で依頼を請ける事もありだとは思いますが、私の場合はあまり安くしない方向です。

理由はこうです。

私はプラグイン WP Admin UI Customize のアドオンを販売しています。(寄付だけではとても厳しいので)

購入者からの問い合わせですが、想像していたよりも、購入後のサポートが非常に大変だという事がわかりました。
(もちろん、お金支払ったんだから問い合わせが増えるのは普通だと思います)

このアドオンの購入に関して私は、返金に一切応じていません。(複製可能商品なので)

購入者のリスクは大きいと思います。販売している側として感じます。

だから”思いきって”購入していただいた方には、私なりにまだまだ上手ではないと思いますがきちんとサポートしています。
(英語得意ではありませんが、出来るだけキャプチャを交えながらなんとか…。)

そのサポートに対しての料金・値段という考え方にしています。

 

海外の方のサポートは、「言葉で通じない部分」はあるし、「直接会って説明すること」も難しい。

日本人相手のサポートとはまた違った難しさがいくつもあります。

 

今回、機を逃す結果になってしまった後に思ったことですが。

他の作者のプラグインの改変という事は、そのおおもとのプラグインがバージョンアップした場合、そのバージョンアップに対応して改変したものをくれっ!という依頼が後々あるのでは?と思いました。

それを考えれば、バージョンアップの度に依頼がリピートされる可能性もある為、リピートを考慮し安くするのもいいのでは?と思いました。 😉

 

いまさら、ですが。 😥

また、WordPressのライセンスやGPLについても、もっと調べなきゃいけないな。と感じています。

 

 

ただこれを機に、海外の方に、管理画面のカスタマイズしますよ。とアピールするのもアリなのでは?と思いました。

日本人でも海外の方でも、WordPressのカスタマイズに関するご依頼があればいつでもご相談ください。 

 

 

以下、WordPressや海外との取引に関して参考にした記事です。本当はもっと参考にしましたが、1日で調べた訳ではないので以前調べたサイトは不明です。。
もっと詳しく知りたい方は色々辿ってみて下さい。

http://wp-d.org/2012/11/07/1046/

http://ja.forums.wordpress.org/topic/5259

http://sakuratan.biz/archives/1091

http://ja.forums.wordpress.org/topic/2780

http://ja.forums.wordpress.org/topic/12644

http://ja.forums.wordpress.org/topic/3151

http://www.yuriko.net/wp-content/uploads/2009/10/20091004-gpl.pdf

http://www.slideshare.net/nogajun/20121124-wordbench-osakalicense

http://wpdocs.sourceforge.jp/License

http://wordpressfoundation.org/

http://ja.naoko.cc/2008/02/25/can-you-remove-wordpress-credit/

http://ja.wikipedia.org/wiki/%E7%A7%9F%E7%A8%8E%E6%9D%A1%E7%B4%84

http://tprofessional.blog.so-net.ne.jp/2010-08-06

http://www.tax-j.com/text/Indiv-12.htm

WordPressのマルチサイト作成、運営で思ったこと

前回、英語のサイトは難しすぎ…。という記事にて、多言語のサイトの作成方法のひとつ、マルチサイトを少しだけ取り上げました。

こちらも参考に。

WordPress で多言語サイトを作成する

 

マルチサイトで作る前は、おそらく

  • 言語別なのでコンテンツの管理は少しは楽だろうなぁ~

ぐらいしか思っていませんでした。

 

実際にWordPressのマルチサイトで構築して、改めて思ったことや気づいた事を書いていきます。

多言語サイト、もしくは複数のサイトを作る必要がある方には参考になるかもしれません。

(こういう方法だと便利だよ~。な情報があれば、是非教えて下さい。)

 

で、改めて思ったことや気づいた事、ですが。

 

同じお問い合わせフォームをサイトの個数分用意する必要がある

これはどういうことかというと、私の場合は、

  • 英語のサイト(以下の説明でSite Aとします)
  • 日本語のサイト(以下の説明でSite Bとします)

という形でマルチサイト化しました。

Site Aにてお問い合わせフォーム(今回はContact Form 7)を用意し、Site Bにも使おうと思い、Site Aで作成したお問い合わせフォームのショートコードをコピってSite Bの記事に貼り付けてみましたが、動かない。

おそらく、Site Aで作成しても、Site Bで使用できない。

またこれは、Site Aで作成したカスタム投稿タイプも、Site Bで使用出来ない事と同じような事です。

(カスタム投稿タイプだけに限定しますが、例えばmy_Themeというテーマ内のfunctions.phpにて、register_post_type()をしている場合は、それぞれのサイトでmy_Themeを有効にしている場合は両方にカスタム投稿タイプが登録されます。
その方法とは別で、プラグインなどによって、登録するカスタム投稿タイプをデータベースに保存して、その保存されているデータをもとに、カスタム投稿タイプを登録させたりする場合は、Site ASite B のデータベースの保存領域が違う為、片方で作成したモノは、片方でしか使えない。という事が起きると考えられます。)

これをなんとかする方法。考えてみましたが、思いつかない。

とりあえず、Site A で作成したお問い合わせフォームやカスタム投稿タイプをSite Bにも同じように用意する。という事がベターじゃないかと思いました。

 

言語別にコンテンツが分かれて管理はし易いですが、同じようなものを同じように用意する…。

ちょっと面倒だなと感じました。(他にいい方法があるかもしれません。むしろあれば教えて欲しいです。。 😥 )

これが10サイト分も作る必要があるとするなら、私は今後マルチサイトは使わない方向で考えるかもしれません。 🙁

 

 

記事は言語別に分けて管理しているが、テーマの各テンプレート用に翻訳ファイルを用意することになる

そりゃそうだ。と思う方もいるかもしれませんね。

私の場合、Site ASite Bでそれぞれ同じスラッグ名が存在する、言語違いの記事を作成しました。

http://siteA/contact/ (英語の記事)

http://siteB/contact/  (日本語の記事)

 

記事自体はサイトごとに違うので、日本語の記事を少し編集したければ Site Bの管理画面から編集するだけ。とシンプルです。

テーマに関しては、1つのテーマだけを作り、Site ASite B の両方ともにそのテーマを適用しています。

(Site A用・Site B用にテーマを作成して適用する方法もあるかもしれませんが、この2つのサイトの違いは言語だけ。言語以外の部分で少し編集や修正をするだけでも2サイト分編集することを考えると、あまり良い方法とは思えません。しかも、その方法で10サイトも存在してたら… 😳 )

なので、翻訳ファイルを用意しテンプレート内でそれぞれの言語で表示されるようにする必要がありました。

言語違いの為、マルチサイトをするのではなく、他の理由でマルチサイトを作る場合は、このことはあまり影響しないかもしれません。

 

Site Aでアップロードした画像を、Site Bで使用できない

これはタイトルのまんまです。

私の場合、Site ASite B の違いは、言語の違い。ただそれだけです。

記事で何かの説明をする際に、画像を使ったり画面のキャプチャ等を記事に貼り付ける場合があります。

Site ASite Bは言語は違いますが、言語が違っても同じ画像を使いたい場合がありました。

Site A でその使いたい画像をアップロードし、記事に貼り付け完了。

同じようにSite Bにも貼り付けようとしましたが。。。

 

WordPressは、マルチサイト内の Site ASite B は別々のサイトという扱いにしているのではないか、と思います。

そう考えると、Site Bでその画像を貼り付けるどころか、画像一覧にも出てこない理由に納得です。

 

かといって、その対処法として、同じ画像をSite Bにもアップローとなると、今後その画像が間違っていた場合など、修正をおこないたい場合が面倒です。

画像は1つですが、2箇所にアップロードされているので、Site A の画像と Site B の画像を修正。。

いやいや、そんなことはしたくありません。管理が簡単で楽にできるようになる為にWordPress使っているんです。私は。 😕

 

なので今回は、テーマディレクトリ内に画像をアップロードして、その画像をそれぞれの記事に貼り付けるよう設定しました。

「メディアライブラリ」からテーマディレクトリ内の画像を選択できるようになったら嬉しいな。 😉

もしくは、マルチサイトが有効の場合だけ、「全てのサイトのメディアライブラリ」みたいな項目があっても嬉しいな。 🙂

 

 

WordPressのいろいろなデバッグ方法

WordPressをカスタマイズしていると、何かとエラーが出たりします。

その際によくあるデバッグ方法として、config.phpへの記述に

define('WP_DEBUG', true);

と記述し、エラーを表示させる機能があります。

ちなみにこれ、エラー表示を抑制するかしないかの機能。

 

もっと詳しく言うと、wp-admin/plugins.phpの140行目あたり、

if ( ! WP_DEBUG ) {
 error_reporting( E_CORE_ERROR | E_CORE_WARNING | E_COMPILE_ERROR | E_ERROR | E_WARNING | E_PARSE | E_USER_ERROR | E_USER_WARNING | E_RECOVERABLE_ERROR );
 }

こんな記述があったりします。

 

でも、WP_DEBUGをtrueにしても、

プラグイン有効化時のエラー
プラグイン有効化時のエラー

プラグインを有効化する際のエラーは表示してくれません。

何かいい方法無いかとぐぐってみましたが。

WordPressって、デバッグ方法について色々と機能が準備されていたんですね。

ほんと、知らないだけでした。

Debugging_in_WordPress

 

※この記事の情報は、記事を書いている時の最新バージョン、WordPress 3.5.1 をもとにしています。

 

define(‘WP_DEBUG_LOG’, true);

これはどんな機能か調べてみると、エラーの内容をログとしてwp-content/に記録してくれる機能。

詳しく見てみたい方は、wp-includes/load.php の 274行目付近を参照ください。

試しにconfig.phpに追加してみると、

エラーログファイル
エラーログファイル

debug.logというファイルが作成されました。その中身はこうでした。

 PHP Warning:  var_dump() expects at least 1 parameter, 0 given in

なんにもパラメータ無いじゃん。このxxxxやろう!! というエラーだと思いますね。

プラグインを有効化する際(ヘッダーを出力する前)のエラーを確認したい時に、とても便利な機能だと思います。

また、エラーの表示は出したくないけど、エラーが出た場合は記録だけしておきたい時には便利です。

たまにしか出ないエラーなんていうものだって、ありますもんね。

クライアントにWordPressをCMSとして提供している場合は、この機能を有効にしておいて、メンテナンスとしてこのログを確認することにも使えそうですね。

 

 

次は、

define(‘WP_DEBUG_DISPLAY’, true);

なんとなく英語を解釈すると想像できますが、念の為調べてみました。

wp-includes/load.php の 269行目付近。

php の display_errors を true にしているだけのようですね。エラーを表示するor しないを選択する機能のようです。

 

お次は、

define(‘SCRIPT_DEBUG’, true);

スクリプトデバッグ?何のスクリプト?と疑問です。で、調べてみました。

で、SCRIPT_DEBUGで条件分岐しているところがいくつかありました。

まずは、includes/class-wp-editor.php の551行目。

$suffix = ( defined('SCRIPT_DEBUG') && SCRIPT_DEBUG ) ? '_src' : '';

うん。$suffix。なんでしょうこれ。見る限りは、SCRIPT_DEBUGがtruだったら、_srcをいれる。

それがどういう役目なのか分からなかったので、$suffixが何に使われているのか調べてみると、

tinyMCEPreInit = {
 base : "<?php echo self::$baseurl; ?>",
 suffix : "<?php echo $suffix; ?>",

ビジュアルエディタのTinyMCEの何かのsuffixの値として、_src という値を入れているようです。

これがまたどういう役目なのか分からないので、もっと追っていこうと思いましたが、そもそもこの単語、どういう意味なんだろうとGoogleで翻訳してみました。

suffix = サフィックス。接尾。接尾語。

つまり、何かの接尾に_srcをつけるものっぽい。何かがさっぱり分からりません。

ただ、TinyMCEに使われている事は確かだと思いましたので、wp-includes/js/tinymce/tiny_mce.jsをひたすら検索していると、

"themes/"+q.theme+"/editor_template"+k.suffix+".js"

suffixが使われていますね。

おそらく、themes/advanced/editor_template_src.js というファイル名になるはず。

念の為確認すると、

  • editor_template.js
  • editor_template_src.js

2つ、ファイルがありますね。違いが分からないので開いてみましたが納得。

srcが無いほうのファイルは、圧縮されていました。(改行やスペース)

srcがあるほうは、デベロッパー向きでコードが見やすいものですね。

納得した後に他のコードも追ってみると、あとはほとんどがjsファイルに min を付けるか付けないか等の判別(圧縮ファイルを読み込むかどうか)で使われていました。

 

ただ、一箇所違う部分がありました。

wp-includes/script-loader.php 850行目付近

if ( ! is_admin() || ( defined('SCRIPT_DEBUG') && SCRIPT_DEBUG ) )
 $concatenate_scripts = false;

$concatenate_scripts ? これは一体なんでしょう。よく分からないので、変数名を翻訳してみました。

concatenate = 連結

連結。なんでしょう。。分かりません。Javascriptファイルの連結?しかも管理画面内のとき。

 

ふと考えると、WordPressのファイル読み込み設定は、

http://サイトURL/wp-admin/load-styles.php?c=1&dir=ltr&load=admin-bar,buttons,media-views,wp-admin&ver=3.5.1

このようになっています。もしかして、この連結のことかな?

SCRIPT_DEBUG をtrue にしたりfalseにしたりして、管理画面内のソースをにらめっこしてみると、trueにした時はbuttons のcssやnav-menusのjsなど、cssやjavascriptファイルをひとつずつ読み込む設定になる仕組みとなっていました。

こうやってみると、WordPressって多くのJSファイルを読み込んでいるんだな~と実感。それでいてよくあまりエラーが起きません。すごいな。。 😉

この機能は、普段のプラグインの開発やテーマの作成では使わないようなデバッグ機能かもしれません。

 

お次は、

define(‘SAVEQUERIES’, true);

クエリをセーブ。ログとして保存するのかな?分からないので探ってみました。

wp-includes/wp-db.php の1195行目あたり、

if ( defined( 'SAVEQUERIES' ) && SAVEQUERIES )
 $this->timer_start();

~

if ( defined( 'SAVEQUERIES' ) && SAVEQUERIES )
 $this->queries[] = array( $query, $this->timer_stop(), $this->get_caller() );

1つめのやつはtime_start()なんで、おそらく何か時間を開始していると解釈しました。

念の為確認してみましたが、microtime()で取得した値を変数に入れているだけのようです。

 

2つめの部分ですが、

 $this->queries[]

これがよくわからない。$this->queriesへ配列として追加。

よく分からないので $wpdb->queries を出力してみました。

Array
(
 [0] => Array (
 [0] => SELECT option_name, option_value FROM wp_options WHERE autoload = 'yes'
 [1] => 0.0027470588684082
 [2] => require_once('...省略...'), wp_not_installed, is_blog_installed, wp_load_alloptions
 )
)

↑省略しています。require_onceの中身。長いので。

クエリが出力されました。

 

ただ、queriesに入るクエリは、どういったタイミングのクエリなんでしょう。

と思い、この関数名を見ると、

function query( $query )

$wpdb->queryで実行されたクエリ全てが対象のようです。

 

今回は何のフックもせずに、$wpdb->queryを実行したのでクエリがひとつしか出力されませんでした。

なので試しに、$wpdb->queriesをadmin_footerにフックさせて実行してみました。

結果、やっぱり$wpdb->queryを実行したクエリの情報を格納しているようでした。

クエリがちゃんと実行できているかどうか、予定通りのクエリを発行しているかどうか、確かめるには丁度いい機能ですね。

プラグイン開発者でデータベースをよく使用してテストする場合は、嬉しい機能です。

 

 

プラグインのデバッグにいいもの

Debug Bar

作成者にwordpress.orgが含まれているので安心して使えそうです。

ただ、私はこのプラグインの使い方がいまいちよく分からないので、使ってはいません。

Developer

作成者にAutomatticが含まれているので安心して使えそうです。

 

 

クライアントに納品するWordPressの管理画面カスタマイズ vol.6

管理画面のカスタマイズするところ、探せばたくさんありますね。

前回はクライアントに納品するwordpressの管理画面カスタマイズ vol.5 にて、クライアントへダッシュボードを使って、クライアントへのお知らせ表示をしました。

  1. クライアントに納品するwordpressの管理画面カスタマイズ vol.1
  2. クライアントに納品するwordpressの管理画面カスタマイズ vol.2
  3. クライアントに納品するwordpressの管理画面カスタマイズ vol.3
  4. クライアントに納品するwordpressの管理画面カスタマイズ vol.4
  5. クライアントに納品するwordpressの管理画面カスタマイズ vol.4.5
  6. クライアントに納品するwordpressの管理画面カスタマイズ vol.5
  7. クライアントに納品するwordpressの管理画面カスタマイズ vol.6

 

今回は投稿画面のカスタマイズとなります。

デフォルト投稿編集画面
デフォルト投稿編集画面

この画面を、クライアント向けにカスタマイズする方法です。

 

まず最初。いらないものはレッツ削除。

すぐに思いつくものは「ヘルプタブ」という名称となるのかは分かりませんが、それ。

ヘルプタブ
ヘルプタブ

まずはこのヘルプタブを削除したいと思います。

今回は簡単にヘルプタブと表示オプションタブを削除することができるプラグイン「Screen Options and Help Show Customize」をインストールして有効化して、そこから削除の設定をしました。

※使い方はWordPress プラグイン Screen Options and Help Show Customizeをご覧下さい。一応使い方を見なくても簡単に設定できるようには作っています。

 

できましたか?ついでに表示オプションも必要ないなら一緒に削除してもいいと思います。

ヘルプタブ削除後
ヘルプタブ削除後

あ、必要の無いメタボックス(タグとかスラッグとかリビジョンとか)は、表示オプションタブを削除する前に非表示にして、表示オプションタブを削除すると良いと思います。

 

投稿画面カスタマイズの本題、ビジュアルエディタ

ちなみに、デフォルトのテーマ(TwentyTwelve)でのビジュアルエディタはこうですね。

ビジュアルエディタ-デフォルト
ビジュアルエディタ-デフォルト

 

H2タグやH3タグやul liタグなど、このような表示です。

ちなみに、フロントのサイト(一般のユーザーが見るサイト)のデザインを変更(style.css)しても、このビジュアルエディタの部分は変更されません。

ビジュアルエディタのCSSは別で用意されている為です。

で、このビジュアルエディタのH2などの部分にも、デザインが適用されるようにカスタマイズしていきます。

 

先に

フロントサイトのコンテンツ部分のCSSを以下のように設定しました。

.entry-content {
 background: rgba(0, 0, 0, 0.06);
 padding: 20px;
}
.entry-content h2 {
 font-size: 30px;
 line-height: 38px;
 background: rgba(195, 87, 0, 0.4);
 padding: 8px 22px;
}
.entry-content h3 {
 font-size: 22px;
 line-height: 28px;
 background: rgba(25, 100, 128, 0.4);
 padding: 8px 22px;
}
.entry-content h4 {
 font-size: 18px;
 line-height: 26px;
 padding: 8px 22px;
 color: green;
}
.entry-content ul {
 margin: 0;
 paddign: 0;
}
.entry-content ul li {
 color: red;
}

 

で、このCSSと同じものを、ビジュアルエディタにもこれから適用していきます。

デフォルトのテーマのままだと、黒字しかないので上手く適用されているのか分からなかったので、上記はCSSが適用されているどうか分かりやすいようh2やh3の背景色を適当に変更しています。

デザイン変更後のフロント
デザイン変更後のフロント

 

フロントのコンテンツ部分はこれでCSSが適用されている事が分かりました。

次に、本題のビジュアルエディタのCSS設定です。

 

デフォルトテーマ(TwentyTwelve)のfunctions.phpをくまなく探せば分かりますが、適用するためにはまず、

add_editor_style();

という関数を、functions.phpに記載します。

※フックを用いて実行させてください。具体的には例えば↓

function mytheme_setup() {
  add_editor_style();
}
add_action( 'after_setup_theme', 'mytheme_setup' );

 

実行すると、テーマディレクトリ内のeditor-style.cssというCSSファイルをビジュアルエディタに読み込む設定をしてくれます。

あとは単純に、テーマディレクトリ内にeditor-style.cssというファイルが無ければご自身で作成して、上記のCSSを適用すればOKです。

※注意 : ビジュアルエディタ内に entry-content というクラスはありません。

なので、.entry-content となっている部分を、ビジュアルエディタ内の mceContentBody クラスなどに変更してください。

 

たまに記述したCSSが適用されない場合があります。
この場合は、ファイル名が微妙に間違っているか、キャッシュが原因だったりします。

ブラウザのF5や更新ボタンを押しても、なかなか更新されない場合もあります。

その場合は、キャッシュを削除するか、スタイルシートを直接ブラウザから一度開いてください。

chromeでのスタイルシート読み込み一覧
chromeでのスタイルシート読み込み一覧

キャッシュが残っていると、ファイルを開くと真っ白だったり古いCSSの記述だったりします。この場合はキャッシュが原因なので、ここで更新をし、CSSファイルの内容が変われば、ビジュアルエディタにも記述したCSSが適用されます。

ビジュアルエディタへのCSS適用後
ビジュアルエディタへのCSS適用後

これでビジュアルエディタにもフロントサイトと同じようにCSSの適用ができました。

これで完了!

と思います。

 

が、よーく考えて下さい。フロントサイトのCSSを触る時って、これからも発生しますよね。

だとすると、同じようにeditor-style.cssも触らないと同じデザインが適用されません。

同じスタイルを適用するだけなのに、もう一度同じような事をする…。ちょっと手間ですね。 😕

 

ビジュアルエディタとコンテンツ部分のCSS適用が1箇所で済めばいいのに。

と思った方は、以下の続きの記事は参考になると思います。

ということで次は、ビジュアルエディタのCSSとフロントサイトのCSSをひとつにまとめる(コンテンツ部分のスタイルを一つにまとめる)方法です。

 

ビジュアルエディタとフロントサイト共通のCSS

どちらにも読み込む為のCSSファイルを先に作成します。

今回は front-content.css というファイルを、コンテンツ部分共通のCSSとして使うことを想定して進めます。

先ほど、ビジュアルエディタにCSSを適用する方法として、 add_editor_style() を使用しましたが、もうひとつこの front-content.cssを読み込ませます。

function mytheme_setup() {
  add_editor_style();
  add_editor_style( "front-content.css" );
}
add_action( 'after_setup_theme', 'mytheme_setup' );

※@importでCSSファイルを読めばいいじゃないか。と思われる方もいるかと思いますが、importだとブラウザのパフォーマンスに影響が出るという事例もあったりするので、今回は追加で読み込ませる方法をとっています。
ご自身のお好みの方法で読み込ませて下さい。

これで、ビジュアルエディタに「editor-style.css」「front-content.css」の2つのCSSが読み込まれるようになりました。

もともとのeditor-style.cssはビジュアルエディタのCSSをリセットする目的等で使用されるといいと思います。

先ほどの、ビジュアルエディタに適用させていたCSSを、front-content.cssに記述します。

が、両方のコンテンツ部分に適用させるために、合体? 😎 させます。

front-content.css

.entry-content, .mceContentBody {
 background: rgba(0, 0, 0, 0.06);
 padding: 20px;
}
.entry-content h2, .mceContentBody h2 {
 font-size: 30px;
 line-height: 38px;
 background: rgba(195, 87, 0, 0.4);
 padding: 8px 22px;
}
.entry-content h3, .mceContentBody h3 {
 font-size: 22px;
 line-height: 28px;
 background: rgba(25, 100, 128, 0.4);
 padding: 8px 22px;
}
.entry-content h4, .mceContentBody h4 {
 font-size: 18px;
 line-height: 26px;
 padding: 8px 22px;
 color: green;
}
.entry-content ul, .mceContentBody ul {
 margin: 0;
 paddign: 0;
}
.entry-content ul li, .mceContentBody ul li {
 color: red;
}

ビジュアルエディタで問題なくCSSが読み込まれましたか?

問題が無ければ、あとはフロントサイトにも追加でfront-content.cssを読み込ませてください。

header.phpに書くなり、wp_headerにフックさせるなりで適用させれば、コンテンツ部分のCSSの管理が1箇所で管理できるようになります。

私はたまにやってしまいますが、

フロントサイトのCSSは設定したが、ビジュアルエディタには適用してなかった。。 😥

なんて事には、多少はなりづらくなると思うのでおすすめです。

 

wordpress plugin Post Lists View Custom Version UP 1.5.1

WordPressの一覧画面のカスタマイズをするプラグイン、

Post Lists View Custom

のバージョンアップをおこないました。

最新バージョンは1.5.1。

 

 

やったこと

思いっきりバグがありました。

記事一覧でカスタムフィールドの項目が、選ぶことはできますが空白のままだなんて。

カスタムフィールド空白
カスタムフィールド空白

誰もそのバグについて言ってくれない。それを自分で気づく。

ちょっと悲しいバグ発見でした。

機能を増やすと、確認する箇所が多くなって大変です。。

 

ダウンロードはこちら
http://wordpress.org/plugins/post-lists-view-custom/

 

 

 

 

 

 

 

帰ってきた英語の時間。外人からの問い合わせ

何度か外人の問い合わせ対応をしていると、不思議と英語がデキる気がして怖いです。。 :mrgreen:

 

最近、プラグインをアップデートすると、なぜか30分もしないうちに寄付してくれた方がいました。

いやー、ありがたいです。ありがとうございます!

ってか早くないですか?ほんとにちゃんとプラグイン使いました??あなたの国はいま何時ですか???

ただのすれ違いのような気もしますが。でも、ありがとう! 🙂

 

今回もプラグインをアップデートした後、さっそく何件か問い合わせがありました。

wordpress.orgのサポートフォーラム、WP Admin UI Customizeのマルチアドオン購入者、直接私宛にメールをくれた方。

私宛に直接メールを送る方は初めてなので、完全にスパムと勘違いしてましたよ。マシューさん。

 

今回の問い合わせは今までと違っていました。

今までは

 

How can I add custom post types to the menu?

カスタム投稿タイプをメニューにどうやって追加できますか?

 

みたいなシンプルな質問だったので、どちらかと言えば答えやすかったです。

でもやはり、長文のメールや初めて聞くような熟語?はなかなか解読&解釈するのが難しいです。

md5で暗号化された文字列を複合化している気分です。 😐

 

今回の問い合わせ。サポートフォーラム経由で、

Like a fool….

 

と文章がはじまり、その後に4行ぐらいのメッセージが。

Like と付いているから、多分プラグインを好いくれているのかな?それは良かったと思いGoogle翻訳で翻訳してみると、、、

 

愚か者のように…..

 

😳

 

えっ?Like a fool ってそういう意味なの?Google翻訳の間違いじゃないの??

確認の為、Google検索で「Like a fool」で検索。すると、、

いやー。いやーーー。やっぱりおろかものーーー 😆

 

ここでおろかものは、プラグインをアップデートしたことで、何か重大なトラブルでもあったのかな…。と考えてみました。

 

でも何も思い浮かびません。とりあえずおろかものは、翻訳を続けてみました。

I removed the custom admin panel links from the administrators menu.

私は管理メニューからカスタム管理パネルリンク?を削除しました。

 

カスタム管理パネルリンク?っていったい何??プラグインの設定リンクの事…かな。

 

Now it tells me i do not have permission to view any of the links of this module.

教えて、私は権限を持っていなくて、このモジュールのいくつかのリンクが表示されません。

 

うーん、この訳は合っているかな。。多分あっていると思うけど。。モジュール?

でも、tells me って使う時もあるんだ。ひとつじゃなくていくつかを教えて欲しいってことかな。

 

I need to find the value that it stores in wp_options and then delete it and reinstall the module.

私はwp_optiionsから値を見つけて削除し、再インストールする必要があります。

 

この、storesって何でしょう。。翻訳をかけても、店。 that it stores 。その店?ここはちょっと分かりません。

というより、再インストールする必要があります。という訳も変だとは思っていますが、他の訳が分かりません。。

 

Could you detail what i need to be removing?

私は削除する為に何が必要か詳しく教えて?

 

あ、なるほど。多分メニューを誤って削除した、自分自身に言っているのかな?Like a foolって。

値を削除する必要があるかどうかって事なのか。

 

とりあえず、削除する必要うんぬんじゃなくて、メニューが表示されればいいのかな?と思い、私はこう返事をしてみました。

I was maybe understand the problem.

The first way
To reset the user roles.
http://sample.com/wp-admin/plugins.php
Settings link from here.

The Second way
Delete the value of the side menu from wp_options.
option_name is wauc_sidemenu_setting.

I'm sorry if you are not resolved.
In addition, please contact me.

私は多分問題を理解しました。

最初の方法
ユーザー権限をリセット。
設定方法はここです。

次の方法
wp_optionsからサイドメニューの値を削除してください。
option_name はwauc_sitemenu_settingです。
もし解決しなかったごめんなさい。
また、お問い合わせ下さい。

 

たぶん、これで大丈夫だろう。。maybe…。

 

そういえば、日本のwordpressのサポートフォーラムでも、的確な回答をするのって結構大変です。

たまにサポートフォーラムで回答したりしていますが、

PHPが全く分からない方もいれば、データベースの存在を知らない人も、目の前の問題だけを質問していてその背景で何をしようとして、そうなったのかが書かれていなかったり。

日本語のサポートでも結構大変だなぁと感じています。

 

それが英語になると、解読だけでも大変です。。

普通に外人に返答が出来る方達は本当に凄いですね。

羨ましいです。首の後ろにUSB挿すことが出来て、コピー出来たらいいのに。といつも思います。

 

ちなみに最近、少し学習?しました。わざとカタコト?みたいな感じで返事を出すようにしました。

自分で書いた文章を、3つか4つに分けた一文形式みたいな。

たとえば先ほどの、「次の方法」の説明部分。

日本語だと、「****テーブルの****が****の値を削除してください。」と一行で書けるんですが、これを機械翻訳すると、英語素人の私でも、「う~ん、これは変。」となんとなく思います。

かといって、長文をかける分けでもないので、

 

「 ポニョ、ソータ、スキ! 」

 

みたいな感じで分けて返事をしています。

きれいな英語というよりは、とにかく伝わる事を第一。にしています。

 

Thanks for the response,

all fixed!

 

なんて返事が返ってきた時はやっと少し落ち着けます。返事が返って来ない時が、不安です。

英語の解釈を間違ったのではないだろうか。。なんて。

 

解釈を間違っていたら、バグを取ったり修正したりすることすらも出来ません。 🙁

グローバル化の波を、地味に感じています。

 

 

wordpress plugin Post Lists View Custom Version UP 1.5

wordpressの管理画面にある様々な一覧画面をカスタマイズする

Post Lists View Custom

のバージョンアップを行いました。

最新バージョンは1.5。

 

こちらもWordPressの3.6のローンチを待っていましたが、まだまだ掛かりそうな気配がしたので待たずにコミットしました。

 

やったこと

WP Admin UI Customizeも疲れましたが、こちらもかなり疲れました。

まず、カラム(一覧表示の列)にカスタムフィールドを指定することができるのですが、そのカスタムフィールドの値が何も無い場合、「 – 」←こんな感じで何にもないよ的な表示をしていましたが、このプラグイン+フックカスタマイズをすると、これが邪魔。なので削除しました。

あとは大幅に中身を変更しました。なんか、無駄な所があったりしたので。

データベースへ更新するoption_name値も変更しました。少し管理がしやすいようにしています。

あとは別で、Widgets List View CustomizeというプラグインもWordPress.orgにて公開していたのですが、そもそもPost Lists View Customizeの中に機能をそのまま入れたほうが楽だな。と思いましたので、利用できるウィジェット一覧もカスタマイズできるようになっています。

そして最後。ここからが一番大変なやつ。

Post Lists View Customを適用する権限を選べるようになりました。

ユーザー権限選択画面
ユーザー権限選択画面

うん、ここまでは普通です。権限を選択して、その指定された権限だけに設定されたPost Lists View Customizeの設定を適用すればいいだけの話なので。

今回はこのPost Lists View Customizeとは別に、アドオンとして、「Post Lists View Customize Multiple setups add-on」をリリースしました。

Post Lists View Customize Multiple setups add-on

機能は、権限ごとにPost Lists View Customizeが設定できます。

なぜか、日本人の方からの要望はありましたが、外国の方からの要望は一切ありませんでした。

下のキャプチャを見ると、分かりやすいと思います。

 

Added the user roles tab
Added the user roles tab

 

なんで、Post Lists View Customizeと一緒にしないの?と思う方もいるかもしれません。

 

アドオンにした理由ですか?

販売しようと考えていました。以外の理由なんてないよ。てへぺろ(・ω<)

というか販売してもプラグインユーザーが少なすぎて売れないじゃないか。
じゃあアドオンにして自分のブログに少しでもアクセスしてね。えへへへぺろ(・ω<)

なんてことをしても別にいいじゃないか! 😳

(個人的にてへぺろを使ってみたいと思いましたので、ちょっとすっきり)

 

次は、まじめなほうの理由。販売のほうはまじめな理由でしたけどね。

権限ごとに設定可能ということは、権限の分だけ設定をしなければいけないという事にもなります。

なので、この権限の分だけ、という部分が必要な方不必要な方が出てくると考えました。

どちらにもメリット・デメリットはありますので、機能を分けることにしました。

アドオン無し

一覧設定がひとつだけ。その一つの設定を適用する権限を選ぶだけ。の簡単設定。権限ごとに分けることはできない。

アドオン有り

一覧設定の数は、権限の数の分だけ。 設定するのは大変だけど、細かく権限ごとに一覧画面のカスタマイズは可能。

 

という感じです。

あとは、普通にまだまだプラグインユーザーとしての信頼や実績が少ないなと思いましたので、無料で配布しています。

 

ダウンロードはこちら
http://wordpress.org/plugins/post-lists-view-custom/

wordpress plugin WP Admin UI Customize version up 1.3.2

WordPressの管理画面UIをカスタマイズする

WP Admin UI Customizeのバージョンアップを行いました。

最新バージョンは 1.3.2

 

やったこと

本当はWordPress3.6のローンチに合わせて、最終確認をしてからコミットしようかと思って5月20日まで待っていましたが、ローンチのスケジュールがまたずれそうな感がしたので、先にコミットしました。

なので、WordPressのバージョンは今のところ、3.6 beta 3 まで確認済みです。

 

さて、やったことですが、まずバグ修正から。

管理画面のサイドメニューのカスタマイズが出来るのですが、サブメニューがひとつも無い設定をすると、エラーの表示が出ていました。ので、このバグ修正です。

次に、いくつかプラグイン内で使用できる変数を増やしました。

今まで全く気づきませんでしたが、テーマを子で使用している場合、template_directory_uriでは使用中のテーマディレクトリが上手く取得出来ませんでした。

※具体的には、親テーマが Twenty Twelve、子のテーマがMy Themeという名前で、ディレクトリ名も同じような名前だと仮定します。
使用テーマがMy Themeです。 で、そのテーマ内のfunctions.phpや他のテンプレート内からtemplate_directory_uriでテーマフォルダのURLを取得しようとすると、

http://サイトurl/wp-content/themes/twentytwelve/

になるようです。でもあくまでも親テーマなんて触ることはほぼ無いので、子のテーマディレクトリを取得できるよう、stylesheet_directory_uri を追加しました。

また、マルチサイトの場合だと現在のブログ名ではなく、ネットワークサイト名も扱えるようにしました。

次に、ここが一番難関でした。

 

投稿編集画面、固定ページ編集画面、それぞれメタボックスがありますよね。

このメタボックスで、デフォルト以外のメタボックスがあります。これを非表示にする機能。

ググっていると、「あぁ、グローバル変数の$wp_meta_boxesから取得できるじゃない」

となるかもしれませんが、実はほとんど取得できません。

(プラグインによって、フックをかける場所・タイミングが違う為)

他に方法は無いだろうか。どこかにフックをかければ取得できるんじゃない?とだいぶ、試行錯誤してみましたが、さっぱり。。

結果、思いついた方法として、「投稿編集画面」を表示すると、現在設定されているメタボックス全てを一度データベースに保存。

その後にWP Admin UI Customizeのメタボックス削除メニューから、先ほど保存したメタボックス一覧を読み込んで、非表示にするか選択する形式です。

この、「一度投稿編集画面または、固定ページ編集画面にアクセスする必要がある」という点を、英語でまた説明するのも私には難しいところです。

 

 

なんだかんだで、こんな機能を更新しましたよ。良かった寄付してね使ってみてね。

ダウンロードはこちら
http://wordpress.org/plugins/wp-admin-ui-customize/

今話題のブルートフォースアタックの対策 (LITE?

最近ブルートフォースアタックという言葉をよく聞きますね。

 

多分あっていると思いますが、まずは認識。

ブルートフォースアタック = 総当たり攻撃。数打てば、いつかは一発あたるでしょ。的な。

 

怖いですね。でも私のブログなんてそんな対象にならないだろう、と思っています。

そんななか、WordPressのフォーラムで、たまたまあがっていたのが、

IDやパスワードを空白でアタック

されるというような内容でした。

へーそんなアタックも存在するんだ。もしやるとすれば、ログイン画面のURLを特定する為にかな?なんて思ったり。

ちょっと気になったので、「ブルーフォースアタック 空白」で検索してみました。

すると・・・なんと!Googleの検索窓の直下にこんな表示が。

次の検索結果を表示しています: ブルーフォースアタック 空白

あ、ブルーじゃないんですね。ブルートなんですね。

真剣にこの記事を読まれていた方へ。大変失礼しました。ここから下は、ちゃんとしています。

 

で、検索結果2件目ぐらいのYahoo!知恵袋の質問に目がいきました。質問は、

「こんな事ここで聞くのはお門違いかもしれませんが、 8文字のブルートフォースアタックってどれくらいの時間を要しますか?」

という内容。ちょっと気になりました。

回答者の計算は、私には全く理解できませんでした。そんなことはおいといて、その回答は、

5.8×94×94×94/60/60/24≒約55日

という結果だそうです。後ろの60/60/24は1日の事か。でもこの94って何なんだ?w

いや、その前に。突破される時間ってそんなに早いの??

 

もちろんこれは、8文字のブルートフォースアタックの場合。ログインのパスワードなんかがこれにあたると思います。ユーザーのIDも分からなければ、もっと時間を要するはずです。

でも、最近WordPressへのブルートフォースアタックは、ユーザーIDを「admin」としての攻撃が多いようです。

そう、何をかくそう…かくしていない…このブログも…。 😳

 

ということで対策しよう( Liteだよ

ちなみに私の場合ですが、サーバはロリポップを使用しています。

幸い、ロリポップはその対策として、「WAF(ウェブアプリケーションファイヤーウォール)」という機能を実装してくれました。

なるほど!これで万時解決!

 

よし、コンパネからWAFを設定しよう!

という事で設定しました。すると…

記事の更新やコメントがたまに返せない等になる(エラーとなる)」

事が発生しました。う~ん、本当にWAFの設定の影響かな?

WAFの機能を切ってみました。すると・・・

記事やコメントがほぼ100%更新

う~んw。

まぁ、いいや。他に何かWordPressか、PHPか、.htaccess系の設定を変更すると、使えるようになるのかな。

 

で、次。

よくあるパターンとして、ユーザー名を変更しよう!という事が多いと思います。

よくある攻撃対象のユーザーIDが「admin」が多いから、というのが理由として多いようです。

 

ユーザー名変更するとなると、記事の作成者も変更しないといけないのか~。ちゃんと変更できたかどうかを確認するのも大変そうだな~。途中で何かエラーが出たら嫌だな~とか、ネガティブな事をとりあえず考えてみました。

で、少しポジティブに、ユーザー名を変更しようと色々と調べていると、WordPressのフォーラムでこんな記事が。

ユーザー名をadmin以外にしてもセキュリティ上の意味は無いのでしょうか

読めばなるほど。よく考えれば確かにそうですね。

admin決めうちでアタックしてくるものは防げる

そして、決め手となる記述が。

補足ですが、twitterでも同様のことがいえますね。
URLを調べればログインIDが分かります。

twitterはあまり使っていないので詳しい仕組みは分かりませんが、そうなるんですね。

ユーザーIDを変更する事自体も、何割かアタックは防げそうですね。

かといって、対策を大きくするのも…。どうかな~。ブログのアクセスが多い訳でも無いし。大事な事だとは分かっているけれど、セキュリティはいたちごっこだし、超機密情報を持っているわけでもないし。

よし、手っ取り早い方法として…。

 

結論

「パスワードを30文字」ぐらいにしよう。

という結論に達しました。これなら、パスワードを決めるだけ。そして出来る限りランダムな英数字+記号を混ぜまぜと。

30文字ぐらいなら、どれくらいの時間が掛かるんでしょうか。

 

追記

よくあるコメントを投稿する時の画像キャプチャの文字列を入力しないとコメントができない仕組みを、ログインにも出来ないんでしょうか。。そんなプラグイン無いかな。

 

 

wordpress plugin Announce from the Dashboard version up 1.2

WordPressのダッシュボードにユーザーの権限別にお知らせを表示させることのできるプラグイン

Announce from the Dashboard

のバージョンアップをおこないました。

最新バージョンは1.2。

 

 

やったこと

今までは、

  • 通常(背景グレー)でのお知らせ表示
  • 赤色での注意的な表示
  • 黄色のアップグレード的な表示
  • メタボックスとして表示

の4タイプでしたが、これに無属性(スタイル無し)の表示ができるよう追加しました。

それと複数お知らせを作成済みの際に、削除をしようと思うとひとつずつしか削除が出来なかったので、一括削除の機能を追加しました。

 

ダウンロードはこちら
http://wordpress.org/extend/plugins/announce-from-the-dashboard/