ではどうするのか？
the_date()にはブラウザに直接出力せず、PHPの変数に結果を戻す方法(第4引数をfalseにする)があるのでそれを使うか、もしくはthe_time()関数を使いましょう。
ではどうするのか？
the_date()にはブラウザに直接出力せず、PHPの変数に結果を戻す方法(第4引数をfalseにする)があるのでそれを使うか、もしくはthe_time()関数を使いましょう。
postfixでは簡単にこれが実現出来ます。(全メールをbccする)
centosの場合
/etc/postfix/main.cf
------------------------------------------------
always_bcc = [転送するメールアドレス]
------------------------------------------------
この1文を追加してリロード(service postfix reload)したら完了です。
なお、上記では送受信メール共にbccされますが、送信メールだけチェックしたいというような場合は「sender_bcc_maps」、受信メールだけの時は「recipient_bcc_maps」を使うことで実現可能です。(postfix2.1以上)
]]>postfixでは簡単にこれが実現出来ます。(全メールをbccする)
centosの場合
/etc/postfix/main.cf
------------------------------------------------
always_bcc = [転送するメールアドレス]
------------------------------------------------
この1文を追加してリロード(service postfix reload)したら完了です。
なお、上記では送受信メール共にbccされますが、送信メールだけチェックしたいというような場合は「sender_bcc_maps」、受信メールだけの時は「recipient_bcc_maps」を使うことで実現可能です。(postfix2.1以上)
]]>ずばっと結論ですが、テーマフォルダのトップディレクトリにあるfunctions.phpに置きましょう。
（ファイルがない場合は新規で作成して下さい。）
これで全てのテーマ関連ファイルから利用することが出来ます。
]]>ずばっと結論ですが、テーマフォルダのトップディレクトリにあるfunctions.phpに置きましょう。
（ファイルがない場合は新規で作成して下さい。）
これで全てのテーマ関連ファイルから利用することが出来ます。
]]>WPには$wp_queryというグローバル変数があり、ここにシステムに必要なほとんどの情報が入っています。
従ってこの変数の中から必要なものを直接アクセスすれば大抵は解決しちゃいますね。
var_dumpしてサンプルを置こうかと思いましたが、大きすぎるためやめときます。。。
]]>WPには$wp_queryというグローバル変数があり、ここにシステムに必要なほとんどの情報が入っています。
従ってこの変数の中から必要なものを直接アクセスすれば大抵は解決しちゃいますね。
var_dumpしてサンプルを置こうかと思いましたが、大きすぎるためやめときます。。。
]]>CSSで実現する方法もありますが、画像が多いと面倒なのでJavascriptを使うことにしました。
Javascriptでこれを実現するためのスクリプトは数多くありましたが、ソースへの追記が少なくて済むという観点で以下のものがよいなぁ～という結論に。
手軽に画像のロールオーバー効果を実装するJavaScript
prototype.js等外部ライブラリへの依存が一切無いところも良いですね。
【使い方】
１．マウスオーバーさせる部分のimgタグに「class="rollover"」を追加。
２．マウスが乗っていないときの画像をa.gifとするとマウスオーバー用にはa_on.gifというように「_on」を追加したファイルを用意する。
これだけです。
ファイルへの追加文字の規則変更等はオプションで指定できます。
CSSで実現する方法もありますが、画像が多いと面倒なのでJavascriptを使うことにしました。
Javascriptでこれを実現するためのスクリプトは数多くありましたが、ソースへの追記が少なくて済むという観点で以下のものがよいなぁ～という結論に。
手軽に画像のロールオーバー効果を実装するJavaScript
prototype.js等外部ライブラリへの依存が一切無いところも良いですね。
【使い方】
１．マウスオーバーさせる部分のimgタグに「class="rollover"」を追加。
２．マウスが乗っていないときの画像をa.gifとするとマウスオーバー用にはa_on.gifというように「_on」を追加したファイルを用意する。
これだけです。
ファイルへの追加文字の規則変更等はオプションで指定できます。
<?php $post_time = strtotime(the_date('Y-m-d H:i:s', '', '', false)); ?>
これで変換できます。
srttotime()はphpの標準関数ですので、不明点があればphpの仕様を確認しましょう。(こちら)
似たような関数としてthe_time()がありますがこれは結果をphpに戻せないのでNGです。
]]>方法としてはカテゴリースラッグを使って読み込むサイドバー(今回はwidgetではなく独自のサイドバー)のソースを入れ替えるというもの。
カテゴリースラッグの取得は
<?php
$cat = get_the_category();
$cat_name = $cat[0]->category_nicename;
?>
これだけで出来ます。
これを必要な部分（今回はサイドバーの読込）で使います。
<?php @include(TEMPLATEPATH . '/_sidebar-' . $cat[0]->category_nicename . '.php'); ?>
スラッグでなくIDを使ってもよいのですがわかりづらいのでスラッグで。
]]>以下その方法です。
１．コマンドプロンプトを開く
スタートメニューから「ファイル名を指定して実行」を選び「cmd」と入力。
２．サービス登録の確認
C:\WINDOWS\system32\sc query [SERVICE_NAME]」と入力しサービスが登録されている事を確認。
３．サービスの削除
C:\WINDOWS\system32\sc delete [SERVICE_NAME]」と入力して削除。
以上XPでの削除方法ですが、2003でも同様に削除可能です。
]]>以下その方法です。
１．コマンドプロンプトを開く
スタートメニューから「ファイル名を指定して実行」を選び「cmd」と入力。
２．サービス登録の確認
C:\WINDOWS\system32\sc query [SERVICE_NAME]」と入力しサービスが登録されている事を確認。
３．サービスの削除
C:\WINDOWS\system32\sc delete [SERVICE_NAME]」と入力して削除。
以上XPでの削除方法ですが、2003でも同様に削除可能です。
]]>そこで出会った様々な問題を備忘録としてまとめておこうと思います。
まず、バージョンが大きく異なるわけですが、
日本のWordPressMe本家ではかる～く、ファイルを上書きして
アップデート処理をすれば大抵は問題ないと記載されていました。
それを信じてそのまま実行したわけですが。。。
確かに動くことは動くのですが、管理画面のメニューなどが英語に
なってしまいましたT-T
ネットでさくっと調べたところ
「WordPressMEをアップデートしたら管理画面が英語になってしまった場合の対処法は？」
というまさにビンゴな感じのコンテンツがあったので参考にして
変更を加えてみましたが結果はNG。。。
結局問題の根幹は設定ファイル(wp-condig.php)の設定内容でした。
2.2.3にあわせて設定をしないといけなかったのです。
(言語設定関係が変わってますね)
普通なら当然設定ファイルはチェックするべきところではありましたが
「単純に上書きして動く」という案内に見事にだまされたわけです><
とうことで上記2つの対策をしたら無事管理画面も日本語となりました。
]]>そこで出会った様々な問題を備忘録としてまとめておこうと思います。
まず、バージョンが大きく異なるわけですが、
日本のWordPressMe本家ではかる～く、ファイルを上書きして
アップデート処理をすれば大抵は問題ないと記載されていました。
それを信じてそのまま実行したわけですが。。。
確かに動くことは動くのですが、管理画面のメニューなどが英語に
なってしまいましたT-T
ネットでさくっと調べたところ
「WordPressMEをアップデートしたら管理画面が英語になってしまった場合の対処法は？」
というまさにビンゴな感じのコンテンツがあったので参考にして
変更を加えてみましたが結果はNG。。。
結局問題の根幹は設定ファイル(wp-condig.php)の設定内容でした。
2.2.3にあわせて設定をしないといけなかったのです。
(言語設定関係が変わってますね)
普通なら当然設定ファイルはチェックするべきところではありましたが
「単純に上書きして動く」という案内に見事にだまされたわけです><
とうことで上記2つの対策をしたら無事管理画面も日本語となりました。
]]>システムとしては
・OS CentOS4.6
・MTA postfix
・SMTP Courier-imap
でバーチャルドメイン(postfixadmin)運用。
さらにMaiaMailguardでスパム、
ウィルス対策(spamassassinとclamav)をしています。
まぁこれだけいろいろなシステムが絡み合うと、
それなりに調整する必要は出てくるわけですが、
今回の場合は認証方法がそれにあたりました。
セキュリティー的には良くないのでしょうが、
最終的にはPlainTextで認証処理をするように設定しました。
当初は特に問題なく動いていたのですが、
いつの間にかsquirrelmailにログインできなくなる問題が発生。
しかも確実にNGな訳ではなくかなり低確率ではあるものの
ログインできる場合もあるのです。
はじめはブラウザ等クライアント側を疑ったのですが
原因がなさそうだったので、少し気合いを入れて調査してみました。
すると。。。
squirrelmailのパスワード処理に不具合がっぽいものを確認。
パスワードを暗号化して復号化する際に、元のパスワードに戻らないのです^^;
ランダムデータとbase64にて暗復号化をしているのですが
この処理方法がどうやら問題ありのようです。。。
ということでこの暗復号化処理を間違いなく実行できるように変更。
この修正を実施後は問題なく動作するようになりました^^
具体的な修正内容については・・・
あまりにもやっつけな方法なので公開できません（ぉぃ
もう少し修正方法を検討してみて、良い方法が見つかったら
公開させていただこうと思います m(_ _)m
# ネットで検索しても困っている人はいないようなので
# 多分必要のない情報でしょう^^;
システムとしては
・OS CentOS4.6
・MTA postfix
・SMTP Courier-imap
でバーチャルドメイン(postfixadmin)運用。
さらにMaiaMailguardでスパム、
ウィルス対策(spamassassinとclamav)をしています。
まぁこれだけいろいろなシステムが絡み合うと、
それなりに調整する必要は出てくるわけですが、
今回の場合は認証方法がそれにあたりました。
セキュリティー的には良くないのでしょうが、
最終的にはPlainTextで認証処理をするように設定しました。
当初は特に問題なく動いていたのですが、
いつの間にかsquirrelmailにログインできなくなる問題が発生。
しかも確実にNGな訳ではなくかなり低確率ではあるものの
ログインできる場合もあるのです。
はじめはブラウザ等クライアント側を疑ったのですが
原因がなさそうだったので、少し気合いを入れて調査してみました。
すると。。。
squirrelmailのパスワード処理に不具合がっぽいものを確認。
パスワードを暗号化して復号化する際に、元のパスワードに戻らないのです^^;
ランダムデータとbase64にて暗復号化をしているのですが
この処理方法がどうやら問題ありのようです。。。
ということでこの暗復号化処理を間違いなく実行できるように変更。
この修正を実施後は問題なく動作するようになりました^^
具体的な修正内容については・・・
あまりにもやっつけな方法なので公開できません（ぉぃ
もう少し修正方法を検討してみて、良い方法が見つかったら
公開させていただこうと思います m(_ _)m
# ネットで検索しても困っている人はいないようなので
# 多分必要のない情報でしょう^^;
・ICANN Blog (ICANN本家のブログ－英語)
・JPNIC（上記ページを翻訳した情報－日本語）
今までのアドレスも半年間は継続して利用することが約束されているそうですが
最終的にはサービスを停止するとのことですので、これに伴いネームサーバーを
運用している人はルートサーバー情報を書き換える必要がでてきました。
善は急げということでBINDでいくつか運用しているサーバーの設定を変更してみました。
まだ対処がお済みでない人は参考になれば幸いです＾＾
方法はとても簡単
BIND8の場合
# locate named.root
/var/named/named.root
こんなかたちで見つけましょう。locateが使えない人はfindコマンドで。
# vi /var/named/named.root
. 3600000 NS L.ROOT-SERVERS.NET.
L.ROOT-SERVERS.NET. 3600000 A 198.32.64.12
↓変更
. 3600000 NS L.ROOT-SERVERS.NET.
L.ROOT-SERVERS.NET. 3600000 A 199.7.83.42
リロードする場合
# /sbin/service named reload
リスタートする場合
# /sbin/service named restart
BIND9の場合
named.caというファイルが編集対象となるだけで後はBIND8と同じです。
はい、お疲れ様でした！＾＾
しかしルートサーバーのIPアドレス変更ってどうなのかと。。。
結局昔のIPアドレスでの運用は停止できずそのまま継続して使われる気がしないでもない＾＾；
・ICANN Blog (ICANN本家のブログ－英語)
・JPNIC（上記ページを翻訳した情報－日本語）
今までのアドレスも半年間は継続して利用することが約束されているそうですが
最終的にはサービスを停止するとのことですので、これに伴いネームサーバーを
運用している人はルートサーバー情報を書き換える必要がでてきました。
善は急げということでBINDでいくつか運用しているサーバーの設定を変更してみました。
まだ対処がお済みでない人は参考になれば幸いです＾＾
方法はとても簡単
BIND8の場合
# locate named.root
/var/named/named.root
こんなかたちで見つけましょう。locateが使えない人はfindコマンドで。
# vi /var/named/named.root
. 3600000 NS L.ROOT-SERVERS.NET.
L.ROOT-SERVERS.NET. 3600000 A 198.32.64.12
↓変更
. 3600000 NS L.ROOT-SERVERS.NET.
L.ROOT-SERVERS.NET. 3600000 A 199.7.83.42
リロードする場合
# /sbin/service named reload
リスタートする場合
# /sbin/service named restart
BIND9の場合
named.caというファイルが編集対象となるだけで後はBIND8と同じです。
はい、お疲れ様でした！＾＾
しかしルートサーバーのIPアドレス変更ってどうなのかと。。。
結局昔のIPアドレスでの運用は停止できずそのまま継続して使われる気がしないでもない＾＾；
その際にメールの受信件数を把握するためメールボックス(Maildir形式)内の
ファイル数を数えてみることにしました。
今回はメール件数を把握するために使っていますが汎用的に使えますので
備忘録として記録しておこうと思います。
例) /var/mail/aaa にあるファイル数を確認する場合
find /var/mail/aaa -type f | wc -l
これだけです。
findはファイルを検索するコマンドで、この出力(検索結果)をwcコマンドで受けることで
ファイル数が分かるという仕組みですね。
ちなみに、上記の方法ですとfindでファイル形式を指定していませんので全ての
ファイルが検索対象となり、純粋なメール件数だけでなく設定ファイルなども
含まれますが、それはまぁ誤差ということで^^;
# 余談ですがメールが受信できなかった人はなんと2万件もメールがありました(O_O)
]]> その際にメールの受信件数を把握するためメールボックス(Maildir形式)内の
ファイル数を数えてみることにしました。
今回はメール件数を把握するために使っていますが汎用的に使えますので
備忘録として記録しておこうと思います。
例) /var/mail/aaa にあるファイル数を確認する場合
find /var/mail/aaa -type f | wc -l
これだけです。
findはファイルを検索するコマンドで、この出力(検索結果)をwcコマンドで受けることで
ファイル数が分かるという仕組みですね。
ちなみに、上記の方法ですとfindでファイル形式を指定していませんので全ての
ファイルが検索対象となり、純粋なメール件数だけでなく設定ファイルなども
含まれますが、それはまぁ誤差ということで^^;
# 余談ですがメールが受信できなかった人はなんと2万件もメールがありました(O_O)
]]>
Drupalが先日6周年のめでたい日にあわせて
メジャーバージョンアップをしましたね(Drupal5)
このサイトの存在も忘れるぐらいやることだらけで暇がなく
忘れかけていたことも多数ある中、
無謀にもアップグレードしてみようとチャレンジしてみました。
まず結果から。。。
今現在（2007/02/02時点)は様子見していた方が無難でしょう＾＾；
理由は色々あるのですが、昔からDrupalの弱点に感じていた
「モジュールの汎用性（流用性かな）の低さ」が一番ネックでしょうか。
メジャーバージョンアップは当然ながら0.1単位のバージョンアップでも
モジュールの仕様が変わりそのまま使い続けることができない。。。（下位互換性を持たない）
よって新しいバージョンができるとその都度
利用しているモジュールの対応版が出てくるのを待たないといけません。
さらにこれらの追加モジュールはバージョンアップの際に一旦無効にして
アップデート後に再度有効にする必要があるなど他の同様なシステムと比べると
欠点といえる仕様ですね。
Drupalをアクティブに使っている人ほどこの問題は深刻です。。。。
このサイトも多数の追加モジュールを利用しているのですが
現時点では利用できないものも多数あります。
時間が解決してくれると思いますがいつになるのかな。
とりあえずやり始めたことは最後までやってみることがポリシーなので
一通りできる範囲でサイトをDrupal5に変更してみました！
見た目上は以前のサイトと同程度に見えるかも知れませんが
実はごまかし多数^^;
時間の必要な悩みの種がまた一つ増えてしまった。。。
Drupalが先日6周年のめでたい日にあわせて
メジャーバージョンアップをしましたね(Drupal5)
このサイトの存在も忘れるぐらいやることだらけで暇がなく
忘れかけていたことも多数ある中、
無謀にもアップグレードしてみようとチャレンジしてみました。
まず結果から。。。
今現在（2007/02/02時点)は様子見していた方が無難でしょう＾＾；
理由は色々あるのですが、昔からDrupalの弱点に感じていた
「モジュールの汎用性（流用性かな）の低さ」が一番ネックでしょうか。
メジャーバージョンアップは当然ながら0.1単位のバージョンアップでも
モジュールの仕様が変わりそのまま使い続けることができない。。。（下位互換性を持たない）
よって新しいバージョンができるとその都度
利用しているモジュールの対応版が出てくるのを待たないといけません。
さらにこれらの追加モジュールはバージョンアップの際に一旦無効にして
アップデート後に再度有効にする必要があるなど他の同様なシステムと比べると
欠点といえる仕様ですね。
Drupalをアクティブに使っている人ほどこの問題は深刻です。。。。
このサイトも多数の追加モジュールを利用しているのですが
現時点では利用できないものも多数あります。
時間が解決してくれると思いますがいつになるのかな。
とりあえずやり始めたことは最後までやってみることがポリシーなので
一通りできる範囲でサイトをDrupal5に変更してみました！
見た目上は以前のサイトと同程度に見えるかも知れませんが
実はごまかし多数^^;
時間の必要な悩みの種がまた一つ増えてしまった。。。
まずはディスク全体の確認
これにはdfコマンドを利用します。
df -h
Filesystem Size Used Avail Use% Mounted on
/dev/sda2 1012M 362M 599M 38% /
/dev/sda1 99M 26M 69M 27% /boot
/dev/sda7 88G 1.6G 82G 2% /home
none 503M 0 503M 0% /dev/shm
/dev/sda5 9.9G 2.2G 7.3G 23% /usr
/dev/sda6 9.9G 2.2G 7.2G 24% /var
こんな感じになって使用状態が一目で分かります。
ここでUse%のところに注目し、100%に近づいているところが
危険領域です。（ディスクを多く使っている）
では次に、その多く使っている領域の何がディスクを圧迫させているかを調べます。
例) /usr の利用状況を調べる
du -s /usr/*/ |sort -rn
678248 /usr/local
390796 /usr/share
346412 /usr/lib
194780 /usr/src
94332 /usr/java
54788 /usr/bin
15072 /usr/sbin
14048 /usr/include
12780 /usr/kerberos
8768 /usr/X11R6
3132 /usr/libexec
4 /usr/games
4 /usr/etc
4 /usr/dict
0 /usr/tmp
こんな感じにディレクトリ毎に使用している容量が分かります。
使用量の多いディレクトリをチェックして
余分なファイルを削除する等することでディスクを空けましょう。
これで解決です。
まずはディスク全体の確認
これにはdfコマンドを利用します。
df -h
Filesystem Size Used Avail Use% Mounted on
/dev/sda2 1012M 362M 599M 38% /
/dev/sda1 99M 26M 69M 27% /boot
/dev/sda7 88G 1.6G 82G 2% /home
none 503M 0 503M 0% /dev/shm
/dev/sda5 9.9G 2.2G 7.3G 23% /usr
/dev/sda6 9.9G 2.2G 7.2G 24% /var
こんな感じになって使用状態が一目で分かります。
ここでUse%のところに注目し、100%に近づいているところが
危険領域です。（ディスクを多く使っている）
では次に、その多く使っている領域の何がディスクを圧迫させているかを調べます。
例) /usr の利用状況を調べる
du -s /usr/*/ |sort -rn
678248 /usr/local
390796 /usr/share
346412 /usr/lib
194780 /usr/src
94332 /usr/java
54788 /usr/bin
15072 /usr/sbin
14048 /usr/include
12780 /usr/kerberos
8768 /usr/X11R6
3132 /usr/libexec
4 /usr/games
4 /usr/etc
4 /usr/dict
0 /usr/tmp
こんな感じにディレクトリ毎に使用している容量が分かります。
使用量の多いディレクトリをチェックして
余分なファイルを削除する等することでディスクを空けましょう。
これで解決です。
そこで利用する様々なサービスではそれぞれデーモンがあるわけですが、
その起動についてはデーモンのインストール時に自動的に設定されます。
（ランレベル毎OSの起動に合わせてそのデーモンを起動するか否かですね）
人によっては必要のないサービスも立ち上がっている方は多いのではないでしょうか？
手動で毎回不要なデーモンを止めることもありでしょうが、
どうせならスマートに起動しないようにしておきたいところですよね？
今回はその方法のご紹介です。
まずは状態の確認。
chkconfigコマンドを使いましょう。
# chkconfig --list
netfs 0:off 1:off 2:off 3:off 4:off 5:off 6:off
network 0:off 1:off 2:on 3:on 4:on 5:on 6:off
apache2 0:off 1:off 2:on 3:on 4:on 5:on 6:off
・
・
・
fam 0:off 1:off 2:off 3:off 4:off 5:off 6:off
named9 0:off 1:off 2:off 3:off 4:off 5:off 6:off
courier-imap 0:off 1:off 2:on 3:on 4:on 5:on 6:off
例えばこの中のapache2デーモンの起動をやめたいとします。
その場合
chkconfig apache2 off
とすると、次回以降のOS起動ではapache2デーモンは立ち上がらなくなります。
やっぱり元に戻したいという場合は、
chkconfig apache2 on
とすると次回以降のOS起動でデーモンが起動するようになります。
もう少し詳細に制御したい場合はランレベルを指定することでピンポイントで
ON/OFF出来ます。
chkconfig --level=2345 apache2 off
こんな感じです。
これで無駄なメモリ消費もなくなりますので、一度チューニングしてみてはいかがでしょうか？
]]>
そこで利用する様々なサービスではそれぞれデーモンがあるわけですが、
その起動についてはデーモンのインストール時に自動的に設定されます。
（ランレベル毎OSの起動に合わせてそのデーモンを起動するか否かですね）
人によっては必要のないサービスも立ち上がっている方は多いのではないでしょうか？
手動で毎回不要なデーモンを止めることもありでしょうが、
どうせならスマートに起動しないようにしておきたいところですよね？
今回はその方法のご紹介です。
まずは状態の確認。
chkconfigコマンドを使いましょう。
# chkconfig --list
netfs 0:off 1:off 2:off 3:off 4:off 5:off 6:off
network 0:off 1:off 2:on 3:on 4:on 5:on 6:off
apache2 0:off 1:off 2:on 3:on 4:on 5:on 6:off
・
・
・
fam 0:off 1:off 2:off 3:off 4:off 5:off 6:off
named9 0:off 1:off 2:off 3:off 4:off 5:off 6:off
courier-imap 0:off 1:off 2:on 3:on 4:on 5:on 6:off
例えばこの中のapache2デーモンの起動をやめたいとします。
その場合
chkconfig apache2 off
とすると、次回以降のOS起動ではapache2デーモンは立ち上がらなくなります。
やっぱり元に戻したいという場合は、
chkconfig apache2 on
とすると次回以降のOS起動でデーモンが起動するようになります。
もう少し詳細に制御したい場合はランレベルを指定することでピンポイントで
ON/OFF出来ます。
chkconfig --level=2345 apache2 off
こんな感じです。
これで無駄なメモリ消費もなくなりますので、一度チューニングしてみてはいかがでしょうか？
]]>