テーマ Tewnty Fourteen の日本語化(非公式)

WordPress のバージョンが 3.7 になりました。インストールしてみたところ、次期デフォルトテーマの Twenty Fourteen が含まれていました。ただしバージョンは 0.1 なので、まだ完成形ではないのでしょう。

(追記)すみません。RCまでは含まれていたのですが、正式な3.7には含まれなくなっていました。重ねてインストールしていたので混乱していました。まあ、いいや。そのうちどこかで役立ててください。(追記終わり)

翻訳の作業は、公式には GlotPress で行われるのですが、バージョンが若すぎて、まだここに登場していません。当然、日本語パッケージにも翻訳は含まれていません。

そこで非公式の日本語リソースを個人的に作成しましたので、公開します。

中身は twentyfourteen-ja.po と twentyfourteen-ja.mo だけです。適当な場所 (wp-content/languages/themes/ の下とか)に 置いてください。

大部分は Twenty Thirteen のリソースを取り込み、それから変更されたり追加された分を訳しました。自分でもまだちゃんと使っていないので、どこに表示されるものかも確認しないままやったものもあり、おかしなところがあるかもしれません。

とにかくまだ Twenty Fourteen 自体が発展途上で固まっていないこと、今回公開するものは WordPress 3.7 パッケージに含まれる 0.1 に対応するものであること、元の文もどんどん変更されるかもしれませんし、あくまで非公式な作業なので訳語も変わりうること、やっつけでやったのでまだおかしな訳があるかもしれないこと(“Featured Content” の訳語ってどうしましょうね)、などをご了承の上、ご自由にお使いください。

wp-login.php への攻撃に対処する

サーバーにログインして作業しようとしたら非常に反応が悪く、どうしたことかと見てみると(普段と違って、コマンドを入力してから応答があるまで数十秒も待たされるのでヒヤヒヤしましたが)、大量の apache プロセスが走っていて、ログには wp-login.php への大量のアクセスが記録されていました。最近よく耳にする wp-login.php へのブルートフォースアタックです。

1つの IP アドレスから5,6回のアクセスがあり、すぐに(あるいは同時に)別の IP アドレスからのアクセスがあります。結局、2時間ほどのあいだに数千回のアクセスがあり、その後沈静化しました。

特に対策らしい対策をしていなかったので、パスワードの強度のみで耐えたことになりますが、実際目の当たりにすると気持ちのいいものではありません。それにどちらかというとサーバーに対する高負荷のほうが心配です。

そこでいまさらではありますが、少し手を打つことにしました。

強いパスワードにする

今回行った対策ではありませんが、そこそこ強いパスワードにしていたので、攻撃に気づくまでの30分間ほどはこのことだけで侵入を防ぎました。

.htaccess で制限する

攻撃に気づいてすぐ、 .htaccess に次のように書いて wp-login.php へのアクセスを制限しました。これは効果てきめんで、すぐにサーバーの負荷は通常の範囲まで下がりました。

<Files wp-login.php>
Order deny,allow
Deny from all
Allow from xxx.xxx.xxx.xxx
</Files>

前述のように攻撃側の IP アドレスは絞り切れないので、Deny に列挙することができません。

さて当面はこれでしのいだとしても、正当に管理画面にアクセスするのが複数の人間で、それぞれの接続元の IP アドレスが固定していなかったりすると、Allow に列挙するのもやっかいです。

WordPress のロックダウン

IP アドレスでふるい分けられないとすれば、wp-login.php のところで何らかの制限をかける方法が考えられます。たとえば Force Email Login は、中心となる機能は「ログインをユーザー名ではなくメールアドレスで」という点なのですが、そのほかに

  • ログインに失敗すると、ログイン処理に対して10秒間 wp_die() を発火させて膨大な量のブルートフォースアタックによるサーバー負荷を軽減します。

ということも行います。

こちらの問題のサイトでは「ログインをユーザー名ではなくメールアドレスで」という機能は必要ないので(というか、ようやく「ユーザー名」が何かを理解するくらいの人たちにもう一度ログイン方法を周知徹底するのが面倒すぎるので)、その部分を削ぎ落とすことにしました。

ただ、これだと誰か(攻撃者)がログインに失敗するとその後10秒間は誰も(正当なユーザーも)ログインできません。たとえば5秒に1回、1週間にわたってログインを失敗し続けるという、もはや「ブルートフォース」とは呼べないようなぬるい攻撃(?)で、そのあいだ正当なユーザーのログインを妨害することができるという欠点があります。

やはり「IP アドレスごとに」という機能をつけざるを得ないのかもしれません。そこで、Limit Login Attempts in WordPress … のようなものにすることにしました。これだと、同一 IP アドレスから1秒間にn回のログインの失敗があったらその後m秒間、その IP アドレスからのアクセスを禁止します[1]。ユーザー名/パスワードを試みる回数は、IP アドレスをチェックしないものよりは増えますが、何も対策しないよりはずいぶん減らせるでしょう。

さて、たとえば1秒間に2か所からそれぞれ2回、3回の攻撃があった場合の対応は、この対策を行わない場合、

  • wp-login.php にアクセス → データベースでユーザー名とパスワードを調べる → 失敗
  • wp-login.php にアクセス → データベースでユーザー名とパスワードを調べる → 失敗
  • wp-login.php にアクセス → データベースでユーザー名とパスワードを調べる → 失敗
  • wp-login.php にアクセス → データベースでユーザー名とパスワードを調べる → 失敗
  • wp-login.php にアクセス → データベースでユーザー名とパスワードを調べる → 失敗

となっていたわけですが、これが

  • wp-login.php にアクセス → データベースで IP アドレスごとの失敗回数を調べる → データベースでユーザー名とパスワードを調べる → 失敗
  • wp-login.php にアクセス → データベースで IP アドレスごとの失敗回数を調べる → 失敗(403)
  • wp-login.php にアクセス → データベースで IP アドレスごとの失敗回数を調べる → データベースでユーザー名とパスワードを調べる → 失敗
  • wp-login.php にアクセス → データベースで IP アドレスごとの失敗回数を調べる → 失敗(403)
  • wp-login.php にアクセス → データベースで IP アドレスごとの失敗回数を調べる → 失敗(403)

となります。いずれにせよデータベースにはアクセスするわけで、1回の試行の負荷はどれほど違い、全体での負荷はどれほど違ってくるのでしょうか。そこまでは調べていません。

apache のモジュールで制限する

データベースへのアクセス前に制限できれば負荷を小さくできるのは明らかなので、前述の .htaccess によるものに代わる、apache のモジュールはないか探してみました。

mod_bw は回数制限ではない、mod_dosdetector は特定ページ(wp-login.php)のみに限定できない、mod_dosblock は IP アドレスごとではない……と、どれも一長一短のようです。ModSecurity だと要求にかなっていそうですが、これだけのためには機能が豊富すぎてルールが難しく、まだ理解できていません。

mod_evasive というのは、IP アドレスごとのアクセス回数を制限できますが特定ページの指定はできないようで、 mod_dosdetector と同じです。しばらくのあいだ、これを試してみることにしました。


管理するいくつかのサイトで、実情に合わせて上述の対策のいずれかをとることにしました。

  1. 実際は、1回の失敗ですぐ制限をかけるようにするため、このページのコードを少し修正しました。

WordPress 3.6 日本語版

WordPress 3.6 日本語版がリリースされました。

今回リリースリーダーを担当しました。3月の下旬、そろそろ 3.6 に向けて動き出すよという雰囲気になって以降、beta 版が4回もあるなどリリースまで時間がかかりました。関わった皆さん、ありがとうございました。また、担当は次の 3.7 がリリースされるまで続きます。もうしばらくよろしくお願いします。

実際の翻訳作業は GlotPress という仕組みを使って、多くの皆さんが協力してやってくださるので、リリースリーダーといってもその主な任務はパッケージを作ることです。3.6 正式版の前に beta 版を4回、RC 版を2回、パッケージを作って公開しました。

この手順を、RC2 のときを例にして、ちょっとご紹介しましょう。

と、その前に、日本語版パッケージは何からできているのか、をおさらいしておきます。大元は WordPress 英語版です。それにメッセージの日本語リソースです。それと、その日本語リソースではカバーできない、直接翻訳するしかないファイル(現在のバージョンでは readme.html と wp-config.sample.php くらいです)と WP Multibyte Patch です。この3つを混ぜ合わせて、日本語パッケージは作られています。

はじまりは

と、英語版のリリース情報を知るところからです。だいたい WordPress News を見ていますが、うっかりしていて誰かの tweet やほかの言語の人たちの様子で知ることもあります。

そこでパッケージ作成の作業に入ります。まず翻訳状況を確認します。翻訳作業は GlotPress で行われていて、日本語なら Japanese というところを見ると、未翻訳の数などがわかります。

前日にちらっと見たら未翻訳が残っていて、やらなきゃなあと思いながらも手を付けられずにいたのですが、夜が明けたらあら不思議、その分はもう誰かがやってくれていたのでした。

英語版でメッセージ文が追加されたり変更されたりすると、未翻訳の数が増えます。今回はそう面倒なものでもなかったので、なんとかやり終えました。beta や RC の場合は未翻訳が多少残っていてもその状態でパッケージ作成、公開することもあります。何しろテスターに見てもらうことが目的ですからね。

ここで、元になる英語版ソースのリビジョンをチェックします。

ソースの状況は Trac で公開されているので、そのコミット記録を見て、「RC2」と印が付けられたのはいつか、を調べてこの数字をメモしておきます。

直接翻訳ファイルは、この例の RC2 の前後では変化がなかったので、作業はありませんでした。もし英語版に変更があれば、それに合わせて日本語版のファイルを書き換える作業をします。

で、いよいよパッケージの作成です。wordpress.org のどこか(秘密です)にログインします。そこで「作成」ボタンをクリックすると、英語版ソース(メモしておいたリビジョンを指定します)に、GlotPress から日本語リソースを自動的に取ってきて、さらに直接翻訳ファイルも別のところから自動的に取ってきて、これらを混ぜ合わせて日本語版パッケージを作成してくれます。

この時点のパッケージの URL は一般には公開されません。

日本語作成チームの皆さんには別の方法で通知しているので、何も tweet しなくてもいいのですが。

チームの皆さんがいくつかの点についてチェックし、問題なさそうだという返事を受けて、公開します。秘密のページで「公開」をクリックすると beta や RC の場合は、「ベータ & RC バージョン」の表に載ります。

最後は告知です。「WordPress|日本語」でお知らせします。beta や RC の場合は、英語版の告知に追記してお知らせすることが多いです。

さあ、どうでしたか。あなたも日本語作成チームに参加して、リリースリーダーを担当してみませんか。

ja.po のコメント欄に見る WordPress 日本語版の歴史

WordPress 生誕10周年だそうです。WWW が生誕20周年らしい(諸説ありますが)ので、その歴史の半分くらいのところで WordPress がもうあったんですね。

さて、東京の WordPress 10周年イベントで、Nao さんが WordPress 日本語版の歴史的なお話をされるとのことで、日本語チームの一人である私にもコメントを求められました。記憶とたぐってお返事したのですが、そのあとちょっと調べてみたら意外と面白かったので、ここに書いてみます。

WordPress 日本語版

私が WordPress を使い始めたのは 2006年の初めでした。それは日本語化されたもので WordPress ME と呼ばれていました。配布サイトがあってフォーラムがあって、日本語での WordPress 情報が集まっていました。

一方、その頃にはもうひとつの日本語版が存在していました。2005年頭には WordPress 1.5 の日本語リソースが出されています。

WordPress ME は 2008年に開発が終了してサイトは閉じられ、いまでは記録が残っていないのでここでは詳しく書けません。その後は、そのもう一方の日本語版が現在の WordPress 日本語版につながっていきます。

私が翻訳チームに加わるまで

日本語リソースは 1.5 以降、svn.automattic.com/wordpress-i18n/ja/tags/ にあります。

このリポジトリは最初、tai さんがたぶんひとりで、WordPress の開発元 automattic に交渉して開設されたのだと思います。まだ私が関わる前なので詳しいことは知りません。

さて、そのなかの ja.po のコメントにその歴史が見えます。ここで一番古い 1.5 の ja.po のコメントでは tai さんひとりのクレジットで、作成日は 2005年3月4日です。2005年末の、次のバージョン 2.0 の ja.po では tai さんのほかに 2人の協力者のお名前が見えます。

2006年7月の 2.0.3 の ja.po のコメントには

#  誤字脱字誤訳、あるいはよりよい訳などありましたら以下までぜひお知らせください。
#  また、翻訳、校正、コミットをお手伝いしていただける方も随時募集中です。
#  連絡先: ....(個人のメールアドレス)

という文言が見えます。「連絡先」は個人のメールアドレスだったのが、2.1.1 の ja.po から翻訳チームのメールアドレスになっています。徐々に態勢が整えられていったようです。

はじめ WordPress ME を使っていた私は、いくつか日本語訳のおかしな所に気づいたのですが、開発者の連絡先というか、どのように要望を伝えればいいのかが(フォーラムなど充実していたにも関わらず)とてもわかりにくかったと記憶しています。またこの頃にこのもう一方の日本語版の存在に気づいて試してみていましたが、こちらにもやはり日本語訳の気になるところがありました。そこで日本語リソースを見てみて、上記の案内を見つけました。どうやらこちらの日本語版のほうが「風通し」がよさそうなので、連絡してみることにしました。ところが、翻訳チームのメーリングリストのアーカイブも公開されていたのでそれを覗いてみたら、私の報告について「そんな細かいこと、どうでもいいじゃんね。ぷ」みたいな話になっていて、がっかりしたことを覚えています。

しばらくは自分で自分のところだけ対処していたのですが、上記の案内に「お手伝いしていただける方も随時募集中」とあるし、外から報告や提案してやきもきしているよりは気が楽かなくらいの気持ちで、今度はチームに参加したいと連絡してみました。2007年3月のことでした。2.1.3 の ja.po には私の名前 Mako が見えます[1]

日本語作成チーム

ここからは手元にいくらか記録も残っていますので、少し詳しく書くことができるでしょう。

その頃は、ja.po のほかにも翻訳文を直接埋め込まなければならないファイルがいくつもあって、svn を使って各人がリポジトリにアクセスし、メーリングリストで「私がこのファイルの翻訳を担当します」と宣言して作業し、また「校正おねがいします」とあると別の人がチェックする、というような態勢でした。

私は、どうにも気になる質のようで、用字用語や点丸括弧ばかりチェックしていました。ひらがなで書くのか漢字なのか、括弧やコロンは全角なのか半角なのか、全角と半角のあいだにスペースは入れるのか……。調べているうちに「日本語スタイルガイド」のひな型を見つけたので自分のブログにそのことを書きました。このひな型を元に、翻訳チームの日本語スタイルを決めていくことになりました。このようにして、2.2, 2.3 の日本語リソースやパッケージが作られていきました。

2007年9月ころ、チーム編成に変化がありました。このころまで、アナウンスや広範な議論は(現在では存在しない)WordPress Japan のフォーラムで行われていました。その記録は残っていないので記憶に頼りますが、開設の経緯からこれまでリポジトリにコミットできたのは tai さん一人のみだったのを、このあとチーム体制にしていきたい、というような議論がたしかそのフォーラムでありました。そこで現在も活躍している有名な方々も加わり、ほぼ現在と同じチームができました。チームの連絡も現在の Google グループに移りました。こうして現在も続く、リリースごとに担当者を決めていく体制ができていきました。

2.3.1 の ja.po までは冒頭のコメントに翻訳チームとして個人の名前が列挙されていましたが、2.3.2 の ja.po からは「WordPress 日本語版作成チーム」と、すっきりした表記になりました。

WordPress.org のローカルサイト ja.WordPress.org が立ち上がったのもこのころだったかと思います。WordPress 2.3 リリースのアナウンスはこちらで行われています。その後フォーラムも立ち上がり、もうひとつの日本語版である WordPress ME に代わってこちらのほうが普及していくことになります。そして 2008年3月、WordPress ME は配布を停止してサイトは閉じられました

作業環境の変化

WordPress は世界的にも普及し、本家のほうでも国際化の環境の整備が進みました。翻訳に関わる議論は以前はメーリングリストでしたが、現在は WordPress Polyglots というサイトで行われています。私が日本語版リリースの担当だった 3.0 のころ、GlotPress という仕組みが導入されました。これまで svn リポジトリを中心とした翻訳作業が、ウェブ・インターフェースの作業になりました。これで、限られた人しか関われなかった作業が、誰でも、たった一行だけでも気軽に参加できるものになりました。2010年のことです。

gettext (ja.po など)でカバーできず、翻訳文を直接埋め込まなければならないファイルは減り続け、ほとんどの翻訳は GlotPress でできるようになりました。2013年5月現在、直接翻訳するのは wp-config-sample.php のコメント文と readme.html だけです。

ja.po のコメントを見てきましたが、2012年の 3.4 の ja.po からは、とうとう日本語作成チームの案内も消えました。GlotPress の出力をそのまま利用するようになったからです。

これから

今年また日本語版リリースを担当しています。もうすぐ出るであろう 3.6 です。

私が日本語版に関わるようになってから6年になります。英語が得意なわけでもないので、もっぱら日本語に力点を置いて、それに翻訳そのものより周辺のこと(スタイルのこととか作業手順のこととか)を微力ながらやってきました。これからチームに参加される方のためにも、もう少しきちんと形にして残したいと思っているところです。

  1. 私の名前の横にある URL は当時のものです。その後これを手放して、現存するこの URL で見えるものはまったく別の人です。

Weaver II テーマ で Youtube を埋め込む

少し前の記事

Jetpack by WordPress.com プラグインで Youtube の画を埋め込んでいるのだけれど、説明どおりにやっても小さくできない。縦は縮むのに横幅はそのまま。別の環境で見るとまたちがうのだろうか。

と書いたけれど、原因がわかった。

youtube を埋め込むには、

  1. Weaver II テーマは独自にショートコード weaver-youtube を持っているので、これを使う。横幅は percent というパラメータで指定する。
  2. 上記を使わず、Jetpack by WordPress.com プラグインのショートコード youtube を使う。ただし Weaver II テーマで設定されているスタイルと干渉する。

のどちらかによる。はじめ (a)に気づいていなかったので (b)の方法にしていた。気づいたいま、どうするか。記事を書く際にテーマやプラグインに依存した記述をすると、そのテーマまたはプラグインを外したときに変なことになる可能性がある。将来 Weaver II テーマを使わなくなる可能性と Jetpack by WordPress.com プラグインを使わなくなる可能性を比べると、後者のほうが断然低そうなので、やはり (b)の記述のままにすることにした。

さてそうすると、どちらの方法でも youtube を埋め込む iframe には class="youtube-player" が指定されているのだが、 Weaver II テーマではそれに対するスタイルが

.youtube-player {
    width: 100%;
}

と設定されていたのであった。(a)の方法では、その上で画像の横幅を制御しているのであろう。そのまま (b)の方法を使うと、前に書いたように、w=320 のような横幅指定を付けてもそれが適用されない。

ここでは、記事の記述は(b)の方法にしたので、このスタイル指定をやめるため、Weaver II テーマの設定画面の advanced Options → <HEAD> Section の Custom CSS Rules に

.youtube-player {
    width: auto;
}

と書くことにした。これでうまくいくようになった。

WordPress: フィルターより前にショートコードを実行させる

検索のしかたがよくなかったのか、日本語での情報をうまく見つけることができませんでした。そこで WordPress Code: Earlier Shortcodes をほぼそのまま訳しつつ、ここに記しておきます。

問題

僕がひっかっかった問題も、そのページのはじめにあるのとほぼ同じでした。すなわち、WordPress のショートコードは優先順位(プライオリティ)が 11 であり、そのため wpautop()wptexturize() などデフォルトのフィルター群(デフォルトの優先順位は 10)の後に実行されることになります。

たとえば

これは適当な文です。

ここに [foobar]80's pop[/foobar] などと書いたとします。

これはまた適当な文です。

という文章を書いた場合、まず wptexturize() によって 80&#8242;s pop と変換されたものが ショートコード foobar に囲まれた内容として渡され、意図しない結果になることがあります。

解決策その1

まず思いついたのはフィルターの優先順位を下げてしまおうというものでした。ちょうど Solution to WordPress adding br and p tags around shortcodes と同じです。ショートコードの処理を書くあたりに

remove_filter( 'the_content', 'wpautop' );
remove_filter( 'the_content', 'wptexturize' );
add_filter( 'the_content', 'wpautop' , 12);
add_filter( 'the_content', 'wptexturize' , 12);

と書いてしまおうというものです。

当面の問題、すなわちショートコード foobar については、これで回避されましたが、ちょっと不安が残ります。WordPress のデフォルトが「ショートコードはフィルターの後」なのですから、他の人がそれを前提に作ったものを使ったときに問題が出るかもしれません[1]

解決策その2

そこでもうしばらく検索して、最初に紹介した WordPress Code: Earlier Shortcodes を見つけました。そこにあるサンプルコードを、コメントを適当に訳しながら再掲しますと、

// これは実際には何もしない。ダミー。
add_shortcode( 'foobar', '__return_false' );
 
// ショートコードの実際の処理
function foobar_run_shortcode( $content ) {
    global $shortcode_tags;
 
    // 現在のショートコード群をバックアップをとってから、すべて削除する
    $orig_shortcode_tags = $shortcode_tags;
    remove_all_shortcodes();
 
    add_shortcode( 'foobar', 'shortcode_foobar' );
 
    // ショートコードを実行 (直前の行で加えた当該のショートコードのみ)
    $content = do_shortcode( $content );
 
    // 元のショートコード群を復元する
    $shortcode_tags = $orig_shortcode_tags;
 
    return $content;
}
 
add_filter( 'the_content', 'foobar_run_shortcode', 7 );

解説

この関数は、まず登録されているショートコードの一覧が格納されている変数 $shortcode_tags を大域変数化し、それを別の変数にコピーし(後で復元させるため)、それからそれを空にします。これで登録されているショートコードは何もありません。

ここに当該のショートコードただひとつを登録し、do_shortcode() で 内容(content)に適用します。その後で、先ほど保存しておいたショートコード群を復元して登録し(ここで当該のショートコードは抹消されるので二重に適用されることはありません)ます。そしてdo_shortcode() の返り値の内容(content)を返します。

最後に、wptexturize() より前に実行されるように優先順位をつけて(1から9の値にします。ここでは 7 にします)、フィルターとして上記の関数を登録します。

感想

それにしてもなんだかまわりくどいなあと思いました。今回見つけた記事やそこに多くのコメントがあるように、ショートコードの優先順位を変更したいという需要があるのですから、登録時に自由に優先順位を設定できる関数が WordPress 本体にあってもいいように思います。

参照した記事の最も新しいコメントはつい最近のようですし、サンプルとほぼ同じコードが本体の持っているショートコード embed にも採用されているように、いまでも(いまのところ)、この方法がこの問題の解決策のようです。

  1. 丹念に読む気は起きませんが、ショートコードの優先順位を wpautop() より下げた経緯が ticket 6444 あたりにありそうです。

Weaver II テーマ に変えてみた。それにプラグインも追加 (その2)

このサイトの見かけを変更するためにテーマを Weaver II に変えた、というのが前回のお話。ついでに、プラグインもいろいろ入れ替えたり追加したりした。

多機能プラグイン

いつからか Jetpack by WordPress.comWP Total Hacks のように、ひとつで多くの機能を持つプラグインを使うようになった。そのために不要になったプラグインを削除した。たとえば、サイト情報の統計情報のためのスマイリー[1]を隠すとか、SNS の共有ボタンの設置やそれらへの自動投稿とか、favicon の設定とか、リビジョンコントロールの制御とか……。

追加したプラグイン

Yet Another Related Posts Plugin

以前は別の何かのプラグインで表示させていたのだがいつの間にか外していたので、このプラグインでふたたび「関連するかもしれない記事」を表示させることにした。

Picasa Express x2

数か月前から写真を Google+ 経由で Picasa に置いてみている。それをこんなふうにこちらから参照するためのプラグイン。

WP-Footnotes

ずっと前から使っているのだが、その頃にはプラグインの公式ディレクトリはなかったのか、作者のサイトから直接もらってきたか何かで、更新の通知がないためにずっとバージョン 0.9.1 のままだった[2]。この機会に探してみたらうんとバージョンが上がっていた。

CSS を管理画面で設定できるようになって便利になっていた。しかし何かの拍子にこれも含め WP-Footnotes の設定全部が消えてしまうようだ[3]。そこで備忘録としてここに書いておく。

  • マークは [ ] で囲い、算用数字。上付
  • 脚注の最後の戻りマークは、カッコをつけず、&#8617;

そして脚注の CSS は次のとおり。

ol.footnotes { 
    clear: both;
    border-top: solid 1px #444;
    font-size: 0.8em;
    line-height: 1.6em;
    padding: 0 2em;
}

AdSense Now!

これまでは不向きだと思って考えてもいなかったのだが、今後書いていきたい内容からすると、広告を載せてもいいかという気になってきた。サイドバーの広告はウィジェットの「テキスト」にそのまま書くことにして、個々の記事に付ける広告にはこのプラグインを使うことにした。

Amazon Widgets Shortcodes

これも広告。文中に画像や、文字へのリンクを簡単に埋め込めそうだったので、このプラグインを入れてみた。下書きで試した程度でまだ本格的には使っていないが、便利そうだ。ビジュアルエディターでしか使えないのがちょっと残念。

【2015年12月21日追記】このプラグインはその後 WordPress 本体がバージョンアップして以来、編集画面でうまく使えなくなっていた。手でショートコードを書き込めば使えていたのだが、2015年末、このブログ全体を SSL 化するに際して、とうとう対応できなくなってしまった。長らくメンテナンスされていないこのプラグインをあきらめ、AmazonJS に乗り換えることにした。

  1. 何もしないと画面の一番下あたりに表示される smily のこと。
  2. あまりに古いのでリンクにはしないが http://www.elvery.net/drzax/2006/02/10/footnotes-0-9-plugin-for-wordpress-2-0-x/ となっているのでその頃のものだったようだ。
  3. いまのところ明らかに、 Weaver-II テーマの設定を変更して保存するとこちらの設定が消えてしまう。