世界最高峰の高機能・スケーラブルなWordPressディレクトリプラグイン
GeoDirectoryは、スケーラブルなビジネスディレクトリ、シティガイド、不動産物件情報、求人ボード、イベントサイト、クラシファイド、地域情報プラットフォームを構築するためのエンタープライズグレードのWordPressプラグインです。汎用のリスティングプラグインとは異なり、WordPressのポストメタではなく専用データベーステーブルを使用しているため、小規模なローカルポータルから数十万〜数百万件の掲載情報を持つディレクトリまで、優れたパフォーマンスを発揮します。主な機能として、最適化された検索、マップ、レビュー、フロントエンド投稿、そしてカスタマイズのための豊富なアドオンエコシステムを備えています。WordPress.orgおよびCapterraにおける700件以上のレビューで4.8/5の高評価を獲得しています。
GeoDirectoryを入手するGeoDirectoryでできることは？
Advanced Custom Fields は、数百万人に利用されている優れたプラグインで、WordPressをフルスタックCMSへと変貌させ、無制限のカスタムフィールドグループやタイプを作成し、あらゆる種類のカスタム投稿タイプに追加することができます。
しかし、Advanced Custom Fieldsのスケーラビリティの限界についてはあまり知られていません。
GeoDirectoryがリスティングのカスタムフィールド管理にAdvanced Custom Fieldsを使用しているかどうか、よく質問を受けます。
GeoDirectoryには独自のカスタムフィールドシステムが搭載されていると答えると、なぜ「車輪の再発明」をしたのかと疑問を持たれます。
私たちにとって答えは明白で、Advanced Custom Fieldsのスケーラビリティはディレクトリ構築においてかなり限界があります。
しかし、ユーザーとして利用している方々は、内部で何が起きているか、そしてウェブディレクトリが抱えるスケーラビリティの課題を把握していないのかもしれないと考えました。
そんな折、あるところで投票を見かけました。それは Facebookの人気WordPressグループで行われていたもので、「最高のディレクトリ」に投票する選択肢には、GeoDirectory、人気マーケットプレイスで入手できるいくつかのディレクトリテーマ、そしてACF + FacetWP.
という選択肢もありました。結果を見て私たちは驚きを隠せませんでした。ACF + FacetWPが予想をはるかに上回る票を獲得していたのです。
投票した方々は一般ユーザーではなく、ウェブ開発者やWordPressの専門家であるはずでした。
そこで、ディレクトリにAdvanced Custom Fieldsを使うべきではない理由を説明する時が来たと判断しました。
また、顧客に対して高速でスケーラブルな、持続的な成長が可能なソリューションを提供することを重視しないWeb開発者でない限り、そのソリューションを誰にも提案すべきでない理由についても説明します。
WordPressカスタムフィールドのスケーラビリティの限界
WordPressはデフォルトで、カスタムフィールドのデータをwp_postmetaデータベーステーブルに保存しており、投稿内で使用されるカスタムフィールドごとに1行が作成されます。
それに加えて、WordPressは各投稿についてこのテーブルに多くの追加データを書き込み、それぞれがテーブルの1行を使用します。
SQLクエリの最適化に時間をかけたことがある方なら、ディレクトリやフィルタリングのような用途にとって、それが理想的な状況ではないことはよくご存じでしょう。
実際、デフォルトのデータベース構造は、多数の投稿やカスタムフィールドを持つウェブサイトにとって、大きなボトルネックになる可能性があります。
これはWordPressの弱点の一つとされています。
カスタムフィールドで投稿をフィルタリングするには、クエリ内でwp_postテーブルとwp_postmetaテーブルを結合しなければならないからです。
テーブルが大きくなればなるほど、クエリは遅くなります。
さらに最悪なのは、2つのメタ値でフィルタリングしたい場合、1つのクエリで処理するにはpost_metaテーブルを2回結合する必要があることです。
これはシステムメモリを消費し、小規模なディレクトリ以外では処理速度を著しく低下させる可能性があります。
Advanced Custom Fieldsのスケーラビリティの限界
Advanced Custom Fieldsプラグインは、投稿数・ページ数・カスタムフィールド数が少ないまたは中程度のウェブサイトには最適です。
しかし、ごく一部の例外を除き、ディレクトリはまさにその逆です。
ディレクトリは非常に多くの投稿を持ち、カスタムフィールドの数も膨大になる可能性があります。
Advanced Custom Fieldsのスケーラビリティにおける主な問題は、リスティングに追加されたカスタムフィールドごとに、データベースのwp_postmetaテーブルに2行が作成されることです。
また、プラグイン自身の設定に関するpostmetaの行もいくつか追加されます。
つまり、デフォルトのWordPressカスタムフィールドシステムを使用する場合と比べて、データベースのwp_postmetaテーブルに2倍以上の行が追加されることになります。
この問題をより分かりやすく説明するために、簡単なテストを行いました。
新しいWordPressウェブサイトを作成し、「Hello World」投稿とサンプルページを削除した上で、Advanced Custom Fieldsをインストールしました。
1つのグループと5つのカスタムフィールドを作成し、その5つのカスタムフィールドを使用した投稿を3件公開しました。
この時点で、wp_postmetaテーブルにはすでに83行が存在していました。
これは驚異的な数字です。
300,000件のリスティングと5つのカスタムフィールドを持つディレクトリでは、一体何行になるか想像してみてください。
ACFを使用すると、wp_postmetaテーブルの行数は最低でも3,000,000行になります
GeoDirectoryはどのようにスケールするのか？
とてもシンプルです。カスタム投稿タイプごとに専用のカスタムテーブルを作成しています。
例：wp_gd_gd_place_detail
このテーブルには、すべてのカスタムフィールドとそのデータを、投稿ごとに1行で保存しています。
また、WordPressがデフォルトのwpデータベーステーブルを操作するための独自のPHP APIを持つように、私たちもカスタムテーブルを操作するための独自のPHP APIを構築しました。
つまりGDは、ほとんどの場合、投稿テーブルと自社テーブルをJOINするだけで済みます。
その結果、任意のカスタムフィールドで結果をフィルタリングできます。
たとえば20個のカスタムフィールドでフィルタリングする場合、ACFではfacetWP（処理を高速化しますが、コアの制限は残ります）を使っても、1つのクエリで同じ処理を行うために複数のテーブルを何度もJOINする必要があり、同じクエリに対して何倍ものサーバーメモリを消費します。
まとめ
GeoDirectoryをWordPressまたはWP + Advanced Custom Fieldsと比較すると、次のことがわかります：
WordPress
1) フィルタリングしたいカスタムフィールドごとに、追加のテーブルJOINが必要になる。
2) wp_postmetaはすぐに肥大化し、クエリの速度が低下する
WP + ACF
1) フィルタリングしたいカスタムフィールドごとに、追加のテーブルJOINが必要になる。
2) wp_postmetaのサイズがWordPress単体と比べて2倍になる
GeoDirectory
1) JOINは不要
2) GDはwp_postmetaに情報を追加しないため、不要な肥大化が生じない。
3) 掲載情報を保存するデータベースは、投稿ごとに1行のみカウントする
WordPressはデータの保存方法にこの制限があることで知られています。ほとんどの場合、このシステムは問題なく機能しますが、大規模なディレクトリとなると、適切なソリューションとは言えません。
だからこそGeoDirectoryを使えば、数百万件の掲載情報を持つディレクトリを作成できます。一方、WP + Advanced Custom Fieldsでは、深刻なパフォーマンス問題が現れ始める前に作れるディレクトリは、せいぜい数百件止まりでしょう。
これらは、GeoDirectoryにAdvanced Custom Fieldsを使用しないと決めた理由となるスケーラビリティの限界であり、あなたも使用すべきでない理由です。
ご質問があれば、下のコメント欄でお気軽にどうぞ。
WordPress のローカライゼーション機能を使用すると、WordPress 言語ファイル（po/mo ファイル）を通じてプラグインやテーマを簡単に翻訳可能にすることができます。
これは特に WordPress 3.7 以降に当てはまり、 WordPress 4.6.
WordPress の翻訳システム全体に多くの改善が加えられたため、改めて記事を書く必要があると感じました。
WordPress 言語ファイル – 混乱の整理（開発者編）
開発者にとっての課題は、翻訳ファイルの存在を WordPress に正しく伝える方法です。
開発者として、"load_plugin_textdomain()" を使用し、プラグインフォルダー内の言語ファイルを指定するよう言われてきました。
しかし以前は、WordPress がファイルを探す場所はそこだけであり、 ユーザーが独自の言語ファイルをそこに追加しても、次のアップデート時に消えてしまっていました！
以前、Web 上の記事で "load_textdomain()" 関数を使って WP 言語フォルダー内のファイルを指定する 2 回目の呼び出しを使用する方法が紹介されており、多くの人（私たちを含む）がその方法を採用しました。
これにより、ユーザーは WP 言語フォルダー内の所定の場所に言語ファイルを配置でき、プラグインのアップデート時に翻訳が失われることがなくなりました。
WordPress 言語ファイル – 混乱の整理（ユーザー編）
ユーザーはプラグイン／テーマのカスタム翻訳をどこに置けばよいかを知る必要がありますが、以前はその場所が複数存在していたため、問題が生じていました。
WP のドキュメントでは、プラグインフォルダー内の「languages」というフォルダーにリンクするよう開発者に案内していますが、開発者によっては「lang」というフォルダーを使用している場合があり、 さらに、プラグイン／テーマが更新されるとその設定が失われてしまいます。
開発者によっては、独自に選んだ場所に2つ目のチェックを追加することもありましたが、多くの場合は WP の languages フォルダー内のカスタム名フォルダーに配置されていました。
そのため、カスタム翻訳ファイルを安全に置く場所をユーザーが一貫して把握する方法がありませんでした。
正しい方法で言語ファイルを読み込む（2017年）
WP 4.6 以降、ユーザーにとっても開発者にとっても、この作業は格段に簡単になりました！
開発者としては、以下の WP ドキュメントに従い、言語ファイルを正しく読み込んでいることを確認するだけで済みます。
<br />
// for plugins<br />
add_action( 'init', 'myplugin_load_textdomain' );<br />
function myplugin_load_textdomain() {<br />
load_plugin_textdomain( 'my-plugin', false, basename( dirname( __FILE__ ) ) . '/languages' );<br />
}<br />
<br />
// for themes<br />
add_action( 'after_setup_theme', 'my_theme_setup' );<br />
function my_theme_setup(){<br />
load_theme_textdomain( 'my-theme', get_template_directory() . '/languages' );<br />
}<br />
'init' および 'after_setup_theme' フックでこれらを実行していることに注意してください。こうすることで、すべてがスムーズに読み込まれるはずです。
直接実行したり、それぞれのフックより前に実行したりすると、一部の文字列が翻訳されないといった問題が発生したり、WPML などの翻訳操作や多言語サイト作成用プラグインがまったく機能しなくなる場合があります。
ユーザーとしては、言語ファイルを置くための便利で一貫した名前の場所が用意されるようになりました。
- プラグインの場合： /wp-content/languages/plugins/my-plugin-en_US.mo
- テーマの場合： /wp-content/languages/themes/my-theme-en_US.mo
「my-plugin」と「my-theme」はプラグイン／テーマのテキストドメインです（通常、プラグインの readme.txt またはテーマの style.css の先頭に記載されています）。
これは従来の方法から大きく改善されており、ほとんどの場合、更新時に翻訳が失われるのを防ぐことができます。
場合によっては、wp.org に保存されているあなたの言語の新しい翻訳がプラグイン／テーマにすでに含まれていることがあり、その場合は .mo ファイルが上書きされる可能性がありますが、ほとんどの場合それは意図した動作です。
プラグインが wp.org でホストされている場合は翻訳に貢献することができます。プレミアムプラグインの場合は、上書きされる可能性はほとんどありません。
ボーナス情報
WordPress は、テキストドメイン「my-plugin」を持つプラグインの言語ファイルをいくつかの場所から探します。まず最初にここを確認します：
/wp-content/languages/plugins/my-plugin-en_US.mo
そこに翻訳が見つからず、プラグインがローカルのパスを指定している場合は、そちらを確認します：
/wp-content/plugins/my-plugin/languages/my-plugin-en_US.mo
プラグインがパスを指定していない場合、WordPress は代わりにここを確認します：
/wp-content/languages/my-plugin-en_US.mo
WordPress のドキュメントに従うことが推奨されますが、実際のところ WP 4.6 以降では、翻訳ファイルをローカルに含めない場合（wp.org リポジトリに保存されている場合）、ローカルファイルを指定する必要すらありません。次のように追加するだけで大丈夫です：
<br />
// for plugins<br />
add_action( 'init', 'myplugin_load_textdomain' );<br />
function myplugin_load_textdomain() {<br />
load_plugin_textdomain( 'my-plugin');<br />
}<br />
<br />
// for themes<br />
add_action( 'after_setup_theme', 'my_theme_setup' );<br />
function my_theme_setup(){<br />
load_theme_textdomain( 'my-theme');<br />
}<br />
これで翻訳についての理解が少し深まれば幸いです。ご質問や追加したいことがあれば、ぜひ下のコメント欄にお書きください。
2019年9月更新
この機能はV 2.0.0.67の定義済みカスタムフィールドとして追加されました。以下のスニペットはGeoDirectory V1を使用している場合にのみ機能します。
問題の背景
あるメンバーから少し変わったリクエストがありました。彼らはGeoDirectoryを使ってローカルフェスティバルを運営しており、宿泊施設などをリスティングしています。リクエストの内容は、各リスティングからメインイベントまでの距離を表示することで、ユーザーが各リスティングからイベントまでの距離を明確に把握できるようにしたいというものでした。私自身も、1か所に特化した自分のサイトで同様のことをしています。空港までの距離と中心市街地までの距離をリスト表示しているのですが、これまではユーザーに手動で距離を入力してもらっていました。入力が間違っていることも多く、その都度修正が必要でした。
解決策
これは新しいカスタムフィールドを作成する絶好のタイミングだと思い、「Distance to（〜までの距離）」と名付けることにしました。コードは以下の通りですが、このフィールドには2通りの使い方があります：
#1 フィールドを追加してユーザーにGPS座標を入力させる方法です。例えば「最寄りの空港」フィールドとして、ユーザーが自分に最も近い空港のGPS情報を入力できるようにします。
#2 このユーザーのケースでは、ユーザーがフィールドの存在を意識することなく、1か所までの距離だけを表示すればよい状況です。そのため、カスタムフィールドを追加する際にフィールドを「管理者専用」に設定し、フロントエンドではユーザーに表示されず変更もできないようにします。そして「デフォルト値」に必要なGPS座標を設定することで、すべてのリスティングに必要な情報が表示されるようになります。
コード
この投稿では、Google Mapsで表示される「このページでGoogle Mapsが正しく読み込まれませんでした。技術的な詳細はJavaScriptコンソールをご覧ください。」というエラーの修正方法をご説明します。
GeoDirectoryをご利用の場合は、こちらのドキュメントをご参照ください こちら。
この問題の詳細については、こちらのブログ記事をご覧ください： https://wpgeodirectory.com/google-maps-api-key-and-new-limits/
「このページでGoogle Mapsが正しく読み込まれませんでした。技術的な詳細はJavaScriptコンソールをご覧ください。」または以下のいずれかのメッセージが表示されている場合：
"Esta página no ha cargado Google Maps correctamente."
"Google Maps ne s'est pas chargé correctement sur cette page."
"Google Maps non è stata caricata correttamente."
"Google Maps wurde auf dieser Seite nicht richtig geladen."
"При загрузке Google Карт на этой странице возникла проблема."
この修正が必要な可能性が高いです。WordPressをご利用の場合は、プラグインやテーマが原因でこの問題が発生しているほとんどのユーザーに対応できるプラグインを作成しました。こちらからご確認いただけます： GOOGLE MAPS API KEY FIX
WordPressをご利用でない場合は、ソースコード内のGoogle Mapsの呼び出し箇所を見つけてAPIキーを追加する必要があります。APIキーの作成手順はこちらでご確認いただけます こちら。 APIキーを取得したら、Google Mapsファイルの呼び出しに追加してください：maps.google.com/maps/api/js?key=YOUR-API-KEY-HERE
お役に立てれば幸いです。フィードバックはいつでも歓迎しています。
The GeoDirectory Team.
サポートを追加できたことを嬉しくお知らせします Snazzy Maps （当社の カスタム Google Maps アドオン (1.0.5).
Snazzy Maps とは何でしょうか？
Snazzy Mapsは、ユーザーがGoogle Mapsの色、彩度、その他のスタイリングオプションをカスタマイズできるオンラインリソースです。
カスタマイズオプションは、ウェブ上のさまざまな作者がデザインした多彩なマップスタイルの形で提供されています。
Snazzy Mapsでマップを編集するだけでなく、ユーザーは自分のウェブサイトやアプリで使用するSnazzy Mapスタイルを独自に作成することもできます。
カスタマイズされたすべてのマップは、ウェブとモバイルデバイスの両方で高解像度の衛星画像とベクターサポートを提供します。
これらの機能により、企業や開発者はコーディングスキルに頼ることなく、プロジェクトに視覚的に魅力的なマップを作成できます。
なぜGeoDirectoryにSnazzy Mapsのサポートを追加したのか？
約1週間前、メンバーの`Pieter Ravelli`がこのウェブサイトを私たちに紹介してくれました。チーム全員の心に響いたため、開発タスクの最優先事項として取り上げることにしました。
これがGeoDirectoryにおける私たちの信念です。メンバーが全員にとって有益な提案をしてくれるなら、私たちは喜んでそれを追加します。
Snazzy MapsのスタイルをGeoDirectoryにインポートする
Snazzy MapsをGeoDirectory Custom Mapsアドオンに追加するのは比較的簡単です。
- まず、snazzymaps.comにアクセスして、気に入ったスタイルを見つけるか作成してください。
- 気に入ったページが表示されたら、コピーボタンが表示されます。それをクリックしてください。
- 次に、GeoDirectoryの設定に移動し、GD>Custom Google Maps>Manage Stylesに進み、変更したいマップの編集をクリックします。
- マップスタイルの編集画面で「import styles」ボタンをクリックし、Snazzy Mapsからコピーしたスタイルコードを貼り付けて、「Import & Save Styles」ボタンをクリックします。
- これで、新しいマップスタイルがサイトで使用されるようになります。
GeoDirectoryでSnazzy Mapsを使用していますか？ご利用の場合、どのスタイルをお使いですか？以下のコメント欄でぜひ教えてください。