Great Stuff

WordPress Contact Form 7 plugin: Great for Forms | Code Stuff

Very nice instruction for Contact Form 7. Yes, it’s better than mine :)

File uploading and attachment with Contact Form 7

In this post, I will explain the file uploading and attachment feature introduced in Contact Form 7 1.9. If you are not familiar with Contact Form 7, please read the plugin homepage and FAQ first.

Summary

With this feature, you can allow your visitors to upload their files via your form, and then an email with attachments of the files is sent to you.

Please note that this feature uses the API of WordPress 2.7. So, in order to use it, you will need to upgrade your WordPress if you are using WordPress 2.6.x or older.

To set up, two steps are needed: 1) Add file uploading fields in your form, 2) Set up your mail settings to attach the uploaded files. The two steps will be explained in the rest of this post.

Adding file uploading fields in your form

Like other types of form fields, you add a tag code into the Form area in the Contact Form 7 admin panel (Tools > Contact Form 7 in WordPress 2.7).

The tag of file upload feild is like this:

[file your-file]

As with other types of tags, ‘file’ means the type of tag, and ‘your-file’ means the name of the tag.

You can use several options with ‘file’ typed tags. To limit the max file size, use the ‘limit:’ option like this:

[file your-file limit:100000]

The unit of the digits is ‘byte.’ So ‘limit: 100000’ means that the limited max file size is approximately 100 kB.

To limit acceptable file types, use ‘filetypes’ option like this:

[file your-file filetypes:gif|png|jpg|jpeg]

List the file extensions after ‘filetypes,’ and separate them with ‘|’
(pipe) character when you set multiple file types.

You can also generate these tags with the Tag Generator, of course.

Set up file attachments with a mail

For file attachments, the new field File attachments is added in the Mail field set in the Contact Form 7 admin panel. To attach the uploaded files to the mail, put tags into this field as shown below.

File attachments:
[your-file]

As other tags used in the Mail field set, only the name (in this case, ‘your-file’) is needed. Don’t put the tag’s type or options.

If you have multiple files uploaded and want to attach them into an email, simply line them up like this:

File attachments:
[your-file][your-another-file]

---

Learning WP_Query

# 書きかけ

WordPress のいわゆる「ループ」の実体である WP_Query クラスの扱いについてよく知ろう、という趣旨です。

クエリ変数のリストを書き込むと、WP_Query により生成される SQL リクエストとその結果、さらに各種 $is_* 変数の状態を見ることができる学習用プラグイン Learning WP_Query を作りました。

ダウンロード: こちら

使い方:

1. zip を展開してlearning-wp-query フォルダごと wp-content/plugins ディレクトリへコピー、Learning WP_Query プラグインを有効化
2. [Options] – [Learning WP_Query] に管理ページが追加されているのでそこに移動
3. いろいろいじってボタンを押したりしていると要領がつかめると思います

Sandbox 1.2

昨年の12月25日に Sandbox テーマのバージョン 1.2 がリリースされています。2006年8月にこのブログで紹介したときには 0.6.1 でしたがあれから大きく変わってきています。

Sandbox 1.0 での大きな変更として、それまで“スキン”と呼ばれていたスタイルシート部分の扱われ方が変わりました。1.0 以前は Sandbox のディレクトリの中にスタイルシートが置かれ、Sandbox の専用管理画面でどのスタイルシートを使用するか選択するようになっていましたが、1.0 以降ではスタイルシートを Sandbox ディレクトリの外に置くようになっています。

例えば Sandbox とそれをベースにした Sandbox Kubrick をインストールする場合、構成は

wp-content/
  |
  +- themes/
    |
    +- sandbox/
    +- sandbox-kubrick/

のように、Sandbox と Sandbox Kubrick が並列になります。

配置した後、管理画面のテーマ選択ページで Sandbox Kubrick を選択します(Sandbox を選択するのではないことに注意)。このように Sandbox は「置いておくだけ」ですが、Sandbox ベースのテーマを使う場合には必ず Sandbox も配置しておく必要があります。

Sandbox ベースのテーマ (Sandbox Kubrick) の中身はどのようになっているかというと、意味のあるファイルは style.css だけです。PHP のテンプレートなどは含まれていません。これだけでどうして Sandbox とつながるのか不思議になりますが、カギは style.css のコメント部にある TEMPLATE の行にあります。

/*
THEME NAME: Sandbox Kubrick
THEME URI: http://wordpress.org/
DESCRIPTION: Modification of the default WordPress theme, Kubrick, originally designed by Michael Heilemann.
AUTHOR: Andy Skelton
AUTHOR URI: http://andy.wordpress.com/
TEMPLATE: sandbox
*/

TEMPLATE 行が指定されていると、WordPress はテンプレート (index.php や single.php など) を指定されたテーマから継承して使うようになります。

このテンプレート継承の機能はこれまでほとんど使われることがありませんでしたが、実は現在のテーマシステムが導入された WordPress 1.5 の時点ですでに用意されていました。

WordPress のテキスト整形 API

WordPress にはテキスト整形のための API が用意されていて、プラグインを作るときなどにはあらかじめ知っておくと重宝します。とはいえ関数が多くて把握しきれないので、自分用のメモとしてまとめてみようと思いました。

以下、WordPress 2.1.3 の wp-includes/formatting.php で定義される関数の一覧です。気が向いたときに注釈を書き足すつもりです。

WordPress 2.1 のアタッチメント API

WordPress 2.1 ではアタッチメント(編集画面からアップロードされた画像などのファイル) 管理のための API が拡張され、それ以前と比べて格段に充実しています。アタッチメント関連のプラグイン作者向けに、WordPress 2.1 の変更ポイントや今後の方向性についてまとめました。

参考: Hitting WordPress Attachment Handling by mdawaffe

WordPress 2.1 のファイル再編成

WordPress 2.0 から 2.1 の間でファイルの大幅な再編成が行なわれています。通常の利用には影響はありませんが、プラグインやテーマを作るような時には関係がある場合もあるので一応把握しておいた方がよいでしょう。

特に変更の大きい wp-includes ディレクトリのファイルの移動について以下にまとめています。それぞれ WordPress Trac の Changeset にリンクしていますので経緯について知りたい場合はそちらを参照してください。

Sandbox テーマ

Sandbox テーマとは

Sandbox という画期的なコンセプトのテーマが最近注目されていて、WordPress の次期デフォルト・テーマの有力候補とも目されています。

Update: 2007年12月25日に公開された Sandbox 1.2 についてこちらに書きました。

従来 WordPress のテーマというのは PHP テンプレートと CSS のスタイルシートがパッケージ化されたものでしたが、Sandbox ではこれらを明確に分離して、スタイルシート部分を “スキン” という新導入のレイヤーに置き換えました。テンプレートは単一のまま、スキンは複数から選ぶことができます。ちょうど現在テーマを複数から選んでいるように、Sandbox テーマの中でスキンを選ぶことができるようになるというわけです。

従来のテーマでは PHP と CSS の両方を理解していないとテーマの中身をいじることが難しかったので、デザイン担当とコーディング担当に分業するような場合に少々都合が悪かったですが、Sandbox ではその辺がやりやすくなると思います。

単にスキンが選べるようになるだけではありません。Sandbox ではテンプレートの主要な要素の class 属性に豊富なセマンティック情報を盛り込んでいて、そのおかげで CSS のセレクタ指定の自由度が格段に高くなっています。実際に見た方が早いですが、

<body class="wordpress y2006 m08 d16 h03 single s-y2006 s-m08 s-d06 s-h10 
    s-category-uncategorized s-author-admin loggedin">

例えばこの body 要素に見られるように、今表示しているページにどのような情報が含まれているかを示すかなり細かい情報がクラスとして盛り込まれます。

クラス指定の全種類とそれぞれの意味について最後に一覧でまとめています。

Sandbox は hAtom マイクロフォーマットをサポートしています。hAtom についてはまだ良くわかっていませんが、ブログやニュース記事などが持つセマンティック情報を class 属性などの形で XHTML そのものの中に埋め込む仕様のようです。この辺はもう少しわかったら詳しく書きたいと思います。

poEdit で翻訳ファイルを作る

翻訳ファイル作成の 3 ステップ

先日、プラグインとテーマのローカライズについて主にプラグインやテーマの開発者の視点に立って書きましたが、今度は翻訳をする人の立場で見てみたいと思います。

gettext の翻訳ファイル作成をサポートするツールはいくつかあるようですが、Windows では poEdit が使えます。poEdit の現時点での最新バージョンは 1.3.4 です。

poEdit を使った翻訳ファイル作成作業の流れは次の各段階に分かれます。

1. ソースコードから翻訳対象のテキストを自動抜粋、.po ファイルを生成する。

   翻訳対象となるテキストは __() と _e() のところなので、poEdit はソースファイルをサーチして自動で収集してくれます。生成される .po ファイルはテキストフォーマットのファイルで、次の翻訳作業で編集に使われます。

2. .po ファイルを編集、翻訳作業を行なう。

   この段階が実際の翻訳作業です。作業は poEdit のインタフェイスから行ないますが、.po ファイルは普通のテキストファイルなので他のエディタで編集することも可能です。

3. .po ファイルを保存、同時に .mo ファイルが生成される。

   編集した .po ファイルを保存すると同時に .mo ファイルが自動生成されます。.po は人間が読み書きするのに適したテキストファイルであるのに対して、.mo はマシンが高速に読み込むことに適したバイナリファイルです。

既に誰かが .po ファイルを公開していてそれを一部手直しして使いたいだけなら、1 を飛ばして 2 の手順から始めることになります。1 は少々ややこしいので先に 2 の説明から始めます。

プラグインとテーマをローカライズする

WordPress のローカライズの基本

WordPress には gettext を利用したローカライゼーション(多言語化、現地語化)の仕組みが組み込まれているので、必要な翻訳ファイルさえ手に入ればわずかな設定で日本語化することが可能です。

簡単に手順をまとめると、

1. 翻訳ファイル(.mo) を入手する。日本語リソースの情報がこちらにまとめられています。
2. 翻訳ファイルを <WP_INSTALL>/wp-includes/languages/ 以下に配置する。languages というディレクトリは最初はないので自分で作る必要があります。
3. <WP_INSTALL>/wp-config.php の
   define ('WPLANG', '');
   の行を翻訳ファイルの名前に合わせて書き換える。日本語なら翻訳ファイルが ja.mo なので
   define ('WPLANG', 'ja');
   とします。WPLANG を変更できない場合はファイル名の方を WPLANG に合わせて変更しても問題ないはずです(ja.mo ⇒ ja_UTF.mo とか)。

ところがこの手順で日本語化できるのは基本的には管理パネルの内容だけで、一般の読者が目にするオモテの部分は対象になりません。なぜかというとオモテの部分はテーマでコントロールされているので、テーマのテンプレートに含まれるテキストの日本語化がされない限りオモテは変わらないのです。プラグインについても同様で、プラグインで制御されるテキストのローカライズは個々のプラグインごとに考慮される必要があります。

それではテーマやプラグインの作者がローカライズのために考慮すべきポイントとは何でしょうか。テーマやプラグインにおいても gettext を使用してローカライズすることには変わりありません。テーマやプラグインではその内部で明示的に翻訳ファイル(.mo) をロードする必要があるわけですが、プラグインが翻訳ファイルをロードするために使うのが load_plugin_textdomain() という関数です。