2016年08月

Eloquentをライブラリとして使ってみた(Laravel ORM)

2016-08-31 18:48 - NozawaTakeshi

先日のエントリーではPHPのORマッパーの簡単な比較と、LaravelのORMである”Eloquent”の特徴をまとめてみました。

今日はEloquentのライブラリとしての使用方法についてまとめてみたいと思います。

githubにはLaravelのEloquentを含むデータベース関連のライブラリが公開されています。

The Illuminate Database component is a full database toolkit for PHP, providing an expressive query builder, ActiveRecord style ORM, and schema builder. It currently supports MySQL, Postgres, SQL Server, and SQLite. It also serves as the database layer of the Laravel PHP framework.

翻訳すると、「イルミネートデータベースコンポーネントはクエリビルダー、アクティブレコードのスタイルのORM、スキーマビルダーを提供するデータベースのPHPツールキットです。現在はMySQL、Postgres、SQL Server、SQLiteをサポートしています。このコンポーネントはLaravel PHP フレームワークのデータベースレイヤーとしても機能を提供しています。」とのことです。

“Illuminate”というのはLaravel本体やLaravel関連のコンポーネントを開発しているgithub上の集団と理解してくれれば良いと思います。Eloquentは狭義では”Illuminate/database”コンポーネントの”Active Record Style ORM”にあたります。ただし、Eloquentがクエリビルダーのクラスをカプセル化しているので、プログラマーはEloquentを通して意識することなく、”Illuminate/database”コンポーネントの機能を活用することができます。

またMongoDBにも対応し始めているそうなので、NoSQLな方もお使いいただけるかもしれません。

それではEloquentライブラリのインストール方法と使い方について見ていきたいと思います。

>>続きを読む

PHPのORM比較: LaravelのORマッパー(Eloquent)の特徴

2016-08-24 15:09 - NozawaTakeshi

最近とあるアプリケーションのライブラリを作成するプロジェクトがありまして、スクラッチで書いていたのですが、DB接続やSQLまわりが煩雑になり、やっぱりORMが欲しいなぁと探していたところ、今アツイと言われているPHPフレームワークの”Laravel”のORマッパーである”Eloquent”を見つけました。(こちらの記事で紹介されています)

フレームワークなのに、ORマッパーだけを独立して使うことができるようです。

今回はDoctrine、Idiorm&Paris、EloquentなどのPHP製のORMを比較し、Eloquentの特徴や使用感をご紹介したいと思います。

>>続きを読む

OPcacheとAPCu

2016-08-19 17:54 - saito

はじめまして。エンジニアの齋藤です。
先日、深遠なる理由によりPHPをコンパイルする機会があったので、その際に行ったOPcacheの設定とAPCuのインストールをまとめてみます。

OPcache:バイトコードキャッシュ

PHPのconfigure時にopcacheはデフォルトで有効になっているので、コンパイル時に自動的にopcache.soは作成されたのですが、php.iniにopcacheセクションはあるものの、ロードの記述がないので、
zend_extension=opcache.so
と明示的にロードする必要があります。
extensionでロードできないので小一時間悩みました。
php.netのインストール手順のページにzend_extensionでロードしろと書いてありますね。マニュアルはちゃんと見ましょう。

設定については同じページに推奨設定があります。引用しますと、

opcache.memory_consumption=128
opcache.interned_strings_buffer=8
opcache.max_accelerated_files=4000
opcache.revalidate_freq=60
opcache.fast_shutdown=1
opcache.enable_cli=1

revalidate_freqが60秒となっています。
これが長いと、ファイルを上書きしてもなかなかキャッシュを再作成してくれないので、更新が頻繁にあるのであれば、デフォルトの2でもいいと思います。
特に開発環境などでは0にしてもいいくらいかと思います。
残りの項目は管理画面で使用量などチェックしながら調整します。

管理画面は3つほどあるみたいですが、
https://gist.github.com/ck-on/4959032
https://github.com/amnuts/opcache-gui
https://github.com/rlerdorf/opcache-status/blob/master/opcache.php
所感としてはどれもそんな変わりませんでした。

参考:PHP OPCache 確認ツール 3つまとめ | 丸ノ内テックブログ

メモ:OPcacheのgitのありか
https://github.com/zendtech/ZendOptimizerPlus

APCu:ユーザーキャッシュ

APCuも入れます。
PHP-5.6.24でpecl installしたところ
pecl/apcu requires PHP (version >= 7.0.0-dev), installed version is 5.6.24
と言われました。
どうやらAPCu5からはphp7にしか対応してないようなので、peclから4系を落としてきて、コンパイルして入れる事にします。

インストールが終わったらphp.iniに追記します。

現時点ではphp.netのAPCuが日本語訳になっていないので、英語がさっぱり分からない私は旧APCを参考にしてます。
とはいえ、APCuではオプションがかなりOPcacheに移動したので、shm_sizeくらいしか変更してません。
こちらも管理画面を見ながら値を適宜調整していきます。
管理画面はtarballに入っているapc.phpを使いますが、認証がうまく動いてくれないので、USE_AUTHENTICATION0にします。
認証なしでキャッシュの削除などができるようになってしまい危険ですので、制限ディレクトリに入れましょう。

メモ:PHP7以上であれば、後方互換用のapcu_bcも入れた方がいいと思われます。
メモ:gccの最適化オプション。今後コンパイルする時にテスト。

以上、そんなに特殊な事はやってないのですが、備忘録的にまとめてみました。

ContactForm7最新バージョン(4.4.2)での確認用メールアドレスの実装

2016-08-02 14:00 - hagiwara

はじめまして。開発担当の萩原です。

今回の記事ではContactForm7の最新バージョン(この時点では4.4.2)で動作する
「確認用メールアドレス」のバリデート(入力チェック)のコードを紹介させていただきたいと思います。

弊社では自社のメディアサイトの運営以外にもウェブサイトの制作をさせていただいていたりもします。
その際、WordPressを使って制作しているのですが、よくあるのがお問い合わせフォームの実装時に、
エンドユーザの情報入力項目として「メールアドレス」と「確認用メールアドレス」を配置したいというご要望です。

お問い合わせフォーム自体は「ContactForm7」という
非常に有名で便利なプラグインがあるので比較的容易に実装できるのですが、
こちらのプラグインには「確認用メールアドレス」のバリデート機能がありません。
ですが、沢山の方が使っているプラグインですので、この機能の追加方法もたくさん紹介されております。

Contact Form 7で確認用メールアドレスの入力フォームを加える方法
contact form 7に確認用メールアドレスの項目を設置する方法
WordPressの問合せフォームプラグイン「Contact Form 7」にメールアドレス入力確認機能を追加する
など、他にもたくさんあります。
※どちらのサイトも最近のバージョンで動作するものを紹介されております

弊社でも独自に機能を拡張して確認用メールアドレスのバリデートを追加していたのですが、
ContactForm7のバージョンを上げたところ、上手く動かなくなってしまったということがありまして、
最新バージョンのContactForm7で動作するコードを改めて実装することとなりました。

実装方法ですが、functions.phpなどに以下のコードを追記してください。
※既に旧バージョンのコードが入っているという方は、既存のコードを以下のコードと差し替えてください

処理内容を説明させていただきますと、

2-3行目:もともと存在するContactForm7の「email」と「email*」のバリデーションのフックに、今回実装した関数(wpcf7_text_validation_filter_extend_email)を追加します。関数追加後の流れとしては、必須入力チェック(既存)->メールアドレスチェック(既存)->今回の追加する確認用メールアドレスチェックとなります。

4行目:確認用メールアドレスのバリデーション関数を定義します。パラメータの$resultはContactForm7の入力チェックのオブジェクトで、$tagはContactForm7の管理画面で設定した入力項目(例:[mail your-email])の情報を持った配列が入ります。

6行目:入力エラーが発生した際に必要となる、$tagのデータをもとにWPCF7_Shortcodeオブジェクトを生成します。

8行目:管理画面で設定した入力項目名が”xxxx_confirm”であるかをチェックします。”xxxx_confirm”でない場合、確認用メールアドレスの入力チェックは行わず、14行目まで進みます。

9行目:”xxxx_confirm”の文字列から、”xxxx”の部分を取得します。

10行目:フォームで入力された、”xxxx_confirm”と”xxxx”の値が一致しているかチェックします。一致していなかった場合11行目に進みます。

11行目:入力チェックのオブジェクトに6行目で生成したWPCF7_Shortcodeオブジェクトとエラー文言を追加します。

14行目:入力チェックのオブジェクトを返します。

となります。

 

管理画面では、

 

というように設定していただけば確認用メールアドレスのバリデーションが使えるようになります。
※”your-email”の部分は任意の名前を設定していただいて大丈夫です

また、

とように、”_confirm”のあり/なしの組み合わせで複数配置すれば、
確認用メールアドレスの項目が複数設置できます。

補足ですが、他サイト様で紹介されているコードでは、よく8行目の前に

というような条件分岐が入ってるものを見かけますが、
2行目と3行目のadd_filter()時に「email」と「email*」に限定しているので
今回のwpcf7_text_validation_filter_extend_email()の中で$typeのチェックは
必要ないのでないかと思います。

ご参考になりましたら幸いです。