しかし、記事を完全に削除するには、ゴミ箱に移動させた後、更に"ゴミ箱を空にする"ボタンを押さねばなりません。直ぐに消したい人には二度手間です。そこでゴミ箱を無効にする方法を紹介します。

この機能は、"wp-settings.php"の中で次のように定義されています。

/**
 * It is possible to define this in wp-config.php
 * @since 2.9.0
 */
if ( !defined( 'EMPTY_TRASH_DAYS' ) )
 define( 'EMPTY_TRASH_DAYS', 30 );

つまり、初期状態では記事がゴミ箱に30日間保管されます。即削除されるようにしたい場合は、"wp-config.php"に次の一行を加えます。定義を書き込む場所は"wp-settings.php"が読み込まれるより前です。上記wp-settings.phpは直接編集しないで下さい。WordPressの更新時に元に戻ってしまいます。

define('EMPTY_TRASH_DAYS', 0 );

この定義で保管期間を0日とする事により、ゴミ箱の文言が"完全に削除する"に変わり、記事を即座に消すことが可能となります。逆に保管期間を伸ばしたいときは値を増やしましょう。

ちなみに、ゴミ箱機能に付随して、プラグイン作者向けに次の4種類8つのフックAPIが提供されました。

* @uses do_action() on 'trash_post' before trashing
* @uses do_action() on 'trashed_post' after trashing

* @uses do_action() on 'untrash_post' before undeletion
* @uses do_action() on 'untrashed_post' after undeletion

* @uses do_action() on 'trash_post_comments' before trashing
* @uses do_action() on 'trashed_post_comments' after trashing

* @uses do_action() on 'untrash_post_comments' before trashing
* @uses do_action() on 'untrashed_post_comments' after trashing

プラグイン作者であればAPI名で察しがつくと思いますが、詳しくは"wp-includes/post.php"を参照して下さい。

関連記事

• 一目で解るPidginのポータブル化方法
• Windows Live メッセンジャー互換ソフト4種比較
• Firefox 3.6に潜むチャイナリスク、その回避策
• 一目で解るFilezillaでのポータブル化方法
• WordPress2.8のwp-configにphp終了タグが無い理由
• WordPressのサムネイルサイズがオリジナルより増える問題の改善パッチ
• WordPressの管理領域を守る10の方法
• WordPress2.6のメディアアップローダのバグ対処と運用方法
• WordPress2.6のリビジョン管理を無効にする方法
• Firefox3ギネス達成、ダウンロード数8兆回を超えた！？

灯台下暗し、ググるより先にWordPress本家を調べてみます。私と同じく疑問に思い問題提起した人が既に存在しました。しかし、提案は否決されています。

Ticket #10106 wp-config-sample.php missing closing PHP tag (WordPress Trac)

This is a feature, not a bug.

First, closing PHP tags are optional.

More importantly, since this is a user-edited file, it's highly likely that someone's text editor will add a line break after the closing tag, causing error messages that aren't immediately traceable. Leaving off the closing tag avoids that headache.

これはバグではなく仕様です。

第一、PHP終了タグは任意です。

更に重要なことに、これはユーザ編集用ファイルなので、テキストエディタが終了タグの後に改行コードを付加してしまう可能性が非常に高いのです。そのため、すぐに特定出来ないエラーメッセージの原因になります。終了タグを省略すれば、その頭痛の種を取り除く事が出来ます。

結果としては仕様だそうです。つまり、ユーザが編集するファイルに終了タグがあるとバグの温床になりかねないため、あえて取り除いたと言うことです。

それでは本当にPHPは終了タグを書かなくてもいいのでしょうか？PHP本家のマニュアルには次のように記されています。

PHP: 命令の分離 (php.net)

ファイル終端における PHP ブロックの終了タグはオプション（任意）です。 include() や require() を利用する際には、 終了タグを省略する方が無難です。というのは、そうすることでファイルの最後に 予期せぬ空白文字があらわれてしまうことを防げますし、後でレスポンスに ヘッダを付加することも可能となるからです。また、出力バッファリングを 使用しており、include したファイルの生成する部分の最後に余計な空白を つけたくない場合などにも便利です。

まさに今回のWordPressの問題と同じ事が書かれています。PHP本家公認です。

よくよく考えてみれば、PHPの開始タグと終了タグは、コードの始まりと終わりを明示しているだけに過ぎません。突き詰めていくと、終了タグを書かなければいけない状況は只ひとつ。HTML内にPHPコードを埋め込む時だけです。終了タグがあろうと無かろうと、最初から神経質に気にする必要は無かったのかもしれません。「タグを閉じないと気持ち悪い」、「タグが無いとファイル終端かどうか確認出来ない」と言う私のような考えの方だけ、以前のように、そっと終了タグを付け足しておきましょう。

関連記事

• WordPressのサムネイルサイズがオリジナルより増える問題の改善パッチ
• WordPress2.6のメディアアップローダのバグ対処と運用方法
• WordPress2.6のリビジョン管理を無効にする方法
• WordPress2.5.1のLightBox不具合を修正する
• WordPress 2.9以降のゴミ箱(Trash)を無効にする方法
• modx-1.0.0 evo対応のSubsite the MAD HACKリリース
• WordPressの管理領域を守る10の方法
• JavaとIrrlichtを使って3Dアプリをウェブ配信するためのチュートリアル
• APNGが普及しない2つの理由、2つの望み
• MODxサブドメイン対応版0.9.6.2

転送量を気にしてインデックスカラーのPNGをアップしたと言うのに、オリジナルよりも肥大化したフルカラーのサムネイルが生成されてしまっては、減色した意味がないですよね？これなら、元の画像をそのまま貼り付けて、imgタグのwidthとheightを小さくした方が遥かに利口です。ただでさえ、複数のサムネイルが作成されてサーバ容量が圧迫されるというのに、このままでは使わないゴミが増えていくばかりです。

そこで、インデックスカラーPNGがアップされたときは、同じ色数に減色したサムネイルを作成する改善パッチを書いてみました。

Index: wp-includes/media.php
===================================================================
--- media.php    (revision 11404)
+++ media.php    (working copy)
@@ -352,6 +352,10 @@

     imagecopyresampled( $newimage, $image, $dst_x, $dst_y, $src_x, $src_y, $dst_w, $dst_h, $src_w, $src_h);

+    // convert from full colors to index colors, like original PNG.
+    if( IMAGETYPE_PNG == $orig_type && !imageistruecolor( $image ) )
+        imagetruecolortopalette( $newimage, false, imagecolorstotal( $image ) );
+
     // we don't need the original in memory anymore
     imagedestroy( $image );

これを適用すれば、インデックスカラーPNGを多用する人も、ファイルサイズで泣かされる事が無くなります。

もっと煮詰めるなら、ディザの有無をユーザが選べるように、imagetruecolortopaletteの第二引数を管理画面で設定出来るようにしたほうが良いかもしれません。ディザ無し決め打ちにしてあるのは、そのほうがファイルサイズが小さくなる傾向にあったからと言う理由です。

一応、本家Tracに投げておきました。

Ticket #9887 Problem that PNG thumbnail size increases more than original (WordPress Trac)

改善案があったら、上記チケットにパッチをアップして下さい。Milestoneが変更されたので、もしかしたら、2.9に取り込まれるかもしれません。余裕があればテストをして、Tracにコメントを残しておいてくれると嬉しいです。

関連記事

• WordPress2.8のwp-configにphp終了タグが無い理由
• WordPress2.6のメディアアップローダのバグ対処と運用方法
• WordPress2.6のリビジョン管理を無効にする方法
• WordPress2.5.1のLightBox不具合を修正する
• WordPress 2.9以降のゴミ箱(Trash)を無効にする方法
• modx-1.0.0 evo対応のSubsite the MAD HACKリリース
• WordPressの管理領域を守る10の方法
• JavaとIrrlichtを使って3Dアプリをウェブ配信するためのチュートリアル
• APNGが普及しない2つの理由、2つの望み
• MODxサブドメイン対応版0.9.6.2

10 Steps To Protect The Admin Area In WordPress (Smashing Magazine)

1. WordPressフォルダをリネームしてからアップロード
   WordPress 2.6から、wp-contentフォルダをリネームして運用することが可能になりました。しかし、肝心のwp-adminフォルダは、この変更に未対応です。そこで、WordPressフォルダを適当な名前に変更しておき、管理アドレスを推測しにくいものに変更しましょう。管理画面の[一般設定]-[WordPress のアドレス (URL)]に実アドレス、[ブログのアドレス (URL)]に運用で使いたい仮想アドレスも設定してください。
2. wp-config.phpの拡張機能を最大限に利用する
   • WordPress 2.7から導入されたセキュリティキーを追加する
     キーの作成はsecret-keyジェネレータから。ジェネレータは稀にバージョンが上がってキーの数が増えるときがあります。
   • テーブルプレフィックスを"wp_"以外のものに変更する
     DBを直にアタックされたときに別名であればクラックされ難くなります
   • SSLが使用可能なら積極的に使う

     wp-config.php file: define(’FORCE_SSL_ADMIN’, true);

3. wp-config.phpの移動
   WordPress 2.6から、wp-config.phpをひとつ上の階層に移動させても動作します。上位階層がブラウザからアクセス出来ない領域である場合に効果的です。
4. wp-config.phpファイルを守る
   全てのプロバイダがブラウザからアクセス不可能な領域を用意しているとは限りません。もし、.htaccessが使えるならブラウザからwp-config.phpにアクセス出来ないように制限をかけましょう。

   # wpconfig.phpの防御
   <files wp-config.php>
   Order deny,allow
   deny from all
   </files>

5. adminユーザアカウントの削除
   WordPressは初回インストール時に自動的にデフォルトユーザとしてadminアカウントを作成します。この名前は容易に想像がつくため攻撃の的にされます。次の手順でadminアカウントを削除しましょう。
   1. 管理画面にてadmin権限のある別のアカウントを作成する
   2. 管理画面からログアウト
   3. 新規作成したアカウントで管理画面にログイン
   4. アカウントリストからadminを削除
6. 強固なパスワードにする
   管理領域を守る一番の方法は、アカウントのパスワードを強固にすることです。大文字小文字、数字、記号を織り交ぜた、十分に長いフレーズにしましょう。
7. wp-adminフォルダを守る
   管理領域へのログインにはパスワードが必要とは言え、フォルダの深層に自由にアクセスできる状態では不安です。.htaccessと.htpasswdを使ってwp-adminフォルダにベーシック認証をかけましょう。
8. ログインページのエラー表示を抑制
   WordPressは、ログインエラーのときにユーザ名が間違っていれば、ユーザ名が違うと教えてくれます。同様にパスワードが間違っていれば、パスワードが違うと正直に答えます。これは管理者には便利ですが、悪意のアタッカーにはクラックのためのヒントを教えているようなもの。このエラー表示を黙らせましょう。お使いのテーマのfunctions.phpに以下のコードを追記。

   add_filter('login_errors',create_function('$a', "return null;"));

9. ログイン再試行回数を制限する
   WordPressはログインエラーを記録してくれません。そのため、誰かがログインアタックを仕掛けていてもサーバのログを見ない限りは気づき難いです。Login LockDownやLimit Login Attemptsといったプラグインを使用して、ログイン試行回数を厳しく制限しましょう。
10. 最新版の維持
    WordPressは絶えずセキュリティアップデートをしています。現在のバージョンに満足しているからと言って、アップデートを怠ってはいけません。プラグインも同様です。ただし、急いでアップデートするとバグに見舞われることもあるので、更新内容を十分に確認して下さい。また、使わないプラグインの放置はセキュリティリスクが高まるため、早めに削除しておきましょう。

関連記事

• WordPress 2.9以降のゴミ箱(Trash)を無効にする方法
• WordPress2.8のwp-configにphp終了タグが無い理由
• WordPressのサムネイルサイズがオリジナルより増える問題の改善パッチ
• WordPress2.6のメディアアップローダのバグ対処と運用方法
• WordPress2.6のリビジョン管理を無効にする方法
• WordPress2.5.1のLightBox不具合を修正する
• WordPress、タグとカテゴリの相違点とは？
• WordPress2.3の同一タグが増殖する
• All in One SEO Packでウェブに優しいサイト構築を
• Value Domainからの他社への移管方法2011年版

WordPress管理画面にログインし、[設定]-[その他の設定]をクリック。[アップロード]の項目にある、[ファイルのフル URL パス (オプション)]にメディアまでのURLを入力してください。これだけです。

WordPress 2.6 and "Full URL path to files" option (WordPress Trac)

他の方法としては、既に2.6.1用にアップされている修正ファイル"Changeset 8353"を適用するのがよいでしょう。ちなみに、既にWordPress 2.6でアップロードしてしまったメディアのパスは修正されませんので、全て破棄して上げなおす必要があります。

さて、WordPress 2.6から、メディアギャラリーにて画像の説明を入れていると、画像の周りが装飾されキャプションが付加されるようになりました。以前は、「画像の説明=imgタグのalt属性」でしたが、alt属性とは無関係の項目になったようです。キャプション装飾をしたくない場合は、画像の説明を未入力のままにしておきましょう。

では、SEOにも有効な代替テキストはどこに記入すればいいのでしょうか？方法は2つあります。1つは投稿エディタをHTMLベースに切り替え、alt属性を埋める方法。もう1つはビジュアルエディタ上で以下のように設定する方法です。

1. ビジュアルエディタで画像を左クリック
2. 左上に表示された[画像を編集]アイコンをクリック
3. ポップアップした画像のプロパティの[詳細設定]-[代替テキストの編集]に代替テキストを記入

また、WordPress 2.5以上でLightBox系でキャプションが表示されなくなる問題は、WordPress2.5.1のLightBox不具合を修正するを参考にソースを修正するか、次の手順で運用してください。

1. ビジュアルエディタ上でリンク付画像をクリック
2. ツールパレットのリンクの挿入/編集をクリック
3. [タイトル]にキャプションを記入

こうも変更点が多いと、旧来の方法を再現するため頭を悩ますより、運用面でカバーしていくのが最良かもしれません。(でも、タグが増殖するバグは早く修正して欲しい)

関連記事

• WordPress2.8のwp-configにphp終了タグが無い理由
• WordPressのサムネイルサイズがオリジナルより増える問題の改善パッチ
• WordPress2.6のリビジョン管理を無効にする方法
• WordPress2.5.1のLightBox不具合を修正する
• WordPress 2.9以降のゴミ箱(Trash)を無効にする方法
• modx-1.0.0 evo対応のSubsite the MAD HACKリリース
• WordPressの管理領域を守る10の方法
• JavaとIrrlichtを使って3Dアプリをウェブ配信するためのチュートリアル
• APNGが普及しない2つの理由、2つの望み
• MODxサブドメイン対応版0.9.6.2

WordPress 2.6から、投稿記事の履歴が無限に保存されるようになりました。この機能は、何度も書き換えた後に記事を元に戻したいとき、大いに役に立ちます。特に、複数人でWikiのように編集する使い方では、変更箇所を人目で把握できるため重宝します。

しかし、日記やコラムを書く用途に、一人で運用している場合はどうでしょうか？過去の変更箇所など、全く参照しない人が多いような気がします。そういう方には、このリビジョン管理は無用の長物。データベースを圧迫するだけの厄介物です。そこで、この機能を思い切って停止させてしまいましょう。

方法はシンプル。wp-config.phpに以下の定義を追加してください。1代限りのオートセーブ以外は停止します。追加場所はwp-settings.phpを読み込む前にしましょう。wp-settings.phpではWP_POST_REVISIONS未定義の場合、リビジョン管理を有効にしようとするからです。

define ('WP_POST_REVISIONS', false);

この定義は上記以外にもオプションがあります。必要に応じて使い分けてください。

Revision Management (codex.wordpress.org)

WP_POST_REVISIONS:

• true (default), -1: 全リビジョンを保存
• false, 0: リビジョン保存停止 (1代限りのオートセーブは除外)
• (int) > 0: int数分のリビジョンを保存(+オートセーブ1代)。古い履歴は自動削除。

他の方法としては、wp-content\pluginsフォルダに次のような内容のプラグインをインストールすればOKです。ただし、公式アナウンスではないため非推奨です。

 <?php
/*
Plugin Name: no Revision Management
Plugin URI: http://etwas.wolfish.org/blog/2008/07/17/2008071701/
Description: Remove 'wp_save_post_revision' action.
Author: MadHyde
Author URI: http://etwas.wolfish.org/
*/

remove_action( 'pre_post_update', 'wp_save_post_revision' );
?>

WordPressは使いやすく機能追加も活発な反面、新機能のON/OFFを制御できる管理画面が未整備なのが残念ですね。

2008.07.27追記 - 最大履歴数も指定できるプラグインが登場しました。 Revision Control (WordPress.org)

関連記事

• WordPress2.8のwp-configにphp終了タグが無い理由
• WordPressのサムネイルサイズがオリジナルより増える問題の改善パッチ
• WordPress2.6のメディアアップローダのバグ対処と運用方法
• WordPress2.5.1のLightBox不具合を修正する
• WordPress 2.9以降のゴミ箱(Trash)を無効にする方法
• modx-1.0.0 evo対応のSubsite the MAD HACKリリース
• WordPressの管理領域を守る10の方法
• JavaとIrrlichtを使って3Dアプリをウェブ配信するためのチュートリアル
• APNGが普及しない2つの理由、2つの望み
• MODxサブドメイン対応版0.9.6.2

この問題は、リンクタグaにtitle属性が付与されなくなったことが原因。LightBoxはaタグのtitle属性を読み込んで画像の説明に使っています。以下修正箇所。

//wp-admin\includes\media.php
function get_image_send_to_editor($id, $alt, $title, $align, $url='', $rel = false, $size='medium') {

	$html = get_image_tag($id, $alt, $title, $align, $size);

	$rel = $rel ? ' rel="attachment wp-att-'.attribute_escape($id).'"' : '';

	if ( $url )
//		$html = "<a href='".attribute_escape($url)."'$rel>$html</a>";
		$html = "<a href='".attribute_escape($url)."'$rel title='".attribute_escape($title)."')>$html</a>"; //Modified

	$html = apply_filters( 'image_send_to_editor', $html, $id, $alt, $title, $align, $url, $size );

	return $html;
}

ちなみにaタグから消えたtitle属性はimgタグに移っていました。こちらは構文的に存在OKなので書き換えていません。LightBox系スクリプトが完全動作しなくてお困りの方は試してみてください。

願わくば、次の更新で修正されていますように…。

関連記事

• WordPress2.8のwp-configにphp終了タグが無い理由
• WordPressのサムネイルサイズがオリジナルより増える問題の改善パッチ
• WordPress2.6のメディアアップローダのバグ対処と運用方法
• WordPress2.6のリビジョン管理を無効にする方法
• WordPress 2.9以降のゴミ箱(Trash)を無効にする方法
• modx-1.0.0 evo対応のSubsite the MAD HACKリリース
• WordPressの管理領域を守る10の方法
• JavaとIrrlichtを使って3Dアプリをウェブ配信するためのチュートリアル
• APNGが普及しない2つの理由、2つの望み
• MODxサブドメイン対応版0.9.6.2

カテゴリは階層構造を持ち1つのエントリーは1カテゴリのみに属す。タグは階層構造を持たず、1つのエントリーは複数のタグに属す。

しかし、WordPressでは1つのエントリーに複数のカテゴリーを与えることができます。もはや、この状態はタグの使い方と同じです。

そう言うわけで、この二つは非常に曖昧な関係。ただ名称が変わっただけと言う印象があります。もっとも、階層構造を持たない分、タグは劣化してると思わざるを得ないのですけどね。以上、使い慣れたカテゴリを放棄しタグの運用方法を模索している八環でした。

蛇足ながら、検索すると私と似た考えの方もいるようです。

タグとカテゴリーの比較文化論 (うるめねっと技研 - Linux派 -)

[カテゴリー]

• カテゴリーの数は比較的少ない
• 階層化された分類になっている
• 記事は１つのカテゴリーに属する
• カテゴリー間の記事数は均等な方が美しい
• カテゴリーは複数記事のサマリーのような名称になっている

[タグ]

• タグの数は多い
• タグ間の関係は特になく、フラットな構造になっている
• 複数のタグの組み合わせで記事の内容を説明する
• タグの使用回数は偏っている。やたら使われるタグと全然使われないタグが出て来る
• タグには標準的なキーワードが使われる

関連記事

• WordPress 2.9以降のゴミ箱(Trash)を無効にする方法
• WordPress2.8のwp-configにphp終了タグが無い理由
• WordPressのサムネイルサイズがオリジナルより増える問題の改善パッチ
• WordPressの管理領域を守る10の方法
• WordPress2.6のメディアアップローダのバグ対処と運用方法
• WordPress2.6のリビジョン管理を無効にする方法
• WordPress2.5.1のLightBox不具合を修正する
• WordPress2.3の同一タグが増殖する
• All in One SEO Packでウェブに優しいサイト構築を
• Value Domainからの他社への移管方法2011年版

例えば、タグ名「コミック」、タグスラグ「comic」にしていたとしましょう。このとき、投稿時にタグ記入欄へ「コミック」と入力してしまうと、タグ名「コミック」、タグスラグ「コミック」と言う別IDのタグが作られてしまうのです。回避方法を見つけたので、改善されるまで下記方法で運用してみてください。

[対象者]
タグ名は日本語、タグスラグは英数字で運用したい人向け

[回避方法]
方法1：タグ記入欄に日本語タグ名を入力せず、タグスラグを書き入れる
方法2：タグ入力支援プラグインを使う(後述)

[プラグイン]
Advanced Tag Entry
タグスラグを基準にタグの追加と削除が可能
Simple Tags
重複タグを統合したり、タグスラグを編集したいときに使用。ただし、オプション機能のキーワード埋込は日本語が文字化けするので使わないほうがいい

その他、2.3のタグについて詳しく知りたい場合はps*wikiを参照してください。

タグ付け機能 (ps*wiki)

関連記事

• WordPress 2.9以降のゴミ箱(Trash)を無効にする方法
• WordPress2.8のwp-configにphp終了タグが無い理由
• WordPressのサムネイルサイズがオリジナルより増える問題の改善パッチ
• WordPressの管理領域を守る10の方法
• WordPress2.6のメディアアップローダのバグ対処と運用方法
• WordPress2.6のリビジョン管理を無効にする方法
• WordPress2.5.1のLightBox不具合を修正する
• WordPress、タグとカテゴリの相違点とは？
• All in One SEO Packでウェブに優しいサイト構築を
• Value Domainからの他社への移管方法2011年版

WordPressはSEO的に問題のあるスクリプトです。HTMLソースを多少理解している人なら、すぐに気づくのではないでしょうか？

さて、どこが問題か？それは、1つの記事が複数のURIから導き出せる事です。記事別エントリーだけが検索エンジンにインデックスされるのは喜ばしい事です。検索して来てくれた人も、すぐに目的のページを閲覧できます。しかし、カテゴリや月別アーカイブをインデックスされてしまったらどうなるでしょう？記事が増えるにつれアーカイブ内の位置がずれていきます。検索で辿り着いた人は、案内されたページに該当記事を発見できず、後続のページを検索する手間を強いられます。

そう言う訳で最低限やっておくべきことは、カテゴリ別、月別アーカイブをインデックスさせない事です。このAll in One SEO Packは、HTMLソース内に以下のタグを挿入して必要なページだけを検索エンジンに見てもらうようにしてくれます。

<meta name="robots" content="noindex,follow">

また、このプラグインはタイトル出力方法の変更やキーワード挿入も可能にしてくれます。 複数の対策を施したい人は導入を検討してみてください。

ただし、rss feedが検索エンジンにインデックスされる問題は解決しません。こちらはrobots.txtでの対応となります。先のアーカイブインデックス問題も、実はこちらだけで対策出来ます。robots.txtに以下の文を記述して、ルートディレクトリに置いておきましょう。例は「全ての検索エンジンにfeedとアーカイブのインデックスを許さない」という記述です。

User-agent: *
Disallow: /foo/rss-feed/
Disallow: /foo/archive/

この他にAll in One SEO Packはタイトルの表示方法等も設定出来ますので、訪問者が見やすいように修正しておくといいでしょう。

関連記事

• WordPress 2.9以降のゴミ箱(Trash)を無効にする方法
• WordPress2.8のwp-configにphp終了タグが無い理由
• WordPressのサムネイルサイズがオリジナルより増える問題の改善パッチ
• WordPressの管理領域を守る10の方法
• WordPress2.6のメディアアップローダのバグ対処と運用方法
• WordPress2.6のリビジョン管理を無効にする方法
• WordPress2.5.1のLightBox不具合を修正する
• WordPress、タグとカテゴリの相違点とは？
• WordPress2.3の同一タグが増殖する
• Value Domainからの他社への移管方法2011年版