WordPress Theme Raindrops 1.252
11/6 差分レビュー終了 Approved
15分ほど前、Raindrops1.252をレビュー審査に提出した。
今回のアップデートは、各方面から、うまく動作しないと指摘されている wp_nav_menu() プライマリメニューの、hoverしても、サブメニューが開かないといった指摘に対する対応
ページの上部に水平に並んだこのメニューは、アクセシビリティ(現在アクセシビリティタグはつけていませんが)対応の過程で、3つのモードで動作します。
キーボードアクセシビリティーを標準で機能するようにしている関係で、バグが止まない。
functions.phpに、
$raindrops_enable_keyboard = false;
と記述すると、キーボードアクセシビリティの機能は停止して、大体うまく動作するのですが、この処理してくださーい なんて言っていると、
「なんだよ、説明しろよ」みたいなことを言われたり、「そんなの解からないから、修正したスタイルシートダウンロードできるようにしろ」とか、注文が付く。
サブメニューが開かない という問題がなぜ発生するのか?
ユーザーの中には、カスタムメニューのページに一切手を付けない人もいて、一切手を付けないと wp_page_menuを使ってページが表示されるわけで、以下のhtml構造になります。
<nav id="access"> <div class="menu"> <ul> <li class="current_page_item"><a href="">Home</a></li> <li class="page_item page-item-26545 page_item_has_children"><a href="">Manufactures</a> <ul class="children"> <li class="page_item page-item-26551"><a href="">…</a></li> <li class="page_item page-item-26547"><a href="">artic cat</a></li> <li class="page_item page-item-26549"><a href="">John Deere</a></li> <li class="page_item page-item-26553"><a href="">Sno-Jet</a></li> </ul> </li> </ul> </div> </nav>
メニューを使った場合は Raindropsの場合
<nav id="access"> <div class="menu-header"> <ul id="menu-menu-2" class="menu"> <li id="menu-item-26583" class="menu-item menu-item-type-custom menu-item-object-custom current-menu-item current_page_item menu-item-home menu-item-26583"><a href="/">Home</a></li> <li id="menu-item-26584" class="menu-item menu-item-type-post_type menu-item-object-page menu-item-26584"><a href="">Manufactures</a></li> ... </ul> </div> </nav>
wp_nav_menu()は、上記のコードを出力し、htmlの構造が異なってしまう。
Raindropsは、通常のメニュースタイル、キーボードフォーカスと共存するメニュースタイル、アクセシビリティモードのメニュースタイルを持っているわけですが、全くメニューを操作しない場合のスタイルが考慮されていなかった
という事が、今回の問題を引き起こした
なら、wp_page_menuのスタイルをさらに追加すればいいだけなのですが、hover()を立てると、focus()に問題が出たりして、シャンシャンシャンと手打ちができない状態を、何とかクリアしようと、ハムスターの走る様のように細かい調整を行ってきました。
フィルタで、クラスを追加して同じ構造にしても、うまくいかない( 理由は、今でも判然としない )
1.252では、オプションを追加して、キーボードフォーカスを無効にするオプションを追加した。
これで、フィールドテスト(ユーザーのクレーム)をみながら、自動的にwp_nav_menu()を使っていない事を検知して、使っていない場合は、キーボードフォーカスを無効にしようと考えている。
自動化のテストは、もう見通しが立っている、あとは、ビンゴか ハヅレかを 見極めるだけ。
同一構造にしても動かない問題は、しばらく継続してみていくつもり
まとめると、間抜けな私は、自分の間抜けに気付けない。クレームをつけてくれる人の有難さ
場当たり的だよ、俺
だから、こうべを垂れて、ひたすら OK! を待つ
こんな事を書いていたら、1.252オプションの追加のテストを頼んだ人から
It worked, thx
と返事が来た
なんとか、デフォルトでこの機能がまともに動くまで、我慢しながらしのごうと思っていたのですが、この種の問題を簡単に解決する方法を準備しないと、疲労が回復できなくなりそうなので、カスタマイザーに項目を追加した。
その名は、「raindrops_disable_keyboard_focus」
そのほかにも、プラグインコンパチビリティのための、機能を追加しました。
- Meta Slider Plugin
プラグインが、テーマの前にアクティブになっていると何もしませんが、テーマをインストールしてから、非アクティブ アクティブにする といった作業を行うと、スライダーIDの入力フィールドがカスタマイザーに表示されるようになります。 スライダーのIDを入力すると、トップページには、「はいスライダー一丁上がり」という寸法
- The Events Calendar
イベントカレンダーも同じやり方で、表示できるようになります。プラグインを個別でアクティブにするのと何が違うのか?
Raindropsテーマは、自動配色機能を持っていて、明るい感じの配色や黒い配色など、指定したベースからと混色して表示するので、少なくても、数えきれないほどの配色が出来る というのが特徴です。
ところが、プラグインというのは、そんな個別のテーマのことなんか考えてくれるはずもなく、背景白、文字黒なんてスタイルが指定されていて、これが自動配色と組み合わされると、実にシュールな光景が広がる。
これが、Raindropsテーマの 使いづらさを印象付けるようなことがあるだろうなー、と考えていました。
そんなことないよ、Raindropsだって、そこそこいけるよ。といった、こうやって設定するんだよーといった道筋を示しておきたかった。というところもあり、つけてしまいました。
イベントファイルの日本語化は、プラグインの翻訳ファイルを、テーマ側でオーバーライドして、日本語化しています(languages/plugins/the-events-calendar)、
全部は日本語化していませんが、表面に出るところは、翻訳済みです。
もう一つは、WordPressでテーマを作った場合、未来の作業に向けての 何らかのつくり込っていうのが出来ないので、そのような機能を持たせてやることに、意義を感じたところもあります。
bbPressについては、プラグインのインストーラも未実装ですが、現時点では、bbPress用のテンプレートを用意したので、bbPressをインストールすると、1カラムで広々表示されますよといった段階です。
こんなわけで、最近のバージョンで、
ページナビゲーション
スライダー
イベントカレンダー
キャッシュプラグイン
各プラグインの、インストール、アクティベート、自動的な表示をすることが出来るようになりそうです。(審査が通れば、、、)
プラグインインストーラが、アクティベート完了しているのに、うまくいきませんでしたという消極的な発言をしますが、その点は、寛容に お願いします
実は、こんな実装していいのかな、いいのかなぁーと悩みながらでしたが、とりあえずやれることをやってから、戻るべきところがあれば 戻ろうと思います。
こういうのは、嫌いですか?
Raindropsテーマは、最近「フリーのプレミアムテーマ」なんて言う人が現れたりしています