プロジェクト

全般

プロフィール

Backport(バックポート) #2438

opSkinClassicPlugin を使うと pc_frontend のナビゲーションでクリックできない箇所がある

isao sano12年以上前に追加. 12年以上前に更新.

ステータス:
Won't fix(対応せず)
優先度:
Normal(通常)
担当者:
-
対象バージョン:
開始日:
2011-09-26
期日:
2012-01-12
進捗率:

0%


説明

概要

OpenPNE にはグローバルナビ、ローカルナビがある。これは3系と2系両方に存在するが、3系と2系では項目が異なっている。

opSkinClassicPlugin は、3系で2系のデザインを模倣するスキンだが、これを用いると2系のナビ項目の名称が表示されてしまい、次の問題が生じる。

  • (P1) 2系にしか存在しない(3系で実装されていない)ナビ項目が機能しない(クリックできない項目が表示されている)
  • (P2) 3系にしか存在しないナビ項目が表示できない(項目名が2系で用いている画像で表示されているため)

これとは別に、次の問題が生じている。

  • (P3) 3系に存在するナビ項目のほとんどが機能していない(クリックできない)

このチケットでは (P3) を扱う。

補足

opSkinClassicPlugin を用いなければよいという話ではあるが、2系からのコンバートを行ったSNSはデフォルトで opSkinClassicPlugin が使われる。これを加味するとこの問題がどれほど重大であるかが考えやすいかもしれない。

バージョン

  • OpenPNE-3.6.x で生じている(ログアウトなど基本機能がクリックできない)
    • stable-3.6.x ブランチ
    • master ブランチ

OpenPNE-3.4.x では、ログアウトなどの基本機能はクリックできる。しかし 3.4.x でも、実装されているがクリックできないナビ項目が存在するかもしれない(後述の原因を参照)。

原因

この問題は主に次の 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 以降)

修正方針

原因の (C2) については CSS に追記する対応をする。

(C1) について、 3.6.x 以降で生じているが 3.4.x では生じていない点については #1004 の修正(3.5.2 対象)がきっかけであり、この問題の根本的な原因は #2573da8aa22 で定義されている op_url_to_id() の定義 か使い方 ( glovalNav / localNav ) が誤っていることである。

(C1) については次のいずれかの方針で修正する。

  • (S1): HTML 側の出力は修正せずに CSS 側のセレクタを修正する
  • (S2): HTML 側の出力(恐らく op_url_to_id() 関数の定義)を修正する
    • この場合、既に CSS ( 3.4.x および 3.6.x 以降)に _foo と __bar のように (C3) の問題を受けた記述が存在するため、 CSS も併せて修正する必要がある

関連するチケット

関連している OpenPNE 3 - Bug(バグ) #2418: opSkinClassicPlugin を使うと pc_frontend のナビゲーションでクリックできない箇所がある Fixed(完了) 2011-09-22

履歴

#1 Fumie Toyooka12年以上前に更新

  • 説明 を更新 (diff)

#2 Minoru Takai12年以上前に更新

  • 題名2.14.x → 3.6.x へバージョンアップ後のグローバルナビでクリックできない箇所がある から opSkinClassicPlugin を使うと pc_frontend のナビゲーションでクリックできない箇所がある に変更
  • 説明 を更新 (diff)
  • 対象バージョンOpenPNE 3.6.0 から OpenPNE 3.4.17 に変更

#3 Kousuke Ebihara12年以上前に更新

  • 対象バージョンOpenPNE 3.4.17 から OpenPNE 3.4.x に変更

#4 Kousuke Ebihara12年以上前に更新

  • 対象バージョンOpenPNE 3.4.x から OpenPNE 3.4.19 に変更

#5 Kousuke Ebihara12年以上前に更新

  • 期日2012-01-12 にセット

#6 Minoru Takai12年以上前に更新

状況

この問題は主に次の 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 を用いているとナビゲーションがクリックできないという問題は生じますが、それについてコア側で対応しておくべきだとは言い切れません。バンドルプラグイン以外のプラグインについてはコアの対応範疇外だということです。

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

(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 を独自に書かれている方へ」という見出しから始まる節で説明しています。

#7 Minoru Takai12年以上前に更新

  • ステータスNew(新規) から Won't fix(対応せず) に変更

note-6 に見解を示しましたが、私自身は OpenPNE-3.4 系で (C3) に対する仕様変更を敢えて行うことはメリットよりもデメリットの方が大きいと考えています。影響を周知しなければならないことや、SNS管理者が仕様変更に対応しなければならないことについて配慮しなければなりません。

ここまでの考察を以て、本チケットは OpenPNE-3.4 系では「対応せず」としてよいのではないかと判断します。

異論があればコメントなりチケットの再オープンを行なってください。

他の形式にエクスポート: Atom PDF