>>>19件の記事があります。

私的SSL化考察

重い腰を上げて遂にこのブログもSSL化することに・・・。
と言っても、やったことはレンタルザーバーのユーザー専用ページでhttp用のリストから
https用のリストへURLを移して、あとはWordPressのプラグインの中に自動的にSSL化してくれるものがあるので、
それを導入しただけ。
何と簡単なことか。
しかし、注意すべき点もいくつかある。
例えば、画像を表示するために外部のURLを貼っているとしよう。
それがhttpsに対応していれば何の問題もないのだが、
対応していない場合はデットリンクとなり
ブラウザがロードを繰り返すことになる。
最終的にはロードを諦めるようだが、javascriptのロードがその後となるようなブラウザだと問題は致命的となる。
モバイル用のサイトでメニューを表示させるためにjavascriptを使っている場合は、
メニューがなかなか表示されないことになってページ移動が儘ならない。
画像だけではなく、cgiやhtmlのページを表示する場合にも注意深くURLを変更する必要がある。
つまり、ただ単にhttpをhttpsに変更すれば良いっていうことではない場合もある。
まあ、SSL化の作業が終わったら、すべてのページでちゃんと鍵マークが付くか確認しよう。

2018/04/18 加筆
天気予報、ニュースなど借り物のパーツはデッドリンクを含む画像やフラッシュが使われていることが多く、
SSL化したサイトには向かないようだ。よって、このブログのウィジェットからも外すことにした。

前の記事の続き

今回採用させてもらったテーマは”Mobile Friendly”というもので、
最初からスライドバーを出現させるスクリプトが備わっている。
しかも片方からだけではなく、左右両方から出てくるやつがだ。
しかし、運用の仕方によっては長所ばかりの機能が付いている訳ではない。
例えば、スライドバーを開いて、それを閉じるにはどこをクリックまたはタップしても
OKのような作りになっている。
これは一見便利なようだが、このブログのように階層があるメニューの場合はNGである。
理由は、ポップアップのメニューが開くと同時にサイドバーは閉じてしまうからだ。
逆に階層構造ではないメニューには最適かもしれない。
では、どのような対処をしたかというと、階層の親メニューだけクリックが無効になるように
スクリプトに少し加筆した。
あと、最初から入っている検索フォームは使い物にならないようだ。
自分でsearchform.phpを用意すれば問題なしかと思いきや、そうは問屋が卸さない。
ここでも前述のクリック問題が発生する。
アコーディオンメニューは安易にプラグインを使うのではなく、
十行足らずで間に合うfunctionをこれまた加筆すれば良いでしょう。
あとはCSSで如何に見栄え良くするかの問題です。
スライドバーの開閉にはトグルボタンを取り付けてカッコよく見せたいのですが、
このスクリプトを改造するのは我々素人にはちょっと無理でしょう。

遅ればせながら・・・

このブログもやっとレスポンシブ化に着手。
今回は両サイドから出てくるスライドバーを採用することに。
右か左から出てくるスライドバーはものすごい数のスクリプトが公開されていますが、
両方から出てくるものは多くはありません。
あったとしても機能的に首を傾げたくなるものや、
やたらとファイルのサイズが大きかったりします。
面倒だからとテーマも探しているうちに、スライドバーのスクリプトを
含んでいるものがあったので、それを採用することに。
しかし、望んではいないというか使わないであろうスクリプトもかなり含まれていましたので、
スライドバーに関するものだけ、と言ってもたった一つだけ採用させてもらうこにしました。
結局テーマのスタイルシートも従来のものを使うことにしました。
スマホやタブレットなどのデバイスへの対応は、
プラグインのマルチ・デバイス・スイッチャーを利用。
基となるテーマはレスポンシブ化が既になされているので、
あまり変更するところはなかったような気がします。
一番大変だったのは、やはりスライドバーとカスタムメニューがそのまま使える
アコーディオンメニューの導入と調整です。
どのように大変だったかは次の記事で・・・。

カスタムメニューで任意のアイテムに”current”を付ける

例えば、このブログのような運営をしている場合、メニューの「WEBLOG」というところには
index.phpにより表示される記事のページにしか”current”というクラス名は付かない。
言い換えれば、投稿やコメントの個別ページ、カテゴリー、アーカイブ、検索などのページには
“current”は付かない。
これをWEBLOGに関するところでは全部”current”が付くようにする方法は、
WordPress Codexに条件分岐のテンプレートタグとして以下のように載っています。

<?php
add_filter('nav_menu_css_class' , 'special_nav_class' , 10 , 2);
function special_nav_class($classes, $item){
     if(is_single() && $item->title == "Blog"){ //この行は状況により変更が必要
             $classes[] = "special-class";
     }
     return $classes;
}
?>

因みに”is_single()”の条件分岐だと投稿やコメントの個別ページにしか”current”は付かないようだ。
“is_singular()”だとカテゴリー、アーカイブ、検索のページまでカバーされる。
ただ、注意しないとブログのトップページに”current”が重複して付いてしまったり、
他のアイテムを表示しているときにも同時に”current”が付いてしまう。
除外するための”!is_xxx()”(”xxx”のところには”single”,”singular”,”page”などが入る)を
忘れないようにしよう。

スクロールしたときにサイドバーを追従させる

プラグインの導入なしでやろうと色々試してみましたが、なかなか首尾よくいきません。
結局プラグインのお世話になることに。
筆者の感想としては、「Standard Widget Extentions」が設定が楽なので導入しやすいかと。
理由はテーマフォルダ内のファイルを弄る必要はまったくありませんし、
3カラムにも対応しているところが実に素晴らしい。
プラグインなしの挑戦をしているときに見つけたNGなスクリプトを幾つが挙げておきます。
・スクロールしたときにサイドバーは追従するが、ページトップに戻ってもサイドバーは戻らない。
・PCではちゃんと機能するが、スマホやタブレットではおかしな動きになる。

以前からずっと気になっていた、スクロールすると真っ白けになってしまうサイドバーからはもうオサラバです。
ただ、逆に固定や個別ページでコンテンツの方がサイドバーより短い場合は・・・?

バージョン4.5にしてびっくり

なんとレイアウトが著しく乱れました。
最初、原因がわからずに少しパニックに陥りました。
ソースをよく見てみると、目的のCSSが読み込まれずに
他のCSSが読み込まれていたのです。
こうなったことの原因はfunctions.phpでCSSの一元管理を行う際に、
common.cssを指定していたことです。
どんなCSSファイルが読み込まれていたかというと、
wp-admin/cssフォルダ内のcommon.min.cssです。
筆者が採った解決策はテーマフォルダ内のcommon.cssの名前を変え、
それを読み込ませるようにする方法です。
スタイルシートを小分けにして、必要な部分だけを読み込ませる手法は
あまりお勧めできる小技とは言えないのでしょうか。

子テーマの設置

懸案だった子テーマの設置がやっと完了した。
元々このブログのテーマフォルダは「weblog」としていたので、
間違ってアップデートされるなんて考えられない。
だから、無理矢理子テーマの設置もどうかと思ってそのままになっていた。
まあ、一番良いのはfunctions.phpファイルに関してではないだろうか。
親フォルダにある従来のファイルに付け加えたい分だけの機能を書き足せば良いので分かりやすい。
もちろん、外したい機能もあるのでそれに関してもコードを書き加えれば良い。
cssとjavascriptは一元管理化すれば、不必要なファイルは読み込ませないようにできる。
これに関しては、まだ道半ばといったところかな。
それでも、お蔭様でソースが少しはすっきりしたように思う。

東京オリンピック

ちょっと気が早いけど、カウントダウンさせてみました。
プラグインは「Countdown Timer」ってのを使ってます。
もう2000日を切っているんですね。
前回の東京五輪と違って、真夏の開催なんですね。
めちゃくちゃ暑いでしょうねぇ。
日本の選手は外国の選手に比べて気候に慣れているだろうから、
日程決定もメダル獲得対策の一環なのかも。
どこかの国みたいに、勝ちたいがための姑息な手段は止めてもらいたいけどなぁ。

アクセスカウンターのカウントアップ調整

Google Analyticsによるアクセス数とあまりにも差が大きいため、同一IPからのアクセスをしばらくしてからでないと
カウントされないように調整してみることに・・・。
二重カウントをOFFにするだけでは、実際のセッションに近い数値は得られないのですね。
取りあえずカウントされない間隔を1時間に設定してみた。
結果はGoogle Analyticsによる数値と大差はなく、まあまあってところかな。
アクセスカウンターはサンプルとして付けているだけなので、数値はあまり気にしていなかったのですが、
正確でない数値を表示するものは、例えサンプルとしても好ましくありません。
使用中のスクリプトは設定次第で数通りの数値が得られるように作ってあります。
だったら累計のカウント数も改めるべきですが、今となっては正確な数字は分からないので
ここは触らないでおきます。

タイムゾーン問題

これが関わってくるのは、だいたいアクセスカウンターを設置している場合ではないだろうか。
それ以外は「設定」→「一般」で東京に設定しているのだから、意識することはない。
よくwp-settings.phpの’UTC’をいじればOKって書いている人がいるけど、
これは確かに機能するけど止めておいた方が良いと思う。
バージョンアップの度に変更しなければならないのは感心しない。
一番の対処法はカウンターのスクリプトでタイムゾーンを設定すること。
簡単に設定できれば問題ないのだが、できない人は簡単にできるものを
最初から選ぶべきでしょう。
因みにここではvcounterを利用させて頂いています。
残念ながら設定の項目にタイムゾーンに関するものはないので、
必要な一文を加えている。
余談ですが、このスクリプトにはオンラインのカウント機能はありません。
それにオンラインのカウントには言うまでもなく、タイムゾーン問題は関係ありません。