社内ネットワークを整備中です。

11ac対応のアイオーデータ WN-AC1167DGR です。


実はネットワーク機器が増えたので、MACアドレスフィルタリングの空きがなくなってきたのです。
それで、どうせなら11acに対応させ、なおかつ有線LANはMACアドレスフィルタリングから開放したかった。
URoad-Homeは、有線までMACアドレスフィルタリングの対象だったから。
それにnet.USBも使って見たいし。
とりあえず設定ですが、ルータなのにAPとして使用中(だってルータモードだと、設定がややこしいし...)
それにしても、マニュアルが簡単すぎる。セットアップ画面が略語だらけ、説明が乏しい。
バッファローかNECにすべきだったか。

インターネットとの接続は、今まで通り URoad-Home です。
光を入れてもいいのですが、速度よりフレッツ光のめんどくささから、WiMAXでとりあえずOK。
WiMAXといえば、URoad-800からURoad-Aeroにアップグレードしました。


WiMAX2が出てきたのに今更。
でもURoad-Aeroなら公衆Wi-fiもシームレスに使えるから便利だ。

ハブも8ポートスイッチングから16ポートギガビット対応スイッチングハブにアップグレード。


機器を新調したら、なんかネットワークが速くなったような。
数値で計ってませんが、多分速くなっています。

しかし、機器が増えると電源がなぁ...困ったなぁ。

先々週、急激な気候の変化について行けず、風邪を引いてしまいました。
溜まる鼻水と戦いながら、何とか先週末には溜まった仕事も一息。
後は決算をするだけと...少し気が抜けたのか、昨日(日曜)は風邪がぶり返し、休むことに

そんなときです。
夜中の23時過ぎ、仕事用の携帯から「ピタゴラスイッチ」
今、特に対応しなければならないサーバーはないはず と思いながら出ると
昔の会社の元先輩から、ドヤ顔(声)で
「ページがちゃんとでんぞ!」
風邪で体調が悪いところに、ドヤ顔(声)
対処方法を教えると「なおさんかい」
ムカッ！
結局、口論となってしまいました。
(因みに、その元先輩はクライアントの関連会社にはいるが、直接のクライアントではない。また あすまるのトップは私である)
むかついてはいたのですが、それよりも体調が悪かったので寝てしまいました。

Internet Exploreは、たちの悪い現象を起こします。
その中で最もたちが悪いのは、再現ができないもの。
今回のものは、その再現しないものなのです。

【現象】
ページの画像等が中途半端に表示される。
【対処方法】
閲覧者(クライアント)が使用中のIEのインターネット一時ファイルを削除する。
このことは、マイクロソフトのホームページにも出ているのですが、あまり知られていないようです。

マイクロソフトサポートオンライン「Internet Explorer で Web サイト上の画像が表示されない」
http://support.microsoft.com/kb/283807/ja


ある程度以上、インターネット一時ファイルが溜まると起きるそうなのですが、それがどの程度とかがよくわかりません。
それに「インターネット一時ファイル」の制御なんて送り手にはできません。
(仕込めばできますが、それをやったら犯罪です。)

それ以外に方法はないのか、朝から探っているのですが、最大の問題点は自分のところで再現できないことです。
IEの環境は持っているのですが、再現ができないのです。
そのため、グーグルなどに頼るのですが、対応方法は上記しか見つかりません。
しかも発生事例もほとんどない。

原因はIEの不具合とわかっています。
もし、読者の中でこの現象を、いつでも再現できる方、つまりはHTMLの書き方等で回避の仕方を知っている方は教えてください。

今、作成中のサイトでthickboxを使っている。
jQueryは1.4.2
thickboxは3.1
一応、最新のものである

試作サイトで各ブラウザで確認したところ、IE6以外は問題なく表示される。
しかし、IE6だけはBOXは問題なく表示されるが、基のページのレイアウトが崩れる。

なぜだろう...

崩れ方を観察すると、全体のwidthが横幅いっぱいに広がる。
全体が太ってしまうのである。

「thickbox IE6 崩れる」でググってみる。
DOCTYPE宣言を変更するとか、IE6用のカスタマイズするとか...
どれもうまくいかない。

そこで原点に帰ってみる。
崩れ方は、「全体のwidthが横幅いっぱいに広がる。」
実は、スタイルシートでbodyタグの横幅とマージンを決めている。

html {
    width : 100%;
    height : 100%;
    margin : 0;
    padding : 0;
    border : 0;
    vertical-align: baseline;
    background: transparent;
}
body {
    width : 750px;
    margin : 0px auto;
    padding : 0 0;
    border : 1px solid silver;
}

通常の表示上は問題なし
thickboxを表示すると、太る。
ならば body {width:750px  !important;}で優先順位変えてしまえ
と乱暴な事をしたところ
太らなくしてしまえば...orz
太らない、thickboxもきちんと表示...でも背景のマスクが変な感じ
ということで、ここへ来てthickbox.jsのソースをみる

なんと、IE6の処理として
  $("body","html").css({height: "100%", width: "100%"});
とある。
つまり、bodyの横幅いっぱいにされてしまっているのが原因。
IE6以外にはこの処理はない。

ググっていた時、次のようなサイトがあった
IEでだけレイアウトが崩れる場合はpaddingを探す - Sakura scope
「paddingによる崩れを解決するために、div#insideを作る」とある。
しかし、paddinngについては気を付けていたのでこれが問題ではないと思っていた。

しかし、原因は明らかにbodyのサイズ指定。
試作サイトのHTMLソース、CSSソースをみると bodyの直下にdivを作っていた。(仮にこのdivのidを"foge"としよう)
しかもスタイル設定全くなし
そこで、bodyのスタイル設定をfogeに移す。

body {
    width : 100%;
    height : 100%;
    margin : 0;
    padding : 0;
    border : 0;
}
#foge {
    width : 750px;
    margin : 0px auto;
    padding : 0px 0px 0px 0px;
    border : 1px solid silver;
}

さぁ、まずはIE6で確認...OK
FireFoxで確認...OK
Operaで確認...OK
Safariで確認...OK
Chromeで確認...OK

もちろん、IE8でも確認...OK
解決である。

まぁ、thickbox.jsのソースを読めば、当たり前の事である。
しかし、CSSで左右に帯を置きたい場合、ついbodyタグに設定してしまう。
今後はこのことは気を付けるべきであると思った。

思ったついでに、あすまるのホームページをIE6でみる...orz
気を付けていたつもりが、いきなり崩れている。
thickbox以前の問題?!
至急対処しなければ!

WordPress 3.0も3.0.1と2010/07/30にリビジョンが上がりました。
内容的には細かい修正のようです。

そういえば、あすまるとBeLiveのホームページのWPも最新版にしました。
今まで使っていたCPIのVPSの一つを閉じ、X-SERVERの方で管理することにしたのです。
結構、WP2.8.6に独自に作ったプラグイン(未公開もの)を入れていたので、WP3.xは大丈夫か心配していました。
しかし『案ずるは産むが易し』
修正箇所もなく、案外すんなり移行完了。
あすまるもBeLiveも、問題なく動いています。

さて、前回 WP3.0の新規インストールで再検証したのですが、今回は『マルチサイト』について試して見たいと思います。
今まで『マルチサイト』といえばWordPress MUという別系統のワードプレスだったのが、WordPress本体でできるようになりました。

『マルチサイト』の方法はCodexにあります。

ここではやり方というより、どこが変化するのか不親切検証をしてみたいと思います。
なお、サーバはX-SERVER X10、サブディレクトリ型で検証してみます。

そうそう、WPの『マルチサイト』対応は、Apacheのmod_rewriteを多用します。
対応しないサイトでは難しいでしょう。

いきなり、Codexの手順3まではしょります。
wp-config.phpを編集して、「マルチサイトの許可」を指示します。
define ('WP_ALLOW_MULTISITE', true);

こうすると管理画面の「ツール」に「ネットワーク」が出現。
さて、ここで「ネットワーク」の設定です。
画面での設定箇所は2箇所
・ネットワークのタイトル
・管理者のメールアドレス
な〜んだ。簡単じゃない...と思ったあなた。これで終わりではないのですよ。
次いきましょう。



「ツール」-「ネットワーク」に適当な入力ののち、「インストール」ボタンを押します。
すると、いろいろなことが書いてあります。

1. 『blogs.dir』をwp-content下に作りなさい。
2. wp-config.phpに『マルチサイト』に関する記述を加えなさい。
   
   • 定数「MULTISITE」でマルチサイト宣言
   • 定数「SUBDOMAIN_INSTALL」をfalseにしてインストールを止める
   • 変数「$base」でワードプレスのベースディレクトリを設定
   • 定数「DOMAIN_CURRENT_SITE」でサイトドメインを宣言
   • 定数「PATH_CURRENT_SITE」でサイトルートパスを宣言
   • 定数「SITE_ID_CURRENT_SITE」で初期サイトIDを宣言
   • 定数「BLOG_ID_CURRENT_SITE」で初期ブログIDを宣言
3. .htaccesにリライト宣言を追加しなさい。
   
   • リライトベースとindex.phpの取り扱い
   • 各サイト毎のアップロードファイルのリライト
   • 各サイト毎の管理画面のリライト
   • wpフォルダの処理

1の『blogs.dir』は自動生成でもいいのではないかと思うのですが、まぁ特別なWordPressだから仕方ないか。
因みに、『blogs.dir』は追加されたサイトのアップロードファイル等が納まるところ。
サイトを追加し、画像等をアップすると、『blogs.dir』下にサイトIDのディレクトリ+「files」が追加され、その下に納まる仕組み。
3のリライト宣言と組み合わされ、ソース上は「(サイトURL)/files/...」となる。

2のwp-config.phpでは、『マルチサイト』に関する多くの宣言がある。
しかし、言語指定がありません。
実はwp-config.phpの「WPLANG」は、初期サイトにのみ適用されます。
そのため、追加されたサイトは最初 英語版です。なぜ引き継がないのでしょう。
または「WPLANG_CURRENT_SITE」宣言があってもいいのではないかと思うのですが...

WordPressのリライト宣言にはなぜか「QSAフラグ」がついていません。
「QSAフラグ」は付けるべきではないのか。

これで、『マルチサイト』が使えます。
管理画面に『特権管理者』メニューが追加されました。
wp-config.phpや.htaccessがいじれれば、結構簡単ですね。

『特権管理者』メニューには下記のサブメニューがあります。

• 管理
• サイト
• ユーザ
• テーマ
• 設定
• 更新

直ちにサイトの追加をしたいと思ってしまうのですが、まずは『設定』を先にすることをおすすめします。
なぜなら、「初期設定言語」がここにあるからです。
私はこれに気付かず、いきなりサイトを追加したら、英語版になってしまいました。
もちろん、各サイトで言語設定は可能なのですが、自分以外のユーザに管理をゆだねるのならば、その方の利用する言語に最初に設定しておかないと、ちょっとパニクるかもしれませんね。
「メディアアップロードのボタン」も設定しておいた方がいいでしょう。
「画像がアップロードできない」といわれかねませんから。

さぁ、サイトを追加します。
追加して気付いたのですが...オプションで下記の設定があります。
なんでしょう？

• 一般公開
• アーカイブ化
• スパム
• 削除
• 成人向け

ソースを見る限り、サイトのステータスのようですが、管理画面以外は特に対応しないみたいです。

では、データベースはどうなっているのだろう。
まず、主テーブルの違いは以下の通りでした。

• {$table_prefix}blog_versions
• {$table_prefix}blogs
• {$table_prefix}registration_log
• {$table_prefix}signups
• {$table_prefix}site
• {$table_prefix}sitemeta

※{$table_prefix}の部分は「wp_」などのテーブル接頭辞

さて、なぜ『site』と『blogs』が分かれているのでしょう。
【site】

• id
• domain
• path

【blogs】

• blog_id
• site_id
• domain
• path
• registered
• last_updated
• public
• archived
• mature
• spam
• deleted
• lang_id

どうやら、『sitemeta』を見ると、『site』はネットワークを示すもののようです。
きちんと調べていないので、私見ですが『site』は一個だけ登録されています。
子サイトを追加すると、その追加状況は『registration_log』に追加されます。
分からないのが、『signups』と『blog_versions』
『registration_log』『signups』と『blog_versions』の3つは、『blogmeta』のようなテーブルを作れば、対応できたのではないかと思う。
『blogs』内の子サイトの状況も、『blogmeta』で扱った方が融通性が高いWPッぽいのだけどなぁ
※『blogmeta』のようなテーブルは現在ないよ。

『blogs』は、各子サイトの状態がはいっています。
各子サイトの詳細設定は下記のテーブル群に納まるようです。

では、各子サイトはどうなのかというと、以下の通り。

• {$table_prefix}{$blog_id}_commentmeta
• {$table_prefix}{$blog_id}_comments
• {$table_prefix}{$blog_id}_links
• {$table_prefix}{$blog_id}_options
• {$table_prefix}{$blog_id}_postmeta
• {$table_prefix}{$blog_id}_posts
• {$table_prefix}{$blog_id}_term_relationships
• {$table_prefix}{$blog_id}_term_taxonomy
• {$table_prefix}{$blog_id}_terms

※{$blog_id}は、各子サイトのブログID

しかし、MUとの互換性のため、サイトとブログ、ネットワークの扱いが煩雑になっている見たいですね。
テーブル上のsite = (呼称)ネットワーク
テーブル上のblog = (呼称)サイト

さて、WP3.0から新設されたカスタム投稿タイプは、どのようになるのでしょう。
これについては、カスタム投稿タイプを扱えるようにするプラグインで試すしかありません。

プラグインがどのように対応するかですね。
ということで、プラグインについては次回。
BeLiveで作ったプラグインの検証も必要ですから。
では

6月17日にオープンソースCMS「WordPress」の最新メジャーバージョン
WordPress 3.0 “Thelonious”
※日本語解説「WordPress 3.0「セロニアス」」
が公開されました。
日本語化も精力的に行われ、6月22日には日本語版もリリースされました。

ハイライトを読むだけでも...さすがメジャーバージョンアップ。
(詳細は 3.0 の Codex ドキュメンテーションページ )
大変魅力的なことが書かれています。
特に気になるところが多く、つくってきたプラグインもテストする必要があるので、まずは最新版を「お試し」します。

通常のインストールについては、3.0 の Codex ドキュメンテーションページ を見る限りは、2.xと比べて特別な準備は必要なさそうです。
今回のハイライトの一つ、「マルチサイト対応」については通常インストール後に行うことなので、今までのバージョンがインストールできるサイトならば問題ないのではないかと思います。
※CPI Xシリーズで試しただけです。他の環境については保証できません。

ソース一式をサーバに送って、インストールを開始します。
最初のページ、セットアップ設定ファイルのページには、特に変更点は内容です。(文言の違いまでは確認していません)
違いは、ブログ名などを入れる「インストール」ページ。
ユーザ名がここで指定できるようになっています。
もちろんパスワードも指定できます。
パスワード指定は必須ではなく、空だと自動生成されます。
後はログインまで今までと同じでした。

まずはインストール直後のトップページです。
ハイライトにもあるように、デフォルトテーマが「Twenty Ten」に変わっています。
ヘッダーの画像の下には「ページナビ」がついています。
これを書いていて気がついたのですが、左図は1024×768のノートPCで見た場合です。
ヘッダー画像が幅広のためか、今度のデフォルトテーマは低解像度のクライアントだと必ずスクロールが出るようです。
でも、シンプルだけどセンスいいですね。
テーマタイトルが「Twenty Ten」ということは、来年は「Twenty Eleven」って言うテーマが出たりして


ところで、このテーマは選択状態では次の機能が追加されます。

• メニュー
• 背景
• ヘッダー

この3つは、今回のハイライトにはいっています。


まずはカスタムメニュー機能です。
ウィジェットなどにカスタムメニューとして追加する機能のようです。

さてこの機能を「Twenty Ten」以外で対応させるには...
Codexには「テーマの function.php ファイルに適切なコードを挿入することができます。」(Codexより)とあるのですが...
まだ解読できていません。


次に背景のカスタム機能です。
こちらは使用するテーマのfunctions.phpに「add_custom_background();」を適切に配置するだけで、管理画面に「テーマ>背景」が追加されます。
やってることは、wp_headフック等でスタイルを追加しているみたいです。


次にカスタムイメージヘッダー機能です。
こちらも使用するテーマのfunctions.phpに「add_custom_image_header」関数を追加するのですが...背景より複雑のようです。

呼び出しは「header_image」関数をimgタグ内で呼び出すといった感じのようです。



こんな感じでデフォルト状態を管理画面で変更するだけでも、デザイン変更が簡単にできそうです。

しかし、さすがメジャーバージョンアップ
変更点はこれだけではないようです。
例えばカスタムポストタイプやMUとの統合など
あと自作プラグインとの相性も調べなければならない...
とにかくやることいっぱいです。
とりあえず、今日は「インストール」と「新テーマ」について記しておきます。

昨年末(2009年12月) WordPressの2.9がリリースされた。
画像の編集機能などが搭載されたものである。

しかし、これまでバージョンアップされる度に使っていたプラグインやテーマが使えなくなることが多かった。
そこで、現在開発中であったり、運用中のシステムのバージョンアップをすべきかどうかを確認する為、WP-2.9を試すことにした。

まずは、あすまる/BeLiveで開発したプラグインが正常に動作するかの確認を行い、その結果を記録する。

現在、BeLive名義で公開しているプラグインがいくつかある。
まずはそれからテストすることにした。
テストには、CPIのテストサーバにWP-2.9をインストールし、それぞれのプラグインを使用/停止させて問題ないかチェックする。

• 自動整形を解除するプラグイン｢WP-UnFormating｣
  → ○自動整形の解除、PHPコードを含む置換 ともに問題なし。
• PHPのPearのパスを追加する｢WP-Pears｣
  → ○sample.phpのインクルードを行ったところ、問題なし。
• iniファイルを利用できるようにする｢wp-IniFileLoad｣
  → ○sample01.ini〜sample03.iniを呼び出す。問題なし。
• 各サイドバーWidgetにCSSクラスやアクセス権など、新たな属性を追加する｢Extra Widget Properties Set｣
  → △機能的には問題なし。但しローカライズ(日本語化)がされない。

公開されているものについては、WP-2.9でも問題なく機能することを確認。
ただ、｢Extra Widget Properties Set｣のローカライズ(日本語化)が上手く行かないことについては調査が必要である。

あすまるでは、各クライアントからの要望に応じ、そのシステム専用のプラグインを作成している。
また、まだ公開していないが、とても便利なプラグインも多々ある。

その中で、これまで開発しているうちに、共通化すべき機能であるが、それだけでプラグインを作るほどのものでないものを「あすまる専用プラグイン」として、蓄積している。
まずは、この「あすまる専用プラグイン」からテストを行った。
その結果、主要な機能の確認だけだが、WP-2.9でも問題なく動作した。

そのほかにも、未公開ではあるが、画期的な機能を持つプラグインがいくつかある。
それを確認したのだが...ある重大な問題にぶつかってしまった。
それを解決する為には、どうしてもWPのソースを改良するしか手立てはないものであった。

続きを読む

前々から、仕事上の開発時の覚書を残しておきたいと思っていた。
もちろん、社外秘及び契約に関わるものはかけないが、そうでないものは書き残したいと思っていた。
だから、｢開発雑記｣を書くことにする。

WordPressを知ってから、いくつかのプラグインを利用してきた。
ただ、それでも必要とする機能が見つからず、新たにプラグインを作ることは多い。
今まで作成した中で、公開しているものもある
など
それ以外にも、各開発依頼用に作成したものや、当社開発案件共通のプラグインなど、たくさん作成している。
ただ、開発中のものや案件独自のものは、公開はできないものがある。
公開できない理由はそれだけではないのだが...

BeLiveの時代も含め、あすまるの開発案件で、｢これ、なくしてはでら大変なことになる｣というプラグインがいくつかある。
その中に、あすまるの開発の根幹となるプラグインがある。
名前は｢common templates｣
(まぁ、名前だけではこのプラグインが、なぜすごいかは理解されないからいいか)
このプラグインの開発はもう3年も前になる。
サブ機能やWordPress本体のバージョンアップによる調整を続けてきたが、基本は3年前に既にできあがっている。
元々、公開するつもりで作ってきた。
なぜ、公開しなかったのか...
それは、プラグイン コンペに出す為 ... のつもりでいた。
ただ、｢プラグイン コンペ｣の時期が来たときに限って、でら忙しかったり、WP本体がバージョンアップされ、新しい仕様に合うか確かめたりしている間に時期を逃してしまった。
そうしているうちに、このプラグインが仕事の根幹となるものになり、公開は取りやめた。

このプラグインは、｢トレーディングカードゲーム｣でいえば、｢進化させる｣効果を持つ魔法カード。
つまり、普通のページを特別な機能を持ったテンプレートを指定することで、機能を追加できる。
しかし、デザインはそのまま、あるいは希望するデザインテンプレートにすることができる。
つまり、ページを進化することができるのだ。
今のところ、この特別な機能を持ったテンプレートは、3種類だけ。
ドラクエでいえば
機能上、ホイミやメラはできないが、WPを攻略する上では大変便利な機能ばかりである。
そのほか、このプラグインは、ページや投稿、カテゴリーを条件に合わせてドレスアップさせる機能も持っている。
このプラグインは、最新のWP2.8.4でも、問題なく稼働する。
とにかく、私にとっては欠かせないアイテムである。

続きを読む