すっかり忘れていてつまづいたので
Wordpressでフロントページの設定をしているとis_home()のチェックを抜けてしまう。
またメインクエリもフロントページに設定したページのクエリに変わる。
まっさらの状態から作っているのではなくデータベースを移して使用している場合には固定ページが
フロントページに設定されていないかどうか注意。
- HOME
- Diary
ラピッド
申請
振込確認とか
メール通知
会員メニューより認証ファイルを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
とタグを書いて入ればそれなりに整ったレイアウトになる環境で作っているのなら必要はないかなぁ。
仕事としてクライアントに進めれるかと言われたらちょっと入力自体が手間がかかりそう。
こういうのが好きな人には良いかもしれないけれどどんな人でもぱぱぱっと更新!という形になるのは難しそうだ。
https://cards-dev.twitter.com/validator
上記のサイトでURLの再登録。
FACEBOOK
https://developers.facebook.com/tools/debug/
FACEBOOKのデベロッパー登録してないと無理だったはず。
最近はやってないから違うかもしれないが、まぁそんなことはないやろ。