先日、Wordpress＆各種プラグインをバージョンアップした時、それまで表示されていた年別アーカイブが表示されず、404エラーになりました。

他のページは問題なく表示されており、パーマリンクがおかしくなったんだろうと推測。そこで、よく知られている対処法、パーマリンク設定の更新をしたものの問題解決せず困ってしまいました。

ちなみにカスタム投稿タイプはCustom Post Type UI を、パーマリンクはCustom Post Type Permalinksを使っている状態です。

で、いろいろ調べて参考になったのが下記2サイトです。

WP カスタムポスト アーカイブ のリンクが効かない！？ [Custom Post Type Permalinks]のバグ？

アップデートを行ったら月別、年別アーカイブのURLが変わってしまいました #74

要するに、

1. パーマリンク設定に[/%post_id%/]を利用している場合、年月日のアーカイブ用パーマリンクには[/date/]が挿入されることになっている。
2. Custom Post Type Permalinksのバグ？かエラーで、wp_get_archives()で出力されるリンクに[/date/]が入らなくなった。

ということのようです。あー、確かに[/%post_id%/]いっつも使ってますわー。

ちなみに、

—

[ターム] https://ドメイン/カスタム投稿タイプ名/ターム名/
[記事] https://ドメイン/カスタム投稿タイプ名/ターム名/記事ID/
[月別アーカイブ] https://ドメイン/カスタム投稿タイプ名/date/年/月/

—

といった感じのパーマリンクです。

つむぐいとさんのサイトを参考に、Custom Post Type Permalinksを削除＆再インストールも試してみたのですが、うまくいかなかったのでwp_get_archives()で出力されるものを加工することで済ませました。方法は別記事、wp_get_archives()で出力されるURLを一部変更するにまとめてあります。

カスタム投稿タイプにカスタムタクソノミーをつけ、パーマリンク設定やfunction.phpをカスタマイズし、何とか思惑通りのパーマリンクに変更……
↓↓↓
[ターム] https://ドメイン/カスタム投稿タイプ名/ターム名/
[記事] https://ドメイン/カスタム投稿タイプ名/ターム名/記事ID/
[月別アーカイブ] https://ドメイン/カスタム投稿タイプ名/date/年/月/
↑↑↑
こんな感じにした時の話です。

WordPressのバージョンも、各種プラグインのバージョンも最新で、テーマは一から作ってすっきり。そんな状態で、テンプレートにwp_get_archives()使って月別アーカイブ一覧を出力したら、なんと https://ドメイン/カスタム投稿タイプ名/年/月/ といったリンクが生成されました……orz

プラグインのコンフリクトを疑ってみたり、パーマリンクの再設定をしてみたり、思いつくことはいろいろやってみたんですが、なんとも上手くいかず。
思惑通りのパーマリンクは得られていることだし、wp_get_archives()のほうをいじってお茶を濁すことにしました。

wp_get_archives()では、引数に echo => false としてやると、値を表示じゃなくって値を取得することができます。なのでその後、str_replaceでdateを入れてやればオッケーというわけです。

例えば、infoというカスタム投稿タイプだったとしたら……

$args= array(
  'type' => 'monthly',
  'echo' => false,
  'post_type' => 'info'
);
$monthly_list = wp_get_archives($args);
$monthly_list = str_replace('/info/', '/info/date/', $monthly_list);

echo $monthly_list;

これで月別アーカイブ一覧のリンクが正常に！
ただし、今後Wordpressやプラグインのバージョンアップでwp_get_archives()が普通に使えるようになるかもしれないので、置き換え前に、if(strpos($monthly_list,’/date/’) !== false){……とかしとくといいかもですね。

毎回タイトル長いな…。
でも、私にとって大切なことなのでもう一度。

どんな現象か

1. それはAndroidではなく、iPhoneのSafariで起こる。
2. 対象は、fixedで固定してある要素で、クリックなどでイベントが発火する物である。（例えばヘッダのハンバーガーメニューとか、フッタ付近の何かのメニューとか）
3. 最下部までスクロールしてあり、下からタブバー（メニューバー？）がひょこっと出てきた・もしくは出てくる直前の状態が鬼門。
4. タブバー出現に備えて？画面領域が再計算され、クリックできるはずの領域がタブバーの高さ分だけ上部にズレてしまう不思議。
5. よって、フッター付近の固定要素ならタップすべきはその直前の亜空間となり、ヘッダーなどで最上部に固定してある場合は、タップすべき場所は画面外となる。

スマホのメニューってドロワーかトグルで大抵右上固定なんで、メニュー押せないとか普通に困ります。
ささっとcssとかソースとか見たんですが、これといった問題も見つけれなかったので、急場凌ぎでscriptとかも書いてみました。
フッターにpadding-bottomを60pxくらいあてといて、scriptでスクロール量を取って、copyright表示部分まで来たら、下部から60px分スクロールとかするように。
が、今度はタイミングによってはバウンスが起こるので、scriptが走って走って、画面がブレブレにw
バウンスをどうこうするよりも、scriptを改修するよりも、大元を突き止めたほうが幸せになれるので、がんばって原因を探ることにしました。

犯人はviewport！

私の書くcssがそんなに悪いのか！？と思って、色々いろいろ試してみました。
よく見る　transform: translate3d(0,0,0);　とか、divで囲ってうんたらかんたらとかも試しましたが駄目でした。
ただ、同じようなことしてあっても、そんな現象起きてないサイトもたくさんあるわけです。何かが決定的に違うわけです。

で、まさかと思って変更してみたviewportがビンゴでした。

ダメなviewportの書き方

<meta name="viewport" content="width=320">
<meta name="viewport" content="width=320, initial-scale=1">
<!-- どっちもダメ -->

大丈夫なviewportの書き方

<meta name="viewport" content="width=device-width, initial-scale=1">

要は、すべて端末に委ねなさい、っていうことですね。
外の人と話し合って、今後のレスポンシブのデザイン規定を変更することにしました。
まさに紆余曲折五里霧中状態でしたが、これでほっと一安心です。

ちなみに、↓が本家本元Appleのviewport指定です。

<meta name="viewport" content="width=device-width, initial-scale=1, viewport-fit=cover">

Appleと一緒なら怖くないので、今後はこれを採用ですね。
ちなみに、 viewport-fit=cover” は、iPhoneXの両端の白いバーを表示しないようにする設定です。
全世界で絶大なる不評を得たダサいあの領域が、存在を主張するわけですね。
だからいっそのこと消してしまえと。わかります。

……って、あれ？あれれれれ？？
Apple…おまえさん……。

仕事が終わってまったりしていたら、トランスビットの外の人に「これ原因突き止めといて。じゃ、出かけてくるから！」って投げられた宿題の話です。

AndroidのChromeでページを一気にスクロールさせていると、footerを表示するあたりで一セクション前の部分まで勝手にスクロールして戻ってしまうので、正常な状態に直す。

他のデバイスではなんともないので、cssかscriptだろうとあたりをつけて探っていくと、Slidebars（2系）でした。
スクロールするのみでドロワーメニューをタップしていないにもかかわらず、slidebars.jsが動いて何らかの処理をしてしまう……。
ということで、slidebars.jsを見ていくと、一番最後にありました！

//459行目（最後から2行目）をコメントアウト

//$( window ).on( 'resize', this.css.bind( this ) );

PCでウインドウ幅を狭めてスマホ版表示にした時、ドロワー表示用のボタンが出てくるようになっています。
このドロワー表示用のボタンをタップしてドロワーメニューを表示させたままウインドウ幅を広げ、PC版表示にした時、ドロワーメニュー用の領域をきれいになかったことにしてくれるのが、この一文です。
なので、この一文がないと、ドロワーメニューを表示させたままウインドウ幅を広げPC版表示にした時、ドロワーメニュー用の領域が白い帯として残ってしまいます。

そもそもトランスビットではスマホ版でしかドロワー使わないということもあるのですが、

• PCでサイト閲覧してて
• 320pxまでウインドウ幅狭めてスマホ表示にして
• ドロワー出して
• 更にそのままウインドウ幅広げてPC表示に戻したりする

そんな人はいないんじゃないか？

という性善説で、トランスビットでは459行目をコメントアウトして問題なしとなりました。
これで宿題クリアです。

Androidでスクロールすると、ウインドウ再描画してるみたいやなーって思うときがあったんですが、リサイズしてたんですね。
cssやscriptの読込順とかなんか色々関係してるんでしょうか……リサイズ……謎です。

久しぶりにIEです。
backgroundにまとめて書くと、IE10と11では背景画像もグラデもでません。
edgeなら問題ないんですけどねぇ。

  /* 何も出てこない */
    background: url("背景画像") center top no-repeat,-webkit-linear-gradient(top, #色, #色々 ),linear-gradient(to bottom,#色, #色々);

なので、面倒ですが、下のように書かないといけません。
この時、背景画像を先に記述することが大切です。

  /* 面倒でも分ける */
    background-color: #背景色;
    background-image: url("背景画像"), -webkit-linear-gradient(top,#色, #色々);
    background-image: url("背景画像"),linear-gradient(to bottom,#色, #色々);
    background-position: center top;
    background-repeat: no-repeat;

いつまで上のようなことしないといけないのかなーと気になったのでちょっと調べてみました。
引用中の表が2016年1月時点でのWindowsのIEサポート状況です。

マイナビニュース：IE10、IE9、IE8のサポート終了

2016年1月のアップデートの段階で、次のオペレーティングシステムおよびInternet Explorerがサポートされている。

オペレーティングシステム	2016年1月のアップデートでサポートされているIE
Windows Vista SP2	Internet Explorer 9
Windows Server 2008 SP2	Internet Explorer 9
Windows 7 SP1	Internet Explorer 11
Windows Server 2008 R2 SP1	Internet Explorer 11
Windows Server 2012	Internet Explorer 10
Windows 8.1	Internet Explorer 11
Windows Server 2012 R2	Internet Explorer 11
Windows 10	Internet Explorer 11
Windows Server 2016 Preview	Internet Explorer 11

Microsoftはこれまでのように1つのOSで複数のバージョンのInternet Explorerをサポートするというポリシーから、それぞれのWindowsで最新版のInternet Explorerのみをサポートするように方針を変更。サポートが終了したInternet Explorerを使い続けると、攻撃を受けるなどセキュリティ上の問題が懸念されるため、サポートが提供されている最新版へアップデートするか、またはセキュリティサポートが提供されている他のWebブラウザへ移行することが推奨される。

『それぞれのWindowsで最新版のInternet Explorerのみをサポート』っていうことですので、WindowsのIEサポート状況と、OSのサポート状況をあわせて表にしてみました。

Vistaはあと一か月足らずで延長サポート切れます。さよならVista。
サーバOSをどう考えるかによりますが、クライアントOSでの閲覧者が大半を占めるはずですので、基本的にIE11以降対応で組んだので問題なさそうですね。

それにしても、IE11は息が長そうや……！