シェアされたページの取り消し方
以前、こんな日記を書いたけど、それに関連して。
イベントの告知ページを、急遽中止ということでお詫びのページに差し替えて欲しいとの依頼があった。ページにはソーシャルボタンが埋め込まれていたこともあって、既に多数のシェアがされている。
- 告知ページの内容を、お詫びページに差し替える。
- 新たにお詫びページを作り、告知ページからリダイレクトさせる。
以前ならどちらでも結果は変わらないのだけど、今はシェアの数が変わってしまうので意味がちがってしまう。今回の対応は後者だし、今後も似た事例はそうすると思う。
wordpressのプラグイン「myCalendar」で突然記入できなくなった件
wordpressで高機能なカレンダー機能を追加してくれる有難いプラグイン「myCalendar」が、いつのまにか新規記入できなくなっていた。
保存を押しても「データベースにイベントを追加できませんでした。」というメッセージが出る。過去データは正常に表示されるし、それ以外におかしな動作は無い。
1年以上問題なく使われていて、プラグインとwordpress本体のアップデート以外に大きな更新はしていない。データベースを最適化してみても変わらず。サポートフォーラムにも具体的な例は見つからなかった。（一件似たものはあったけど、それも原因不明のままで、作者が「奇妙だ」と言っている）
ふと思いついて英文で記入してみると、すんなり保存できた。どうも日本語の投稿だけでエラーが出るらしい。
データベースを確認すると、該当テーブルの文字コードが、utf8_general_ciであるところがujis_japanese_ciになっていて目を疑う。何故？いつから？
ともかく、それが原因だった。phpMyAdminでちまちまと文字コード設定を変更したら、問題解決。
とあるサイトのモバイル率の変化、ここ数年について
古い書類を整理していたら、ふと目が止まったので、メモ。
2013年5月日付のサイト運営報告書に、「モバイルの割合は、前年度が35.6％だったのが、現在49％まで増えています」との記述があった。
ちなみに、同サイトの2014年8月現在、モバイルのアクセス比率は58%。タブレットを含めると60%を超えている。
和文Webフォントを使った際のメモ
web更新から画像文字の面倒を解消してくれるだろう、Webフォントを使ってみたので、メモ。
前提
使用するのはページ見出し部分。本文には使わない。
使ったのはライセンスに問題がない条件を満たせば使える、IPA系のフォント。ここでの例として、IPAex明朝。TTFフォントそのままだと7.47MBもあり、いくら回線が速くなったとはいえども、実用的ではない。
容量を小さくする
そこで必要な文字だけを抜き出したサブセットを作る。使わせていただいのは株式会社 武蔵システム様の「サブセットフォントメーカー」。ありがとうございます。
必要な文字の選定は、見出し限定だったら、サイトマップを作ったついでに見出し文を抽出するのが最小。汎用的に使いたい場合は、第一水準漢字に限定。第2水準漢字以降は、頻度の少ない人名地名などで使われる文字だけなので、見出し文に使われることは、まずないとする。
第一水準漢字と英文、各種記号とかを足すと3,671文字になった。これを使ってサブセットを作る。
すると、TTFファイルで、1.09MBまでサイズが落ちた！約15%にもなる縮小だ。
Webフォント用で一番多く使われるwoff形式だと更に小さくて、765KB。IEが使うeot形式は687KB。
これならちょっと大きめの画像ぐらいなので、十分実用レベル。実機でも許容範囲であると確認済み。
WebフォントにCSS3で装飾を加えると見栄えも十分だし、スマートフォンなどでピンチインして拡大しても滲まないのは、とても気持ちがいい。CMSなどで動的に変化する見出しに使えるのは、画像フォントを使った場合のめんどくささや、システムフォントを使った貧相さから思えば、感激ものだ。
WindowsPCで困る
ただ、意外な落とし穴があった。小さな文字が、WindowsPCだと表示が汚いのだ。使えないのではない。対応しているのだけど、25pxより小さな文字サイズでは、アンチエイリアスが有効になってくれなず、ジャギーでまくり。これはIEだけでなく、Firefox、Chromeなど他のブラウザでも変わらない。例外的にWindows8.1のIE11だけはちゃんとアンチエイリアスがかかっていたけど、これは少数。同じWindows8.1でもFirefox、Chromeは未対応。Windows7のIE11でも駄目。（Windows8のIE10,11は環境が手元にないので未確認）
MacOSはもちろん問題なく、iOSも、Androidも、Linuxでも、綺麗にアンチエイリアスされて表示される。Windowsでだけ、ジャギーがでる。
ネットで検索すれば、同じ問題に頭を抱える人は多数で、CSSで滲ませたりする事で軽減する工夫も提案されているものの、「しないよりも、ちょっとまし」レベルでしかない。
大見出しは25ピクセル以上にできるので問題ないのだが、ナビゲーションメニューなどはどうしてもひっかかる。クライアントによっては首を縦に振ってくれなかった。その場合、javascriptでUA判別をした。
if(navigator.userAgent.indexOf('Windows') != -1){
$("body").addClass('ms');
}Windowsだけ、bodyに「ms」クラスを足している。これをセレクタにして、該当箇所をCSSで画像文字に置換した。
この問題が、Webフォントの普及の足かせになっていると思う。スマートフォンですら綺麗に表示できるのに、残念だ。早い日に、Windows8.1+IE11がIEの大多数になって、他のWindowsのブラウザも、綺麗なアンチエイリアスに対応してくれることを切望する。
前期までのWebの仕事の雑感
まだ終わっていない仕事もあるけど、一段落付いた感じもあるので、備忘的に。
レシポンシブWebデザイン
前々期と比べて一番変わったのはこれだろう。新規案件はほぼ全てで採用。反対意見は特に無かった。
IE6,7の切捨て
WindowsXPのサポート切れに合わせて。コーディング上の悩みがかなり減って、これまで控えていた記述も積極的に試せるようになった。
スマホ・タブレットのアクセスがPCを上回った
去年からの事だが、もう元へは戻らないだろう。自己体験的にも、仕事で使うからPCに毎日触れるが、ネットをリードオンリーなら、わざわざPCを使う理由は思いつかない。一般家庭ではなおのことと推測。
携帯サイトの衰退
スマホの普及とともに激減した、携帯からの閲覧。1%を下回ってしまうと、もはや制作コスト的に見合うとはいえない。CMSを使っているなら変換プラグインで放置するぐらいがせいぜいで、きっぱり廃止したところも。それは正しい判断だと思う。ガラケーしか持たない人は周囲にほとんど居らず、そして彼らはガラケーでネット閲覧をしない（だからガラケーを使う）。
携帯サイトを切り捨てたことのメリット
javascriptが存分に使える。Shift-JISを意識しなくていい。絵文字を触らなくていい。携帯に配慮してテーブルの使用を控える必要が無くなった。携帯向け情報取捨のコストが無くなった。振り分けでのキャッシュトラブルから開放される。
和文Webフォントを使用した
モバイルでの回線速度による問題が無くなったと思えたので、実践採用。今のところ苦情はない。WindowsPCでは25ピクセル未満でのジャギー問題（アンチエイリアスされない）があるので、Windowsのみ画像文字との併用が残る。MacOS、iOS、Android、Linuxで問題ないのだから、早く解消して欲しい。
rethinaの対応
ロゴなどの一部では高解像度モニタへの対応が必須。手間は、2枚の画像を用意するのと、対象画像に目印のクラスを足すぐらい。javascriptで差し替える。そんなに面倒でもない。
カスタムアイコンフォントの採用
上記に関連して。思ったより簡単だった。CSS3との併用で見栄えも十分だし、サイズ・色が自由に変更できるので使い勝手がいい。テキストシャドウが使えないIE9が消えてくれれが完璧。
BASIC認証のグループ設定を自動で更新する
.htaccessによるBASIC認証でアクセス制御しているサイトで、ユーザーリストから、特定のルールに沿ったユーザー名のみ抽出して使いたい案件が出た。頭文字にaが付いているユーザーだけを認証する、みたいな。ユーザーリストはデータベースでなく、テキストファイル。
データベースでなくても.htaccessは正規表現が使えるから簡単に出来そう、と最初は思ったが、実際にはユーザー名に正規表現は使えなかった。そもそも、認証するユーザー名にワイルドカードが使えたら危なすぎるから当然か。
ユーザーの絞込み目的には、BASIC認証にグループという機能がちゃんと用意されているので、グループリストを作ればいい。作り方は簡単で、グループ名：ユーザー名 ユーザー名…といった書式でテキストファイルを用意して、.htaccessでグループとして読み込んで使う。
ただし、ユーザーリストが静的なものならこれで問題ないものの、動的に更新されている場合は、グループリストの更新のタイミングが問題になる。コマンドラインからユーザーを追加された場合、どうやって検知し、反映するか。
.htaccessから呼ぶグループリストのパスに、phpなりperlなりのスクリプトを置いて、そのまま加工済みデータを渡せたら、と試すも、不発。スクリプトを置いても、単なるテキストとしか認識しないらしい。
cronで監視するのもタイムラグが出るし、更新頻度を上げるのは無駄すぎる。たかが読み出し専用のテキストデータに、CGIでの管理やデータベース認証するような大げさな話にしたくない。手軽で効率の良い方法はないものか、と考え続けて、思いついた方法。
「認証を失敗した時のエラーページに更新スクリプトを書けばいい」
BASIC認証の.htaccessファイルに、以下を付け加えた。
ErrorDocument 401 /error/error.php
error.phpには、元になるユーザーリストを読み込んでグループリストをファイルに出力する記述を書いておく。ブラウザへの表示には、実際のエラーページから取ってきたhtmlを使えば、見た目の判別はつかない。（エラーページへのパスはブラウザに表示されない）error.phpの設置場所をもっと複雑なパスにしておけば、更に安心。ただし、呼び出し可能な状態にはしておかないとならないようだ。
追加されたばかりのユーザーが認証を受けようとした場合、初回は当然失敗する。しかし、失敗した瞬間にグループリストが更新されて、ユーザーはすぐに認証されるようになる。
実際にやってみると、これで上手くいく。この仕組みをユーザーには知らせておかなくても、初回一度の認証失敗はタイプミスかと思うだけだろうから、気づくことはないだろう。
