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

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化する①