WordPress Theme Raindrops 1.265
昨日、今年初めてのレビュー申請を行った。
今年は、モーストポピュラーテーマの7ページ目からのスタートになる。 近年まれにみる最悪のスタートになった。
ダウンロード数の推移は、テーマのメンテナンスや改良が、ユーザーに受け入れられているかどうかの指標だと考えている。
昨年末は、いろいろと、タメの少ない 「改良」を少なからず行った。
一つは、グーグルフォントの CSSクラスの実装であり、もう一つは、ビジュアルエディタへのテーマ設定のダイナミックな反映を行うものでした
ユーザーから、「アップデートしたら、ビジュアルエディタが真っ黒になっちゃった。どうしたんだー」みたいな質問が寄せられたり、
良いと思ってやったことが、実は 違和感を生んでいるという事は よくある事。
ただ、違和感を共有するのは難しい、
ビジュアルエディタへの設定の動的な変更なんて、まだ やっている人は少なく、背景やフォントの再現を含んだものなどは、皆無で、エイヤァで実装したことで、気が付かない不具合を含んでいるかもしれない。
グーグルフォントについても、このテーマのような実装の仕方を取っているプラグイン等は見つけられず、手探りで作っているものだ。
悲しい事に、課題が見えない。
これらの改良？を行う前に、htmlの中にembed していたスタイルや、スクリプトを外部ファイル化するという変更を行いましたが、これは、時間の中で問題点が次第に明確になりつつあります。
それまで、禁断の手法と考えていた template_redirect()を使った方法で、スタイルを外部化したのですが、依存関係がコントロールできないという問題でした。
依存関係がコントロールできないというのは、どういうことかというと、チャイルドテーマを使った場合に（以下は、bootsというチャイルドテーマを使った場合）
<link rel='stylesheet' id='style-css' href='http://example.com/wp/wp-content/themes/raindrops/style.css?ver=1.259.0' type='text/css' media='all' /> <link rel='stylesheet' id='child-css' href='http://example.com/wp/wp-content/themes/boots/style.css?ver=1.259.0' type='text/css' media='all' /> <link rel='stylesheet' id='raindrops_responsiveness-css' href='http://example.com/wp/wp-content/themes/raindrops/responsiveness.css?ver=1.259.0' type='text/css' media='all' /> <link rel='stylesheet' id='raindrops_color_type-css' href='http://example.com/wp/?raindrops_color_type=1&ver=01c0ae9b6f5414a6d80ba66b0b15f572' type='text/css' media='all' />
スタイルシートは、上記のように並ぶわけですが、正しくは、
<link rel='stylesheet' id='style-css' href='http://example.com/wp/wp-content/themes/raindrops/style.css?ver=1.259.0' type='text/css' media='all' /> <link rel='stylesheet' id='raindrops_responsiveness-css' href='http://example.com/wp/wp-content/themes/raindrops/responsiveness.css?ver=1.259.0' type='text/css' media='all' /> <link rel='stylesheet' id='raindrops_color_type-css' href='http://example.com/wp/?raindrops_color_type=1&ver=01c0ae9b6f5414a6d80ba66b0b15f572' type='text/css' media='all' /> <link rel='stylesheet' id='child-css' href='http://example.com/wp/wp-content/themes/boots/style.css?ver=1.259.0' type='text/css' media='all' />
こういう並びにならないと、チャイルドテーマでのカスタマイズ性が損なわれるという問題です。
最初の並び方の場合、raindrops_color_type cssに以下のようなスタイルルールが記述されていた場合
.title{
color:red;
}
チャイルドテーマでは、詳細度を上げてやらないとスタイルが適用されません。
div.title{
color:red;
}
正しい並び順の場合は、
.title{
color:red;
}
で、読み込む順位でオーバーライドが可能という問題です。
どうすべきかという方向性を立てるまでの間、暫定対策として body 要素に、テーマスラッグのIDを追加しました。
今考えてみると、当たり前のことなのですが、そこまで考えが及んでいない。しかし、もう後戻りはできないので、変わる最善の方法を探しています。
前置きが長くなりましたが、こんな中でも、新しい 改善？に取り組んでいます。
昨年の暮れぐらいから、いくつかのメジャーなテーマを読んでみたのですが、テーマのオプション値が、スイッチしても削除されてないヤーン！ という事に、また一つ気づいてしまいました。
ここ2年ほどの間に、テーマのレギュレーションは大きく変化しました。
ある時には、外部クラス等を使うなら、クラスのメンバー関数 クラス内の変数についても、すべて テーマのプレフィックスをつけなければならないというルールでした。
このルールのおかげで、一部の、テーマフレームワークは、排除されるという事が起きました。
私自身も、lessphp を含んでいた obandesというテーマのメンテを中止しました。（ Raindropsが使っていたPEARのクラスは、開発も終了していたので、全力でprefixを付けましたが、、、）
現在は、クラスを含んでもよくなっています。
更に、機能を持たせたければ、プラグインのインストーラを含めることもできます。
このような変化は、テーマをスイッチしたら、テーマ設定は削除されるべきというルール を過去のものにしてしまったようでした。
今考えると、Using Sane Defaults in Themes 等というルールも、このような中で、テーマの切り替えのたびにオプションテーブルに溜め込まれる ゴミ設定を 軽減しようとする試みだったのかもしれないと思うようになりました。
というわけで、テーマオプションに、テーマをスイッチする時に、テーマが自動的に設定した各種の値を 削除するか 保持するか ユーザーが選択できるスイッチを追加しました。
このスイッチがあれば、「試しにほかのテーマをちょっと使って、だめだったらRaindropsに戻そう」という作業が可能になるからです。
この変更は、Raindropsを使っていたユーザーが、チャイルドテーマに切り替えた場合に、Raindropsの設定を引き継いでしまうという 弊害を生みますが、この問題は、説明で解決していくしかないかなと、今のところ考えています。
今回、スクリーンショットをヘッダー画像の縦横比を変更したものに変更しました。
（推奨のヘッダー画像のサイズは、今のところ変更していません）
修正しました 266px から 573px に変更、ver1.266
なんで、変更したのかというと、「もうディスプレイを横基準でテーマを作るのは、限界に近付いているのかなぁ」と思い始めていて、「縦型ディスプレイ」意識し始めました という 意図を込めています。（ 変ですか？ ）
