Most Plugin Version up for on SSL

いやー、最近かなりバグの報告をいただいていて、なかなかブログの更新ができませんでした。

とにかく相手の症状を理解し、原因探し、解決策考え…。

なんとか最近落ち着きました。いやー、疲れました。
外国の方はあまりWordPress.orgのサポートフォーラムは使わないのでしょうか。。直接のメールの問い合わせが多かったです。

(2~5件/1日、でも英語での問い合わせはかなり大変)

今回もほぼすべてのプラグインをアップデートしました。

 

一部のプラグインは機能追加を加えたりしています。

あと、全てWordPress 3.6 にて動作確認済みです。

 

更新するまでの経緯

ユーザーから寄せられるバグの症状をひとつひとつ見ていっても、なかなか”これだ”という原因が見つからず、よくある「他のプラグインの影響じゃないだろうか」という事を想定して原因を探っていました。

ただここで、症状を報告した方が色々試した結果「あなたのプラグインを使用している場合だけこういう症状が出ます」と調べていただたいた場合はありがたいです。

●●●のプラグインを一緒に使うとバグがありました~とか(バグではないですが)、使っていてこういうバグが出ますよーと教えてくれる場合は、なんとか改善の方法を検討をする事ができますが、「ヘイ、どうなってんだよ。動かないじゃないか」みたいな報告の場合、かなり厳しいです。

どうなっているのか調べたいけど、「動かない」とだけ言われても分からない。
分かるなら、直してますよ~。。 🙁

(そんなことはおいといて)

 

ただ今回、ひつとだけ、いつもと違うバグ報告をいただきました。

そのバグの原因を探る為に、プラグインの影響やテーマ、WordPressのバージョンやPHPの設定等をもとに原因を探っていたのですが、全く見当外れな所でした。。 😳

 

ちなみに、私は英語が得意ではありませんので、バグ報告をいただいた際に、「ごめんなさい、キャプチャを送っていただけませんか?」とお願いすることが時々あります。(というより、最近は画面を見せたほうがスムーズに解決すると感じています)

その際、「自分の画面はなるべく見せたくない」という方が多いと思います。
(特に管理画面に関しては)

なので、プラグインの設定画面”だけ”送ってもらう場合が多いので、その部分だけで原因がどこにあるのかを考えていました。。

これが、原因を探すことができない原因でした。。 😳
どんなに調べても、原因不明。

次に、バグ報告をいただいた方の中に、どでかい画面キャプチャを送っていただけた方がいました。
(操作している画面を動画で送ってくれた方もいました。これは非常に助かりました。  🙂  )

そして、キャプチャと同じように設定したりしてみましたが、相変わらず。。
プラグインの設定画面に原因があると思いひたすら探っていましたが、やはり見つからず。

う~ん。分からない。(こういう時はノートPCを( ̄  ̄ )ノ⌒)

一息ついて、ふと、キャプチャを再度よく見てみると、アドレスバーにhttps
SSLでの管理画面への接続でした。

あ、確かにSSL環境での動作確認はしていなかったな~。でも、SSLでも使えるとは思うけどな。

とりあえず確かめてみないと分からないものは分からない。という事でxampp内のOpenSSLを利用して試してみました。

そして、やっと原因が分かりました。

 

 

SSLの場合だけ上手く動作しなかった

不正確ですが、一言で言うならこんな感じのバグです。

少しだけ正確に言うと、プラグインでJavascriptを読み込むように設定しています。

そのJavascriptでjQueryのSortableやDropable等を設定しているので、データが変化します。最終的にユーザーが保存するデータは、ソート後のデータです。

そしてそのソートを行う為には、その処理を記述しているJavascriptファイルが読み込み出来なければ、もちろんソートすらも出来ません。

そしてSSLの場合だけそのJavascriptファイルが読み込まれない、というバグでした。

ただ、よく分からないのが何故SSLの環境だけ?と思いました。

以前からSSLの環境でプラグインを使っている方はおそらくいると思うのですが、なぜ今になってそんなバグ…?ユーザーが増えてきたから?

と色々考えても仕方ないので、実際に試してみたら…動きました…。SSLでも。  😕

う~ん、やっぱりSSLでも動くよね。。

その後も色々試行錯誤&バグ報告くれた方と色々とやりとりをしていて、やっと分かりました。

正確に言うと、「管理画面へのアクセスはSSL、フロントへは通常のhttp」。

「アクセス」。なるほど。気づきませんでした。 🙄

 

今回の方はおそらくですが、「サイトのURL(home)及びWordPressのURL(siteurl)httpでも管理画面にアクセスするときだけはhttps」という環境で使っているのではないかと考えました。

 

SSLで試すという事で、私のほうでは動作確認の為に、WordPressのインストールからサイト及び管理画面の閲覧まで全てhttpsの環境で全て試していました。

おそらくこのバグ報告をくれた方は、インストール時はhttpでインストールしたのか、または途中でhttpに変更したのか。等をおこなったのではないかと思います。

何をしたのかはおいといて、そのような環境を想定して試してみることに。

そりゃ、いくらget_option(‘siteurl’)とかを使って、CSSファイルやJavascriptファイルを読み込もうとしても、アクセスしているプロトコルはhttpsだったら読み込めないよね。 😎

 

で、私の場合プラグインディレクトリ内のCSSやJavascriptファイルを読み込む際に、

WP_PLUGIN_URL . '/' . dirname( plugin_basename( __FILE__ ) ) . '/'

という風にプラグインディレクトリのURLパスを取得していました。

この  WP_PLUGIN_URL が https:// で管理画面にアクセスした場合、https://にならずにhttp://のままでした。

get_option('siteurl') . '/wp-content' . '/plugins'

このように取得・設定している為です。

get_option(‘siteurl’)では、いくらhttpsでアクセスしても、一般設定にて設定されているhttpでのURLを取得するのでダメでした。

 

ただ私は詳しくは分かりませんが、分かることとしては、Google Chromeの場合、https:// で呼ばれる画面から http:// のファイルにアクセスさせない仕組みのような感じでした。(具体的には何の影響でそうなるのかは分かりません。セキュリティ的な意味合いな気はしますが)

なので、全プラグイン、WP_PLUGIN_URL は使わず、

plugin_dir_url(__FILE__)

これにしました。

これだと、set_url_scheme が間に入って、WP_PLUGIN_URLで取得したアドレスに対してhttpやhttpsも書き換えてくれるような感じでした。というか、こっちで動くならこっちのほうがいいですね。シンプル。 😮

(なんか、WordPressのデバッグ機能を有効にしたら「この関数よりこっちの関数のほうがいいですよ」みたいな表示を出してくれたら嬉しいな。。便利な関数があったとしても、存在が分かりません。。) 

 

で、これで試してもらうと無事動作したようでした。

今回のケースはたまたまどでかいキャプチャと、動画ファイルをいただけたのでなんとか解決までに至りました。

めでたしめでたし  🙂

Most Plugin Nonces Version UP

今回、ほぼすべてのプラグインのバージョンアップをおこないました。

 

更新するまでの経緯

とあるアメリカ?の方からWordPress.orgのサポートフォーラム経由で「あなたにプラグインのバージョンアップ版をあげます。」と、今までにない、不思議な問い合わせ?プレゼント?がありました。

怪しいな。 😈

とりあえず、そんな気持ちはおいといて。バージョンアップ版を確認してみることにしました。

確認してみると、確かに今のプラグインに導入したほうが機能性は良くなりそうでした。

なんていい方なんでしょう! 🙂

すぐに導入させてもらいました。

 

すると、「あなたのプラグインにNoncesを導入したほうがイイヨ!」とご返事がありました。

Nonces? 全く聞いたことの無い言葉でした。何かの注意表示のこと?

プラグインの使い方について、注意を表示したほうがいいという事かな??

 

う~ん。。分かりません。 😕

こういう時は素直に「分かりません」と言う事にしています。 返事いただけたら嬉しいですが。 🙁

で、その後返事が来ました。 😮

そのNoncesはというと、

http://codex.wordpress.org/Glossary#Nonce

http://markjaquith.wordpress.com/2006/06/02/wordpress-203-nonces/

WordPress Nonces

セキュリティに関する事のようでした。(正直、長文の英語のほうはあまり理解できていません。英語力不足…。 😆 )

今回、問い合わせのあった方の意見として「あなたのプラグインにXSS攻撃から保護する仕組みを導入したほうが良い」という意見だと解釈しました。

WordPressってそんな仕組みがあったんですね。

というか、私のプラグイン、XSSから保護されていなかったんですね。。これはすぐに対応しなきゃ。。 😳

 

 

やったこと

今回はセキュリティに関する事でしたので、ほぼすべてのプラグインを更新しました。

プラグイン設定フォーム内に

wp_nonce_field()

を追記。

フォームデータの更新直前に、

check_admin_referer()

にて、wp_nonce_field()にて設定されたワンタイムトークンのチェック。

 

あとはAjax経由でデータを取得しているプラグインには、Ajaxでデータを取得する際にワンタイムトークンのチェック確認を入れました。

既に利用されている方は出来るだけ最新バージョンを使用してください。

 

wordpress plugin Archive Posts Sort Customize Version UP 1.2

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

Archive Posts Sort Customize

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

最新バージョンは1.2。

 

やったこと

今までは「ホーム」「カテゴリ一覧」「タグ一覧」の3種類のみが、記事一覧ソートカスタマイズの対象でしたが、コメントからご提案ありました「検索結果」のソートのカスタマイズに対応しました。

「検索キーワード」プラス、「指定項目の昇順or降順」といった記事一覧の表示ができるようになります。

Search Archive menu
Search Archive menu

 

ダウンロードされるかたはこちらからどうぞ。

http://wordpress.org/extend/plugins/archive-posts-sort-customize/

wordpress plugin Post Lists View Custom Version UP 1.5.3

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

Post Lists View Custom

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

最新バージョンは1.5.3。

 

やったこと

翻訳ファイルを実験的に9つぐらい追加しています。

(ドイツ語・スペイン語・フランス語・イタリア語・オランダ語・ポルトガル語・トルコ語・ロシア語・ポーランド語)

 

それと、ここが一番大きな部分ですが、プラグインで自動で追加される投稿一覧等のカラム(列)もカスタマイズ可能にしました。

今まではデフォルトのカラム+カスタムフィールドをカラムとして設定できるようにしていました。

プラグインで自動で追加されるカラムはカスタマイズの対象では無かったので、使いづらかったかもしれませんが、これでだいぶ使いやすくなったんじゃないかと思います。

 

ただ、今回のアップデートでちょっと使い方に”コツ”があります。

 

Post Lists VIew Custom をインストール、有効化OK。ではさっそく…。と Post Lists View Custom にてカラムのカスタマイズを行おうとしても、一部のデフォルトのカスタマイズ画面では何も表示されません

(下の画面は投稿一覧のカラムカスタマイズのデフォルトの画面です)

「投稿一覧ページにアクセスしてください。」とだけ表記が出ます。

デフォルト 投稿一覧カスタマイズ画面
デフォルト 投稿一覧カスタマイズ画面

現在のカラムの設定を読み込む為に、投稿一覧の画面にアクセスしてください。ただ、アクセスするだけです。

 

投稿一覧等の画面にアクセスすると、Post Lists View Custom プラグインが、一覧のカラム設定を読み込み、データベースに保存されます。(設定ボタンを押す等のアクションをする必要はありません。)

これでもう一度、投稿一覧のカラムカスタマイズ画面にいくと、データベースに保存されている一覧のカラム設定を読み取り、プラグインで作成されたカラムを含め、一覧画面のカラムのカスタマイズが可能になります。

(固定ページ・カスタム投稿タイプも同様です)

投稿一覧カスタマイズ設定画面
投稿一覧カスタマイズ設定画面

 

それにプラス、ユーザーの権限グループ別にカラムを変更したい場合は、Post Lists View Custom for Multiple setups Add-on というアドオンを一緒にインストールすると可能になります。

設定画面はこんな感じです。

Added the user roles tab
Added the user roles tab

 

ダウンロードはこちらです。

http://wordpress.org/plugins/post-lists-view-custom/

WordPress Plugin Media Insert from Themes Dir

久しぶりに新しいプラグインを作りました。

このプラグインは、テーマディレクトリ内の画像を、投稿編集画面の「メディアを追加」から挿入できるようにするプラグインです。

 

と、そのままプラグインの説明に入ろうと思いましたが、今見ているこのページ、勝手ながら”二部”に分けることにしました。

  • 第一部 : プラグイン開発中のうっぷん。
  • 第二部 : プラグインについてのご説明

プラグインの説明を期待されている方が9割以上もしくは10割だと思います。

このプラグインを作ることに、予想以上に時間が掛かり、ちょっとだけうっぷんが溜まっていたので、その鬱憤晴らしを書きました。。鬱憤については読まなくても、プラグインの使用方法に全く影響しません。

プラグインを使いたいだけの方はそのままプラグインの説明までスクロールしてください。 😉

 

↓ここからうっぷん開始。

だいぶ、だいぶ、疲れました。。 😳

このプラグインを必要とする方はあまりいないと思います。あと、このプラグイン自体使ってみればわかりますが、もの凄い機能を持ったプラグイン。という訳ではありません。

なので、気持ち、ぱぱっとやって、動作チェック。としたかったのですが、知識やスキルが少なかった分、想像以上に時間が掛かりました。

 

ちなみに、なんでこのプラグインを作ったかと言うと、別の記事「WordPressのマルチサイト作成、運営で思ったこと」に書いていることへの対策方法として、作りました。

私の場合、マルチサイト内の投稿の本文にテーマディレクトリ内の画像を挿入することがよくあります。

テーマフォルダ内の画像を投稿に挿入する方法として、

  1. 「メディアを追加」を押して、「URLから挿入」を選択
  2. ブログのURLをコピペ
  3. /wp-content/ からはじまり、テーマフォルダ内の画像が入っているフォルダまでのパスを記入
  4. テーマフォルダ内の挿入したい画像ファイル名をコピペ
  5. 最後に、整列やらリンクやら選んでキャプションやらを書いて挿入

という感じだと思います。

テーマフォルダ内の画像を投稿に挿入するまでのこの手順。初めは何とも思っていませんでしたが、投稿が多くなるにつれ、かなり手間でした。 🙁

 

挿入したはずの画像が表示されない。

「あれ?画像のパス合っているはずだけど…。」入力したパスが微妙に違っていたり。 🙁

FTPでサーバに接続してファイル名を確かめにいったり。。 🙁

これをもっと手軽に、今の「メディアライブラリ」のように、画像の一覧から選択して、はい、そーにゅー。

手間を最大限省きたかったので、このプラグインを作りました。

 

また、作りあがるまでの途中についてですが、

このプラグインの作成に取り組み始めるまでは、簡単にこうこう、こうして、こうすれば、あぁん違う。もっとこうぅ。とか、「media_upload_tabsにフックして、あれこれすればいけそうかな」と考えていました。

色々と試してみました。

が、結果、できませんでした。メニューやページは作れても、挿入が出来ない。 😕
(他にやり方があるのかな…。結構試しましたが出来ませんでした。)

とにかく、まだ情報が足りないようなので、色々とググってみましたが、あまり参考になるような情報が出てきませんでした。

うーん、まいった。 😥

 

誰か他の方が、同じ機能のプラグイン作ってくれていたら嬉しかった。。(それとも既にあったりするのかな。。だとするなら、そのプラグインを探しきれなかった。。)

情報が無い以上しょうがないので、フックさせる所を探す為に、WordPressのコアファイルとひたすらにらめっこ。 😯

そして、にらめっこをし続けて、なんとなく出た結果。
Javascriptで動作させているような感じでした。

「media-view.js」あたりがメディアを挿入する際の画面レイアウトを作成しているような。

 

jQueryはよく触る機会があるので、なんとかなるだろう。
と思い、media-view.jsのコードとひたすらにらめっこしました。

ひたすらにらめっこした結果、今回のプラグインを作成する為に必要な知識やスキルは全く別物でした。 :mrgreen:

Backbone.jsってなんですか?Underscore.jsってなんですか? 😯
<script type=”text/html” id=”tmpl-attachment”>ってなんですか?

そんな状態です。。見なけりゃ良かった。。でも見ないと進まない。。

そもそも、Backbone.jsというフレームワークの存在を私は知らなかったので、フレームワークを使用している存在に気づくまでに時間が掛かりました。

MVCについては何となーく…なら分かりますが、Selectionってなんですか? 🙁
なんだこのinitializeやら、eventの設定の仕方は…。
どういう仕組みでやっているのか理解するまでに、かなり時間が掛かりました。。

Backbone.jsについての情報をぐぐりました。
基本中の基本、みたいな所は何となく分かりましたが、これをWordPressの場合にどういう風にしたらいいのかが分からない。。

ひたすらググって、なんとかアテになりそうな情報を見つけました。 😮

Add a menu item to WordPress 3.5 Media Manager

こちらのページの情報が、今回のプラグインを作るための情報として一番の候補になり、この情報をもとにあーだこーだをひたすら、ひたすらやって、なんとかできました。。。。あー。

↑グチ、ここまでです。人間って言葉に出すだけで気が晴れる生き物ですね。私だけかな。。。

 

ここから、プラグインの使い方について記載しています。

 

使い方

いまのところ、WordPress 3.5 ~ 3.5.2 までの対応となっていますのでご注意ください。
(試してはいませんが、3.5未満はおそらく動かないと思います。3.5から画像挿入の機能が変わったはずなので。)

私のプラグインは基本、WordPress 3.4.2 からの対応をしているのですが、今回は対応させませんでした。

サポートフォーラムなんかで3.4.2への対応希望者がいれば、対応するかもしません。 😉

 

インストール方法は、プラグインインストールの画面から「Media Insert from Themes Dir」と検索すると、そのまんまのプラグイン名が出てくると思うので、それをインストールして有効化してください。

インストールした後、有効化しても画面上、何も変化もなく設定画面も存在しません。

ちょっとわかりづらいですが、これで使用可能な状態です。

 

投稿編集画面などで「メディアを追加」をクリックすると、「URLから挿入」の下に「テーマディレクトリから挿入」のメニューが追加されます。

メニュー追加部分
メニュー追加部分

 

「テーマディレクトリから挿入」を選択すると、現在選択しているテーマディレクトリ内の画像やフォルダを読み込み始めます。読み込みが完了すると、画像とフォルダ一覧が表示されます。

画像・ファイル一覧
画像・ファイル一覧

 

もちろん、サブディレクトリ内の画像も読み込みます。 🙂

あとはいつも通り、投稿に挿入したい画像を選んで、リンクをつけるなり整列を変更するなりして、「投稿に挿入」をクリックすると本文に挿入できます。

画像選択時
画像選択時

 

簡単に、テーマフォルダ内の画像を投稿に挿入できます。

 

どうぞご利用ください。

Media Insert from Themes Dir

外国人から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/