Insights

技術情報

WordPressを使っているのに、あえてフォームはプラグインを使わない理由

WordPressでサイトを作るとき、お問い合わせフォームをどうするかは、ほぼ必ず話題になります。

多くの場合は、

  • Contact Form 7
  • MW WP Form (現在はSnow Monkey Formsに移行)
  • その他フォーム系プラグイン

といったものを使うのが一般的だと思います。

ただ、私の場合はフォーム系プラグインを使わないというスタンスです。

今回は、その理由を整理してみます。


フォームプラグインを否定したいわけではない

最初に書いておくと、フォームプラグイン自体が悪いと言いたいわけではありません。

  • 手軽に導入できる
  • 管理画面で完結する
  • 非エンジニアでも触りやすい

こうしたメリットがあるのは事実ですし、条件によっては最適な選択になることもあります。


それでも毎回使っていない理由

それでも私がフォームプラグインを使わないのは、シンプルに言うとコードで管理したほうが楽だと感じているからです。

ここで言う「楽」というのは、

  • 実装が楽
  • 管理が楽
  • 数年後に見返したときも分かりやすい

という意味です。

また、Contact Form 7 などのフォームプラグインは、wp_mail() という WordPress の関数を使ってメールを送信しています。
以下のような流れでメールを送信しています。

wp_mail()
  ↓
PHPMailer(wp_mail() が内部で使用しているライブラリ)
  ↓
サーバの MTA(mail / sendmail / postfix など)

プラグインごとにUIや設定方法の違いはありますが、メール送信のコア部分の構造自体は大きく変わらないため、それならばPHPMailerを自前で設置して使うほうがカスタム性・拡張性が高くなります。
WordPressの更新の影響を受けにくく、また、プラグインのアップデートによってメール送信ができなくなるリスクも低くなります。


プラグインだと「把握する場所」が増えるので、自分でコードで書いたほうが楽だと感じています。

フォームプラグインを使うと、

  • HTMLはどこか
  • バリデーションは設定画面か
  • メール文面は管理画面か
  • フックは functions.php か

と、確認すべき場所が分散しがちになります。

一方、コードで書いていれば、

  • このファイルがフォーム
  • この処理が送信
  • この部分がバリデーション

と、構造が一目で分かります。

後から自分が触るにしても、他の人が引き継ぐにしても、この差は意外と大きいです。


MW WP Form の開発終了アナウンスがあったことも影響している

以前、定番だった MW WP Form について、一度「開発終了」というアナウンスが出たことがありました。
※現在は同開発者による「Snow Monkey Forms」があります。

現在もプラグイン自体は公開されていますが、

  • 今後どこまで継続的にメンテナンスされるのか
  • WordPressやPHPの将来バージョンに追随できるのか

正直、外からは判断しづらい部分があります。

この件をきっかけに、フォームという重要な機能を、特定のプラグインに依存するのは少し怖いと感じるようになりました。


フォームは「止まると困る」機能

フォームは、

  • 壊れてもすぐ気づきにくい
  • でも止まると機会損失が大きい

という、かなり厄介な機能です。

  • メールが届いていない
  • スパムだけ届いている
  • アップデート後に動かなくなった

こうしたトラブルの切り分けで、プラグイン・WordPress本体・サーバ設定を行き来するのは、正直あまりやりたくありません。


管理画面から文言を変えたい、という要望について

フォームプラグインを使う理由として、「管理画面から文章を変更したいから」という要望もよく聞きます。

ただ、この点についても、必ずしもフォームプラグインが必須とは限りません。

例えば、

  • フォームの説明文
  • 注意書き
  • 送信完了メッセージ
  • メール本文の一部

こういった文言は、カスタムフィールドとして用意しておき、フォームのコード側で読み込めば、管理画面から自由に変更できます。

構造や処理はコードで管理しつつ、変更頻度の高い文言だけを管理画面に切り出す。

この形のほうが、

  • どこを触ればいいか分かりやすい
  • 設定が散らばらない
  • 数年後に見ても把握しやすい

というメリットがあると感じています。


プラグインを使うと、どうしても制約が出てくる

フォームプラグインを使っていると、どうしても「プラグイン側の仕様」に合わせる必要が出てきます。

例えば、

  • HTML構造を細かく調整したい
  • クラスの付け方を統一したい
  • バリデーションの挙動を少しだけ変えたい
  • 分岐条件を要件どおりに書きたい

こういった細かい調整をしようとすると、

  • 用意されている設定では足りない
  • フィルターやフックを探す
  • 結局、プラグインの内部仕様を追うことになる

という流れになりがちです。

それなら最初から、

  • HTML
  • バリデーション
  • 送信処理

をコードで書いてしまったほうが、結果的に早く、分かりやすいと感じることが多くなりました。

「ある程度まで簡単にできる」代わりに、「それ以上の調整がしづらい」。

このトレードオフも、フォームプラグインを使わない理由の一つです。


自作フォームでやっていることは最低限

自作するといっても、特別なことをしているわけではありません。

  • フロントとバックエンドのバリデーション
  • トークンを使った簡易CSRF対策
  • PHPMailerなどを使ったメール送信
  • 必要最低限のスパム対策

「フォームとして最低限必要なこと」だけをコードでシンプルに書いています。


それでもプラグインを使うケースはある

もちろん、どんな場合でも自作するわけではありません。

例えば、

  • 管理画面から構造自体を頻繁に変えたい
  • 非エンジニアがフォーム仕様を触る
  • 要件がかなりシンプル
  • 短期案件でスピード優先

こうした条件なら、フォームプラグインを選ぶほうが合理的です。


まとめ

フォームプラグインを使わない理由は、思想というより、かなり実務的な話です。

  • コードで管理したほうが分かりやすい
  • プラグイン依存や制約を減らしたい
  • 数年後の自分や他の人が触りやすい

過去の経験から、今はこのやり方が一番しっくりきています。