さくらのSSLの更新

ラピッド

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

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

SSLの更新忘れはダメよ。

リダイレクト先もキャッシュで記録される場合がある。

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

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

サーバーのphpのバージョンを5.2から

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

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

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

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

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

WordPressの記事の管理画面の「すべて」が


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

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

DBのはまったところ

初歩的なところも含めて

$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のところでコロンが使えない。
あと全てのカラムを埋めない場合はカラム名の指定が必要、そりゃそうだ。
はまった。

WordPressで

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

ツイッターカードとかSNSに登録された情報の更新

https://cards-dev.twitter.com/validator
上記のサイトでURLの再登録。

FACEBOOK
https://developers.facebook.com/tools/debug/
FACEBOOKのデベロッパー登録してないと無理だったはず。

最近はやってないから違うかもしれないが、まぁそんなことはないやろ。

イラレの問題

・パスの数が多すぎたりすると保存できなかったりエラーになったり。
・パターンを縮小していきとてつもなく小さな状態になるとエラーになることもある。
・ある程度のエリアの中に1ミリの中に大量にアンカー等があってもエラーになる場合がある。
・スウォッチの名前が長いとエラーになる場合がある。

聞いた話を簡単にまとめるとこんな感じだった。

さじアストロパーク
良さそうだ・・・。