さくらで初めて知って自分のサイトのサーバー移管のためにちょっと触ってみたのだけど。
（そのときはちゃんと使えなかったけど
いろいろ調べてみたらすごいなぁ。
もう1回サーバー移管してみようかな。

というわけでphp7.28モジュールに対応してついでにSSLの対応もしました。
そのほかの対応もしたのでグーグルスピードチェックが55から95まで上がりました。
うーん、どんだけほったらかしだったんだって話だー。

php7.2cgiでも体感できる速度差だったけどそれ以上に動作が速い。
昔はうぃいいいいいいいいん、ぽ〜〜〜ん。
という感じだったが、今はきゅっきゅ。って感じがする。

SnapUpはメールアカウントの移行までは行えない感じかな？
あくまでWebサイトだけの話なんだろうか。
要検証。

初期ドメインからSSL化した独自ドメインにリダイレクトするように変更。

これで一通りの作業が終わりかな？

変更されないファイルがある。（Wordpressの設定だからなどいろいろあると思うけど
wp-config.php
.htaccess
データベース名とか

最初に手動でデータを移動してWordpressの移行をしているので
その辺りの場合でもデータベースの中身はちゃんと移動していた。
サーバーのファイルも更新されている。
データベースの中身が移動されているのでプラグインによってはエラーを出すものものある。
・保存先のディレクトリのパスが変わる場合ことなど
・例：本番[home/test_a/www/] 移行元[home/test_old/www/]
などの違い。
まるまる移行するのでそのこと念頭におく。

SSLの環境でも若干変化がある感じではある。

便利な部分はあるけどちゃんと挙動を知っておかないといけないな。
いろいろかんがえるとちょっと便利だなという感じ？

すっかり忘れていてつまづいたので
Wordpressでフロントページの設定をしているとis_home()のチェックを抜けてしまう。
またメインクエリもフロントページに設定したページのクエリに変わる。
まっさらの状態から作っているのではなくデータベースを移して使用している場合には固定ページが
フロントページに設定されていないかどうか注意。

ラピッド

申請
振込確認とか
メール通知
会員メニューより認証ファイルをDL。
指定の場所にアップ
その際にブラウザでアクセスできるかの確認。
場合によっては.htaccessの編集。
認証ファイルアップ後に再度メール通知（SSLの証明書の発行通知メール）
会員メニューに移動し証明書をDL
サーバーのコンパネに移動
中間証明書の更新（SSLの証明書発行通知のメールにリンク先あり）
SSL証明書の更新

＊DLしたファイルをテキストエディタで開き内容をすべてコピペ。

SSLの更新忘れはダメよ。

いろいろと試した結果
phpの
max input value を増やしたらちゃんと対応できた。
やったぜ。

かも？
サーバーよりWordpressのsqlファイルをエクスポートし
ローカルにインポート
この際にDBの特定項目を書き換えるのを忘れて先にブラウザでローカル環境を開いてしまう。
そうそう、書き換えないとねと思い出しphpmyadminで書き換えをするが
反映されていない。
何度かDBを書き換えたりして試してみるがダメ。
ローカルのURLを叩くと本番環境のURLにリダイレクトされる状態。
管理画面には直接URLを叩けばログイン画面まで移動しログインが可能なことが判明。
ほかのブラウザではどうだろうか？と試してみるとサファリだとリダイレクトされないでページ内の巡回も可能。
一度使っているブラウザを終了させてみるが現状は変わらず。
ちょっと検索してみるとFirefoxの公式サイトにキャッシュを削除する〜〜みたいな話しが出ていたので削除したのちに
該当のローカル環境にアクセスすると普通に表示される。

返して、返して私の1時間！

7.2cgiにした。
これだけでも体感できるぐらいWordpressの動作に変化があったけども
コンパネからステージングサーバーをつかって7.2のモジュールモードを試してみた。

うん、全然違う・・・。
現在のサーバーはかなり古いサーバーだから・・・。

プラン さくらのレンタルサーバ スタンダード
CPU Intel Xeon E312xx (Sandy Bridge)
メモリー容量 18GB
Apacheバージョン Apache/2.4.33

うん、はやり最近借りた同プランのサーバーとくらべて見劣りしてしまうスペック。

乗り換えようかぁ・・・。
ついでにサイトのデザイン変更とレスポンシブ対応するかなぁ。
ついでにSSL化もしておくか。

実はゴミ箱に入っている記事は「すべて」に含まれていない。
うっそだろ、おまえ！＼(^o^)／

ついにcoda2のsassプラグインの挙動を把握。
sassファイルを作る→書く→保存→コンパイル
その後書き出される箇所は同名のcssファイル名がある場所に書き出される様子。
こんな挙動なのか・・・。

初歩的なところも含めて

$mysqli = new mysqli($wpdb_host, $wpdb_user, $wpbd_pass, $wpbd_dbname); //DBに接続
if($mysqli->connect_error){
  echo $mysqli->connect_error;
  exit();
}else{
  $mysqli->set_charset($wpdb_charset);
}
$sql = "INSERT INTO " .$wpdb_tablename2. " (tabel_name, i_date) VALUES (?, ?)";
$stmt = $mysqli->prepare($sql);
$stmt->bind_param('sd',$ctg_name,$i_date);
$ctg_name = $ctg_name;
$i_date = date('Y-m-d H:i:s');
print_r($stmt);
$stmt->execute();

プレパラでハマったmysqliではvalueのところでコロンが使えない。
あと全てのカラムを埋めない場合はカラム名の指定が必要、そりゃそうだ。
はまった。

function remove_class_action ($action,$class,$method) {
    global $wp_filter ;
    if (isset($wp_filter[$action])) {
        $len = strlen($method) ;
        foreach ($wp_filter[$action] as $pri => $actions) {
            foreach ($actions as $name => $def) {
                if (substr($name,-$len) == $method) {
                    if (is_array($def['function'])) {
                        if (get_class($def['function'][0]) == $class) {
                            if (is_object($wp_filter[$action]) && isset($wp_filter[$action]->callbacks)) {
                                unset($wp_filter[$action]->callbacks[$pri][$name]) ;
                            } else {
                                unset($wp_filter[$action][$pri][$name]) ;
                            }
                        }
                    }
                }
            }
        }
    }
}

なんでも強引にactionをremoveしちゃうfunctionとのこと。
まだ試してないのでメモ書き程度

新しいWpのエディタを使って記事を書いて
プラグインを停止させると案の定レイアウトが大きく崩れる。
プラグイン側のレイアウト用のCSSの仕様にそったコンテンツエリア内での記述ならそれなりにレイアウトが整えられた公開画面にはなると思った。

現状の導入の問題としてはthe_contentが吐き出したソースに
#main div.entry ul
とかの感じでスタイルを作っていると案の定影響を受ける。

最初からこのエディタを導入する前提でつくるのであればある程度回避方法はあるが
新エディタに対応しているのが現状で投稿と固定ページのみ。
また、カスタムフィールドなどの独自の入力項目に対応していないので色々と問題は出る。

新エディタのプラグインをONにし旧エディターのプラグインもインストール。
有効化を行ったら画面上部のメニュー項目に新エディタと旧エディタの行き来ができるようにはなる。
旧エディタ画面にいけばカスタムフィールドや自前で追加したBOXの操作ができるようになる。（旧画面にもどるということだ）

日本人が大好きなbrBrbrを導入している場合ももちろん影響を受ける。
あとは独自コメントタグが導入されるようなので
タグ打ちをする人は気をつけるかエディタを統一したほうが良いように思う。
特にリッチエディタとは相性が悪いと思う。
テキストエディタなら特に問題はないがタグを間違えて消すとかは論外として。

まぁ、エディタの特徴を理解してちゃんと使える人ならええんちゃう。
特に細かいレイアウトをしたいと思う人は自力でタグを学んだ方がやりたいレイアウトにはなると思うな。
現状としてはベータ扱いの箇所もあるがすごいエディタだとは思う。

必要かどうかは置いておいて。
今までの書き方だと
ul li
とタグを書いて入ればそれなりに整ったレイアウトになる環境で作っているのなら必要はないかなぁ。
仕事としてクライアントに進めれるかと言われたらちょっと入力自体が手間がかかりそう。
こういうのが好きな人には良いかもしれないけれどどんな人でもぱぱぱっと更新！という形になるのは難しそうだ。