ちょっと特殊な例ですけども、こんなことがあったので記事にしておきます。

以下のような条件：
すでにCMSで稼動しているサイトをWordpressでリニューアル。
以前のサイトのＵＲＬはすべて[?itemid=●●●]というパラメータがついていてURLの正規化はされていない。
ただし、リニューアル前のＵＲＬは引き継がない。

このとき、YahooやGoogleにすでにインデキシングされてしまっているパラメータつきのURL

http://hoge.com/?itemid=1

などは、リニューアル後のWordpressでは（まぁ、WPに限った話ではないけれども）
パラメータを無視してトップページ（http://hoge.com/）を表示してしまうため、
インデキシングされたページがいつまでたってもたどれてしまう。
このままでは複数のパラメータから同一ページに遷移させていることからペナルティを食らう可能性を残してしまうので、
Wordpressのfunction.php内の頭のほうに以下のようにソースを追記して404を返すようにしてみた。

if($_GET["itemid"]){
	header("HTTP/1.0 404 Not Found");
	include '404.php';
	exit;
}

おしまい。

先日、なけなしの預金を切り崩してCS5を購入したわけですが、Flash CS5に関してちょっと困ったことに。
今相当忙しいのにコレにぶち当たって、ついカッとなってあげてみた。後悔は(ry
（報告がまだほとんどないようで、私の環境だけかもしれませんが。。。）

CS5からはファイルの構造が変わり、XML形式になったことが原因ではないかと推察されますが、
現象再現手順は以下のとおり。
（ちなみに環境を書いておきますと、Win Vista32bit SP2ですが、その他の環境ではまだテストしてません。）

1.xfl形式fla形式問わず、CS5形式でシーン（ライブラリ）に画像を読み込んで保存します。
2.Flashを終了して、もう一度保存したファイルを開きます。（てか普段やる作業手順ですよねｗ）

すると

・
・
・

え？

・
・
・

なんか、画像が正しくロードできてない。。。
（更新ボタンを押すと表示されるようになるのですが。）

xfl形式だと、LIBRARYディレクトリを勝手に作って読み込まれている画像を
保存（生成？）してくれるようなのですが、それも0バイト・・・。
（ちなみにCS5形式のflaファイルも実態はzipファイルです。拡張子を.zipにして解凍するとxfl形式と同じものが出てきます。）

ちなみに、CS4以前のファイルをCS5で保存して開きなおすと

・
・
・

メモリにシーンをロードできませんでした。

ムービーが壊れている可能性があります。

CS5ェ・・・

どう考えてもバグだろ。これ。

これ、バックアップとってないデータでやっちゃうと死ねるので、
パッチが出るまではしばらくCS4で作業しないと。。。

あ、CS5でもCS4形式で保存すればこれらの問題は起こらないようです。・・・てCS5の意味ねぇし。

こりゃジョブズも怒るわけだ。

ちょっとネタに困ってきたので、社内外で割とよく聞かれる質問について書いてみたいと思います。
って、今まで割とマニアックな技術ネタだったのに順番ぐちゃぐちゃですみません。（ほんとに思いついた順に書いているのでご勘弁を。）

私自身の体験談としては、初体験はやっぱ仕事でだったのですが、
それまでにNucleusを触っていたこともあってか、「PHPベースで動き、ブログから発展してCMS的な使い方のできるミドルウェア」という共通点から、比較的すんなり覚えることができました。
というか、むしろMovableTypeやNucleusを触ってからWordPressに触れると、WPの持つ優位性に色々と気付かされてすぐに虜になってしまっていました。ｗ

ただし、これからWordPressを覚えたいという方の誰しもが、すでにPHPが書けたり、そのほかのミドルウェアのカスタマイズの経験があるわけではないでしょう。

でも、私が思うにそれは些細な問題です。

WordPressに限った話ではなくツールはあくまでツール（道具）なのであって、それ自体が勝手に何かをしてくれるわけではないので、要はそれで何をしたいかがあれば、必ず習得できる・・・はず。
（PHPにしたって、私の場合WordPressのテーマを編集するために、しゃーなしについでに覚えた感じですし。）

まぁ、逆に言うと、目標が「WordPressを覚えたい」の場合、人によっては、なかなか習得が難しいんじゃないかと。
あ、アレです。英語ができなかった人が海外に行くという理由で語学学習して習得する過程と似てるかもしれません。

タイトルで、てっきり「技術系の話」と思われてたかもしれませんが、なんだか今回は一気にメンタリティな話ですみません。

覚えたい気持ち自体は素晴らしいんですけど覚えて何がしたいかがないと、仮に一旦覚えてもどんどん忘れていっちゃいます。
特にこの業態は、次から次へものすごいスピードで進化を繰り返しているので覚えた知識もすぐ古くなって使えなくなってしまいますしね。

でも、どうしても目標が思いつかない場合は、自分で課題を出すとよいかもしれません。
例えば、仮想的に「コーポレートサイトをWPだけで構築してみる」とか、「個人ブログを作ってみる」とか。

一旦、WPで何ができるかは考えずに、そういう仕事の依頼が来た、もしくは、こういうサイトが作ってみたい、みたいなノリから初めて、
そのあと、WPで何ができるのかを調べてみて、できることとできないことを設計段階で調査していくと習得までがスムースかもしれません。

あと、よく聞かれるのが、WordPressってなにができるの？それっておいしいの？って質問。

少々意地悪な回答かもしれませんが、PHPで作られてますので基本的にPHPでできる範囲のことなら大抵何でもできます。
PHP単体でできなくても、SQLコマンド、JavascriptやCSS等がカバーしてくれるかもしれません。
できることを調べるよりも、WPが苦手なことが何なのかを調べたほうが早いです。

例えばそれは、カテゴリスラッグが重複してつけることができないことによるリニューアル時のURL引き継ぎの問題であったり、
アップロードした画像のディレクトリ構造、管理の仕組みであったり、色々と壁にぶち当たることでしょう。

その辺はきく前に一回インストールしてじっくり触って感じてみないとほんとの意味では理解できないとも思いますので、
これからWordPressを覚えたいと検討している方は、迷わずサクッとインストールして体感してみてください。

あれ？当たり前のことすぎておもろないかも。
てかなんかマジ体調悪いや。。。

コーポレートサイトを製作するときに、WordPress（以下WP）で下記のような使い方をすることはありませんでしょうか。
たとえばそれはスタッフブログとしてだったり、新着情報の表示用としてだったり、WPをサイトのコンテンツの一部として利用したとき、静的なページでWPの動的な情報を掲載したいシーン等々。

WPのテーマ側でJavascriptを出力させるようなロジックを組むのもアリですが、SEO的にはまったく無力です。

そこで、WPの情報を読み込む必要が出てくるわけで、そんなシチュエーションに出くわした際は下記サイトを参照してみてもらえると幸せになれるかも。

■hiromasa.another :o)» Blog Archive » 静的 HTML に WordPress を埋め込む方法

と、いうわけで。
wp-load.php
をページ内にインクルードして、後はテーマを作るときと同じようにWPのタグやPHPの関数を駆使しながら
好きな情報を好きなように配置してやればよいわけです。

通常、WPは1にも2にもテーマありきで、テーマがないと始まらないといっても過言ではありません。
なぜならそれは、テーマ 内にはサイトを構成するためのビジュアルやロジックが詰まっているはずだからです。

でも、コレができるってことは、
たとえば、既存の何がしかのCMSが動いている環境でもWPの情報を呼び出して好きなように表示させれる「かも」しれないし、
たとえば、ヘッダフッタなどのビジュアルはWPのテーマを呼び出して使用するとか、
たとえば、WP自体にはテーマファイルを利用せず、静的ファイルに埋め込んで普通にDreamweaverで編集しちゃう運用とかも可能「かも」しれない。

社内製のオリジナルのバックオフィスやWP、その他のミドルウェアを使った案件をこなしてきて感じていることとして、CMSって使いようによっちゃメリットも大きく便利かもしれないけど、それと同時に一度CMSを導入してサイトを構築するとその仕組みから簡単には抜け出せなくなる怖さもあると思います。また、CMSだけでなく、基幹系ががっちり食い込んでいるシステム案件では特に、気軽に「全面WPでリニューアルしましょ」とは行かないことも多いでしょう。

私自身はWPが好きですけども、何もかもすべてWPで管理する必要はないと思う。

今まで慣れ親しんできたツールで運用できるようにクライアントが運用するエリアと制作会社が運用するエリアの切り分けをしっかりしておけば、より柔軟なサイト運用が可能となるのではないでしょうか。

（ああ、なんか喉が。体調悪いので今日はおとなしくしておこ・・・。）

WordPress（以下WP）を使ってCMS的なことをやろうとしたとき、デフォルトの設定入力項目以外の情報をWPのDBに保存して、必要に応じて呼び出したい。
そんなシーンに直面したときは、フックを使ってオリジナルの管理画面を作れば解決します。

そのあたりの作成手順は、公式サイトにも詳しく掲載されていますのでそちらを参考にしてみてください。

■管理メニューの追加

入力ページ自体の作成手順は以下を参考に。

■設定ページの作成

以上の手順で、好きな項目を好きなようにWPの管理画面内に追加することが可能になるかと思います。

続いて管理権限について。

たとえば、管理者のほかに運用者が別にいた場合。
仕事で使った場合を想定すると、製作者はもちろん「管理者」権限だと思いますが
クライアント側でテンプレートが操作できてしまうと崩されてしまう危険性があるため
「編集者」もしくはそれ以下に設定するのは定石でしょう。

ただ、ユーザの権限を編集者以下とした場合、先ほどの手順で作成したオリジナルの入力画面はデフォルトでは管理権限がなく、利用できないはずです。
（もしくはメニューには表示されているけど編集できない。）

ではどうするのか・・・ここでもフックで解決です。

オリジナルで作成した画面（manage_options）に関する編集権限を与えてやればよい感じです。

参考URL）
■要らないメニューを省きたい（CHUO SPECIAL RAPID）
■独自の Role を定義する（CHUO SPECIAL RAPID）

上記のURLにも書かれていますが、
ユーザの権限は、管理画面上では5種類ですが、実際にはもっと細かく定義されています。
そのあたりについては、公式ページにもちゃんと記載がありますので、そちらも参考に。

■ユーザーの種類と権限 - WordPress Codex 日本語版

というわけで、これらを組み合わせると、WPがデフォルトで持っていない情報を編集者などのユーザが好きに編集できるようになるわけですね。

具体的に書くと、ページではないパーツパーツでの要素、
トップページのロゴ画像を差し替えたいだとか、ページを持たない一言コメントを出力させたいだとか、
そのほかの出力の際の条件として使いだとか、使い方は無限大。
それこそ、CMSツールとしてサイトのレイアウトをぐりぐりカスタマイズできる画面を
組み込むことも可能ですよね。夢が広がりんぐですね。


というわけで、オリジナルで作成した画面（manage_options）とその管理権限の操作についてでした。
（むむむ、早くもネタがしんどくなってきた・・・。）