WordPress Theme Raindrops 1.252 - ミショニポー

11/6 ライブになりました

DEMO

マルチサイトでデモを動かしてみたのですが、スライダーの位置がマルチサイトだと、ちょっとおかしいみたいです。

次のアップデートまで検討します。

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
- https://wordpress.org/plugins/ml-slider/

プラグインが、テーマの前にアクティブになっていると何もしませんが、テーマをインストールしてから、非アクティブ　アクティブにする　といった作業を行うと、スライダーIDの入力フィールドがカスタマイザーに表示されるようになります。　スライダーのIDを入力すると、トップページには、「はいスライダー一丁上がり」という寸法