久々にwordpressというか、html/css小ネタが発生しました。

ある日、更新をしたレコードのリストを眺めていると、字間がやたらと空いている場所を発見しました。

原因はすぐに分かりました。本文中のカッコに対してspanクラスを付与しカッコ内のフォントウェイトを変更していたためです。
htmlの法則では、spanで囲まれた部分はどうやら原則として改行しないようで、CSSでtext-alignをjustifi（均等配置）としていたため、１行に入りきらなかったカッコ内の文が丸ごと次の行へと送られ、カッコ前の部分がjustifiによって均等に配置されて、無駄に大きな文字送りとなってしまったようです。これは紙の本などでも、幅の狭い文面に長い英単語が入った時などに起こりがちな現象です（そのためのハイフネーションです）。

早速「span内で改行」などと検索してみますが、どうも出てくるのは「気持ちの良いところで改行するためにspanで囲う」というような記事ばかりで、spanで囲まれていても通常通り改行させるような記事はなかなか見当たりません。
そんな中で気になったのがwbrタグです。<wbr />は改行が必要なときにはここでしてね、というある種のハイフネーションタグで、たいていは諸々のCSSと組み合わせて使うようです。
このspanとwbrは、デザインされたレイアウトを死守するためにどのように使うか、相当に議論や研究、実証が行われているようでした。
しかし…しかし、しつこいようですが私が欲しているのは、たとえspanで囲まれていたとしても通常の文章のように改行してほしいだけなのです。

まず考えたのがtext-align: leftとして左寄せとしてしまう方法です。これですとたとえカッコ内が次の行へ送られたとしても、カッコ前の文は左寄せとなりますから、だらしのない空白は生まれません。
ただ、この方法ではカッコの無い、つまりspanの出てこない文であっても全て左寄せとなってしまいますし、そもそも複数行となった場合に右側が揃わないので少なからず…いや大いに残念です。

そこで、ものは試しとspanで囲まれた文の適当なところにwbrタグ入れてみました。すると（ある意味当たり前ですが）wbrタグを入れた場所できちんと改行されました。つまり、wbrタグを使えばspan内であっても改行させることができる、というところまでは分かりました。
問題はwbrをどこに入れるかです。画面のバランスを見ながら手入力するのは、労力を考えれば馬鹿げたことですし、そもそも全ての人が同じウインドウサイズで見るわけがないのですから実用になりません。

こうなったらダメ元と、論理的に考えると何も起こりそうに無いのですが、span閉じタグの直前にwbrを入れてみることにしました。

<span>……<wbr /></span>

気持ちとしては「span内のどこかで改行あるかも、よろしく」という意思表明だったのですが、なんとその念はhtmlにも伝わったようで、ほぼ完璧に私の希望通り、つまりspanで囲まれている部分でも必要であれば改行する、という動作となりました。はて…どうしてそうなるのかは未だよく分かりませんが。確認はしていませんが<span>直後に<wbr />を入れても大丈夫そうな気がします。
もともとwbrタグは、「必要であればココで改行」ですから、カッコが終わっても改行が必要なければそのまま文は続いていきます。余程変なところへ入れなければ副作用も無さそうです。

念のためEdgeとChromeで動作確認をして、最後にwordpressファンクションの置換部分を、</span>から<wbr /></span>へと書き換えて、めでたく解決しました。おそらくですが…

当店のWebサイトはWordPressで作られおり、ショッピングカート部分はwelcartというECプラグインを使用しています。Wordpressは強力なCMSで、さまざまなプラグイン（welcartもその一つ）が用意されている他、カスタマイズも比較的容易でSEO対策も優秀なため、そのWordpress上で動き、原則無料（制作・カスタマイズの有料オプションあり）のwelcartはとてもありがたいプラグインなのです。

そのwelcartが、このたびVer. 2.7へアップデートを行ったのですが、そのアップデートがデータ構造まで変更するというメジャーなものだったため、当HPもその煽りを受けて様々不具合が発生する事態となりました。

以下備忘録として、症状と行った対策を書き記しておきます。

1. welcartデータの更新が途中で止まる
Ver. 2.7へアップデートした後、welcartデータの更新が必須となりますが、その更新作業が25％ほどで止まってしまいます。実はこの症状、Ver. 2.6の時にも起こりましたが、その時はwelcartレスキューへ連絡したところ修正されましたので、今回はバージョンアップを待ちましたが、Ver. 2.7.2になっても対応されなかったため、再びwelcartレスキューへ連絡。Ver. 2.7.3で無事データ変換が完了しました。

2. NEW ARRIVALリストが表示されなくなる
次の検索結果が表示されなくなる原因と同じなのですが、当WebpageはWelcartがカスタムフィールド（メタキー）に作っている「_itemCode」という項目を参照して、welcartのアイテムか通常の記事なのかを判断していた他、「NEW ARRIVAL」では並べかえ用のキーに使用していました。
この「_itemCode」が原因と分かるまでに少し苦労しましたが、実は随分前から「Welcart 2.7 のためのカスタマイズ修正」というドキュメントが発表されていたようです。マニュアル・ドキュメント類はきちんと読まないといけません。
NEW ARRIVALの並べかえは日付がメインで「_itemCode」は同一日時だった場合にのみ意味のある値でしたので、Wordpressのメタキー「ID」で代用することにしました。

3. レコード（welcartアイテム）の検索結果が表示されなくなる
上記同様「_itemCode」をwelcartアイテムの確認に使用していたのが原因でした。上手い具合に、すべてのwelcartアイテムに並べかえのためのメタキー文字列「Sorting」が埋め込んでありましたので、「_itemCode」の代わりに「Sorting」を参照することで解決しました。「Sorting」はWelcart内部のメタキーではなく、独自に追加したメタキーだったため問題なく使用できました。

4. 通常記事の検索結果が表示されなくなる
前述の通り当Webpageは「_itemCode」の参照によってWelcartアイテムの場合と通常記事の場合とで表示方法を変えていたのですが、検索用窓も別々に設定しており、通常記事検索とレコード（商品）検索が個別に行えるようになっていました。上記の通りレコード検索の方は復旧したのですが、通常記事検索は復旧しませんでした。
これは原因に気づくのに苦労しました。あれこれと勘でいじくってみても復旧しなかったのですが、ふと検索後のURLを見てみると、

　https://classicus.jp/category/[homeurl]?noitem=y&s=シェーンベルク

となっています。どうやら<form>内のショートコードで設定した「action=”[homeurl]“」が上手く働いていないようです。ひとしきり何が原因か考えたりソースコードを眺めたりしてみたのですが、よくわからず、さりとてステップ・バイ・ステップで原因を探るのも面倒なため、「action=”/”」としてお茶を濁してしまいました。デバッガーを使えばたちどころに判明するのかもしれませんが、使ったことがないものですから…。これは、welcartのアップデートが原因ではなかったかもしれません。

以上、ほぼ丸一日を費やしてようやく通常状態へと復旧した次第。今回はWelcartが使用していたメタキーの扱いが大幅に変更されたため、カスタマイズした部分で大きく影響を受けてしまいました。