カテゴリー: テクノロジー

ContactForm7とGoogleスプレッドシートを連携してみよう!

弊社でお受けするサイト制作案件では主にWordPressを使用しています。
そして基本的にお問い合わせフォームの設置もご依頼されることが多くあります。
弊社ではお問い合せフォーム設置の際は、おそらく国内のプラグインでは1番有名なContactForm7を利用して実装するようにしています。
カスタマイズが簡単にできたり、自動返信メールなども対応可能ということで大変便利なプラグインなのですが、たまに「お問い合わせ内容をGoogleのスプレッドシートに記録されるようにしてほしい」というご相談をいただくことがありました。

そこで今回はContactForm7とGoogleスプレッドシートを連携させる方法をご紹介したいと思います。

「CF7 Google Sheet Connector」をインストール

【WordPress管理画面】プラグイン > 新規追加


プラグイン管理画面から「新規追加」をクリックして「CF7 Google Sheet Connector」で検索します。

赤枠のプラグインをインストールします。

連携用のスプレッドシートの作成

次にお問い合わせ内容を連携させるためのスプレッドシートを新規作成します。
いくつか設定しないといけないことがあるので順に説明します。

「スプレッドシート名」と「タブ名」を設定する


今回は、
スプレッドシート名 : cf7-contact
タブ名 : contact-sheet
とそれぞれつけました。
名前は何でもいい(半角英数字)のですが、あとから見たときにわかりやすい名前がいいと思います。

「お問合せフォームの項目」を設定する


次に、ContactForm7で利用しているお問い合わせ内容の全項目をスプレッドシートの1行目に入力します。
この設定をして次の項目の連携設定をすると、スプレッドシートの2行目以降にお問い合わせ内容が反映されていきます。

スプレッドシート連携の設定

【WordPress管理画面】お問い合わせ > お問合せフォーム > Google Sheetsタブ

まず、Google Sheet Settingsの項目に必要事項を入力していきます。

上から「スプレッドシート名」「スプレッドシートID」「タブ名」「タブID」となっています。

スプレッドシート名は先ほど作成したスプレッドシートの「cf7-contact」、タブ名は「contact-sheet」を入力します。
「スプレッドシートID」と「タブID」は以下を参考にして入力してください。

・スプレッドシートIDの確認方法

スプレッドシートのURLの「*****」の部分がスプレッドシートIDになります。

https://docs.google.com/spreadsheets/d/*****/edit#gid=0

・タブIDの確認方法

スプレッドシートのURLの最後の「edit#gid=0」内の数字「0」がタブIDになります。

https://docs.google.com/spreadsheets/d/*****/edit#gid=0

必要事項を入力したら、「保存」ボタンをクリックします。


次にスプレッドシートとの連携をします。

【WordPress管理画面】お問い合わせ > Google Sheets

「Google Access Code」の横にある「Get Code」をクリックすると、Googleアカウント認証のページへ遷移します。

順番に3つ承認画面が表示されるので、全て「許可」を選択します。

最後の画面でコードが表示されるので、そのコードをコピーしてください。
※このコードは非常に大切なものなので、他人には絶対に共有しないようにしてください。

その後、先程の管理画面のコード入力欄にコードを入力して「保存」ボタンをクリックします。

これでお問い合せフォームとスプレッドシートの連携設定は完了です。

動作確認

最後にお問い合せフォームを送信して、送信内容がスプレッドシートに反映されているか確認してみましょう。

問題なく反映されていれば連携は完了です!
もし反映されないなどエラーが発生した場合は、もう一度最初からやり直してみてください。認証したGoogleアカウントがスプレッドシートを作成したGoogleアカウントと同一のものでないと連携はできません。

さいごに

CF7 Google Sheet Connectorを利用すれば、簡単にGoogleスプレッドシートとお問い合わせフォームを連携させることができるようになります。
お問い合わせの管理が非常に効率的に行えると思いますので、お困りの方はぜひお試しください!


JavaScriptのおもしろシンタックス

SNSみてるとセカオワのドラゲナイはもう懐メロなんだろうなって感じました。
マエダです。
(´-`).。oO (え?懐メロって死語ですか?

javascript

さて、みんな大好きJavaScript。
おもしろいシンタックスをご紹介します。

文字列型へのキャスト

var a = 1;
console.log(typeof(a)); // number
var b = "" + a;
console.log(typeof(b)); // string

数値型へのキャスト

var a = "1";
console.log(typeof(a)); // string
var b = ~~a;
console.log(typeof(b)); // number

配列の重複削除

const array1 = ["a","b","b","c","a"];
const array2 = [...new Set(array1)];
console.log(array2); // ["a","b","c"]

オブジェクトの値渡し

var object1 = ["a","b"];
var object2 = object1;
object2[0] = "c";
console.log(object1); // ["c","b"]
console.log(object2); // ["c","b"]

JavaScriptではオブジェクト型は参照渡しとなります。
以下のようにすればプリミティブ型のように値渡しとすることができます。

var object1 = ["a","b"];
var object2 = JSON.parse(JSON.stringify(object1));
object2[0] = "c";
console.log(object1); // ["a","b"]
console.log(object2); // ["c","b"]

僕の場合、どんなプログラミング言語もなのですが、ときどき触るとはじめましてになりがちです;

ドラゲナイ


【Solr】JapaneseReadingFormFilterについて

はじめに

Solrでは、扱う対象の言語に応じた Tokenizer や TokenizerFilter が用意されています。リファレンスに日本語用のものもまとめられています。リファレンスには何故か載っていないもののよく知られているフィルタとして JapaneseReadingFormFilter があります。これは、形態素解析後の単語の読みをインデックスするためのものです。

この JapaneseReadingFormFIlter を使って、漢字の読みで検索できるように設定してみました。

JapaneseReadingFormFilterの基本的な使い方

JapaneseTokenizer を使うフィールドダイプの定義に以下を追加します。

<filter class="solr.JapaneseReadingFormFilterFactory" useRomaji="false"/>

_default コンフィグセットの定義に倣うと、以下のようになります。

    <dynamicField name="*_txt_ja_reading" type="text_ja_reading"  indexed="true"  stored="true"/>
    <fieldType name="text_ja_reading" class="solr.TextField" positionIncrementGap="100" autoGeneratePhraseQueries="false">
      <analyzer>
	<tokenizer class="solr.JapaneseTokenizerFactory" mode="search"/>
        <filter class="solr.JapaneseBaseFormFilterFactory"/>
	<filter class="solr.JapanesePartOfSpeechStopFilterFactory" tags="lang/stoptags_ja.txt" />
        <filter class="solr.CJKWidthFilterFactory"/>
        <filter class="solr.StopFilterFactory" ignoreCase="true" words="lang/stopwords_ja.txt" />
        <filter class="solr.JapaneseKatakanaStemFilterFactory" minimumLength="4"/>
	<filter class="solr.LowerCaseFilterFactory"/>
        <!-- 以下を追加 -->
        <filter class="solr.JapaneseReadingFormFilterFactory" useRomaji="false"/>
      </analyzer>
    </fieldType>

読みで検索できるようにする

JapaneseTokenizer で使われている Kuromoji はカタカナで読みを提供するので、JapaneseReadingFormFilter を通した結果はカタカナでインデックスされます。

[
    {
        "id" : "1",
        "body_txt_ja_reading" : "Solr 8.4 からパッケージ管理機能が追加されました。リファレンスによると、ここでいうパッケージは1つまたは複数のプラグインを1つにまとめたものという意味のようです。Solr におけるパッケージ管理について調べました。"
    },
    {
        "id" : "2",
        "body_txt_ja_reading" : "昨日の午後"
    }
]

この2つの文章をインデックスしたときのタームは以下のようになります。

上の基本的な設定の内容だと、インデックス作成時と検索時とで同じ Tokeinizer の設定になっているで、読みで検索するには不都合です。漢字表記とカタカナ表記とで単語の分割のされ方が異なる場合があるからです。

そこで、入力されたカタカナはそのまま利用するというルールにして、検索時には WhitespaceTokenizer を使うことにします。

   <dynamicField name="*_txt_ja_reading" type="text_ja_reading"  indexed="true"  stored="true"/>
    <fieldType name="text_ja_reading" class="solr.TextField" positionIncrementGap="100" autoGeneratePhraseQueries="false">
      <analyzer type="index">
        <tokenizer class="solr.JapaneseTokenizerFactory" mode="search"/>
        <filter class="solr.JapaneseBaseFormFilterFactory"/>
        <filter class="solr.JapanesePartOfSpeechStopFilterFactory" tags="lang/stoptags_ja.txt" />
        <filter class="solr.CJKWidthFilterFactory"/>
        <filter class="solr.StopFilterFactory" ignoreCase="true" words="lang/stopwords_ja.txt" />
        <filter class="solr.JapaneseKatakanaStemFilterFactory" minimumLength="4"/>
        <filter class="solr.LowerCaseFilterFactory"/>
        <filter class="solr.JapaneseReadingFormFilterFactory" useRomaji="false"/>
      </analyzer>

      <analyzer type="query">
        <tokenizer class="solr.WhitespaceTokenizerFactory" rule="java"/>
      </analyzer>
    </fieldType>

この設定により、「キノウ」で検索すると文書1と2の両方が、「キノウ ゴゴ」で検索すると文書2だけがヒットするようにできました。

{
  "responseHeader":{
    "zkConnected":true,
    "status":0,
    "QTime":2,
    "params":{
      "q":"キノウ",
      "defType":"edismax",
      "qf":"body_txt_ja_reading",
      "fl":"id,body_txt_ja_reading",
      "stopwords":"true",
      "_":"1606578263384"}},
  "response":{"numFound":2,"start":0,"numFoundExact":true,"docs":[
      {
        "id":"2",
        "body_txt_ja_reading":"昨日の午後"},
      {
        "id":"1",
        "body_txt_ja_reading":"Solr 8.4 からパッケージ管理機能が追加されました。リファレンスによると、ここでいうパッケージは1つまたは複数のプラグインを1つにまとめたものという意味のようです。Solr におけるパッケージ管理について調べました。"}]
  }}
{
  "responseHeader":{
    "zkConnected":true,
    "status":0,
    "QTime":1,
    "params":{
      "q":"キノウ ゴゴ",
      "defType":"edismax",
      "qf":"body_txt_ja_reading",
      "fl":"id,body_txt_ja_reading",
      "q.op":"and",
      "stopwords":"true",
      "_":"1606578263384"}},
  "response":{"numFound":1,"start":0,"numFoundExact":true,"docs":[
      {
        "id":"2",
        "body_txt_ja_reading":"昨日の午後"}]
  }}

[Android 11] USBテザリング時の IP アドレスが変わっていた話

Android が 11 にアップデートされてから、
USB テザリングで使われるIPアドレスが変更になっているようです。

Android 10 のときは、USB テザリングを有効にしたときのIPアドレスには 192.168.42.* が使用されていました。

USB、Bluetooth、Wifi のテザリングに加え、
新たに有線LANテザリングに対応した影響ではないかと思います。

 

Windows は設定がおかしいと自動的に別のネットワークで繋いでくれるようで場合によっては気付きにくいかもしれません。

同じような使い方をしている人向けに確認する方法を一応書いておくと、
タスクマネージャーのリソースモニターからネットワークの欄を見ると、
ローカルアドレスとリモートアドレスが表示されています。

 

テザリング時の端末のIPアドレスを固定してしまうと楽かもしれませんが、
仕様変更があったときに面倒なのと、
IPアドレス自体は簡単に分かるので何もしていません。

新しく対応した有線LANテザリングは、
余ったSIMフリー端末でもあれば遊べそうな気はします。

 

脱線しそうなのでここまで。
以上、USBテザリング時に使われるIPアドレスが変わっていたという話でした。

 

192.168.42.* が USB テザリング用に割り当てられるというのは後からググって知った情報ですが、設定が有効だった頃は常に 192.168.42.129 が使われていた気がします。調べてみるとハードコーディングされているという記事がヒットして、それについては自分で確認はしていませんが実際にそうだった可能性はありそうです。 ただ、固定だった場合はUSBやBluetooth複数でテザリングするとどうなるのか試してみたいと思いつつ、その実験のためだけに複数回線を契約するのは厳しい。にも関わらず世の中には実際に複数接続を実現している人もいるようですごい…。


【Solr】3種類の言語判定ライブラリの対応言語

はじめに

Solrでのインデックス作成の際の言語判定には以下の3種類のライブラリが利用できます。

  • Apache Tika
  • LangDetect
  • Apache OpenNLP

ただし、Solrのリファレンスを読んでも、どのライブラリがどの言語をサポートしているかの情報がありません。詳細についてはそれぞれのプロジェクトページを参照するようにと書かれているので確認してみました。

Apache Tika

プロジェクトのページには言語判定について詳しい情報が無かったので、ソースコードを確認しました。

LanguageIdentifierクラスを見ると、各言語のプロファイルとして .ngp という拡張子のファイルを読み込んでいることが分かります。そこで、solr-8.6.1 同梱の tika-core-1.2.jar に含まれる .ngp ファイルをリストアップしました。

$ jar tvf ./contrib/extraction/lib/tika-core-1.24.jar | grep .ngp
 10960 Wed Mar 11 18:05:28 JST 2020 org/apache/tika/language/be.ngp
 10411 Wed Mar 11 18:05:28 JST 2020 org/apache/tika/language/ca.ngp
 10004 Wed Mar 11 18:05:28 JST 2020 org/apache/tika/language/da.ngp
  9999 Wed Mar 11 18:05:28 JST 2020 org/apache/tika/language/de.ngp
 12664 Wed Mar 11 18:05:28 JST 2020 org/apache/tika/language/el.ngp
  9897 Wed Mar 11 18:05:28 JST 2020 org/apache/tika/language/en.ngp
 10292 Wed Mar 11 18:05:28 JST 2020 org/apache/tika/language/eo.ngp
  9960 Wed Mar 11 18:05:28 JST 2020 org/apache/tika/language/es.ngp
  9648 Wed Mar 11 18:05:28 JST 2020 org/apache/tika/language/et.ngp
 11479 Wed Mar 11 18:05:28 JST 2020 org/apache/tika/language/fa.ngp
 10081 Wed Mar 11 18:05:28 JST 2020 org/apache/tika/language/fi.ngp
 10050 Wed Mar 11 18:05:28 JST 2020 org/apache/tika/language/fr.ngp
 10416 Wed Mar 11 18:05:28 JST 2020 org/apache/tika/language/gl.ngp
  9738 Wed Mar 11 18:05:28 JST 2020 org/apache/tika/language/hu.ngp
  9301 Wed Mar 11 18:05:28 JST 2020 org/apache/tika/language/is.ngp
  9960 Wed Mar 11 18:05:28 JST 2020 org/apache/tika/language/it.ngp
 12509 Wed Mar 11 18:05:28 JST 2020 org/apache/tika/language/lt.ngp
  9923 Wed Mar 11 18:05:28 JST 2020 org/apache/tika/language/nl.ngp
  9373 Wed Mar 11 18:05:28 JST 2020 org/apache/tika/language/no.ngp
  9165 Wed Mar 11 18:05:28 JST 2020 org/apache/tika/language/pl.ngp
 10023 Wed Mar 11 18:05:28 JST 2020 org/apache/tika/language/pt.ngp
 10456 Wed Mar 11 18:05:28 JST 2020 org/apache/tika/language/ro.ngp
 11783 Wed Mar 11 18:05:28 JST 2020 org/apache/tika/language/ru.ngp
 10431 Wed Mar 11 18:05:28 JST 2020 org/apache/tika/language/sk.ngp
 10329 Wed Mar 11 18:05:28 JST 2020 org/apache/tika/language/sl.ngp
 10081 Wed Mar 11 18:05:28 JST 2020 org/apache/tika/language/sv.ngp
 14302 Wed Mar 11 18:05:28 JST 2020 org/apache/tika/language/th.ngp
 11942 Wed Mar 11 18:05:28 JST 2020 org/apache/tika/language/uk.ngp

サポートされている言語は28。日本語はサポートされていないようです。

LangDetect

リファレンスからリンクされているプロジェクトページがgithubになっており、ほとんど情報が無いため、こちらもソースコードを確認しました。

profiles というディレクトリの下に各言語のプロファイルが置かれています。

$ ls profiles
af  bg  cs  de  en  et  fi  gu  hi  hu  it  kn  lt  mk  mr  nl  pa  pt  ru  sl  sq  sw  te  tl  uk  vi     zh-tw
ar  bn  da  el  es  fa  fr  he  hr  id  ja  ko  lv  ml  ne  no  pl  ro  sk  so  sv  ta  th  tr  ur  zh-cn

サポートされている言語は53。日本語も含まれています。

Apache OpenNLP

こちらはREADMEにしっかり記載されていました。

サポートされている言語は103。日本語も含まれています。