タグ: マルチサイト

  • WordPress Plugin Custom Options Plus Post in Version UP 1.3.1

    WordPress でオプション値を手軽に作成できる

    Custom Options Plus Post In

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

    最新バージョンは 1.3.1。

     

    やったこと

    作成したカスタムオプション値を管理しやすくなるように、カテゴリを作成できるようにしました。

    カテゴリー作成
    カテゴリー作成

    100個カスタムオプション値を作成した場合に、カテゴリ別で10個ずつ分けることが出来る。みたいなイメージです。

    あとは、管理しやすくなるように「メモ」を作成できるようにしました。

    ~用のカスタムオプション値。

    とか、

    ~までのカスタムオプション値でいついつから~に変更予定。

    などが書き込めるようになっています。

    あと、マルチサイトで各サイトで使用できるように対応しました。

     

    ダウンロードはこちら

    http://wordpress.org/plugins/custom-options-plus-post-in/

     

    実は、この「カテゴリー作成」の機能自体は私の案ではなく、とある外国の方からの問い合わせから機能追加をすることになりました。

    下記にそれまでのいきさつを書きました。

    気になる方は宜しければお読みください。 🙂

     

    いきさつ

    とある外国の方(多分イギリスの方)から問い合わせフォームにて「~省略~ メインカテゴリで分けたい」と問い合わせがありました。

    メインカテゴリ?Parent? Child? (省略部分に書いていました)

    そんな機能をつけた覚えはありません。

    なので「WordPressのカテゴリーと連携させたいのかな?」と考えたり、「ページのように親と子の属性をつけれるようにしたい」という事なのと考えてみました。

    どちらにしてもはっきりとなんの事を言っているのか分からなかったのですが、一つだけはっきりと分かることがありました。

    I have 1,000s of items

    驚きました。そんなに使ってくれていたんですね。嬉しいです 🙂

     

    言っていることを理解する為に、実際に1,000個、カスタムオプションを作成して試してみました。すると…

    すこぶる表示が遅い。あと、例えば628番目のカスタムオプション値を編集する為にものすごく時間と手間がかかる。

    という事が分かりました。あ、おそらくこれを何とか解決したいのかな?と言っているのではないかと思いました。

    でも確証はなく、私の英語力では、これだけの理解が限界でした。。 🙁

     

    なので、

    I was surprised, That you have the items of 1,000. 

    I’m sorry, I could not understand the some mean of you said.
    >parent/child collapsible lists
    >main categories
    What does this mean?

     

    こんなニュアンスです。

    それは驚きました、1,000個もアイテムがあるなんて。

    すみません、あなたの言ったことが私は理解できませんでした。

    これらはどういう意味ですか?

    英語が合っていればこのような意味になるはずです。

    とりあえず、こう返事をしました。

    それから返事をいただき、返事のメールの中にスクリーンキャプチャが入っていて、「こうしたい!」という書き込みがあり、相手が何を求めているのかとてもよく分かりました。 🙂

    それから色々と試行錯誤をして、相手の求めている内容とはちょっと違う形で提案してみました。(今回のカテゴリーの作成機能の事)

    それで返事に、「良かったらメールに添付した、開発バージョンのプラグインを使ってみてください」と書き、プラグインを一緒に添付して送りました。

    返事が届き、

    It works well on empty test server.
    Does not work when put on live server.

    こう書いていました。翻訳内容はおそらく、

    まっさらのテストサーバ上では上手く動作します。

    ライブサーバ(実際のサーバ)の時は動作しません。

    という事だと思います。

     

    余談ですが、日本で言う”本番サーバ”のことを、海外(アメリカ&ヨーロッパ系&オーストラリア)の方はよく live server という呼び名をしている事が多く感じます。直訳すると”生きるサーバ”。

     

    あ、おそらく上手くアップデート出来なかったのか。アップデートの仕方を教えていなかった。。

    このプラグインは、プラグインを有効化した時にデータベース上にテーブルを作成するように作っていたので、おそらく有効化したままプラグインを新しいもので上書きしたものだと考えました。

    なので、カテゴリー用のテーブルがlive サーバで作成されず、上手く動作しない。

    上手く動作するように、「こういう風にアップデートをお願いします」とご返事し、それから返事をいただくと、

    THANK YOU!!!!!!!!!
    It is brilliant!!!!!!!!!!!!!!!!!

    おぉ、びっくりマークいっぱいです 😯

    このびっくりマークの数は今までの記録でダントツです 😎

    そんなことはおいといて、上手く動作してくれて良かったです。 😮

    これで一件落着と思い、近いうちこのアップデートをしようかなと思いながらメールを読み進めていると、

    Send me your paypal account number and I will "buy" your plugin.

    ん?

    私はあなたのプラグインを”買う”のであなたのPaypalアカウント番号を送ってください。

    んん?これは全く予想外でした。本当ですか?まさかぁ~ 😉

    と思いつつも、本当だったら嬉しいな 😀

    そんな気分で、Paypalの情報を送りました。すると…。

    I have sent you £50.00 by paypal as this is so useful to me.

    またまた~そういう人よくいるんですよ~。 😎

    あ、でも will が書かれていない。(will = ~する予定)

    と思ったらすぐにPaypalからもメールがあり、本当に送金されていました。

    うそ。はやっ!いや、嘘じゃないほうがいいです。

    いやぁ、とても嬉しいです! 🙂

    初めて見た、この単位は何なんでしょう?ユーロ?50ユーロっていくら?まぁ金額は後から調べればいいや!とにかく、その気持ちがとても嬉しかったです! 😛

     

    と、実はここでひとつ、どうしたらよいのか分からない事がありました。それは、

    Could you email a simple invoice to me for £50.00

    翻訳すると、

    私に simple invoice(請求書)をメールで送ってください。

    請求書?多分イギリスの方、向けの請求書?

    イギリス向けの請求書なんて一度も作ったことが無いので、どのようにしたら良いのか分かりませんでした。 😕

    とにかくググりました。。ググればググるほど、色んな情報やサンプルは出ますが、合っているかが分かりません。(インターネットのはがゆいと感じる所) 😐

    まいったな~

    OpenOfficeでそれっぽく作ってみたけど、これでいいのかな~

    分からないから一度送ってみて、間違いや不足している部分は指摘してもらおうかな~ 😕

     

    ん?待てよ?

    Paypalって決済システム的なものだから、請求書も送ることが出来るんじゃないだろうか?

    調べてみると、あっさり。ありました。このググった時間は一体何なんだ 😳

    それからPaypal経由で請求書を送ることができ、これでひとまず安心。メールで「この請求書で不足や問題があればご連絡お願いします。」と付け加えました。

    ただ、私なりの問題がひとつ残りました。それは、

    この方は、プラグインを“買う”と言ってくれました。
    じゃあ今回のこの機能は、アップデートせずにこの方専用の機能としたほうがいいのではないだろうか?

    買ったものが、後で無料で公開されたら、買った意味が無いですよね。

    でも、この方専用だと、どうやって今後この方のプラグインをアップデートさせようか。。

    かなり悩みました。

    考えて、考えて、、考えて、、、分かりません。 🙁

    なので一つの決断として、買ってくれたこの外国の方に判断してもらおうと考えました。

    Do you not want to update this category feature for WordPress.org to CUSTOM OPTIONS PLUS POST IN?
    I am thinking of which to update.

    かなり英語が間違っている気がします。でも、他に言い方が分かりません。

    言いたい事は、

    あなたはカテゴリー機能をWordPress.orgのCustom Options Plus Post Inにアップデートして欲しくないですか?

    私はアップデートしようか考えています。

    という感じです。

     

    そしてその返事は、

    I don't understand your other comment.

    おふっ。そうでしたか。。理解出来なかったんですね。英語頑張ります。。 😳

    ただ続きがあり、

    But I think you are asking should you update your plugin with these changes.
    I think you should.

    翻訳はおそらく、

    しかし、私はあなた(gqevu6bsiz)がこの変更をアップデートして良いかどうか尋ねていると考えました。

    私はすべきだと考えます。

    という意味だと解釈しました。多分、私の言いたい事が理解していただけたと思います。

     

    と、このカテゴリー作成の機能を追加する迄に実はこのような流れがありました。

    この方からも良い返事をいただいたので、そのままカテゴリー作成の機能を追加する事にしました。

     

    開発支援となり、励みとなり、このような方達には本当に感謝です!ありがとう! 😛

     

     

  • 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 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/