WordPress テンプレート Twenty Seventeen の困った点

Twenty Seventeen オサレだし、カスタマイズも進歩してるし、日本語フォントなんかもデフォルトで良い感じなのですが、

トップが画面全体を使って画像や動画を置くような形式(以下、勝手に「表紙」と呼ぶ)なのも、用途によるだろうけどいいとして、

その表紙にあるサイト名をクリックすると、ホームへのリンクなので、(当然)表紙が表示されたままなんですね。スクロールさせるか、右下にある(サイト名と比べると目立たない)「↓」を押せばいいんですが、ちょっと不親切な気がする。

それだけならいいんですが、ページ下にあるナビゲーション使うと、またいちいち表紙が表示されるんですね。そこでうっかりサイト名クリックするとトップに戻ってしまう。

で、Twenty Seventeenの子テーマ作って、home_url のフィルタで URL の後ろに #content 足したらいいかなと思ってやってみたものの、今度はナビゲーションのリンクの途中に http://.../#content/page/2 みたいに入ってしまって、リンクとして機能しなくなるのでダメ。このフィルタ、こういう使い方想定してないですかね。

で、このナビゲーションはテーマじゃなくて wp-include/general-template.php で作ってるようなので、そこを見ると paginate_links というフィルタがあるらしい。なので、それを使う。

結果として、子テーマの functions.php は、

<?php
add_action( 'wp_enqueue_scripts', 'theme_enqueue_styles' );
function theme_enqueue_styles() {
    wp_enqueue_style( 'parent-style', get_template_directory_uri() . '/style.css' );
}

add_filter('paginate_links', 'mylink', 1, 1);

function mylink( $link='' ) {
    return $link . '#content';
}
?>

こんな感じに。

んで、home_urlの方はフィルタでいじるのを諦めて、元のテーマの template-parts/header/site-branding.php をコピーして home_url('/') を直接home_url('/#content') へ変更。

もっとうまいやり方がありそうだけど、Wordpress(の中身)もPHPもマトモに触ったことないのでこの辺で妥協。

デフォルトがマシになってくれることを祈る。

Google App Engine

忙しさにかまけていたら,こんなに面白いモノがでてたのを見逃してた。
http://code.google.com/intl/ja/appengine/
早速 Hello world! 的なものを作ってみる。
http://iwate.appspot.com/
ActivePython の x64 版だと SSL のモジュール (_ssl.pyd) がなくて,dev_appserver.py 動かすときや appcfg.py update するときに,怒られる。

AttributeError: 'module' object has no attribute 'HTTPSHandler'

自分で入れてもいいんだろうけど,(XP x64 や Vista 64bit ユーザでも)面倒な人は x86 版を入れるのが吉。っていうか,何で x64 には入ってないんだろ。
もうこれから作るアプリ全部 Python でよくね?という気もするくらいおいしいが,Perl で今まで書いたのをゼロから作り直す気はしないんで Perl サポート希望。

WAMP初挑戦

Windows+Apache+MySQL+PHPで作られているという社内(?)のシステムのUNIX系OSへの移行作業とその後のメンテを押し付けられ命じられたので中を覗いてみる。
PHPは使ったことがないんだがなー。
DBを軽く見てみると

  • テーブル数個のうち半分くらいしか使ってない
  • 何もかもコード化されていなくて,ユーザやグループをはじめとする名称がそのままキーになっている。
  • 一人のユーザに対応するグループが10個分用意されている。正規化されてない。
  • コンテンツを保持するひとつの項目にplain textとhtmlが混在していて判別のための項目はない。
  • たまに情報がDB内ではなく公開ディレクトリに無造作に置かれたテキストファイルに入ってる。
  • フィールド名の綴りがいろいろ間違っている。

PHPの方を見てみると

  • オブジェクト指向ではなく,別ファイルになっている関数群をまとめたものを require する形式。
  • 関数群をまとめたファイルというのが,ディレクトリ毎に同じ名前の別ファイルとして存在していて,同じ関数が定義してあるが中身が少しずつ違う。
  • 同じような手続きがあちこちにある。
  • 組み込み関数の呼び出し方がいろいろ間違っている。
  • ほとんどのデータを登録・修正・削除するインタフェースがない。
  • 入力値に対するチェックがない。
  • 単純に文字列連結でSQL文を作っている。
  • HTMLのエスケープはほとんどやってない。SQLに追加される文字列のエスケープはまったくやってない。
  • 使ってない(作りかけ)のファイルが多数。

など。
さて,どうやって捨てさせるか…。

POSTされる文字列のencoding問題

掲示板などをはじめ,フォームから日本語を入力してsubmitしてサーバ側で処理をさせるような処理を行う場合,大昔のWebブラウザは日本語化が無理矢理だったりした関係で,ブラウザによってPOSTされる文字列のencodingがまちまちだった。このため,多くのブラウザに対応するとなると,受け取る側は自動判定をはじめ小技がいろいろ必要だった。
例えば任意の文字列のEUC-JP/Shift_JISの自動判別を完全に行うことは不可能である。ここでhiddenで適当な文字列を埋め込んで,その文字列を使ってencodingを調べるといった方法もあったが,hiddenと通常の入力フォームでそれぞれ違うencodingで送るブラウザもあったり。User-Agentを見て判定の優先順位を変えるとか涙ぐましい努力をしているものもあったが,新しいブラウザがまた違うパターンだったりしてぶち壊しだったり。
最近のWebブラウザだとだいたいフォームのHTMLのcharsetと同じものを用いるので,下手に自動判定等はしない方がいいようである。
ところで,最近のWebブラウザは英語や日本語以外の多言語を取り扱うことができる。EUC-JPで書かれたHTMLのフォームにEUC-JPにはない(ASCIIにもJISX0208にもない)文字を書くとどうなるか。

“POSTされる文字列のencoding問題” の続きを読む

それPla

某大学情報系学部・卒業研究発表会想定ツッコミ
「~~という背景で~~を目的とした~~システムを構築しました」
「それPlaggerでできるよ」

企業のWebページはどれくらいの画面幅を想定しているか

人に頼んでいたけれど,いつになってもやってもらえないので自分で調査。
対象は,(何かの企業ランキング上位+近所の学生さんが良く見てるページ)のトップページのみ。つまりてきとう。
調べ方もてきとうなので若干ずれがあるかも。(調査日: 2006-08-24)
ピクセル数 ページ
980 www.toyota.co.jp
840 www.squere-enix.com (中は 770)
814 www.gyao.jp
770 www.ntt.co.jp
762 www.nttdocomo.co.jp
760 www.keyence.co.jp
750 www.livedoor.jp
750 www.takeda.co.jp
738 gree.jp
730 canon.jp
720 mixi.jp (中は 800 だったり 950 だったり…)
720 www.nissan.co.jp
710 www.yahoo.co.jp
700 www.honda.co.jp
640 www.nintendo.co.jp
トヨタ広すぎ。
700px台が主流のようです。横800pxの画面でもなんとか見れる大きさ,ってことですかね。

“企業のWebページはどれくらいの画面幅を想定しているか” の続きを読む

Catalystを使ってみようとしたらSQLiteでハマる件

Catalyst::Manual::Tutorial とか見ながら Catalyst をいじっていたところ,

$ script/hoge_create.pl model CDBI CDBI dbi:SQLite:/hoge/hoge.db

とかやったあたりで、

DBD::SQLite::db prepare failed: unsupported file format(1) at dbdimp.c line 269 (以下略)

プギャー。
原因は,db 作るのに使った sqlite (最新)が

$ sqlite3 -version
3.3.4

Catalyst で使ってる DBD::SQLite (1.11; 最新のはず) の中身が,

$ perl -e 'use DBD::SQLite;print "$DBD::SQLite::sqlite_versionn";'
3.2.7

で,http://www.sqlite.org/ によれば,

2006-Jan-10 – Version 3.3.0 alpha
(中略)
The file format for version 3.3.0 has changed slightly in order provide a more efficient encoding of binary values. SQLite 3.3.0 will read and write legacy databases created with any prior version of SQLite 3. But databases created by version 3.3.0 will not be readable or writable by earlier versions of the SQLite. The older file format can be specified at compile-time for those rare cases where it is needed.

でまあ、逆なら読めるんだけど、今回の場合はダメ。
以上,Google 先生に訊いてもわからなかったので一応メモ。
SQLite 2 と 3 の非互換の話はよくあるんだけれども。
えーと,それで対応は,
1. sqlite3.2.x をインストール
2. DBD::SQLite の中身を 3.3.x に置き換える
3. 他のDBを使う
4. 寝る
とりあえず 4. で。