タグ別アーカイブ: WordPress

WordPress.comでTwenty Thirteenを試す

WordPressのサイトを新しく始めようと思った時、まずレンタルサーバを借りて、WordPressを手順通りインストールして…というような手続きが必ずしも必要というわけではない。というのは、WordPress.comという公式が提供するASPが存在するからだ。WordPress.com(日本語版)

このサービスに登録すると、×××.wordpress.comというアドレスが貰え、不要なインストールをせずにWordPressのブログページが作成できる。勿論、広告が多少入り、また完全版より機能が劣っているという制限はあるのだが、少しの気まぐれで思いついたサイトを実現するには、手軽で丁度良い。WordPress形式なので、本格的にサイトを始動しようと思った時は、データベースのエクスポートをして移行すれば良い。

私はTwenty Thirteenを見た。

このWordPress.comだが、デフォルトのテーマ選択肢の中に、Twenty Thirteenが入っている。最近Twenty Twelveが正式版になったばかりだという印象もあったのだが、何とも気の早いことで、ベータヴァージョンというわけでもなく使えてしまうのである。各所で話題になっているようだが、今回のデフォルトテーマの見た目は非常にポップである。

Twenty Thirteen見た目

Twenty Thirteen見た目

これまでのものと比べ、アクの強さもかなりある。きっともう増やす機能がなかったので、メジャーリリースのインパクトを損じないようにデザインを大きくいじったのだろう。

おそらく、最大の目玉機能となるのは、WEBフォントの全面採用。アイコン類もフォントにすることで、真にスケーラブルな、レスポンシブデザインに近づけたということなのだろう。まあ、正直時期尚早だと思っているのだが、これまでも、WordPressが先進技術を積極的に採用してきてくれたおかげで、それらの技術がWEB標準に育っていったという経緯を見ているので(HTML5やレスポンシブデザインね)、諸手を上げて歓迎しておこう。

で、WordPress.comは実用に足るのかということだけど、プラグインが使えない。この時点で、選択肢から外れてしまう。ただ、WordPressの事が何も分からないという人に手っ取り早くブログを作らせるには、インストールもいらないWordPress.comを勧めておけば良いということだろう。


WordPressプラグイン WP Social Bookmarking Lightを導入 

今更ながら、世間で流行っているtwitter、Facebookのユーザにおいでおいでをするため、ツイートするボタンやいいね!ボタンをブログ記事につけられるプラグインを入れてみた。WP Social Bookmarking Liteという、日本では非常にポピュラーなプラグイン。

何故導入するに至ったかというと、数年前と比べてこのブログ(前身は2010年からですので、もう4年経ちましたか)に他ブログからリンクが貼られることが少なくなり、たまに貼られるリンクはtwitterやFacebookのものが多くなってきていたもので。おそらく、以前ネット上でどこか他のページのコンテンツを紹介する際に行われていた、URLコピー&ペーストという儀式が廃れ、全てSNSのボタンをクリック→紹介という手順に変わってしまったのだろうと思われる。最早、URLという存在があるということも意識されていないかもしれない。twitterのタイムラインだけ眺めて、自分ではネットサーフィンをしないという利用もあるかもしれない。

で、導入の手順は、wordpressのプラグインメニューで検索して、インストールするだけなのだが、設定が独特だったので、少し解説をしておきたいと思う。

WP Social Bookmarking Light設定

設定画面

まず一般設定のタブで、SNSボタンの表示位置や表示非表示を決める。表示するものは、ウィジェットの登録と同じようにドラッグ&ドロップで左の枠に投げ込む。

スタイルのタブは、CSSをいじる画面。その隣から先ほど登録したサービスごとの設定画面になるが、言語設定が選べるので、国粋主義者なら日本語を選ぼう。もし志賀直哉ならば、フランス語を選んでも良い。

以上で、記事中の決めた位置にボタンが出るようになる。まあ大抵のテーマならデフォルトの位置で大丈夫だろうけど、見栄えが悪いようだったらCSSでmarginなどをつめるとよい。何故か全てのボタンを囲む.wp_social_bookmarking_lightというクラスのdivは、高さが指定されておらず、ボタンがはみ出している状態で表示されているので、marginをつけるのならばまずheightを指定しておかないといけない。それ以外は特に気をつけることはないだろう。

あと数年もすれば、ボタンを押す手間もなく念ずるだけでリンクが出来るようになるはずなので、それまでこのプラグインには活躍してもらおう。


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

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

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

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

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

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

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

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

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

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


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

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に変更

去る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テーマ

iPadでのTwenty Twelveテーマ

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

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


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

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

ThickBox導入手順1

ThickBox導入手順1

ThickBox導入手順2

ThickBox導入手順2

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


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

以前このブログでは、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ではもう少し融通が利くようになってほしいものです。