マクロでよく使う最終列・最終行を取得する~空白セル・はみ出しセル対策版~

VBA(エクセルのマクロ)で作業を自動化する時、多くの場合最終行と最終列を知る必要があるよね

最初に最終行・列を取得しない場合なら、使用セルをカウントアップして空白セルまでループしていく等

通常のリストやテーブルであれば、1行目が項目で1列目はシリアル番号であったり日付であったりで、更新していく度に1行目、1列目はカウントアップして埋まり(いわゆるインクリメント)、空白セルができたりしないよね

でも、マクロの特性を知らない使用者が、なんらかの理由で1行目、1列目セルの途中の値を消去してしまうという事が起こり得る

マクロ作成者であれば、1行目、1列目セルの削除が必要となった場合でも、「削除済み」と入力する等の対策をとるが、使用者がそこまで考えてくれるとは限らない

そんな時によく用いるのが、エクセルの最終行からカウントダウンして降りて行って使用セルまで辿り着く方法

じゃあこんな場合どうだろう

1行目、1列目の最終セル範囲外に値が入力されている場合(画像のD6とF2セル)

ひねくれ過ぎかもしれないが、あり得なくもない

これで最終セルから降りてくる(カウントダウン)マクロを実行してみる
※Sub test ()を実行

6行目、6列目の値は当然見つけられないので5行5列となってしまいます

こんな時は SpecialCells メソッド(オブジェクトを返すメソッド)で引数に xlLastCell (使用している最後のセル)を指定してやればよい

ついでに行は番号だけだとさみしいので対応するアルファベットに変換した値も表示するようにした

実行してみる
※Sub test ()を実行

これで目的が果たせた

どうかな。osamushi

WordPressのブログサイトをSSL化する②

いろいろあったけど、3回目でやっとSSL化が上手くいった

経緯は前記事に書いたので興味があればどうぞ

関連記事:WordPressのブログサイトをSSL化する①

さて、今回最終的に実施した方法を画像交えながら書いていきます

前記事と重複もあるけど悪しからず

まずは環境から

リモートサーバーはCPIのレンサバ

対象サイトはWordPress 4.7.3 Theme Exrayバージョン: 1.5.2(子テーマ)

手元はWindows7 SP1

ブラウザ:Google Chrome バージョン 56.0.2924.87 (64-bit)

FTPソフト:FFFTP Ver.1.99a

テキストエディタは今回、試用で使う EmEditor

SSLサーバーについては知識もなく面倒が嫌なので、CPIが提供しているCPI SSLサーバーを契約して設定済み

手順は前記事では下記のリスト通りだけど、DB書き換えるのでWP管理画面でのURL変更は不要です

大きく分けて6項目

WPフォルダのバックアップはSSHでもFTPでも、各レンサバの管理画面でもできるね

CPIの場合は毎朝3:00頃に自動バックアップされていて、簡単に戻せるので(時間はかかるけどね)今回はDBと.htaccess以外はバックアップしません

①DBバックアップ
②.htaccessバックアップ
③DB内のURL置換
④WP管理画面のURL変更
④301リダイレクト処理(.htaccess)
⑤Googleアナリティクス変更
⑥Googleサーチコンソール変更(httpの既存サイトを削除してhttpsを新規作成)

それでは説明しよう

まず、以降に登場する3つのDBを識別する為に定義する
・A_DB WPとつながっているアクティブなDB
・B_DB 書き換え前のA_DBをバックアップしたDB
・C_DB http://⇒https://書き換えDB


①DBをバックアップする

まずバックアップするにあたり、現状がエラーなく動いているかを確認する

確認用ブラウザを用意しておいて、キャッシュやクッキー、その他の履歴なども全部消してからトップページやアクセスの特に高いページなどを確認

アナリティクスやアドセンスの管理画面などで、対象サイトがアクティブに認識されているか確認

WPなどで更新のアラートが上がっていてもこの時点で上げてしまって不具合が起きると別問題が発生してしまうので、プラグイン含めすべての更新は無視

DBのバックアップは2つ作成する(ローカルのは作業用)

1)リモートサーバー上(B_DB)
2)ローカル作業用(C_DB)

CPIのレンサバではDBサーバーで直接DBを追加する事ができないので、サーバー管理画面から空のDBを2つ作成し(B_DB、C_DB用)、phpMyAdminでアクティブDBをコピーするというやりかたでいきます
(WEBサーバー同様、CPIのDBバックアップ機能によりバックアップされていますが、今回は使いません)

CPIサーバー管理画面 この時点ではBとCは空(実際のCPIサーバーではA_DBというDB名は付けられない)

空のDBを作ったら phpMyAdmin でアクティブDB(A_DB)の管理画面で「操作」タブを選択して、コピーを実施

バックアップ用空DB(B_DB)の名前を入力して、ラジオボタンとチェックボックスでオプションを選択する
・構造とデータ
・コピーの前に CREATE DATABASE する

phpMyAdmin 画面 A_DBをB_DBにコピー

 

コピーが終わったらリモートのバックアップは完了

次にローカル作業用のバックアップをとる為、エクスポートタブを選択

DBエクスポート

対象のDB(A_DB)を選択して、特に設定は気にせずデフォルトのままエクスポート

ローカルSQLファイル

このSQLファイルを書き換える訳だが見ての通り74MB近くもあり、普通のテキストエディタでは開けない(開けても作業における信頼性は低い)ので、今回は248GBまで扱えるというEmEditorを試用で使用wwする

それは後程

関連記事:WordPressのブログサイトをSSL化する①


②.htaccess のバックアップ

WPの最上位階層にある.htaccessファイルを念のためバックアップしておく

パーマリンクがデフォルトのままだったりするとこのファイルが存在しない場合もある、その場合は不要

これはFTPソフトでも、ファイル管理マネージャーなどが使える場合はそれでも簡単にできるね

確認が必要になるかもしれないので、ローカルに落としておこう

ちなみに、ファイル管理マネージャーとか一部のFTPソフトではこのファイルが見えない場合があるので要注意

FFFTPなら間違いない


③ダウンロード(エクスポート)したSQLファイルのURL置換

先ほど①でダウンロードしたSQLファイルを書き換える

テキストエディタの置換機能でファイル内の「http://example.com」という文字列をすべて「https://example.com」に置き換えるという方法

http://だけ指定すると本文内の無関係なURLまで書き換わってしまうのでドメインまで指定する必要があるで注意

EmEditor で置換

流石 EmEditor 152662個の置換が一瞬で終わった

これをアップロードして書き換えるのだが、いきなりアクティブなDBを書き換えるのではなくて、①で作成した空のDB(C_DB)に一旦上げて、リモート上で書き換えを行う

ローカルからいきなり本チャンを書き換えてしまうと、もし万一通信障害などで上手くアップロードできなかった時にサイトに不具合が発生してしまう

リモート上で行えば、同サーバー内で書き換えができるので、リスクは半減する

まずは、phpMyAdminで空のC_DBを選択して、先ほどのローカルにあるSQLファイルをインポートする

インポートは特にオプションは選択せず、デフォルトで実施した

置換済みSQLファイルインポート

次に今インポートしたDB(C_DB)をアクティブDB(A_DB)に対してリストアする

既にデータが存在しているDBに対しては、上書きではなくて、テーブル単位で消してから書くという事をしないとエラーになる

phpMyAdminで上記でインポートしたDB(C_DB)を選択して、「操作」タブを選択して、コピーを実施

アクティブDB(A_DB)の名前を入力して、ラジオボタンとチェックボックスでオプションを選択する

・構造とデータ
・DROP TABLE/DROP VIEW(挿入前にテーブルを削除)

 

C_DB を A_DB にコピー

これが正常終了すれば主要の作業は完了

ここで一旦サイトを確認する

不具合があれば、すぐに①でリモートにバックアップしたB_DBをA_DBにコピーして元に戻す

手順は書き換えと同等

B_DBを選択して「操作」タブを選び、上記同様にA_DBを指定してオプションも同じ設定でコピーを実施する(不具合が無ければ元に戻っちゃうからやらないでね)


④301リダイレクト処理(.htaccess)

サイトに問題が無ければ、301リダイレクトを仕掛ける

301リダイレクトとは恒久的な転送で、一時的な転送302と区別されている

今回のような場合は、障害がない限りhttpに戻す事はないので301リダイレクトが正しい処置となる

.htaccessの先頭に下記の記述を追記するのだが、対象サイトの場合キャッシュプラグイン(WP Fastest Cache Premium)が独自の記述をしている為、干渉してしまう懸念があった

対策になるかは不明だけど、一旦プラグインを停止して独自の記述が削除されていることを確認してから下記を追記して、動作確認後にプラグインを有効化した

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://example.com/$1 [R=301,L]
</IfModule>

結果、SSL通信にてサイトが正しく表示されている事を確認し、http://でアクセスしてもhttps://にリダイレクトされる事、キャッシュプラグインも正常に動作している事を確認した

ちなみに、この301リダイレクトのコードだが、この方法がすべてのサイトに有効か不明です

サーバーの仕様によっては無限ループになるなんて話も小耳にはさんだので、熟知していない人はググっていくつかのパターンを用意しておいた方が良いかもしれないね

さぁあともう少し


⑤Googleアナリティクス変更

Google Analytics の管理画面を開いて左のナビゲーションバー下の歯車アイコンをクリックして
プロパティ ⇒ プロパティ設定 ⇒ デフォルトのURL
をhttp://からhttps://に変更する


⑥Googleサーチコンソール変更(httpの既存サイトを削除してhttpsを新規作成)

GoogleサーチコンソールでURLを変更するというのは出来ないので、対象サイトを一旦削除して、htpps://で再度登録する

当然URLが変わるので、データはリセットされて「データはありません」状態から始まるけどそれはしょうがないね


全ての項目を熟知してる訳ではないので、不足や誤りがあるかもしれません

もし、この記事を参考にする場合は自己責任でおねしゃす。osamushi

関連記事:WordPressのブログサイトをSSL化する①

WordPressのブログサイトをSSL化する①

2017/03/15 追記

3回目のチャレンジでようやく成功

2回目の時は1回目に確認し忘れたキャッシュプラグイン(WP Fastest Cache Premium)が吐き出す .htaccess の確認も忘れずに実施したが、そこに根本的な原因はなかった(と思う)

結局1,2回目の失敗原因は不明

多い時だとリアルタイムで500くらい同時アクセスのあるサイトなので、追究するのがリスキーでできなかった

3回目はテーマをダウンロードし直して、子テーマ作ってきれいにしてから下記手順でやりなおしたら上手くいきました(3回目は少しレベルアップしてちょっとだけやり方変えたんで別記事で書きます)

関連記事:https://ctrl–z.com/2017/03/ssl-https-2/

Exray というテーマを借りてたんだけどいじくり倒してたんで、何かクリティカルな構文ミスがあったんだと思う←なおせないならいじるなという話orz


結果
失敗しました(1回目)
ん~というかURLを http ⇒ https はコンプリートしたんだけど、ものぉすごぉく遅くなっちゃった
キャッシュプラグイン(WP Fastest Cache Premium)を入れる前と同じかそれ以下になってるんでキャッシュが効いてない感じだけど原因不明
中身熟知しないで使ってるとこういう時ダメなんだよなぁ
この手の不具合を追究してるとキリがなくてWPやめたくなっちゃう

やる気満々で下の記事を書いていたのだがまことに残念な結果に。。

まぁなにかの参考になるかもしれないから興味ある方はどうぞ

/***** この記事書き終わって最後にふと思ったんだけど.htaccessのキャッシュプラグインが記述する部分が上手く書き換わってなかったんじゃないかと気づく。そこだけでも確認してみれば良かったorz *****/

以下、本文


今回ウチで一番稼いでくれているWordPressサイトをSSL化(https)する事にした

先々週あたりGoogle大先生がアルゴリズムのそこそこ大きい変更をしたという噂を聞いたがその影響なのか、先週からPVが半分近くになって泣いている

非SSL通信である事が関係してるかわからないけど、世間ではSSLデフォの波が押し寄せてきているので、やらない訳にはいかんくなったという状況

記事数は400弱だけど1記事が結構なボリュームで、DBエクスポートしてみたらテキストファイルで74MBもあるんで正直、あんまり触りたくなくて。。

そんなんでダラダラとSSL化を引き延ばしてしまったのだが今回そのような事情で重い腰を上げたという訳

以前から考えてはいたので、手順はそれほど迷わず以下の通りに確定

①DBバックアップ
②.htaccessバックアップ
③DB内のURL置換
④WP管理画面のURL変更
⑤301リダイレクト処理(.htaccess)
⑥Googleアナリティクス変更
⑦Googleサーチコンソール変更(httpの既存サイトを削除してhttpsを新規作成)

環境はCPIのレンタルサーバーで当然相手はLinuxでこちらはWindows7

LinuxのPCもあることはあるのだが、なにせ使い慣れていないんでトラブった時にあたふたするのが目に見えてる
親和性はベストではないかもしれないが、やはりこういう時こそ手慣れたPCでやるのが良いんだろうなとおじさん考えました

今回、一番悩んだのがDB内のURLをどうやって置換するか

DBダンプ(エクスポート)してローカルに落としてエディタで置換するのが一番早いかと思ったけど、Linux ⇒ Windows ⇒ Linux というのがどうも気になって、できれば避けたい

SSHでリモートサーバーにログインして、MySQLのコマンドで直接やるのが一番良いと思ったのだが、CPIってSSH経由で操作できる範囲が狭いみたいで、コマンドがきかなかった(熟知していないのでやり方悪いのかもだけど他のサーバーで試したらできたので、恐らく制約かと。。間違っていたらごめんなさい※Poderosa使用)

phpMyAdminからクエリで置換していくという手も考えたけど、DB全体を文字列で一括置換というSQLコマンドは存在しないらしく(たぶん)、対象のテーブルをピックアップして全部のカラムに対して置換をかけるというなんとも手間のかかる作業なのでそれも断念

もちろんWordPressのプラグインを使っちゃうというのもあるんだけど、中身がどうなってるかわからないからなぁと。
恐らくは↑の手作業をグリグリっとスクリプトがやってくれるだけだとは思うがトラブった時に何が悪いのかわからないのは嫌なので、これもやっぱり不採用

こうなるとやはり最初にあげたDBエクスポートしてローカルでテキストエディタで置換というのが最もシンプルなのかなぁと

問題は74MBもあるファイルを何で扱うか

手元にあるエディタでは開くだけでも数分かかり、置換が正しく行われるか怪しいので248GBまで扱えるという最強エディタEmEditorを使ってみることにした

永久ライセンスが18000円とテキストエディタとしてはかなり高額だが、30日間の試用期間があるので、とりあえず今回は試用で使ってみた

まぁ~チョッパヤだね

74MBのファイルが一瞬で開いた。さすが

.htaccessの変更は以下の構文を”# BEGIN WordPress”の前に挿入(実際はWP Fastest Cache Premiumのヤツが長々と# BEGIN WordPressの前に挿入されているので、その更に前に挿入予定)

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://example.com/$1 [R=301,L]
</IfModule>
これも環境によって無限ループになる事があるようなので、要注意ですよ
※結果、これで現在は上手くいってる 2017/03/15 追記

関連記事:https://ctrl–z.com/2017/03/ssl-https-2/

手順をさらってみる

①CPIの管理画面からバックアップ用のDB作成

下の*****_dbが既存DB、*****_bup0219がバックアップ用

②phpMyAdminで既存DBの内容をバックアップ用DBにコピー

既存DBの管理画面から操作タブを選択してコピー先にバックアップ用DBを指定
バックアップ完成(+で開くと既存と全く同じ構成になってる)

③既存DBをエクスポートしてローカルに落とす

74MB弱。デカすぎw

④テキストエディタで http:// ⇒ https:// に一括置換する

他のURLまで書き換わらない様に http://example.com の様にドメインまで指定する

関連記事:https://ctrl–z.com/2017/03/ssl-https-2/


あとは書き換えたSQLファイルで既存DBをリストアすればOK

MySQLってインポートで上書きにはならないから、一度テーブルをすべて削除して、インポートする

そして、アクセスの少ない明け方4時頃を狙ってDBリストアした

WPの管理画面の設定⇒
WordPress アドレス (URL)
サイトアドレス (URL)
については、確認したらhttpsに変わっていた

そりゃそうだ、DB内のURL全部書き換えたんだから、ここも変わってなきゃおかしい

結果

URLの書き換えは上手くいった

しかし、何故かキャッシュプラグインが効いてないようで、ページ開くのに10秒とかそれ以上かかってしまう

全てのキャッシュを削除はやってみたが改善せず

CDNも変えてみたりしたけど変わらず

正直なにが悪いか全く思いつかなかったので、とりあえず戻すしかない

再度、既存DBのテーブルをすべて削除して、バックアップ用DBの管理画面に入り、操作タブからコピー先に既存DB指定をして実行

戻しは上手くいった

もちろんページの表示スピードも従来通りに戻っている

そんな訳で現状、SSL化は仕切り直しと相成りました。osamushi

関連記事:https://ctrl–z.com/2017/03/ssl-https-2/

PageSpeed Insightsでユーザーエクスペリエンス テストをしてみた

Googleのユーザー エクスペリエンス(UX)テストをしてみた
URL: https://developers.google.com/speed/pagespeed/insights/

この記事を書いている時点では、WordPress 4.7.2 Twenty Seventeen をカスタマイズ無しでキャッシュ以外のプラグインも無しのほぼ吊るしで使っているが、モバイル67点、PC75点だった

決してよい数字ではないよね

注意レベル?

当然のことながら、検索順位にも影響してくるからもう少し点数上げたいなということで、キャッシュのプラグインを強化した

WP Fastest Cache が使いやすいので元々導入しているが、有料版の WP Fastest Cache Premium にアップグレードした
※キャッシュ系プラグインは注意⇒ 英語(URL)の表示を折り返したい※キャッシュに注意!

他のサイトで使っていて実力は認識していたので、5000円弱のコストも特に高いとは思っていないので、すんなり導入

結果

ブラウザキャッシュの有効化とかCSS見直しとか、100点目指すのもそれほど難しくはなさそうなんだけど、WPやテーマのアップデートしたりすると、恐らくイタチゴッコみたいになるんで、このくらいで良いかと

このサイトはXサーバーのwpxクラウドというヤツでスピードも定評あるサーバーなので、レスポンスに関しては問題ないと思う(実際はサーバー側もWPに最適化されていてサーバー内部キャッシュも使われている)

キャッシュ系のプラグインで効果が大きいのは、PHPで一時的に作成したページをHTMLで吐き出して、リクエストに対しては静的ページを返す事でスピードも速くなるしCPUの負荷も減らしてくれる事だろうね

っと今回自力ではなくプラグインのお世話になっちゃったんで、技術的な話はないけど、正直、自力で何日もかけてやるより5000円払ったほうが早いよというつまらない話でした

おあとがよろしいようで。osamushi

iPhoneのバッテリーが急激に減る問題を解決した話し

iPhoneのバッテリーについていろいろ云われてるようだけど、手元の環境はiPhone6 でそろそろ使い始めて1年半くらいかな
ご多分に漏れず、最近バッテリーの減り早くなったなぁなどと気にしていて、音楽とか聴いてると30分程度で80%台とか・・

iPhone6s ではロットによってバッテリーに問題があったようで、キャリア経由でも交換してくれるらしい(ソフトバンクショップの店員さん談。自分は該当していないので詳細不明。キャリアかAppleに問い合わせてみてね)

自分の話に戻ると、先日フル充電の状態で朝家をでて、30分後に目的地に到着してみたらなんと45%だった

みるみるうちにソレが30%くらいになっちゃって、異常事態ということで一旦シャットダウンしてみた

ハイご臨終

っという訳でもないけど、バッテリー切れで起動しない

電源入れても赤のバッテリーマークがでて、既にemptyの状態になってた

もうダメかぁ

と思ったが、この症状を見てて気づいたのが、バッテリーそのものが問題なら、こんな急激に無くなるのはおかしいなと

もしや、バッテリー残量を検知するセンサーとか残量の数値を管理してるデータベースまわりに問題があるんじゃぁないかとオレ考えたね
※プリンターのインクカートリッジにも同じような現象が起こる話はまた別の機会にしたい

それで試してみました強制再起動

ライトニングケーブルで電源繋げてとりあえず起動

立ち上がったらホームボタンと電源ボタンを同時に押したまま、Appleマークが出るまで長押しする

リンゴが出たらすぐに離す

押し続けてると再起動しないで、そのままシャットダウンしちゃうので注意

はっはっは

無事解決

強制再起動すると微妙に残ってるメモリ的なヤツがクリアされるような感じ(かなりいい加減な表現だがニュアンスでよろしく)

全ての症状に効果があるわけじゃないけど、修理に出すしかないような事態の時には試してみる価値はある

そうなる前にバックアップは忘れずに


ダメならリセットかけてiOS入れなおしというのも考えてたけど、起因がソフトでなくバッテリーそのものならあきらめて修理か新調するしかないというところまでは切り分けしてた

今回は助かったけど、何れにせよバッテリーがかなり消耗してるのは確かだね

こんな薄っぺらいバッテリーだもん、やっぱり2年くらいが限界なのかな

でもおかげさまでとりあえずは使えるようになったんで、後半年残ってる交換時期まではなんとか使いたい

osamushi

すべてのプログラム の アクセサリ が Accessories になっちゃった【Windows 英語表記】

先日の記事 Windows Update 更新プログラムの確認 が終わらないを解決する の最後に書いたのだが、アクセサリやその中のメモ帳、電卓その他が英語表記になってしまった

スタートボタン ⇒ すべてのプログラム ⇒ アクセサリ
通常、日本語版のWindowsならこのようなカタカナ表記のはずが
「メモ帳」⇒「Notepad」
「アクセサリ」⇒「Accessories」
「電卓」⇒「Calculator」
こんな感じで英語表記になっていた

どのタイミングでなったか不明

Windows7 のOSをリストアしたので、最初からそうなっていたのかもしれないが今となっては追及不可

環境:Windows7 Home Premium SP1 64bit

くーちゃん@りんこさんのサイト http://ameblo.jp/wajiro/entry-11352864253.html を参考にさせてもらった

要約すると、2つのシステムフォルダにダミーのショートカットを作る
たったそれだけ

手順は以下

①デフォルトで見えないようになっているフォルダを見える設定に変更

まずは、現在Windowsにログインしているアカウントに管理者権限が与えられている事を確認する(標準ユーザーでできない事は確認してないけどシステムファイル・フォルダをいじるので管理者じゃないとダメかと。。アカウントが一つしかない場合は問題ないはず。)

エクスプローラの左上「整理」メニューから「フォルダーと検索のオプション」を選択

フォルダーオプションの「表示」タブを選択して

・1つ目
上から5行目くらいにある「ファイルとフォルダの表示」の「隠しファイル、隠しフォルダー、及び隠しドライブを表示する」のラジオボタンを選択する

一番下までスクロールする

・2つ目
「保護されているオペレーティングシステムファイルを表示しない(推奨)」のチェックを外す

準備OK
上記2つ目の変更はこの作業が完了したら必ず戻す事
Desktop.ini を誤って削除したりすると面倒な事になる

②2つのシステムフォルダにダミーのショートカットを作成する

以下2つのシステムフォルダーにショートカットを作る

エクスプローラを開いて、左のナビゲーションカラムにあるデスクトップ(ダウンロードでもOK)にカーソルを合わせて右クリックメニューから
送る ⇒ デスクトップ(ショートカットを作成)
でデスクトップにショートカットを作る
※下記のパスについて、webでの見え方はバックスラッシュ\ですがWindows上ではエンになります(半角の¥。バックスラッシュになってしまうのでここでは表示できない)

  • C:\Users\自分のログインユーザ名\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Accessories
  • C:\ProgramData\Microsoft\Windows\Start Menu\Programs\Accessories

この時、ちょっとしたコツがあるので注意

ショートカットは何でも良いわけじゃないみたい

やってみた限りでは、「ダウンロード」と「デスクトップ」は有効だった

でも「マイドキュメント」はダメだったのでWindowsのデフォルトフォルダなら良いという訳でもないみたい

各々、Desktop.ini を開いて確認してみる

最下行にデスクトップのショートカットリンクが追加されている


これで確認したところ英語表記がカタカナ表記になっていた

めでたしめでたし

最後に①で変更したフォルダーオプションを必ず元に戻してね

今回、気づいたきっかけはメモ帳を開こうとして「プログラムとファイルの検索」で検索してもヒットしなかった事

無くなった訳ではなくて、表記が変わってしまったからヒットしなかったんだね

こういうこともあるんで、検索でヒットしないからと言ってそのファイルやプログラムが存在しないとも限らないという教訓 osamushi

Windows Update 更新プログラムの確認 が終わらないを解決する

PCの動きが悪くなってきたので Windows7 をリカバリした

インストールは正常に完了したが、Windows Update が「更新プログラムの確認」状態から抜けられなくなった

Windows7がリリースされてから、現在までのすべての更新をインストールしようとしているのだから当然時間がかかると思い、そのまま一晩寝かせたがダウンロードどころか「更新プログラムの確認」すら終わっていなかった

ほっとけば何れアップデートは完了するとも考えられるが、SP1に上げないと使えない機能やソフトがあるので早急にアップデートする必要があったのだ

実際、今の状態ではアップデートの確認作業をしてくれてるのかどうかも怪しく、正しい動きとは思えなかったので、ググってみると、たくさんでてくるでてくる

中でも一番シンプルかつ明快に答えてくれているサイトを見つけた

解決!7とVista更新プログラムの確認が終わらない対策まとめ | パソコンりかばり堂本舗
URL: https://www.ikt-s.com/howto-check-for-update-rollup/
管理人 ikuta naoki さん ありがとうございます!

KB3020369 Rollup事前必須パッケージ
KB3125574 Rollup第一弾
KB3172605 Rollup第三弾

3つのKBをインストールするのだが、1つ目はサービススタック更新、2,3のKBはロールアップという更新プログラムをまとめたもので何れもブラウザ経由でダウンロードして一括インストールする

これで多くの更新プログラムを Windows Update を経由せず直接ダウンロードしてしまうので、対策後は最近の更新プログラムを Windows Update で地道にアップデートしていけばよい

ikuta naoki さんのサイトを参考にちょい足しして実施した手順を紹介します


手順

準備:まずは現在動いている Windows Update の「更新プログラムの確認」を止める

Ctrl + Alt + Delete キーを同時に押してセキュリティダイアログを表示させて、タスクマネージャーを選択する

サービスタブからwuauserv(Windows Update)を選択して「サービス」ボタンをクリック

Windows Update を選択して「サービスを停止」をクリック

Windows Update を停止したら準備完了

下記へ進む


①KB3020369

https://support.microsoft.com/ja-jp/kb/3020369
「方法 2: Microsoft ダウンロード センター」という表記の下にあるリンクから自分の環境にあったものを選んでダウンロードして、インストールする

自分のPC環境の確認方法は下記の通り

スタートボタン⇒コンピューターを右クリック⇒プロパティ

32bit ⇒ サポートされているすべての x86 ベース バージョンの Windows 7
64bit ⇒ サポートされているすべての x64 ベース バージョンの Windows 7

対象の「パッケージのダウンロード」から更新ファイルをダウンロードしてインストールする

インストールしたら一旦再起動する

②KB3125574

https://support.microsoft.com/ja-jp/kb/3125574
ページ中ほどの「Microsoft Update カタログ」リンク先へ飛ぶ
(http://www.catalog.update.microsoft.com/Search.aspx?q=KB3125574)


Microsoft®Update カタログから自分PCに該当する更新プログラムを選択してダウンロードしてインストールする

ここでもインストール後、再起動

③KB3172605

https://support.microsoft.com/ja-jp/kb/3172605
「方法 2: Microsoft ダウンロード センター」という表記の下にあるリンクから自分の環境にあったものを選んでダウンロードして、インストールする

インストール後、再起動

※実際のところ、上記の操作中にインストールが先に進まない状況があったが、キャンセル ⇒ 再起動でやり直したらうまくいった
なぜだか各KBとも、1回目はコケたけどリトライでイケました


おかげさまで Windows Update も正常に動くようになったが、別の問題発生

「すべてのプログラム」の表示が一部英語になってしまった

Windows Update の一連の作業が原因かどうか不明で、もしかしたらリカバリ後の初期起動時からなっていたのかもしれない

気づいたきっかけは「メモ帳」を使おうとしたら無かったこと

スタートボタン ⇒ プログラムとファイルの検索 ⇒ 「メモ帳」 ⇒ 検索結果なし

えっ??

実際はメモ帳が無いわけじゃなくて英語表記になってしまっていたので検索に引っかからなかったのだ

「メモ帳」⇒「Notepad」
「アクセサリ」⇒「Accessories」
「電卓」⇒「Calculator」

こんな調子

コイツの解決方法は後日、別記事にします

英語(URL)の表示を折り返したい※キャッシュに注意!

HTMLは、英文の場合ワードの途中では折り返さないという思想で設計されている(と思う)

長い英文の区切れないワードの場合、サイトの幅を超えてはみ出しちゃう事になる

日本人かつ昭和人なオレは馴染みがないが、英語は言葉の途中で折り返す(次行へ送る)のは非推奨なので、ブラウザもそれに則ってリフローしない設計になってるという事なんだろうね
※基本は半角スペースがワード区切り

当然、URLもアルファベット(半角・1バイト文字)の羅列なので、英文とみなされ、なにもしなければ、webページの右端で折り返さず、言葉の区切りまでハミ出す

たとえ英語圏の人たちだって、こんなのイヤだよね

現状においては、様々な幅のデバイスで閲覧されるので、コンテンツ側で丁度よく折り返るように文章を調整するなんて事をしても無意味

それでこんな対応

CSSに以下を追記
body{
word-wrap : break-word;
overflow-wrap : break-word;
}

※ word-wrap は旧タイプで overflow-wrap は未対応ブラウザがあるみたい
いずれは overflow-wrap に置き換えられるみたいだけど両方書いておくのが良いらしい

しか~し!

オレが運営しているあるサイトで、この対策が効かなかった

追記しても折り返らなかったのだ

検証サイトで全く同じ環境を作ったのにもかかわらず折り返り、対象サイトでは折り返らない

結論から言います

Word Press のプラグインで WP Fastest Cache Premium というのを導入している

wpで吐き出す動的ページをキャッシュして静的ページで渡す、CPUの負担を軽くしてくれるヤツだ

そいつはCSSもキャッシュするのだが、通常のwebページなどは、設定によって定期的にキャッシュをクリアするがCSS/JSは手動でクリアしないと、差し替えてくれない仕組みになってた

そんなんで、時間が経っても変更したCSSが書き換わらず、break-word が効いてなかったのだ

そいつをクリアして無事URLが折り返ってくれた

チャンチャン

※wpのテーマによっては、英文が折り返るようにCSSが書かれているのもある

参考:https://w3g.jp/blog/confusing_word-break_word-wrap

Forbidden You don’t have permission to access / on this server. とは

wordpressで運用している検証サイトをサーバー移行してみた

対象フォルダをzip圧縮して、データベースは phpMyAdmin から sql エクスポートして、移行先サーバーにすべてをインポートして完了(ダウンロード、アップロードはブラウザ経由)

検証用サイトなんで、22MB程のサイズで難なく完了と思いきや

開いてみると下記の通り

Forbidden
You don’t have permission to access / on this server.

クライアントからのリクエストに対して、サーバーが403エラーを返しているという事

permission(許可)が不十分

閲覧禁止とか訳される事もあるかな

ファイル・フォルダのパーミッションはもちろん変更していないので問題ないはずなのに。。

でも、一応対象フォルダのパーミッションを確認してみた

おぉ~なんと変わっちゃってるじゃないか

750じゃ開けないよね

コレって移行先サーバー(今回はさくらのレンサバ)でzipを解凍したのだが、その場合、最上位フォルダは750に設定されるようになってるのかもね(たぶん)

755に変更

はい解決

さくらのレンタルサーバーの場合ファイルマネージャから簡単にパーミッションを変更できる

対象フォルダを右クリックしてフォルダメニューを出す

プロパティを選択するとパーミッション設定画面ポップアップが出てくる

ffftpとかでも同じような操作で簡単に変更できるよね

よくみかけるのはサーバーメンテナンスで403が返ってくるケース

メンテナンス中、ユーザーからのアクセスを避ける為にサーバー側で上位フォルダの閲覧権限を狭くしてるんだろうね

Word Pressの子テーマ使用時の注意_001/Google AdSens

ワードプレスで子テーマを使っている時の注意点_001

子テーマを使う目的とは、親テーマを直接カスタマイズとか追記すると、アップデート時に上書きされて、デフォルトに戻ってしまう事を回避する為だよね

しかし Google AdSens の認証コードを貼りつける位置は、<head>タグの直後と指定されている

テーマを自作している場合なら良いけど、誰かの作ったテーマを使う場合は、必ずしも子テーマで追記したモノが期待した場所に挿入されるとは限らない

オレの場合、yhiraさん が配布してくれている Simplicity2 を使用しているサイトで、アドセンスの認証時にこの問題に直面した

<head>タグの直後でなくてもイケそうな気がするが、指定の場所以外に貼りつけて、認証は通ったとしても、その後 Google 側で変更があり不具合が起こるリスクもあるので、やはり指定されている方法で運用したい

なのでとりあえず、子テーマ(Simplicity2 child)では無く、親テーマ(Simplicity2)の header.php に Google AdSens の認証コードを直接貼りつけた

当然、親テーマのアップデート後に再度、追記をする必要がある

この程度なら自力でカスタマイズして解決できる気もするので、ヒマな時にチャレンジしてみよう

とりあえず、忘れない為に書いたとさ

Simplicity: https://wp-simplicity.com/