ダリの雑記：WEBプログラム版

WordPressメモ。

サイトの検索にて、post_typeを絞ろうと、functions.phpに

function include_post_type($query) {
	if ($query->is_search()) {
		$query->set('post_type', array('post','xxx','xxx'));
	}
}
add_action( 'pre_get_posts', 'include_post_type' );

と記述したのですが、管理画面の検索にまでこれが反映されてしまいました。

正確には

function include_post_type($query) {
	if (!$query -> is_admin && $query->is_search()) {
		$query->set('post_type', array('post','xxx','xxx'));
	}
}
add_action( 'pre_get_posts', 'include_post_type' );

というように、「!$query -> is_admin」も必要だったみたいですね。

いきなり管理画面の検索がおかしくなったからあせったわ～^^;

参考サイト

query_postsを捨てよ、pre_get_postsを使おう【追記あり】【報告あり】 | notnil creation weblog

Joruriというか、Ruby on Railsを始めたばかりのど素人のメモ。

Joruri CMSには残念ながら「カスタムフィールド」という機能が存在しません。

ということで任意の入力フィールドを追加する場合、データベースから操作する必要があります。

ちなみに自分が使っているJoruri CMSのバージョンは「1.3.2」です。

以下、「コンテンツ種別：記事」の、ページ新規作成・編集画面に、「備考」入力フィールドを追加してみた手順です。

1. DBの「article_docs」テーブルに「remark」カラムを追加。
   カラム名：remark
   種別：TEXT
   NULL：チェック
2. app/views/article/admin/docs/_form.html.erb
   を編集。
   「内容」フィールドの下あたりにこんな感じで追加。

   <tr>
   <th colspan="1">備考</th>
   <td colspan="3"><%= f.text_area :remark, :rows => '3', :class => ' remark ', :style => 'width: 500px;' %></td>
   </tr>
   

3. apache再起動。（これしないと反映されない）
4. app/views/article/public/node/docs/show.html.erb
   を編集。
   表示させたい部分に、

   <%= @item.remark %>
   

   と記述する。

5. apache再起動。

apacheを再起動させる理由は、そうしないとviewの編集内容が反映されないからですが、キャッシュを削除する方法さえわかれば、わざわざapacheを再起動させる必要はないかと思います。
これについてはまだ調査中。
viewレベルの変更でapache再起動はさすがにしんどい^^;

まだ開始したばかりなので、いろいろと分かってない部分がありますが、なんとか任意のフィールドを追加したり、カスタマイズできそうですね。

【追記　2013/06/27】

キャッシュの削除方法分かりました。

config/environments/production.rb

の

config.cache_classes
config.action_controller.perform_caching
config.action_view.cache_template_loading

をすべてfalseにすると、再起動させる必要が無くなり、viewやcontrollerの更新がすぐに反映されます。

config.cache_classes = false
config.action_controller.perform_caching = false
config.action_view.cache_template_loading = false

こちらのサイトを参考にさせていただきました。

mongrelを再起動させずにRailsアプリのコードの修正を反映させる日々の階段を。 - このブログは証明できない。

Custom Field Templateプラグインを使用すると、投稿時に入力フィールドを任意に増やせるカスタムフィールドを作ることが出来ます。

↓こういうの

追加ボタンを押すことで、フィールドを増やしていけるわけですが、入力はともかく、取り出し方には注意が必要です。

通常、カスタムフィールドを取り出す場合

<?php $meta_values = get_post_meta($post_id, $key, $single); ?>

$post_id：投稿ID
$key：カスタムフィールド名
$single：取得方法。配列ならfalse、１つめだけならtrue

というふうに取り出すのですが、これで取り出すと、複数フィールドの並び順がばらばらで取得されてしまいます。

しかも投稿を編集するたびに並び順が変わるという困った状態に。

なぜ上から順に取り出してくれない・・・

ということで、検索したところ、こちらの方法で解決しました。

Custom Field Template（カスタムフィールドテンプレート） | WordPress 編

複数フィールドを上から順に取り出す場合はsqlをつかって取り出します。

複数フィールドのカスタムフィールド名が「Hoge」とした場合

<?php
global $wpdb;
$query = "SELECT * FROM ".$wpdb->postmeta." WHERE post_id = ".get_the_ID()." AND meta_key = 'Hoge' ORDER BY meta_id ASC";
$cf = $wpdb->get_results($query, ARRAY_A);

$Hoge = array();
if($cf){
foreach($cf as $row){
$Hoge[] = $row['meta_value'];
}
}
?>

これで複数フィールドの並び順（meta_id）順でデータを取得することができます。

$term

これだけです。

echo $term;

とすると、タクソノミーのスラッグ名が表示されます。

さらに「get_term_by」を使用すると、そのタクソノミーの情報を取得できます。

$the_term = get_term_by("slug", $term, "タクソノミー名");

うかつに、$termに変数を代入してしまわないよう注意しましょう。

ほかにも、

投稿記事ページで記事の情報を取得できる「$post」

カテゴリーアーカイブページでカテゴリーIDを取得できる「$cat」などがあります。

参照サイト

• グローバル変数・定数：WordPress私的マニュアル
• get_term_by:WordPress私的マニュアル
• スラッグからカテゴリIDを取得する

カテゴリページで現在の階層の深さを取得する方法は以下のようにMTParentCategoriesを使用します。

<MTSetVar name="category_depth" value="0">
<MTParentCategories>
<MTSetVar name="category_depth" op="++">
</MTParentCategories>

あとは<MTGetVar name="category_depth">で取得できます。（トップレベルは1になります。）

一発で取得できるタグがあるといいんですけどね。

MT5.2.2にて、記事のプレビューを見るとMTのエラーが表示されてしまうという現象が発生しました。

エラーは

再構築エラー: ～
～～～～～～～
～～～～～～～
～～～～～～～
<mtEntryCategories>タグでエラーがありました:
<mtCategoryArchiveLink>タグでエラーがありました:
カテゴリアーカイブを公開していないので<$MTCategoryArchiveLink$>は使えません。

というもの。

一応この部分は

<MTIf tag="EntryCategory">
<MTEntryCategories type="primary">
<a href="<$MTCategoryArchiveLink$>"><$MTCategoryLabel$></a>
</MTEntryCategories>
</MTIf>

という風に条件分けしたのですが、やっぱりプレビューでエラーが出てしまいます。

もちろん再構築では問題ありませんし、プレビューをしない場合はちゃんと保存もできるのですが、一度プレビューでこのエラーが出てしまうとまともに保存もできなくなってしまいました。

解決方法は、プレビューかどうかの条件文を追加すること

<mt:Unless name="preview_template">
<MTIf tag="EntryCategory">
<MTEntryCategories type="primary">
<a href="<$MTCategoryArchiveLink$>"><$MTCategoryLabel$></a>
</MTEntryCategories>
</MTIf>
</mt:Unless>

<mt:Unless name="preview_template">～</mt:Unless>でプレビューではない場合という条件文になります。

参考サイト

MovableType プレビュー画面判別用変数について｜ホームページ制作のプラルトweb

WordPressをデフォルトの設定で、ゆるゆるのパスワードにしていると簡単に抜かれてしまうということが分かった今日この頃。

ということで、いろいろとサイトを見たり、実践したりしたことをまとめることにしました。

門を固める

そもそもログイン画面で敵を止める必要があります。（理想はログイン画面にすら到達できなくすることですが）

パスワードの複雑化

パスワードについては最近こんな記事がありました。

2万5000年かかっても破られない究極パスワードの設定方法（1/4） - ウレぴあ総研

どんなものかと思いきや、実は12桁にするだけでまず抜かれないパスワードになるとのこと。（もちろん半角英数字、大文字小文字まぜこぜの辞書アタックにも引っかからない文字列で構成されたものです。）

よく８ケタ推奨といいますが、今では８ケタは危ないらしいです。

12桁だっていずれは危なくなるでしょうが、とりあえず今のところは12桁以上にしておいたほうがよいでしょう。

リトライの回数制限を設ける

デフォルトでは、Wordpressは何度でもログインのチャレンジができます。

これではいつか破られるかもしれません。

というわけで、プラグインを使って回数制限を設けましょう。

リトライの回数制限を設けるプラグイン：Limit Login Attempts

指定した回数失敗すると、しばらくログインできなくなり、またそんなことがあった場合メールで知らせてくれたりします。

万が一ログインされてしまったら

万が一ログインされてしまった場合でも、被害を最小限に留める必要があります。

出力される内容はエスケープする

スクリプトを埋め込まれないよう、よほどコードを書いたりするサイトでない限り、出力されるものはすべてエスケープ処理をしておきましょう。これはテンプレートを地道に編集するしかないです。

もちろん内容フィールドのpタグやaタグなどまでエスケープされては困りますが、scriptという記述を全角に置換したり、strip_tagsで許可したタグのみ出力されるようにすれば、投稿記事に悪意のあるスクリプトを埋め込まれてそのまま出力されると言う心配は少なくなります。

あと、投稿にPHPを書けるプラグインを入れるのも、できるだけやめましょう。

テーマを管理画面から編集できなくする

テーマは管理画面から編集できなくしておいたほうが良いでしょう。

通常、メニューの外観＞テーマ編集で管理画面からもテーマを編集することができますが、wp-config.phpに

define('DISALLOW_FILE_EDIT', TRUE);

と記述すると、メニューから「テーマ編集」が消え、編集画面が表示できなくなります。

サイト構築中であれば必要かもしれませんが、公開後はそれほど触ることもありませんし、直上げすれば済むことですので、この設定をしておいたほうが良いかと思います。

ちなみにプラグイン編集もできなくなります。

プラグインでテーマが正常か確認する

テーマに異常がないか確認してくれるプラグイン：AntiVirus

このプラグインは、手動でもスキャンできますし、設定しておくと１日ごとに定期スキャンをし、異常があったときはメールで知らせてくれるという便利機能まであります。

注意点として、いいね！ボタンなどのiframeにまで反応してしまうので、最初の手動スキャンで個別に許可しておきましょう。

その他としては

• WordPressのバージョンを常に最新にする。
• プラグインも常に最新のものにする。
• wp-config.php、htaccessにはアクセスできなくする。
• 可能であれば管理画面はSSL接続する。
• 可能であれば管理画面にアクセスできるIPを制限する。
• WordPressのバージョンを隠す。
• ユーザー名に「admin」は使わない。ある場合は同権限のユーザーを作って削除するか、通常以上の複雑なパスワードを施す。
• 定期的にバックアップは取る。
• 定期的にパスワードを変更する。

といったところでしょうか。

サイトの性質上できないものや、そもそも効果があるのか疑問なものもありますが、やれるものであればやっておいて損はないかと思います。

参照サイト

WordPressのセキュリティを徹底強化 | CSSPRO

WordPress のセキュリティ、こんな記事は要注意 | 8bitodyssey.com

WordPressのセキュリティをアップする11のポイント | コリス

メモ。

MTをテストサーバから本番サーバへ移転したところ、MTにログインした時、以下のようなエラーが出てしまいました。

必要なモジュールが見つかりません Digest::SHA

Digest::SHAモジュールが入っていないから、戻ってねとのこと。

しかしmt-check.cgiでは、MT動作しますよと言われたのだから、これが入ってなくても問題なく動作するはずなんだけどなぁ・・・

ひとまず、普通にMTをインストールしてみて、新規に作成されたデータベースと、テストサーバから移転してきたデータベースとを見比べてみることにしました。

見比べてみた結果、「mt_author」テーブルの「author_password」というフィールドの値が、新規に作成されたデータベースの方は「{SHA}〇〇〇〇・・・」、移転してきたデータベースの方は「〇〇〇〇・・・」となっており、キーとなると思われる{SHA}の有無が確認されました。

「{SHA}〇〇〇〇・・・」の方の値をまるごとコピーし、移転してきたデータベースの方の「author_password」フィールドに上書きしたところ、正常にログインすることができました。（もちろんこの時のログインパスワードは、新規に作成したほうのパスワードです。）

MT移転には注意が必要ですね。

メモ。

ファーストサーバのライトビズにて、MTをインストールしようとしたところ、テーブルの作成段階で以下のエラーが表示されてしまい、インストールが止まってしまいました。

Connection error: Too many connections

何度やってもダメ。

どうやらDBサーバの調子が悪い時か、コネクションが多すぎる場合に出るようなのですが、契約直後のサーバなのにコネクションが多すぎるということはないはず・・・（共有サーバだから他の利用者がコネクションしまくっているということはあるのか？）

いろいろと調べた結果、「max_connections」を引き上げるといいみたいということが分かり、この値を100に変更してみることにしました。

phpMyAdminにて、以下のSQLを実行。

set global max_connections=100;

その後、インストール作業を再開したところ、何とかインストールが完了。

ちなみに

show status like 'Max_used_connections';

にて、コネクション最大値を調べたところ、設定前が「11」。設定後が「18」になりました。

デフォルトは11ってことなのかな？

【追記2013/02/12】

どうやらMT5.2.2自体に問題があるそうです。
MT5.2.3なら大丈夫みたい。

http://www.movabletype.jp/documentation/mt5/release/movable-type-523.html

参考サイト

MySQLのチューニング？ - satospo

メモ。

MT４系からMT5.2.3にバージョンアップしたところ、ブログ記事が存在しないカテゴリーアーカイブページが無くなってしまいました。

どうもMT5.2.2からこんな仕様になってしまったらしいです・・・（仕様というかバグというか）

これは困った。

親カテゴリーには記事が無くても、サブカテゴリーには記事があるというようなこともあるので、親カテゴリーページがなくなったら辿れなくなってしまいます。

パンくずリストだってリンク切れちゃうし。

MT5.2.2では以下のような解決方法が紹介されてました。

ブログ記事がないカテゴリアーカイブが出力されない(MT5.2.2) - The blog of H.Fujimoto

しかし環境の問題なのか、バージョンが違うせいなのか、プラグインの相性問題なのか、上記の方法ではどうにもならず・・・

完全にお手上げ状態＼(^o^)／

仕方ないから、本文が空のエントリーを作って、該当カテゴリーに所属させ、テンプレートで

<MTEntries include_subcategories="1">
<MTIf tag="EntryBody">
～
</MTIf>
</MTEntries>

という風にして対応しました。（include_subcategories="1"はサブカテゴリの記事も表示するというもの。）

しかし何とかしてほしい・・・

MT5.2.2または5.2.3にバージョンアップする際はご注意ください！