先週ぐらいにWordPressをモバイルに対応させるプラグインKtai Styleを導入したのですが、Google Analyticsだとモバイルサイトのアクセス解析ができなくってどうしようかと思っていたら、ケータイサイトでGoogle Analyticsを利用するためのライブラリという記事があったので早速試してみました。
- まずはファイルをGA4Kからダウンロードして解凍し、”GoogleAnalytics”というディレクトリをKtai Styleプラグインで利用しているテーマ(自分の場合は”default”)のディレクトリである wp-content/plugins/ktai_style/themes/default/ 配下にコピーします。
- そしてコピーしたGoogleAnalyticsディレクトリ配下にある Config/analytics_config.php にトラッキングしたいサイトのIDとドメインを設定します。該当箇所がコメントアウトされているのでこれを解除します。
- 最後にトラッキングするため、以下のようにコードを wp-content/plugins/ktai_style/themes/default/header.php あたりに追加します。
--- header.php.orig 2009-01-25 19:46:39.000000000 +0900
+++ header.php 2009-02-01 23:01:34.000000000 +0900
@@ -6,6 +6,15 @@
<style>p {margin:0.75em 0;}</style>
<?php }
/* ks_wp_head(); */ ?>
+<?php
+/* customize: Google Analytics */
+require_once (dirname(__FILE__) . '/GoogleAnalytics/Service/analytics.php');
+require_once (dirname(__FILE__) . '/GoogleAnalytics/Config/analytics_config.php');
+sendGoogleAnalytics(ANALYTICS_ID, WEBSITE_DOMAIN);
+/* /customize: Google Analytics */
+?>
</head>
<body>
<?php /* <body bgcolor="" text="" link="" vlink=""> */ ?>
@@ -28,4 +37,4 @@
<h1><?php bloginfo('name'); ?></h1>
<?php } ?>
<div align="right"><img localsrc="325" alt="0." /><img localsrc="30" alt="<?php _e('v', 'ktai_style'); ?>" /><a href="#tail" accesskey="0"><?php _e('Menu', 'ktai_style'); ?></a></div>これで実際に携帯でアクセスしてみてから1,2時間後にGoogle Analyticsをチェックしてみると、以下のように携帯端末のアクセスが記録されているはずです。
それにしてもKtai Styleプラグインの携帯対応ぶりがすごい。プラグインの自由度が高いからここまでできるのですかね…なお、Google Analyticsのモバイル対応にあたってはこちらを参考にさせてもらいました。
昨日のAutoPagerizeに引き続き、LDRizeも設定しました。LDRizeはscript/LDRize/siteinfoのWikiに追記すると設定できますが、例によって一旦ローカルでうまく動くか試すのがよいでしょう。
- Greasemonkeyのアイコンを右クリック
- ユーザスクリプトの管理
- LDRizeを選択
- ”編集”ボタンをクリック
してスクリプトを開き、var SITEINFO に以下を追加します。
{
name: 'おいぬま日報',
domain: '^http://tech¥.lampetty¥.net/tech/',
paragraph: '//div[@class="post"]',
link: 'h2/a',
view: 'h2/a/text()',
}
これで動作確認したらローカルのスクリプトは元に戻しておいて、script/LDRize/siteinfoのWikiに追記します。で、Greasemonkeyのアイコンを右クリック->ユーザスクリプトコマンド->LDRize – update siteinfoをクリックするとSITEINFOのデータが最新の状態になります。
これで”j”, “k”, “p”, “o”キーで一気に読めるようになりました。めでたしめでたし。
タイトル通り、このブログにAutoPagerizeを設定しました。これでGreasemonkeyでAutoPagerizeを入れている人はちょっと幸せになれるはず。今回もwedataを使っているのですが、ここに書き込む前にローカルで動作確認をしました。具体的には
- Greasemonkeyのアイコンを右クリック
- ユーザスクリプトの管理
- AutoPagerizeを選択
- “編集”ボタンをクリック
してスクリプトを開き、var SITEINFO に以下を追加して下書きをします。
{
url: '^http://tech\.lampetty\.net/tech/',
nextLink: '//span[contains(@class,"older") or contains(@class,"next")]/a',
pageElement: '//div[contains(@class,"post")]',
insertBefore: '//div[@id="postnavi"]',
exampleUrl: 'http://tech.lampetty.net/tech/',
},
これでコメント欄の直後に次のページの内容が挿入されるので、あとはブラウザをリロードして正しく動くかどうかを確認。問題なかったらこっちはコメントあうとして、wedataに反映させます。
コンテンツを作っているのは自分なので、本来であればHTMLにmicroformatsで入れても良いのですが、あんまりテーマのファイルをいじりたくないのでwedataに書き込みました。さて、次はLDRizeをやらないと…
投稿を表示するページをIEまたはSafariで表示するとデザインが崩れてました。あらためてクロスブラウザチェックの必要性を感じた今日この頃orz…
どうもこのiNoveというテーマのフォントサイズが小さい(bodyタグで12px指定)のが無性に気になったので、WordPressでフォントサイズを変更できるプラグインがないかを探してみたら、WP-chgFontSizeというそのままずばりのものを発見しました。
インストールはいつものようにファイルをダウンロード→解凍→wp-content/plugins に移動→管理画面から有効化するだけです。で、管理画面から設定をするんですが、フォントサイズの単位が px, em, %が選べるので、自分はfont-sizeのパーセント表記一覧 – Webtech Walkerを参考にさせてもらい、パーセンテージ指定にしました。具体的には
- Min: 100 (12px相当)
- Max: 150 (18px相当)
- Default Font Size: 108 (13px相当)
という感じです。これで12pxという小さいフォントサイズは解消できたのでめでたしめでたし。本当は14px相当にしてもよかったのですが、投稿タイトルのh2タグのフォントサイズがなぜか大きくできないので、本文のフォントサイズは控えめにしてあります。
Google Mania経由で知ったのですが、Google Notebookの開発が中止され、今後新機能が追加されなくなるようです。ちょっとしたメモ書きを残すのに便利に使っていたので、非常にショックです。ただ、開発は中止になってもサービス自体は継続されるらしいので、しばらくは利用できるらしいのですが、先行き不安…
不景気だからGoogleも採算の取れないサービスに見切りをつけ始めたのですかねぇ。
自分がMySQLをインストールしたあとに行う設定を備忘録がてら書いてみます。サーバのスペックによって若干変動するところもありますが、チューニングする項目というのは大体こんなもんでしょう。
user = mysql
pid-file = /var/run/mysqld/mysqld.pid
socket = /var/run/mysqld/mysqld.sock
port = 3306
basedir = /usr
datadir = /var/lib/mysql
tmpdir = /tmp
language = /usr/share/mysql/english
skip-external-locking
# ここまではわりとお決まりの設定。環境によってファイルのパスは適宜変えます。
# サーバ側で使用する文字コードの設定
default-character-set = utf8
# クライアント/サーバ側での文字コード変換を行わない
skip-character-set-client-handshake
# CREATE TABLE する際に ENGINE=InnoDB の指定をしなくてもInnoDBにする
default-table-type = InnoDB
# クライアント/サーバがやり取りすることのできるパケットサイズを指定
# 巨大なデータをやり取りする場合は指定した方がよい
max_allowed_packet = 16M
# MyISAMで使用するINDEXのキャッシュサイズ
key_buffer = 64M
# スレッドのスタック領域のサイズ
thread_stack = 128K
# 生成されたコネクション用のスレッドをキャッシュしておく数
thread_cache_size = 16
# 最大同時接続数。メモリ搭載量にもよるが100〜300ぐらいが良いらしい
max_connections = 150
# MyISAMで一度開いたテーブルをキャッシュしておく数
table_cache = 128
# 同時に実行できるスレッド数。CPUのコア数の2倍を設定
thread_concurrency = 2
# query cacheの設定
# 0: OFF, 1:ON, 2:DEMAND
query_cache_type = 1
# キャッシュするクエリ結果の最大サイズ
query_cache_limit = 1M
# クエリキャッシュに割り当てるメモリ量
query_cache_size = 16M
# slow logの設定
log_slow_queries = /var/log/mysql/mysql-slow.log
# 3秒以上かかったクエリは上記ログファイルに出力
long_query_time = 3
# ここからレプリケーションの設定
# MySQLサーバごとに固有のID
server-id = 1
# バイナリログ出力先
log_bin = /var/log/mysql/mysql-bin.log
# データ書き込み(トランザクションのコミット)を何回行ったらバイナリログを
# フラッシュするかの回数。0の場合はデータ書き込みがあってもバイナリログをフラッシュしない
sync_binlog = 0
# バイナリログを保持しておく日数
expire_logs_days = 60
# バイナリログの1ファイルあたりの最大サイズ
max_binlog_size = 1024M
# バイナリログを出力する対象のDB
binlog_do_db = hoge
# バイナリログの出力対象外とするDB
binlog_ignore_db = mysql information_schema
# Berkley DBは使わない
skip-bdb
# InnoDBのデータファイルの名前とどのぐらいで自動拡張するか
innodb_data_file_path = ibdata1:128M:autoextend
# テーブルごとに.ibdのデータファイルを作成するかどうか
innodb_file_per_table = 1
# InnoDBの内部データなどを保持するための領域
innodb_additional_mem_pool_size = 20M
# InnoDBのデータやインデックスをキャッシュするためのメモリ上の領域
# DBサーバ専用のマシンの場合はメモリの50%-80%を指定
innodb_buffer_pool_size = 256M
# InnoDBの更新ログを記録するメモリ上の領域
innodb_log_buffer_size = 8M
# InnoDBの更新ログを記録するディスク上のファイルのサイズ
# 大きくするとパフォーマンスはあがるがクラッシュ時のリカバリに時間がかかるようになる
innodb_log_file_size = 64M
# データをファイルに書き込む際のメソッド。
# Linuxの場合は O_DIRECTがパフォーマンス的にはよい
innodb_flush_method = O_DIRECT
# InnoDBのログバッファをInnoDBログファイルに書き込むタイミングを決める
# 基本的には1
innodb_flush_log_at_trx_commit = 1
# 2相コミットを行うかどうか
innodb_support_xa = OFF
# クラッシュ対策としてデータの二重書き込みを無効にする
skip-innodb_doublewrite
innodb_で始まるInnoDB関連の設定項目の詳細についてはMySQL5開拓団 ストレージエンジンの吟味 (2)にとても詳しく載っているので一読してみた方がよいです。あとはDSAS開発者の部屋:5分でできる、MySQLのメモリ関係のチューニング！も非常に参考になるでしょう。MySQLの設定はなかなか奥が深いですが、設定項目の意味を理解していればよいパフォーマンスを引き出せると思います。
コメント