WordPress 4.2.x のマルチサイトトラブル…

WordPress 4.2 より絵文字が使えるようになって、それを早速試してみたのですが、エラーが出る場合があったのでその対処法と苦闘?を備忘録として書きました。

苦闘はどうでもいいからとりあえず試してみたい。 😥 という方は一番下までスクロールしてね。 😯

 

エラーについて

その時の環境は以下となります。

  • ローカル環境
  • Windows 8.1
  • XAMPP 1.8.1
  • Apache 2.4.3
  • PHP 5.4.7
  • MySQL 5.5.27

 

まず、WordPress4.2.2をいつも通り、データベースを作成して新規インストール。

https://codex.wordpress.org/Installing_WordPress

インストールOK。wp-confing.php にてデバッグモードをtrue、デバッグログを trueにしておく。

使ってみる。特にエラーは何もなし 😛

絵文字を使ってみる。やっぱり何もエラーなし。 😎

※Windows 8.1 でノートパソコンをお使いの方は、下にある、アプリケーションや時間等が表示されている「ツールバー」を右クリックして、「ツールバー(T)」> 「タッチキーボード」を選択すると、ツールバーにキーボードが表示されると思うので、そのキーボードから絵文字は入力できるようになっています。

 

で、問題はここから。

Announce from the Dashboard 等マルチサイト対応のプラグイン等もあるため、マルチサイトに変更して動作を試してみました。

Codexはこっち。http://codex.wordpress.org/Create_A_Network

うん、とりあえずマルチサイトになりました。

マルチサイト画面
マルチサイト画面

そして「サイト」>「サイトの作成」から、2つめのサイトを作成しようと思ったら…

サイトの作成
サイトの作成

む? 😕 画面上にエラーが出ました。。

Warning: preg_match() expects parameter 2 to be string, object given in wp-includes\formatting.php on line 3435
Warning: preg_match() expects parameter 2 to be string, object given in wp-includes\formatting.php on line 3424
Warning: preg_match() expects parameter 2 to be string, object given in wp-includes\formatting.php on line 3435
Warning: strip_tags() expects parameter 1 to be string, object given in wp-includes\formatting.php on line 3407
Warning: strip_tags() expects parameter 1 to be string, object given in wp-includes\formatting.php on line 3407
Catchable fatal error: Object of class WP_Error could not be converted to string in wp-includes\kses.php on line 1038

preg_matchに値が何も来ていないのかな?strip_tagsにも来ていないのかな?

色々推測してみましたが、結局原因は分からないので、とりあえず画面を戻ってみると、

サイト一覧
サイト一覧

サイトは作成できているっぽいです。細かいバグ?が何かあるのかな。

と思いつつ、作成した2つ目のサイトのダッシュボードにアクセスすると、なぜか404エラー。

 

 

ん?(´・ω・`)

 

.htaccessの問題?.htaccessファイルを確認するも、特に問題は無さそう…
さっきのエラー、多分関係あるな。。

さて、どこから原因を探したほうがいいかな。。ワカンネ(´ー`)

 

😕

 

他に問題がないか調べてみようと思い、新しく作成したサイトのデータを編集画面(ネットワーク管理画面内)から見てみましたが、ユーザーがいない。。

あれ、admin 足したけどな…WordPress4.2からブルートフォース対策とかでadminは足せないのかな?だとすると、初めからadminでユーザー作成できるのはおかしいから関係はないか。admin足せば問題ないのかな?

でもユーザーがいないからって、404エラーはないか。 🙁

細かいバグでは無さそう。。

次にサイトの編集設定を見ると…

サイト編集設定
サイト編集設定

設定できる項目が、サイトのアップロード領域のクォータ っていう項目しかない。。

え?なにこれ?サイトが上手く作成できていない? 🙄

 

他にエラーが無いか確認してみようと思い、次にwp-content/debug.logの中身を確認しました。

すると、かなりのエラー。。 😳

そして、画面を表示する度にこのエラー。

WordPress データベースエラー: Table '42.wp_3_options' doesn't exist for query SELECT option_value FROM wp_3_options WHERE option_name = 'home' LIMIT 1 made by WP_List_Table->display, WP_List_Table->display_rows_or_placeholder, WP_MS_Sites_List_Table->display_rows, get_home_url, get_option

doesn’t existって、テーブルが無いってこと?まさか~、そんな事今までにないよ?

サイト一覧にちゃんと作ったサイトがあるんだし。

で、phpMyAdminから確認してみました。

phpMyAdmin
phpMyAdmin

😈

うん。。。無いですね。(´・д・`)ゞ

これで問題は分かったけど、原因は何だろう。

今までこんなエラーは無かったので、WordPress4.2からのエラーかな。
エラー内容を見る限りでは、文字コード系かな~と推測。。

それからwp-config.phpの以下をにらめっこ。

/** データベースのテーブルを作成する際のデータベースの文字セット */
define(‘DB_CHARSET’, ‘utf8mb4’);

WordPress4.2からのエラーというのが気になって、もしかして最初にCodexを参考にデータベースを作成した時の文字コード utf8_unicode_ci が4.2以降では違うのかなと思い、今度はデータベースを作成する際に、照合順序ってのを utf8mb4_general_ci で作成して、同じくマルチサイト環境でサイトを作成してみましたが、だめでした。

しかも全く同じようなエラー。 😳

じゃあ文字コードじゃないのかな。。

ログファイルをにらめっこしていると、ほとんどのエラーが wp_2_****** のテーブルが無いよ!みたいなエラーだったので、そもそもテーブルが作れていない!?
ようなので、そこだけ注意してみてみると、

WordPress データベースエラー: COLLATION 'utf8_general_ci' is not valid for CHARACTER SET 'utf8mb4' for query CREATE TABLE wp_2_terms

あ、create table でデータベースエラーなのね。。 😳

utf8_general_ci is not valid ?え?どーゆーいみ?わっつ?( ´゚д゚)ン?

 

🙄

意味が分からなかったので、とりえあずサイト作成のコードを追う事にしました。

まずはURLの通り、wp-admin/network/site-new.phpをざっくり見る。

ざっくり見ると、分からない…なので、詳しく見る。 :mrgreen:

エラーが発生しているっぽい怪しいコードを発見。その上と下でごにょごにょ。色々試した結果、wpmu_create_blog()内が問題っぽい。

それをさらに追うと…insert_blog()はエラー無し。問題無さそう。
install_blog()はどうだろう…あ、エラーか。

またさらに追う。make_db_current_silent(‘blog’)直後にログにエラーが出る。

もっと追うと、dbDelta()でquery()を実行した時にエラー。テーブル作る際のクエリ内に多分問題あるのかな。 😐

クエリがたくさんあって、どれがエラーのクエリか分からないので、1つクエリを抜粋してphpMyAdminで試してみました。

CREATE TABLE wp_2_terms (
term_id bigint(20) unsigned NOT NULL auto_increment,
name varchar(200) NOT NULL default '',
slug varchar(200) NOT NULL default '',
term_group bigint(10) NOT NULL default 0,
PRIMARY KEY (term_id),
KEY slug (slug(191)),
KEY name (name(191))
) DEFAULT CHARACTER SET utf8mb4 COLLATE utf8_general_ci

あ、エラーなんだ。一旦、WordPressのエラーとデータベースのエラーのどちらなのかを判別するために、phpMyAdminにて直接クエリを実行。

phpMyAdminのレスポンスは以下。

#1253 - COLLATION 'utf8_general_ci' is not valid for CHARACTER SET 'utf8mb4' 

クエリの文法エラーではなさそう。これはWordPressでもPHPのエラーでもなく、MySQLでのエラーっぽい。
と、ここでやっとさっきのエラーの意味が少し分かりました。

あ、utf8mb4のエラーじゃなくて、COLLATION の utf8_general_ci っていう文字コードのほうで、エラーなのね。 😳

それで、COLLATIONってなに?で、ググってみましたが、、

http://dev.mysql.com/doc/refman/5.5/en/charset-connection.html

なるほど。。…ワカンネ(´ー`)

で、お次。

http://qiita.com/kazu56/items/6af85ffcf8d3954455ad

おぉ、これは少し分かりやすい!COLLATIONは文字コードの設定ではなくて、ソートする際の文字コード(照合順序)、みたいな意味合いっぽいですね。

で、問題は、そのソートする際の文字コードが is not valid かな。

おそらく、照合順序に utf8_general_ci なんていうものは無い又は、何かのバリデーションに通らない、みたいな意味かな。not valid って、意味が大きいな。。

さて、問題は何で not valid なんだろう。。 😐

まず、utf8_general_ci があるかどうか確認するために、phpMyAdmin から選ぶことができる照合順序を確認してみました。

ちゃんと utf8_general_ci はあるじゃん。スペル間違い?いや、そうでもない。

あれ、ちょっと待てよ…。WordPress4.2からmb4だから、utf8_general_ci 自体、違うんじゃないかな。。それとも、別の原因かな。

こういう時は、にらめっこ。 😎
さっきのテーブル一覧をにらめっこしていると…

phpMyAdmin
phpMyAdmin

😈

あれ、全部、テーブルの照合順序が utf8mb4_general_ci じゃないか! 😈
でもなんで新しいサイトのクエリは utf8_general_ci になる?
あ、これが原因?少し解決できそうな予感…。 😮

phpMyAdminから直接クエリを試してみます。
さっきエラーのあったコードの一部、COLLATIONの値を utf8_general_ci からutf8mb4_general_ci に変えてやってみました。

CREATE TABLE wp_2_terms ( term_id bigint(20) unsigned NOT NULL auto_increment, name varchar(200) NOT NULL default '', slug varchar(200) NOT NULL default '', term_group bigint(10) NOT NULL default 0, PRIMARY KEY (term_id), KEY slug (slug(191)), KEY name (name(191)) ) DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci

お!

おぉ!

うまくテーブルが作成できました。 🙂

これが原因!?

じゃあ、今度はWordPressで試してみようかと思い、COLLATION を指定しているところを探してみる。

wp_get_db_schema()にてCOLLATEとしているみたい。

もっと追ってみると、wp-includes/wp-db.php のinit_charset()にてCOLLATEを指定しているっぽい。

今はテストなので、とりあえずwp-db.phpに直接、COLLATEが utf8mb4_general_ci になるよう変更して、サイトの作成を試してみました、、、

🙂

 

うまくいきました!エラーは特になし。あ~疲れた(まだ早い)。 😆

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

うん、テーブルも上手く作成されているし、作ったサイトのダッシュボードにもいけますね。

これは、なんとか解決できたっぽい。

上手くサイトが作成できない時は、COLLATION (文字コードの照合順序)が違う為なのかな。

サーバごとに、COLLATIONが違っていればを変えればいいのか。

今はテストだからwp-db.phpに直書きだけど、簡単にサーバごとにCOLLATIONを変更するいい方法ないかな(´・ω・`)

で、さっきの init_charset() を見ていると、

} elseif ( defined( ‘DB_COLLATE’ ) ) {
$this->collate = DB_COLLATE;
}

お、どこかでDB_COLLATEを定義できるんだ。ー(‘∀’)ゞ

で、検索してみると…wp-config.phpにあるし。 👿
いつもこの辺はWordPressが自動で作成するからスルーしていました。 😉

/** データベースの照合順序 (ほとんどの場合変更する必要はありません) */
define(‘DB_COLLATE’, ”);

今まで一度も変更したことなかった。。こういう時に変更するんだね。 🙂

ってことで、ためしにdefine(‘DB_COLLATE’, ‘utf8mb4_general_ci’);として変更してサイトを作成してみましたが、うまく動作しました。:-o

 

念のため、もう一度試しました。

さきほど、データベースを作成する際の、照合順序の文字コードを変えていたので、一旦 Codex と同じ照合順序 utf8_unicode_ci にてデータベースを作成。

データベース作成
データベース作成

同じようにインストール&マルチサイト化。

照合順序の文字コードはいまこんな状態。

データベース: utf8_unicode_ci

各テーブル: utf8mb4_general_ci (どのタイミングでutf8mb4_general_ciになるんだろう…) 😕 

サイトを作成してみる。やっぱりエラー。

wp-config.phpにて

define(‘DB_COLLATE’, ‘utf8_unicode_ci‘);

に変更してサイト作成を試してみる。

同じようなエラー。ってことは、テーブルを作成する時の照合順序ではなくて、他のテーブルの照合順序と同じようにすればいいのかと思い、

define(‘DB_COLLATE’, ‘utf8mb4_general_ci‘);

で試すと上手くいきました。 🙂

 

追記

wp-config.phpのDB_CHARSETによって、utf8mb4_general_ciかどうかも変わるっぽいです。

DB_CHARSETutf8mb4 だったら、utf8mb4_general_ci

DB_CHARSETutf8 だったら、utf8_general_ciutf8_unicode_ci

 

 

参考にされる方へ。

同じようなエラーに遭遇した方は、wp-config.phpのDB_COLLATEを

define(‘DB_COLLATE’, ‘作成済みのテーブル wp_options とかの照合順序の文字コード‘);

みたいな感じで、一度試してみてください。

🙂

 

久しぶりにブログ更新… 😉

 

はまりました。。max_input_vars。

WordPressで様々なプラグインを導入すると、おのずとそのプラグインのメニューが増えたりしていきます。

私のプラグインは殆どが、管理画面をカスタマイズするものなのですが、プラグインで管理画面にエラーが出る場合には大抵、他のどのプラグインを有効化した時にエラーが出るのか、超地道にひとつずつ調べています。 😳

 

今回も、多分アメリカ?の方から「動かないよーどうなっているだYo! 😈 」とメールをいただき、「動かないのは分かったので、どういう設定をしているのか教えてYo! 😳 」をもっと丁寧な感じにした英語で返事をして、さっそく調べていました。

 

まずは出来る限り同じ環境へ

相手の方がお見せ出来る限りの環境(管理画面のスクリーンショットやプラグイン一覧画面等)を見せていただき、私もローカルサーバに同じように環境づくりをします。

WordPressのバージョンも同じバージョンにOK。プラグインの一覧・バージョンもOK。

で、さっそくやってみると…
はい、確かにエラーとなります。 🙁

でも、ここでやっかいに感じた部分。。
それは、「微妙に保存されている、ような、いないような 😕 」。。

まぁ、そんな事は後で考えようか。(本当は一番の原因に関係すること)

そして、一つずつぽちぽちと、プラグインを有効化して無効化、有効化して無効化… 😆
をやってみるのですが、どのプラグインの場合でも同じようなエラーがでました。 😕

ユーザー権限の問題だろうか。 😕

はたまたWordPressのバージョンが上がった時の何かの影響なのだろうか。 😕
と思い、バージョンダウンして試してみたりしましたが、これもやはりダメ。。

それからも色々試してみて、少し発見したことがありました。
「Woocommerceと何かを有効化すると、結構な確立でエラーが出る」という事でした。 😕

(誤解された方がいたらすみません、Woocommerceはエラーが良く出る。という訳ではありません。詳細は下記をお読みください)

 

って事は、Woocommerceの問題なのかな~と目星をつけ、またひたすらトライ&エラーの繰り返し。
それからまた分かった事は、「メニューの数が多い時だけ、エラーになる」という事でした。

(Woocommerceはたまたまメニューの数が多かっただけ)

 

ふーん。なるほど~。。わかりません。 😳

 

色々と設定をいじくり、なんとか画面にPHPのエラーが出るようにしました。

ログよりも、画面にエラーが出ると、どのタイミングでのエラーなのか分かりやすいです。 😮

 

で、そのエラー文をもとに色々とググっていると、phpmax_int_varsという設定にたどり着きました。

max_int_vars でぐぐると、ほぼ確実に同じような状況のエラーについて書かれた多くのブログがあります。
なるほど、フォームのアイテム数が指定した数よりも多すぎる。という事なんですね。

その数を指定する項目が max_int_vars。

しかもそれが、PHP 5.3.9 以降だなんて。。それは知らなかったよ。。 😥

 

かと言って、フォームの数を減らせばOK!

という解決策では上手くいかないので、どういう風にすればフォームの数を”PHP”上で減らす事が出来るかな~と試行錯誤すると、あっさり解決。 😐

 

原因がWordPressもしくはプラグインのほうにある。とばかり思い込んで原因を探っていたのでかなり時間取られました。。

色んな方面から原因を考えられるようにならねば。 🙄

 

Google Chrome のXSS仕様にはまる。

このページは、WordPressのプラグインを作成している方や、テーマ内のfunctions.phpより独自の設定管理を設けている方には参考になるのではないかと思っています。

もしかしたら私だけの影響かもしれませんが。

(その際はコメントフォームに何か一言言ってもらえると嬉しいです 🙂 )

もし試してみたいという方は、下記よりお試し下さい。
(ブラウザの影響と私は仮定しています。なのでブラウザが更新されて仕様が変わった場合は、別の動作になるのかもしれません。この現象はこの記事を書いている 2013年8月ごろの、とても暑い日が続く日の事です 😳 )

 

いきさつ

かなりの時間。はまりました。

とあるバグを報告してくれた方から、「あなたのプラグインでこの部分が設定できないよ。他は動くんだけどねとご報告がありました。

他は動く…?

ということは、動かない部分の記述や分岐が間違っていたりフックするタイミングや処理が間違っていたりするだろうな。と想定していました。

なので、そのような考えのもとで原因を探していました。

でもどれだけ試しても、バグの報告をしてくれた方と同じような状況にならず、想定通りの動作をしました。

う~ん、どうしたもんだろう。。とそういえば、以前動画ファイルでバグの症状を報告してくれた方がいました。

その方の動画を参考に、どのようなプラグインをインストールしているのかを調べ、できる限り同じような環境を作りました。

それで初めて、バグの症状が分かりました。

一言で言えば他プラグインの影響。と言ってしまえばそれまでですが。

しかし、有名なJetpackプラグインを使用している時、または WooCommerce Admin Bar Addition を使用している時のバグでした。
(どちらもプラグイン側のバグではありません)
 

で、色々と調べてみると

どうも、<form>タグ関係の場合だけ、バグが出るという症状でした。

どんどん調べていくと、結論としては、Google ChromeのXSS対策の仕様?と判断しました。 😳
正確にはプラグインの影響ではなく、そのプラグインの影響を可能にした場合の<form>タグ関連の影響でした。
(WordPressを一切使わず、シンプルなHTMLだけの場合でも試してみました)

これはプラグインうんぬんではなく、様々な場合に影響があると思っています。
「投稿」「固定ページ」等も含まれます。でも公開はできますが)

この症状を試してみたい方は以下をお試しください。

 

はじめに用意

試す方法として、まず用意するものが独自の設定画面。

できる限り他の影響を受けないようにする為にシンプルな設定にします。
テーマもプラグインも、WordPressをインストールしたばかりのデフォルトの状態が理想的です。

今回は簡単な設定ページを用意します。

まず設定ページを作成する為に、以下のコードをfunctions.phpなり、追記してください。

function ex_xss_menu() {
  add_menu_page( 'Example Xss' , 'Example Xss' , 'administrator' , 'ex_xss' , 'ex_xss_page' );
}
add_action( 'admin_menu' , 'ex_xss_menu' );

そして管理画面を読み込むと、設定の下のほうに「Example Xss」というメニューが追加されていると思います。(今はそのメニューをクリックしてもエラーが表示されます。まだメニューしか作成していないので。)

 

メニュー設置
メニュー設置

 

次にExample Xssの設定ページ作成用のコードです。先ほどのコードのところに追記してください。

function ex_xss_page() {
  if( !empty( $_POST["ex_text"] ) ) {
    update_option( "ex_text" , stripslashes( $_POST["ex_text"] ) );
  }
  if( !empty( $_POST["ex_area"] ) ) {
    update_option( "ex_area" , stripslashes( $_POST["ex_area"] ) );
  }

  echo '<div class="wrap">';
  echo '<h2>Example XSS Test</h2>';
  echo '<form action="" method="post">';

  echo sprintf( '<p>Input: <input name="ex_text" value="%s" style="width: 300px;" /></p>' , get_option( 'ex_text' ) );
  echo sprintf( '<p>Textarea: <textarea name="ex_area" rows="5" cols="10" style="width: 300px;">%s</textarea></p>' , get_option( 'ex_area' ) );
  echo sprintf( '<p class="submit"><input type="submit" value="%s" class="button button-primary" /></p>' , __( 'Submit' ) );

  echo '</form>';
  echo '</div>';
}

 

これでメニューをクリックすると、シンプルな設定ページが出来上がります。

設定ページ
設定ページ

 

あ、ここは重要です。

Google Chromeのコンソールを表示させておいてください。(キーボードのF12を押す)

コンソール表示
コンソール表示

コンソールで既にエラーが無いことを確認してください。エラーがある場合はそれなりに対処して、エラーが無い状態にしたほうがテストとしては理想的だと思います。

 

で、ここから。

バグとなってしまう症状を確認していきます。

作成した設定ページにinput text 、textareaの2つのフォームフィールドがあります。
どちらでもかまいませんが、何か、フォームを作成するように<form>タグを入力してください。サンプルとして私は以下のように入力しました。

フォーム入力例
フォーム入力例

で、送信ボタンを押して下さい。すると…なんと。

ちゃんとデータは保存されています。変な期待をした方ごめんなさい。 😳

でも、これは一回目の送信ボタンを押した時(一回目のデータ保存時)の動作です。

 

送信ボタンを押した直後、他のページに移動せずGoogle Chromeのコンソールを確認してみてください。

コンソール画面
コンソール画面

 

先ほどは何もエラーは表示されていませんでしたが、送信ボタンを押した直後にエラーが表示されます。しかし、入力したデータはきちんと保存されています

The XSS Auditor refused to execute a script in 'http://example.com/wp-admin/admin.php?page=ex_xss' because its source code was found within the request. The auditor was enabled as the server sent neither an 'X-XSS-Protection' nor 'Content-Security-Policy' header.

なにやらXSSに関してのエラー?注意?が出ていることが分かると思います。

 

ここが大事です。この状態でもう一度「送信」を押してみて下さい。

 

出ましたか?真っ白な何もない画面。アドレスバーにはabout:blank。 😯

Google Chrome だけ、このような仕様だとは全く予想していませんでした。

 

具体的には

あのコンソールの文章をもとに色々なブログを見て回って、私の個人的な考えですが、辺なコードを埋め込まれないようにする為の、Google ChromeのXSS対策処理ではないかと思います。

あ、Firefoxですか?バンバン保存できます。 :mrgreen:
それが良いのか悪いのかは別ですが。

ただ、もっと具体的にどのようなコードを記述すると、このような仕様になるのかを私なりに調べた結果、ひとつは分かりました。(多分、ひとつではなく複数あると思っています)

ちなみにその記述は、

action="

(アクション イコール ダブルクォーテーション)

調べた結果、フォームタグかどうかは関係が無いようでした。

action=”というような記述が問題の現象を引き起こしているようでした。

試してみたい方は、この記述をどこでもいいので記述してみてください。
「新規投稿」や「固定ページ」でも。あのコンソール文が表示されます。
(テキスト編集の場合です)

ただ、ちょっと面白いというか、これは良いのか? 😕 と思ったのですが、

action=''

このように記述すると、何のエラーも出ません。(全角ではありません)

違いは ダブルクォーテーションシングルクォーテーション か。それだけです。

なんでこんな仕様なんでしょうか。ちょっと分かりません。この記述は安全とみなされるのでしょうか。。ちょっとこの仕様に関しては理解が難しいです。  😕

ただ、やっとバグが出るタイミングがはっきりと分かりました。

この仕様が原因でプラグインの設定データが上手く保存出来ない。
という事に気づくまでに、ものすごく時間を取られました。 😳

 

うん、どう対処しようか。。

ダブルクォーテーションを正規表現の置換で強制にシングルクォーテーションに書き換えようか。または「Google chrome、今のところ上手く動きません」と表示させようか。(これは最終案…)

 

解決方法として

私なりに色々と調べた結果、X-XSS-Protection というヘッダーの値を 0 として出力するという事でした。
おそらく、「お願いだからXSSのフィルターチェックしないでね!」というサーバからの意思表示的な意味合いだと私は考えています。

先ほどのエラー文にはこう書いています。

The auditor was enabled as the server sent neither an 'X-XSS-Protection' nor 'Content-Security-Policy' header.

翻訳内容はおそらく、

サーバ管理者(auditor)は’X-XSS-Protection’ または ‘Content-Security-Policy’ヘッダーのどちらかをサーバから送信することができます。

このような意味だと解釈しました。どちらのヘッダーでも良さそうだったので、とりあえず今回は X-XSS-Protection ヘッダーを送信することにしました。両方送信したらどうなるんだろう?

 

じゃあこれをどのタイミングで出力すればいいんだろうと思って色々情報探してみました。

https://gist.github.com/ocean90/3622298

あ、wp_headers なるフックがあるんですね。今回はこの作者のコードをパクって参考に試してみます。 😉

function ex_xss_add_header( $headers, $object ) {
  $headers['X-XSS-Protection'] = 0;
  return $headers;
}
add_filter( 'wp_headers', 'ex_xss_add_header', 10, 2 );

これで無事、action=”を入力しても動作するようになりました。

 

※このコードを使おうと考えた方へ

このままの状態では注意が必要です。

このままだと、アクセスしたページ全てのヘッダーで’X-XSS-Protection’が出力されるので、事前に何かしら条件分岐の処理(管理画面のこの設定画面のこのデータが送信された時等)をしたほうが安全の為に良いと思います。

 

 

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

 

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

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

めでたしめでたし  🙂

外国人から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が含まれているので安心して使えそうです。

 

 

今話題のブルートフォースアタックの対策 (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文字ぐらいなら、どれくらいの時間が掛かるんでしょうか。

 

追記

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

 

 

管理画面サイドメニューにカテゴリ内記事一覧のメニューを

カテゴリを作成して、記事にカテゴリ属性を付けることはよくありますね。

で、その作成したカテゴリ内の記事一覧を、管理画面から見る方法としては、

「投稿一覧」 から 指定のカテゴリを選択して絞込み検索をする事でできます。

投稿一覧カテゴリ選択部分
投稿一覧カテゴリ選択部分

訳あって、そういう機能を使いたくない。いちいち絞込み検索するまでの流れが面倒。

という方もいると思います。最初からサイドメニューに作成したカテゴリの記事一覧メニューが表示されて、クリックするだけでその記事一覧が表示されるように。

今回は、それをやりたいと思います。

 

ゴールとするメニューの例

「投稿」メニューと、「メディア」の間にカテゴリ一覧が表示されるようにしていきます。

ゴール
ゴールとするメニュー例

 

まずはカテゴリ一覧を取得。

の前に。まずはフックさせます。

管理画面のメニューに追加する事は決まっているので、ご自身のテーマのfunctions.phpにて、admin_menuにアクションを追加します。

add_action( 'admin_menu' , 'my_admin_menu' );

今回は適当に、my_admin_menuという関数を用意する前提です。で、関数を用意。

function my_admin_menu() {

}

この関数内でカテゴリ一覧を取得したりメニューを追加したりしていきます。

 

じゃあまずは、カテゴリ一覧を取得

$args = array( 'hide_empty' => 0 );
$categories = get_categories( $args );
print_r($categories);

で、カテゴリ一覧が出力されます。表示が変にはなりますが、今はカテゴリを取得する事が目的なので、それは無視してください。

get_categories 出力結果
get_categories 出力結果

このカテゴリが表示されている順番の通りに、メニューが作成されることになりますので、順番を変更したい方は今のうちに順番を変更してください。

get_categories()については関数リファレンス/get categoriesを見てパラメータを設定すれば順番を変更できます。

ここまでで、カテゴリ一覧が取得できたらprint_rは消して下さいね。

 

管理画面サイドメニューへの追加

メニューへの追加方法は、add_menu_pageで追加する方法とglobal $menuを使って追加する方法の2種類は知っています。

どの方法でやろうかと考えましたが、今回は「カテゴリ一覧メニューの上下に、セパレーター(区切り線)も設置」するので、グローバル変数の$menuを使って追加していきます。

まずはこれを。

global $menu;
global $submenu;

print_r($menu);

どうですか?とりあえず上手く出力できましたか?

$menu 出力
$menu 出力

次に、この出力を「HTMLソース」から確認してください。

htmlソース
htmlソース

今回は「投稿一覧」と「メディア」の間に追加する予定です。配列のキーを見ると、投稿は5、メディアは10となっているのが分かると思います。このキーの小さい順に、wordpressの管理画面のサイドメニューは表示されているので、今回は7ぐらいのところにカテゴリ一覧のメニューを表示させたいと思います。

$slug = 'edit.php?cat=' . $categories[0]->cat_ID;
$menu[7] = array( $categories[0]->cat_name , 'edit_posts', $slug , '' , 'menu-top menu-icon-post', 'menu-posts-cat' );

カテゴリ一覧で取得した最初のカテゴリを親メニューとしました。

親メニュー設定
親メニュー設定

確かに、記事一覧は指定のカテゴリの記事のみが表示されました。しかし、このままではメニューが「投稿」「投稿一覧」のままです。現在のページが、

edit.php?cat=*

ではなく、

edit.php

として認識されているようです。

なので、この部分を変更する為に、グローバル変数 $parent_file を変更します。

変更する為には現在のフックポイントとは別にフックしなければいけないので注意。

function edit_parent_file() {
 global $parent_file;
 global $current_screen;

 if( $current_screen->base == 'edit' && isset( $_REQUEST["cat"] ) ) {
 $args = array( 'hide_empty' => 0 );
 $categories = get_categories( $args );
 $parent_file = 'edit.php?cat=' . $categories[0]->cat_ID;
 }
}
add_action( 'admin_head', 'edit_parent_file');

これで、現在のメニューの設定が効くようになります。

現在のメニュー
現在のメニュー

この調子で、サブメニューも作成していきます。

先ほどのmy_admin_menu関数内にサブメニュー用に以下を追加。

foreach( $categories as $key => $cat ) {
 $slug_s = 'edit.php?cat=' . $cat->cat_ID;
 $position = $key + 1;
 $submenu[$slug][$position] = array( $cat->cat_name , 'edit_posts', $slug_s , '' , 'menu-top menu-icon-post', 'menu-posts-cat' );
 }

これで、サブメニューができました。

サブカテゴリー
サブカテゴリー

が、またしてもサブメニューを選択しても、サブメニューが選択状態にならない。。

どうやら、グローバル変数 $submenu_file も少し変更しないといけないようですね。

先ほどのedit_parent_fileを少し変更して、

function edit_parent_file() {
 global $parent_file;
 global $submenu_file;
 global $current_screen;

 if( $current_screen->base == 'edit' && isset( $_REQUEST["cat"] ) ) {
 $args = array( 'hide_empty' => 0 );
 $categories = get_categories( $args );
 $parent_file = 'edit.php?cat=' . $categories[0]->cat_ID;
 $submenu_file = 'edit.php?cat=' . intval( $_REQUEST["cat"] );
 }
}
add_action( 'admin_head', 'edit_parent_file');

$submenu_file にあたる部分を追加しました。

これで、完成ですね。

サイドメニュー
サイドメニュー

 

すっかり忘れていました。区切り線を作成したメニューの上下に入れるのを。

$separator = array( '' , 'read' , 'separator' , '' , 'wp-menu-separator' );
$menu[6] = $separator;
$menu[8] = $separator;
ksort($menu);

※ちなみに、ksortを実行しないと、なぜか上下に区切り線が出ませんでした。

 

 

何度かコードを追加したりして分からなくなってきた方もいるかもしれませんので、コードを下記に記載します。

 

functions.php

function my_admin_menu() {

 $args = array( 'hide_empty' => 0 );
 $categories = get_categories( $args );

 global $menu;
 global $submenu;

 $slug = 'edit.php?cat=' . $categories[0]->cat_ID;
 $menu[7] = array( $categories[0]->cat_name , 'edit_posts', $slug , '' , 'menu-top menu-icon-post', 'menu-posts-cat' );

 foreach( $categories as $key => $cat ) {
  $slug_s = 'edit.php?cat=' . $cat->cat_ID;
  $position = $key + 1;
  $submenu[$slug][$position] = array( $cat->cat_name , 'edit_posts', $slug_s , '' , 'menu-top menu-icon-post', 'menu-posts-cat' );
 }
 $separator = array( '' , 'read' , 'separator' , '' , 'wp-menu-separator' );
 $menu[6] = $separator;
 $menu[8] = $separator;
 ksort($menu);
}
add_action( 'admin_menu' , 'my_admin_menu' );

function edit_parent_file() {
 global $parent_file;
 global $submenu_file;
 global $current_screen;

 if( $current_screen->base == 'edit' && isset( $_REQUEST["cat"] ) ) {
  $args = array( 'hide_empty' => 0 );
  $categories = get_categories( $args );
  $parent_file = 'edit.php?cat=' . $categories[0]->cat_ID;
  $submenu_file = 'edit.php?cat=' . intval( $_REQUEST["cat"] );
 }
}
add_action( 'admin_head', 'edit_parent_file');

英語のサイトは難しすぎ…。

先日、WP Admin UI Customizeプラグインの専用サイトを作り、公開しました。

そのサイト内では、このプラグインを使って出来る機能を、画面のキャプチャを主に使って説明しています。

これだけでも少し疲れましたが…

英語のサイトってこんなにも難しいなんて。。

しかも英語が合っている気がしない。

そこは気にしない。(ことに…)

いまだに to、for、の違いがよく分からない。。

 

しかし、みなさん多言語サイト作る時ってどうやって作っているんでしょうか。

私の場合は、Wordpressのマルチサイト機能を利用して、

  • 親サイト(英語)
  • 子サイト(日本語)

という風にし、あとはGoogle Transrate バーを設置して好みの翻訳してねという感じにしました。

(翻訳のプラグインは様々ありますが、私は普段、外人からのサポートフォーラムへの返事で、GoogleとWeblio両方の機械翻訳をなんとか駆使して返事しているのですが、最近は機械翻訳の結果のままで返事を出す事はまずなくなりました。なので、機械翻訳プラグインは使わない事にしました。
この辺は好みかな。)

 

こちらも参考に。

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

 

マルチサイトって大変ですね。 😯

後々考えたら、通常サイトで英語投稿ページ専用ユーザーと日本語投稿ページ専用ユーザーの2種類作ってそれぞれの言語ページを投稿していけばいいんじゃないかとも思いました。

結局は、2種類の言語の記事を作る為に、どの方法が作りやすく運用しやすいかってトコですね。

 

ついでに、マルチサイトアドオンを販売しているので、Paypalのデジタルチェックアウトを使用していますが。

かなり難しかったです。ただ、料金を決めてチェックアウトボタンを設置、という場合なら簡単かもしれませんが、購入者に使用するサイトのドメイン・パスを入力させる画面を設ける必要があり、この入力画面をどの段階で入力させるべきか、どの段階なら入力させることができるのか

最近その疲れがやっと、取れた感じ。

 

ぼちぼちこのブログも更新していきます。

コメントからプラグインへの要望もありましたので、検討していこうかな。