OpenPNE 3

状況¶

この問題は主に次の 3 つの原因によるものである。

• (C1) opSkinClassicPlugin の CSS に記述されているセレクタと、実際に出力される HTML 上の id 値が一致していない（3.6.x 以降）
• (C2) 3系で新たに実装された機能（バンドルされたプラグインで実装された機能）に対応するナビ項目について、そのナビ項目を機能させるために opSkinClassicPlugin の CSS を書き換える（追記する）必要があるが、それを行なっていない（3.6.x 以降、もしかしたら 3.4.x でもあるかもしれない）
• (C3) ナビゲーション項目の id 値を決定するための op_url_to_id() 関数が URL の記述の仕方（member/search か @member_search かの違い）によって、出力される値が異なっている（ #257 時点からで、これは 3.3.0 対象なので、 3.4.x 以降）

とチケットに書いていますが、チケットタイトルが示す問題は (C1) です。この (C1) の問題は OpenPNE-3.4 系では発生しません。

問題が発生しないのは 3.4 系のデフォルトでナビゲーションに設定される URL 形式（ルーティング名形式 or module/action 形式）から生成される id 属性値が、 opSkinClassicPlugin に記述されている CSS のセレクタと一致するためです。 3.6 系では module/action 形式の URL をルーティング名に書き換えたことによって、 id 属性値とセレクタが一致しない状況であったために (C1) が生じていました。

これらについては全てチケットに書いてありますが、改めて書くと OpenPNE-3.4 系では (C2) と (C3) を改善すべきではないかという話で、それがこのバックポートチケットで扱うべき内容です。

(C2) について¶

（新たに追加されたものも含めて）バンドルプラグインに対する opSkinClassicPlugin への CSS 記述が不足しているという点についてですが、 OpenPNE-3.6 系では追加された 3 つのバンドルプラグインについて記述がありませんでした。

OpenPNE-3.4 系ではこの 3 つのプラグインはバンドルされていないので、それに対する CSS を追加する必要性はなさそうです。そして、他のバンドルプラグインについては、特に CSS の記述不足はなさそうでした（ opSkinClassicPlugin を適用時に、グローバルナビやローカルナビでクリックできるべき箇所がクリックできないという問題は見当たらない）。

OpenPNE-3.4 系で例えば opRankingPlugin をインストールした際に、 opSkinClassicPlugin を用いているとナビゲーションがクリックできないという問題は生じますが、それについてコア側で対応しておくべきだとは言い切れません。バンドルプラグイン以外のプラグインについてはコアの対応範疇外だということです。

もちろん、これをコア側で対応してしまってもよいのではないかという考えを否定するものではありませんが、対応しなければならないとは考えなくてよいという意味です。

• 3.6.0 の opSkinClassicPlugin の CSS https://github.com/openpne/OpenPNE3/commit/02ef3d6b1fa7d2bf8463fe4101b213d1010e6222#diff-3
• 3.4.18 の opSkinClassicPlugin の CSS https://github.com/openpne/OpenPNE3/blame/OpenPNE-3.4.18/plugins/opSkinClassicPlugin/web/css/main.css#LID526

(C3) について¶

ここまでで OpenPNE-3.4 系では (C1) と (C2) の問題は起こっていないことが分かりました。また、 (C2) についてバンドル外のプラグインについては考慮が不要だと判断しています。

OpenPNE-3.4 系に対して、このチケットの (C3) に対応するべきかという点ですが、 (C3) は次のような内容でした。

• (C3) ナビゲーション項目の id 値を決定するための op_url_to_id() 関数が URL の記述の仕方（member/search か @member_search かの違い）によって、出力される値が異なっている

管理画面のナビゲーション設定での URL の書き方によって、 HTML に出力されるナビ項目の li 要素の id 属性値が次のようになります。

• "@member_search" と書くと id="__member_search" となる
• "member/search" と書くと id="_member_search" となる

これはある意味、これまでの「仕様」でした。このチケットの元チケットでは「この仕様が不自然であることに起因した不具合があった」ため、ナビ項目部分の id 属性値の仕様を変更する（C3 への対応）と共に (C1), (C2) の問題を解消しました。

(C1), (C2) の問題が発生していない以上 (C3) を対応する必要性は高くありません。

(C3) に関して上記に示した op_url_to_id() の仕様が不自然に見えることは事実ですが、不自然に思うのは観点次第かもしれません。 op_url_to_id() 関数の実装時点で、このような場合に（同じ URL を指しているにも関わらず）異なる id 属性値が返されることを想定していたかどうか私には分かりません。

まとめ¶

OpenPNE-3.4 系について、このチケットで考えなければならないのは (C3) に限ります。

• (C3) の件は前述の通り不自然なように思えるので、仕様を変更してしまってもよいのではないか。
• しかし仕様を変更した場合への影響を考慮しなければならないことを考えると、 OpenPNE-3.4 系ではこれは仕様を変更しないほうがよいのではないか。

どちらかというと、後者の見解が有力ではないかと思っています。もちろん、 OpenPNE-3.4 系で仕様を変更しないとなると、仕様を変更した OpenPNE-3.6 系と状況が異なることとなり、特に (C3) についての影響を受けることにはなります。が、これは OpenPNE-3.4 以下から OpenPNE-3.6 以上にバージョンアップした際に対応すればよいことです。

仕様を変更した際の影響については http://www.openpne.jp/archives/6500/ で「グローバルナビやローカルナビの CSS を独自に書かれている方へ」という見出しから始まる節で説明しています。