サイトでアマゾン商品プレビューを利用すると左右に余白がつく。

前回はamazon商品プレビューのjavaスクリプトを読み込ませるとcssでid="navbar"と指定した場所が乱れることを書きましたが、今回もうひとつ問題を見つけました。

iPod touchやAndroido端末で表示を確認していたらどうも指定していないはずなのに内容表示全体の左右にすこし余白が追加れてました。例によってchoromeの機能である「要素を検証」で調べたところやっぱりamazon商品プレビューのjavaスクリプトによってbodyタグの左右にマージンを指定するcssが効いていたのでした。

↓こんなことしてたのです。

body {
  margin: 0 8px !important;
}

PCのブラウザで見る分にはたいして問題になりませんけどiPod touchやiPhoneやAndroid端末では画面が小さく狭いですから左右の8pxずつは気になります。
携帯端末ではマウスカーソルをリンクの上にのせるということはできないのでamazon商品プレビューを有効にしても意味がありません。よって携帯端末(user agentで判断)ではamazon商品プレビューのスクリプトは読み込ませないように修正しました。

これで期待通りの表示ができるようになりました。

アマゾン商品プレビューでナビゲーションバーの乱れる理由

WordPressでサイトの構築を完了したあと、amazonの商品プレビュー用のjavaスクリプトを設置したらナビゲーションバーの表示が乱れた。cssで設定した幅よりも少し広がってしまうのだ。

なぜ乱れるのか検索してもこの症状について書いてあるページがないのでしばらく使用しないでいたけれど、先ほどなおすことができたのでここに書いておきます。

理由：
htmlのnavタグのidの名前をnavbarにしていたから。

つまり、

<nav id="navbar">

としてサイトを作るとamazon商品プレビュー用のjavaスクリプト側でnavbarのcssによる設定を上書きしてしまうからだった。
しかたがないのでnavbarという名前をやめてglobalnavとしました。

<nav id="globalnav">

たぶんクラス名とかID名がかぶってるのではないかなぁとは薄々思ってはいました。まさかアマゾンさんがそんなことしないだろうと思っていたし。で、ブラウザのchromeに標準にある機能「要素を検証」で調べていってわかりました。やっぱりそうなのかというがっかり感。

ちなみになぜnavbarにしていたかというとWordPressの本に書いてあった例をそのまま採用したから。でもこれ高い確率で使われる名称だと思うんですよね。
あとからやってきたamazonのjavaスクリプトになんか負けた気がしてしまうのでした。

WordPressとツイッターとの連携、私の場合

WordPressで投稿した時、投稿したことをtwitterでも自動で通知したいときどうしようか。
すぐ思いつくのはそれ関係のプラグインをインストールし実行することだよね。

でも、私の場合はそれはしなかった。プラグインをなるべく入れないようにするためです。
どうするかというとWordPressが出力するRSSを利用すれよくて例えばdlvr.itというサービスがあります。最初はこれを利用させてもらうと考えたのだけれどすでに使っている別のサービスでも同じ事ができるのでそちらで行うことにした。

それはIFTTTというサービスでこれについては以前にも記事を書いています。
これで「RSSが更新されたらそのタイトルとURLをツイートする」という設定をしておけばいいのです。

このIFTTTはいろいろなサービスに対応しているし、設定も簡単なのでアカウントをひとつ持っておけばいろんなことができて便利。
ついでにtumblrの更新もこれでツイートするようにした。（Tumblr自身にツイートする機能はあるんですけどね。この方がなんとなく面白いから(^^)）

WordPressでの実運用をして気がついたちょっとしたこと

自サイトをWordPressにして数日後にGoogleウェブマスターをチェックしたらエラーなどがでていた。

リンクがたどれない。

サイドバーに貼った自サイト内へのリンクが見つからないという。そのリンクは相対指定にしていたのがまずかった。最初のページならそれでもいいのだけど2ページ目以降はURLの関係で相対指定できないのだった。

href="aaaa/bbbb.html" とした場合、
1ページ目なら http://sitename/aaaa/bbbb.htmlへのリンクとなるけれど
2ページ目以降は http://sitename/page/2/aaaa/bbbb.html となってしまう。
慣れてる人なら当たり前のことだろうけど自分はローカル環境で試作していたときは気がつかなかった。

titleタグとが重複する。

WordPressにする前でもtitleとdescriptionが重複したので修正したことがあったので一応気をつけていたのだけど一発でうまくは行かなかった。
メタデータdescriptionの方は2ページ目以降にはページ番号をつけて重複になるのを避ける処理を入れていたのだけど、titleタグの方には何もしていなかった。なぜか気がつかなかったのでtitleタグにもページ番号を入れるようにした。


<?php global $paged; $pagestr = ($paged >= 2)? ' (ページ'. $paged . ')': ''; ?>
<title><?php wp_title('&laquo;', true, 'right'); ?><?php bloginfo('name'); echo $pagestr; ?></title>



ウェブマスターで気づいたのはそれくらい。

自分で自分のページを見るときのGoogleアナリティクスコードの実行抑止

正式公開後、固定ページの更新や投稿ページ作成の時にプレビューを見るのだがこの時もGoogleアナリティクスのコードが実行されてカウントしてしまうことに気づいた。気づくのが遅いね！
ということでプレビューならカウントしないようにPHPを修正した。
けど落ち着いて考えたらWordPressにログインしている時にカウントしないようにしておけばプレビュー以外でも自分のアクセスをカウントしないことに思いいたった。
のでログインしていたらカウントしないようにさらにPHPを修正した。


<?php if(!is_user_logged_in()): ?>
（Googleアナリティクスのコード）
<?php endif; ?>



しかし「気がついた」「気がつかなかった」の多い文章だね。

私のページのWordPressのインストールから公開まで

私が行ったWordPressへの移行作業をここに記録しておきます。

まず、前提。
・レンタルサーバーはさくらインターネット。
・元のページはライトプランだったのでWordPressは使えない。よってスタンダードプランを新規に用意した。
・さくらインターネットで用意されているクイックインストールは使わず手動でインストールする。とくに理由はなくなんとなくそうしたかったから。
・コンテンツの作成もエクスポート・インポートではなくひとつづつコピーアンドペーストで。これもとくに理由はなく単にそうしたかったから。
・WordPressを独自ドメインで素直に使うためにはインストール作業を独自ドメイン名で行う必要がある。したがってあらかじめWordPressをインストールしてから独自メインを設定し直すというやり方はしない。
ただそれだと作業中の中途半端な状態が訪問者に見えてしまうのでメンテナンス中という表示をする必要がある。


全体の流れは以下のとおり。

1. データベースの準備
2. 独自ドメインの付け替え
3. WordPressのインストール
4. 独自テーマの構築
5. 固定ページの作成
6. 過去投稿から最近のものを持ってくる
7. その他の部分の作成
8. 正式公開

1.データベースの準備

データベースMySQLをコントロールパネルから作成。これはとくに気をつけること点はなく素直に作成した。

2.独自ドメイン付け替え

まず新しいサーバー上に「準備中」と表示されるだけのシンプルなHTMLファイルをWordPressをインストールするディレクトリに作成しておく。この場合インストールするディレクトリ名はwordpressとした。
/home/ユーザー名/www/wordpress/index.html

次に前のサーバーのコントロールパネルから独自ドメインを外して2時間待つ。ドメイン設定関連は2時間ほど間を開けろと書いてあるので。
2時間たったら新しいサーバーのコントロールパネルからWordPressをインストールするディレクトリに独自ドメインを設定する。
そして、独自ドメイン名でアクセスしそれがネットに反映され準備中が表示されるのを待つ。

3.WordPressのインストール

WordPressをja.wordpress.orgからwordpress-x.x.x-ja.zipを/home/ユーザ名/wwwにダウンロード。
先のindex.htmlファイルとディレクトリwordpressを削除してからwordpress-x.x.x-ja.zipを展開。unzipするとディレクトリwordpressが作らるので問題ない。
で、すぐに独自ドメイン名でアクセスする。でないと悪い訪問者に乗っ取られかも？
設定ファイルがないから作るよ、っていう画面が出るのでそこから画面に従ってインストールしていく。それにはMySQLのデータベース名などの入力、サイト名やユーザー名などの入力を行う。
wp-config.phpとかを直接編集するようなことはしていない。

4.独自テーマの構築

ここで独自テーマの構築だけどその前にメンテナンス中と表示するプラグインをインストールし実行しておく。

ここでちょっとした問題が発生しました。ローカル環境でも試したプラグインを使おうと検索したらなくなってた！どうも作者が取り下げたらしい。ということで急遽なにかよいものを探すことに。
どれがいいかなと検討している間にもHPに訪問者がくるかもしれないのでWordPressに初めからある最初の投稿の内容を「準備中」に変更した。
そしてあらためてプラグインを探してインストールした。

さて、訪問者にはメンテナンス中と表示されるようになった所で独自テーマを構築していく。

独自テーマの構築といってもローカル環境に作ってあるのでそれをコピーするだけ。

ところがここでまた問題が発生。WordPressのphpファイルなどを編集して更新ボタンを押すとブラウザの表示が真っ白になってしまう。functions.phpを空にすると白くはならないのだけどもちろんそれでは意味が無い。wp-config.phpのDEBUGをtrueにしてみるとエラーメッセージが表示される。
"Cannot modify header information - headers already sent by………"と。
このエラーメッセージを検索したところなにやPHPの関数を使うタイミングが良くないらしいのだが、ローカル環境で問題ないので悩んだ。さらに調べていくと別の解決方法が見つかりこの場合php.iniに一行記述すれば良いらしい。
"output_buffering=on"
と書いたところちゃんと更新ボタンを押しても白い画面にならずちゃんと表示されるようになった。よかった。このエラーには焦りました。

プラグインもインストール。使ったのはContact Form 7と.html on PAGESのふたつだけ。

これで独自テーマの構築は完了。

5.固定ページの作成

これもローカル環境で作ってあったものをコピー・アンド・ペーストするだけ。とはいえエクスポート・インポートというやり方にはしなかったのでそれなりに時間がかかった。

6.過去投稿から最近のものを持ってくる

これもエクスポート・インポートというやり方はしなかった。ローカル環境ではダミーの投稿だけだったので前のサーバーのデータからコピー・アンド・ペーストするだけ。ただ、投稿日はあわせるので注意した。やはり時間がかかる。

7.その他の部分の作成

サイドバーを構築。
次にページのトップに固定でカスタム投稿タイプをひとつ表示するための作業があったのでけれど
この段階で10時間かかっているし、休憩を長く取りたかったのでメンテナンスモードを解除し公開した。

8.正式公開

十分休憩をとったあとページトップにカスタム投稿タイプの記事をひとつ表示する設定をした。そのあと固定ページにあるリンクアドレスの確認や表示乱れがないかなどの確認し正式公開とした。

正式公開後にGoogleアナリティクスのコードをヘッダに記述し、プラグインGoogle XML SitemapsをインストールしてGoogle対応した。


次のエントリでは実運用して気づいたことを書こうと思う。

WordPressへの移行完了。

WordPressの勉強中であるとこの前のエントリで書きましたけどついにWordPressを実運用を一週間ほど前から開始しました。
長い間HTML手打ちで運用してきた私のページがWordPressへと移行したのです。

ローカルPCに環境を作っていたので移行はスムーズにできましたと言いたいところですが少しトラブルがあったのと意外と時間がかかってしまいました。

構築手順やトラブルについては次のエントリに書こうかと思います。
作業は数時間で終わるかなと思っていたけどトラブルや過去のエントリの再掲作業に意外と時間がかかってしまった。夜中の1時に始めて朝には出来るつもりが昼ごろに仮公開し、半日休んでからちょっとづつ作業して完全になったのは次の日の18時ごろとなってしまったのでした。

現在は順調に運用中です。