地味で地道なはてなブログ

ダイアリー「地味で地道な」から引っ越しました。

地味で地道な子宮全摘ー術後4ヶ月

さて、しばらくは何もなく、完全に安定したかと思っていたのだが、今年(2019年)に入ってから、腹部の左下、ちょうど骨盤の内側あたりで、手術創のすぐそばが、時々じわじわ痛むようになった。たまに右下(左右対称の位置で、一番大きい術創)も同じように痛む。
どうも、便秘していて圧がかかる→多分創のどこかが癒着してる→痛む、という構造になっているっぽい。
動けなかったり、薬を飲むほどの痛みではないのだが、とげが刺さったときみたいに、ちょっと気になる感じ。
まだ溶けてなかった糸があったとかだったら、これから痛くなくなる可能性もある。
病院行くほどでもないので、次の検診時にまだ続いているようなら相談する。

では早速Windows10とUbuntuのデュアルブートを解除…ってあれ?

一連の作業が面倒くさい&失敗したことがあるので怖い、というチキンな理由で、大晦日まで引っ張った、SSD換装の下準備、デュアルブート解除。
自分の記事をプリントアウトして、手順通りに進めたら、最後の

bootrec /fixboot


「アクセスが拒否されました」のメッセージが出る。
別にWindows自体には(さほど)問題がないので、立ち上げて調べてみたら、

- てかそもそも bootrec /fixbootは非推奨
windows 10 ブートセクターをコマンドプロンプトで修復 | パソブル
とある。
えーと、そうするとうちのMBRは今どの状態にあるのだろうか…立ち上げるとき普通にGRUBデュアルブートメニューが出るんだが…
「このツールを使えば簡単にMBRが再構築できるよ!」という記事があったのでやろうとしたら「有料版の機能だから買ってね!」という素敵なメッセージが出た。うんまあ、買えるお金がある人はかってもいいんじゃないかな、私は今は無理だ…。

何故デュアルブートを解除したいかというと、SSDを換装してちゃんと立ち上がる保証がないから。確か、ブートローダーには物理的な機器情報が書いてあったと思うんだよな。
とりあえずデュアルブートの解除方法をぐぐったら、うちの記事を引用している記事に行き当たるし。無限ループしている気分。

いやまあ、クローンかけてもブートローダーが大丈夫ならいいんだけど、と思ってまたぐぐったら、なんだか不吉な記事にあたるし。
https://ameblo.jp/sijukara-tama/entry-12383745756.html

そういえば、なんか変わった立ち上げ方にしてなかったっけ、とBIOSでメニューを見たら、SSDからではなくてHDDからにして、Ubuntuデュアルブートのメニューが出るようにしていたことを思い出した。そういえばそうだった。じゃあSSDの換装は、Windowsには直接の影響はないんじゃない?
ということで、Ubuntuのことはしばし忘れ、ブートをSSDから行うよう直してから、SSDの換装を行う。
SSDを120GBから240GBに換装 - 地味で地道なはてなブログ
ほぼこのまんま。EaseUSがバージョンアップしてたけど、動作は変わらず。

はまったのは、「セクタバイセクタクローン」を選んだら「編集」で領域が拡張できなくなってしばらくパニくった。これを外せば、領域は拡張できるようになる。
結構時間がかかるので、元旦だったから『年の始めはさだまさし』を観ながら待ってた。
「終了したらシャットダウン」にしておいたので、放置しても大丈夫だった。
翌日、フタ開けて換装してフタして作業完了。

さて、Ubuntuはどうなっておるのかのう…。

またSSD換装とかUbuntu削除とか色々

ついついSSDを衝動買いしてしまったので、うちのブログの記事で今んとこトップのこれ
Windows10(MBR)とUbuntuのデュアルブートでUbuntuを削除 - 地味で地道なはてなブログ
を参考に、今あるUbuntuには消えていただく。
それで、SSDが来たらまるっとコピって、元のはどうしようかなあ。
環境が一通り揃ったら、Ubuntu18.04を入れる。
だいぶ先だなあ。
スマホも機種変更するし、なんか設定まつりである。

箱のお引越し

古い上に全然コンテンツをメンテしてないのでアレなんだが、箱(WordPressのサイト)の参照先を変更してみた。
要は、どっかにDB名があるはずなので、ソースにgrepかけてみたら、wpのルートにwp-config.phpがあって、そこにデータベース接続情報が全部載っていたので、全部新しいデータベース情報に書き換えた。
ついでに、バックアップ取ってみたらInnoDBでなくMyISAMだったので、そこも全部書き換えて、wp-config.phpのDB_CHARSETをutf8→utf8mb4に変えてみた。
ただしこれ、新しい方のデータベースを、

ALTER DATABASE `データベース名` DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci;

を叩いてキャラセットを変えてから実行している。
テーブルも、CREATE TABLEの最後でキャラセットを指定してる。
これがあらかじめないとはまるかもしれない。

) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

とりあえずなんとか無事に移行できたようだ。
SSL化も、設定で親サイトのURLを無理やり貼りつけると、一度はエラーになるのだが、トップを表示させると、ちゃんと最新になってくれる。なんぞこれ。まあ通ればいいや。

さて、PDOののろいに戻るかね…。

箱のお引越し

ずっと前から使っているもんだから、本体はバージョンアップしていても、データベースが古いまんまなのだった。
なので、一応古いデータベースをエクスポートして、古いのはとりあえずおいておいて、参照先を新しく作った方のデータベースにしたいのだが、WordPressではどうやるんだろうな。
たんにテーブルを全部差し替えて大丈夫なもんか、新規作成してpostsだけあとで一括で入れちゃえばよいのか。
utf8mb4で接続エラーになるのろいも解かなくてはならないので、実験場が必要なのは事実なのよな。
とりあえずあとで調べる。

PHP7にあげたらWordPressのktai-Styleがエラー吐きまくってログインできなくなった

久々に、放置してあった箱本館を見に行ったら、PHP7にあげたもんだからKtai-Styleがエラーをげろげろ吐いて入れなくなってしまったので、ぐぐってちなちま直してログインして、ktai-Styleは削除した。さすがにもうガラケーでうちを見に来る人もいるまいて。
手順は、下記の記事の通りにえんえんと修正を入れた。
WordPressのKtai StyleをPHP 7で動作するように修正した : トイレのうず/ブログ
いずれ古いシステムやWordPressの改修でこれに見舞われる可能性はあるので、とりあえずメモっとく。

プレースホルダーが効かない

タイトルまんま。これではまっている。
いつから発生していたのか記録しておけばよかったなあ、即値指定を静的プレースホルダーに変更したあたりだと思うのだけど、すぐ変わったらさすがにわかる。
とりあえず即値で動作チェックですな。それからプレースホルダーが効かない原因を確認。
全体的に処理が重いので、できればバインドしたい。

//MySQLの接続オプション指定
$db = new PDO($dsn, $dbUser, $dbPass);
$db->setAttribute(PDO::ATTR_EMULATE_PREPARES, false);
$db->setAttribute(PDO::MYSQL_ATTR_MULTI_STATEMENTS, false);
$db->setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION);
} catch (PDOException $e) {
$errorMsg[] = 'データベースの接続に失敗しました: ' . $e->getMessage();
$dberror = true;
}