カテゴリー別アーカイブ: WordPress

ハネムーン期間は終わりだ！WordPress3.5のメディアアップロードに対する不満

WordPress3.5を使用していて、それはあまりにもどうかと思う、という現象に出会ったので。

WordPressで投稿にメディアを追加するためには、投稿画面の”メディアを追加”ボタンをクリックし、各種メディアをファイル選択またはドラッグ&ドロップアップロードで登録、必要であれば名称やキャプションなどをつけた上で投稿に挿入するという手順になっている。

このとき、”添付ファイルの表示設定”というセクションで投稿記事中のサムネイルファイルの配置、大きさ、リンク先を指定するようになっている。そして、リンク先の選択肢はサムネイルの元ファイルである”メディアファイル”の他に、”添付ファイルのページ”も選べるようになっている。というか、私がアップデートしたWordPress3.5では、デフォルトで勝手に”添付ファイルのページ”が選ばれていた。

しかも、そのページはThickBoxを使うテクニックを使って、いわゆるlightBox的挙動をするように設定していたページだ。結果、ライトボックスのウィンドウに添付ファイルのページが表示されてしまうという、わけのわからない事態になっていた。

で、記事を投稿するときにつける画像に、いちいちライトボックスが正常に働いているか一つ一つチェックする人は少ないわけじゃない。私にしてもそういう物臭な人間だったため、WordPres3.5にアップデートしてからの投稿記事で、全ての画像のリンク先がページになっていた！

修正作業が面倒くさい。100点ぐらい画像ありますよ？いちいち一つ一つについてリンク先を画像ファイルに変えて、更新。しかもリンクのrel属性に添付ファイルページを識別する名前をつける仕様も好ましくないため、relの部分の指定も削らないといけない。

WordPress3.5にアップデートしてからGooglebotがよくこの添付ファイルのページのクロールエラーを報告してくるのだけど、このサムネイル画像からのrel指定のせいではないですかね。そもそもrel属性はnofollowをつけたりnext、prevなどのクローリングの最適化のために使うべきであって、勝手に謎な識別名の格納場所として使用してしまって良いのですか？

本当にこういう修正作業が空しくなります。やはり、万人のかゆいところに手が届くように作られたソフトウェアというものは、余計なところを掻きむしって使用者の皮膚をボロボロにする定めなのですかね。

そういう例は、本当によく見かけます。

小ネタ：WordPressがHTML5に対応して、過去記事の見出しに困る

1件のフィードバック

WordPressはそのアップデートの歴史の中で、まさにアップトゥデートな技術を取り込み成長してきました。現在のヴァージョン3.5+Twenty Twelveでの売りはレスポンシブデザインですし、Twenty ElevenではHTML5対応という飛躍がありました。

さて、そうなると過去からずっとWordPressを使い続け、記事を投稿している人間にとっては、過去の投稿資産がアップデートで価値を失ってしまわないかと不安になります。何しろ新技術が過去の資産をラッピングして表示するわけで、何かしらの不具合になってもおかしくありません。

そうしたアップデートに伴い発生する不具合（不都合）の例を挙げましょう。Twenty ElevenでのHTML5対応により、HTML5の大きな特徴であるセクショニング・コンテンツの宣言と、セクション宣言の直後の見出しレベルh1からの使用が可能になりました。

それまで、Twenty Tenおよび他のHTML5未対応テーマでは、投稿記事のタイトルが<h2>から始まっていたため、あえて記事中で見出しをつける際には<h3>タグをルートレベルとせざるを得ませんでした。
ところがHTML5ではセクショニング・コンテンツの開始を宣言すれば、文書中のどの場所でも<h1>タグからの階層構造にする事ができます。そして、Twenty Eleven以降の標準テーマでは、投稿記事を<article>タグで囲んでセクショニングコンテンツとするとともに、記事タイトルを<h1>としているのです。

そこで、Twenty Eleven以降のテーマで過去の記事を表示すると、記事タイトルの<h1>タグの下に”空気を読んで”<h3>に揃えておいた見出しタグが来てしまいます。<h2>タグのない、崩れた構造になってしまいます。

WordPressの売りは、テーマの自由自在な変更に代表される、深く考えなくても良いカスタマイズ性だったはずですが、HTML5へのステップアップを挟む事で、記事本文のテーマからの独立性が保証されなくなったと言えます。いまや、そのテーマが記事でどの見出しタグをルートとしているかあらかじめ知っていないと、無闇にテーマを変更する事ができなくなっているのです。

何が言いたいのかというと、投稿記事の見出しを<h3>タグで始める、手癖がついてしまっているのですよね。困った。

こうしたステップアップを挟んだからか、WordPressのテーマプレビュー（Lorem ipsum…）でサンプル文章中に<h1>、<h2>タグも含まれているのですが、特にこれにスタイルを設定していないテーマもよく見かけます。

誰に腹を立てたら良いのか、怒りのやりどころもわからぬままポチポチ過去記事を修正です
。

サイトC：WordPress3.5＆Twenty Twelveに変更

1件のフィードバック

去る2012年の12月、WordPressのヴァージョン3.5が正式リリースになりました。

このブログでは、WordPressをヴァージョン2.9から使用しており、大きなアップデートとしては3.0へのアップデートを一回経験しています。以降は小数点以下のアップデート経験しか無いのですが、ヴァージョン3.4へのアップデートあたりから、3.0リリースの補完的アップデートとは異なった新たなWordPressへの脱却を感じさせるアップデートになってきたという印象があります。今まではWordPress以外のWEBアプリケーションの機能をなぞるような意気だったのが、最近ではWEBアプリケーションのトップをひた走るという自負すら見えてくるといいますか。たとえば、3.4でMovableTypeやBlogger由来のAPIを使わなくても、自前のAPIだけでxml-rpc投稿ができるようになったことなどが例として挙げられましょう。

とは言え、あまりWordPressの機能を使い込んでいない人間からすれば、そうした目に見えないアップデートはさして重要ではありません。
今回のアップデートの目玉の一つは、デフォルトテーマのTwenty Elevenのグレードが一つあがり、Twenty Twelveに生まれ変わったことです。このブログでも早速（いや、単体では8月あたりにリリースになっていたことは知ってますよ）導入してみました。

Twentyシリーズはヴァージョンアップのたびに目玉仕様を乗っけてくるのですが、Twenty ElevenがHTML5への対応だったのに対し、今回のTwenty TwelveはRetina対応とレスポンシブデザインとなっています。確かにTwenty ElevenをiphoneやiPadで見たときの間延び感は気になっていたので、アップデート後真っ先にその点をチェックしてみましたが、そつのないスッキリとしたデザインに統一されています。

iPadでのTwenty Twelveテーマ

ちなみに、余談ではありますがこのスクリーンショットを撮影するのに使ったchrome機能拡張は、Rippple Emulatorといい、各種スマートフォン、タブレットの縦横表示チェックの他、本体の振動やGPSもテストできる便利ツールです。

メニューがデフォルトで展開されず、ユーザアクションで開く形になったのがスマートフォンサイトっぽいですね。サイドバーは投稿下部に付き、Twenty Elevenのような面倒くさい設定も要りません。
今後はこれをたたき台にしたデザインのページが増えそうですね。

WordPressでプラグイン無しでThickBoxを使う方法

1件のフィードバック

WordPressの比較的よく知られた隠し機能として、画像をクリックしたときにフロートウィンドウを出し拡大表示をするThickBoxを、プラグインなしで実現できるというものがあります。方法はまあまあ簡単で、<head>タグに囲まれた部分で、<?php wp_head(); ?>が呼ばれるより前に<?php add_thickbox(); ?>を呼んでおく。すると投稿中の画像の<a>タグにclass=”thickbox”を指定してやる事で、画像クリック→フロート拡大表示の機能が実現します。

ThickBox導入手順1

ThickBox導入手順2

LightBoxという呼び名が一般的な機能かもしれませんが、何故LightBoxと呼ばれているかというと、この機能を広く知らしめたのがLightBoxというプログラムだったからで、繰出鉛筆をシャープペンシルと呼ぶのに似ています。
標準でこの機能が有効化されていない理由は、ThickBox自体がディスコンになってしまっているためとのことです。WordPressの最近のアップデートが、プログラムのスリム化とそれに伴うサポート終了という傾向であるため、この機能もいずれはなくなってしまい、プラグイン導入が推奨されるようになるかもしれません。

Twenty Elevenテーマで、個別記事にサイドバーを表示したときのレイアウト崩れ対策

2件の返信

以前このブログでは、digitalnatureのMystiqueというWordPressテーマを導入し、デザイン部分についてはほぼデフォルトのまま使用していました。何しろ優秀なテーマで、機能も多く、特に他のテーマに乗り換える動機も無かったのですが、000webhostのテロルによってブログを強制削除された事件の後は、これを機に自作テーマ開発でも行おうかという目論見もありWordPress標準テーマであるTwenty Elevenを暫定的に使い続けていました。

このTwenty Elevenテーマですが、デフォルトの設定だと各記事ページ、固定ページにサイドバーが表示されないため、不便です。自作テーマ移行まで過渡期的な利用だと割り切っていたため対策も行わなかったのですが、容易に設定ができるようなので実験がてら設定してみました。

固定ページへのサイドバー追加

固定ページへのサイドバー追加は非常に簡単です。

固定ページへのサイドバー追加

投稿画面のページ属性で、Sidebar Templateを選択するだけです。

各記事ページへのへのサイドバー追加

各記事ページへサイドバーを追加するには、実際にTwenty Elevenのソースに手を加えなければなりません。とは言え、失敗するリスクやヴァージョンアップ時に変更がリセットされてしまう危険性を避ける為に、以前紹介記事を書いた子テーマを利用しましょう。

記事の中での説明にあるように、カスタムスタイルシートについては、子テーマの中で親テーマのstyle.cssを呼び出す処理が書けました。追加の部分についてはCSSの後着優先という性質を利用して上書きをしましたね。一方、××.phpのような処理を書くファイルについては、処理の順序の問題もあり、子テーマのファイル中で親テーマのファイルを呼び出すというのは難儀です。そのため、カスタム処理を書きたいファイルを子テーマのフォルダ内にコピーし、そのファイルに処理を追加するという形になります。子テーマに同名のファイルが見つかると、親テーマのファイルは参照されません。

さて子テーマの作成、有効化までは完了したものとして、サイドバーを呼び出す処理を書きます。各記事ページにアクセスする時に呼び出されるのは、Twenty Elevenのテーマフォルダの中にある、single.phpです。WordPressではテンプレートエンジンのごとく、HTMLを断片的に吐き出してページを完成させています。つまりサイドバー部分の断片を吐き出す命令を、しかるべき位置で呼び出してやれば良いわけです。

//子テーマにコピーしたsingle.php
<?php
/**
 * The Template for displaying all single posts.
 *
 * @package WordPress
 * @subpackage Twenty_Eleven
 * @since Twenty Eleven 1.0
 */
 
get_header(); ?>
<div id="primary">
<div id="content" role="main">
<?php while ( have_posts() ) : the_post(); ?>
 
/*　中略　ちなみにこの部分で記事を取得、表示しています　*/
 
<?php endwhile; // end of the loop. ?>
</div><!-- #content -->
</div><!-- #primary -->

//ここにこの一文を追加します。
 
<?php get_sidebar(); ?>
 
//追加部分終わり
 
<?php get_footer(); ?>

get_sidebarという命令がそのまま、サイドバーを取ってくる処理です。フッターを呼び出す、get_footerの前で呼びましょう。これをsingle.phpという名前で子テーマフォルダに保存すると、個別ページの表示がこのようになります。

サイド？バー

ご覧のように、コメント投稿欄の下にサイドバー部分がはみ出てしまいます。新しくサイドバーを表示するようにしたため、個別記事ページで呼び出されるCSSも調整する必要があります。子テーマのstyle.cssに、以下の内容を追加して下さい。

.singular #primary{
float: left;
	margin: 0 -26.4% 0 0;
	width: 100%;
}
 
.singular #content,
.left-sidebar.singular #content {
	position: relative;
margin: 0 34% 0 7.6%;
	width: 58.4%;
}
 
.singular .entry-header,
.singular .entry-content,
.singular footer.entry-meta,
.singular #comments-title {
	margin: 0 auto;
	width: auto;
}

個別記事ページでは、記事が表示されるエリアに.singularというクラスによる限定が付いており、通常の記事エリアのidである#primary、#contentの指定より優先されています。したがって基本的には#primary、#contentの指定をそのまま.singularで限定されたセレクタの宣言にもってきて上書きすれば良いのです。

子テーマでの宣言が有効に

ちなみに、追加部分の最後、.singular .entry-header以下略の部分は、コメント投稿欄の幅などを指定しています。親テーマのstyle.cssそのままだと、サイドバー抜きの場合の表示幅を基準にサイズを合わせるので、不格好になってしまいます。そこで、widthをautoに指定し直しています。

面倒だという方に…

以上がサイドバー表示の手順ですが、ここまで手を入れるのは面倒だという人の為に、Twenty Elevenにサイドバーを追加するニッチなプラグインがいくつかあります。Twenty Eleven Theme Extensionsが有名ですね。

Twenty Twelveではもう少し融通が利くようになってほしいものです。

子テーマを使ったWordPressカスタマイズ（CSS編）

コメントをどうぞ

（前口上が長いので、とりあえずタイトル通りのカスタマイズの方法だけ知りたいという方は、四段落ほど飛ばして読んで下さい）

WordPressカスタマイズ、ダッシュボードの左メニューからの設定変更を初級編とするならば、さしずめ中級編はCSSを用いた各要素の表示変更といったところでしょうか。静的ページのCSSによるレイアウトに習熟された方でも、いつも通りの手順でCSSをいじったが反映されない、あるいはダッシュボードで促されるままアップデートをしたら、苦労して設定したスタイルが無効になったなどなど、トラブルに直面して初めてWordPressが一筋縄でいかないという事に気付く筈です。まさにそこからが中級編の入り口で、中級編以降のカスタマイズには、WordPressの仕組みの一定以上の理解が必要とされるのです。

WordPressでは、一つのページを作るのに様々なディレクトリの様々なファイルを参照し、それらを決められた優先順位で読み込んで表示します。スタイルシートについてもそれは同様ですが、スタイルシートの性質として、同じ要素に対するスタイル指定は後に宣言された方を優先とするという原則と、idやクラスなど具体性のある宣言を優先するという原則があります。ゆえに、特定の要素について最終的に有効になっているスタイルがどのファイルのどこで宣言されたものかが判別できないと、現在のスタイルを変更しようと思っても変更の箇所がわかりません。
要素に実際どういったスタイルが有効になっているのかは、CSSの熟練者にとっては常識ですが、ブラウザの機能を使って調べられます。SafariやChromeなどのWebKit系ブラウザであれば、要素の上で右クリックし”要素の詳細を表示”を選択すると、”webインスペクタ”ウィンドウが現れるので、右側の”一致したCSSルール”という部分に注目します。画像の例ではp要素に適用されたルールが列挙されていますが、line-heightについてはcore.cssというファイルの250行目で宣言されたものの、同じcore.cssの1350行目でより具体的なルールが宣言されたため、効果が打ち消されていることがわかります。

Firefoxの場合も、右クリック→”要素を調査”で同様の機能を使うことができます。

さて、ブラウザの機能で宣言の位置が特定できたら、その箇所を変更することでスタイルの変更も有効になります。WordPressでは、大抵の場合最終的に有効になっているスタイルは、ルートディレクトリからwp-content→themes→現在使用中のテーマ名のディレクトリ、と階層を下ってその中にある、style.cssというファイルで宣言されています。つまり導入しているテーマに付随したCSSなのですが、このファイルをいじれば、とりあえずスタイルの変更ができることが多いと覚えておいて下さい。

しかしながら、このstyle.cssを直接いじっての変更は非推奨です。というのも、不具合が起きてしまったときにその原因が果たしてテーマ自体の問題なのか、あるいは加えた変更の問題なのか、が判別しづらくなります。また、テーマをアップデートする際にはこのstyle.cssごとアップデートされることになるので、アップデート毎に変更部分がリセットされてしまいます。

そういった問題を回避する方法として、WordPress3.0以降のヴァージョンには子テーマという仕組みが存在します。これにより現在有効になっているテーマを直接変更することなく、任意の部分のみに変更を付け足すことができます。また、ファイルとしては親テーマのパッケージの外部に置く形となるので、親テーマのファイルがアップデートされても影響を受けません。
具体的な設定方法を見ていきましょう。まずは子テーマのディレクトリを用意し、その中にstyle.cssというファイルを作ります。今回はmystiqueテーマの子テーマとしてchildtheme1というテーマを作るとします。style.cssの先頭に最低限以下の記述があれば、子テーマとして機能します。

/*
Theme Name: childtheme1
Template: mystique
*/

CSSのコメント行を使って、まずテーマ名と継承元テーマ名を宣言します。通常のスタイル宣言と違いコロンの左側にスペースは許されないので注意して下さい。またTemplateのラベルに指定する値は、親テーマの名称ではなく、themesディレクトリ下の親テーマのディレクトリ名です。大文字小文字の区別もあるので注意を払って下さい。
ともあれ、これで子テーマとして認識されるようになりました。ダッシュボードの左メニューの”外観”から”テーマ”を選ぶと、この子テーマが通常のテーマと同様選択できるようになっています。子テーマを選択すると、親テーマのファイルはそのままにstyle.cssのみ親テーマのではなく子テーマのものを読み込むようになります。

先程のstyle.cssに少し肉付けをしましょう。まず、子テーマのstyle.cssではスタイルの記述が行われていないので、このまま読み込むとテーマの表示が滅茶苦茶になってしまうはずです。親テーマのstyle.cssの記述を継承するための記述を行います。

/*
Theme Name: childtheme1
Template: mystique
*/
@import url('../mystique/style.css');

@import宣言に親テーマのパスを与えます。注意すべきなのは、子テーマのstyle.cssからの相対パスを与えるということです。
これで親テーマのスタイルを丸ごと読み込みました。さて、先述のCSSのルール、後から宣言した方を優先というものを思い出して下さい。つまり@import宣言の後でスタイルの設定を行えば、既に親テーマのstyle.cssで同じ要素に対する設定がされていても、自動的に子テーマのものが優先されるということです。

/*
Theme Name: childtheme1
Template: mystique
*/
@import url('../mystique/style.css');
#none{
display : none;
}

このように書くと、idがnoneの要素が親テーマでどのように設定されていようと表示されなくなります。仕組みがわかれば、あとはつらつらといつも通りのCSS編集ができますね。

以上が子テーマのカスタマイズ（CSS編）です。子テーマではスタイルの変更以外にも、親テーマのもつテンプレートやウィジェットなども置き換え／追加することができます。そちらはPHPの知識が必要となってきますので、いずれ詳しく紹介したいと思います。

WordPressテーマMystiqueの実力

1件のフィードバック

WordPress解説の後編で言及したように、WordPressテーマの中には見た目やページ構成の変更のみならず、ウィジェットやプラグイン機能をもパッケージの中に内包する大規模なものがあります。このブログで採用しているMystiqueというテーマもそうした総合的なパッケージであり、一度使い慣れてしまうと他のテーマへ移行するのが億劫になってしまう程機能が多岐にわたります。折角なのでさらりと紹介させていただきましょう。

まずテーマの基本的な情報です。ルーマニアのdigitalnatureというデヴェロッパーによって開発されているこのテーマは、2009年に最初のヴァージョンが出た後、2.x系から3.x系で一度互換性の無いメジャーアップデートをしています。現在はこの2.x系の系譜のlightヴァージョンと、3.x以降のbasicヴァージョンというラインナップを有しており、basicヴァージョンはダッシュボードのテーマ検索でヒットしない為、オフィシャルページからダウンロードして手動でインストールしなければなりません。昔からのユーザでも、未だに3.x系の存在を知らず2.x系のアップデートを待ち続けているという人が結構いるのではないかと思います。
このテーマの初期からの特徴は、見ての通り少しオタクっぽいデザインとjavascriptを利用したインタラクティブなメニューウィジェットです。当ブログのウィジェットエリアにある黒背景のウィジェットは、実はTabbed WidgetというMystiqueテーマ固有のウィジェットです。これがあることにより、ウィジェットエリアに幾つもウィジェットを並べてスペースを消費することを避けられるというわけで、デザイン上の恩恵は多大です。
3.x系では、このTabbed Widgetの設定もドラッグ＆ドロップでするようになり、タブ化できるウィジェットの選択肢が増えた一方で、初心者がその存在に気付きにくくなりました。設定中のスクリーンショットを撮っておきましたので、導入時の参考にしてみて下さい。

まずArbitaryウィジェットエリアに投げ込む

Tabbed Widgetウィジェットの設定項目として登場するので、チェックボックスで有効化

その他、ひととおり他の人気テーマでできることは抑えています。画像をクリックした時のLightBox的挙動、投稿画像のサムネイル化、写真ギャラリー機能、ソーシャルメディア対応、コメントのレーティングなど。また、さすがにメジャーアップデートで前ヴァージョンからの設定引き継ぎができなかった事は問題と認識していたのか、テーマの設定を独自フォーマットでインポート／エクスポートする機能が追加されています。

このような強力な機能を備えたテーマであるが故、ここまで技術力があるならもうWordPress作っちゃえばいいよという感もあるのですが、実は作っているらしいです（笑）。公式ホームページによれば、テーマのアップデート頻度が減少したのはWordPressクローンを作っているからとの事。かつてのWordPressで可能だったように、データベースにMySQL以外を指定できるようにするらしいです。その他、モジュールとプラグインの一本化などなど。
個人プログラマのこのプロジェクトが、将来的にWordPressを淘汰するまでに至ったら面白いですね。Movable Typeとのシェア転換がそうであったように、OSSは一見些細な切っ掛けから勢力図のドラマティックな転換もあり得る筈です。

（2012.6追記：現在一時的にテーマを外しています。）