カテゴリー: 宅サバとWordPress

宅サバとWordPressらへん

Scrape key check failed. Please try again.対処

スクレイピングキーチェックに失敗しました。 もう一度試してください。(Google翻訳様)

スクレイピングは「こする、かき集める」webでは「データを抽出する」的な？

知らんうちにGA4とかになってたGoogleアナリティクスのトラッキングコードを埋め込もうとheader.phpいじって更新したらコレよ。

テーマを別なのに変えて戻してみたらいいよ的なサイト見てやってみたけど意味なし、永久オブジェクトキャッシュのアレが邪魔してるって人がおるからそれ原因説が濃厚かな。

またキャッシュ関係でのトラブルかよ。

プラグインちゃうからちょっと解決に手間かかるな。

…いや、やってみたら全然手間ちゃうかったわ。

テーマファイルエディターで更新ボタン押す手前まで準備しといてからターミナルからsudo mv でobject-cahce.phpに.bakつけて、テーマファイルエディターの画面から更新ボタン押したら更新出来た。んでまたターミナルからsudo mvで.bak外すだけでOKやった、良かった。(あれ？なんかめっちゃ早口で喋ってそう…)

プラグインで永久オブジェクトキャッシュ対応してるなら一旦プラグイン停止でよさげ。

ってかマジでキャッシュ原因やったんやな、キャッシュダルいわ。

宅サバの外観

こちら2023年12月27日現在の宅サバ外観、このブログの入れ物、つまり貴方たちはこのブログを閲覧するときにこのチープな宅サバの中を覗いているのだ、そう、深淵を覗く者は深淵に覗かれているのわよ。

バックアップ保存用のmicroSDかUSBメモリでも刺しておこうかと思案中、容量めちゃあるUSBメモリ刺してNAS運用も実現可能かと思うと夢広がる。アクセス少な目なおかげか特に工夫せずともCPUは45℃らへんで安定。

スティックPCは低消費電力、省スペース、安価でオススメ、特にコイツMorefine M1sはHDMIダミープラグ不要やったのでキャップ付き運用出来てラッキー、もう売ってないんだけがネック。電源も20w取れる780円、電源ケーブルは短くて3A許容。

スティックPCは近いのコレかな？タッチパッド付キーボード付属とかこっちの方がええやん


モバイルPCセット タッチパッド付キーボード付属 4GBメモリ 64GBストレー…[楽天] https://item.rakuten.co.jp/fa-fe/f-mw-mps4/?scid=wi_ich_androidapp_item_share #Rakutenichiba

アダプタはコレ


【一年間の長期保証】 ACアダプター 2ポート usb 充電器 PSE認証 US…[楽天] https://item.rakuten.co.jp/midumadou/nk2201013/?scid=wi_ich_androidapp_item_share #Rakutenichiba

ケーブルはコレ


マイクロUSBケーブル15cmショートコード、HOTNOW [3本、15cm] …[楽天] https://item.rakuten.co.jp/azmeilly32/20231007180245_73/?scid=wi_ich_androidapp_item_share #Rakutenichiba

消費電力はスペック表で低いなとは認識してるけど実際値不明なので消費電力計測出来るスマートプラグでも購入して実測してみようかしらわよ。


単純な消費電力計測プラグより多機能なスマートプラグ一択っしょ、スマホアプリで色々出来るんほんまスマート。

JuiceSSH

手持ちスマホ、AndroidからSSHしたいなと思い立ちSSHクライアントを探し始める。

Termius入れてみたけど鍵認証上手くいなせないからやめてJuiceSSHにした、OpenSSHと鍵認証ちゃんと出来て一安心、あまり好みなインターフェイスではないが肝心なのは機能、っぱ機能っしょ。

とりま新規投稿するのに再起動せなあかんやつスマホで済むから便利やのぉ、えぇもん手に入れたわぃ、夢広がるー。

新規投稿画面に不具合

object-cache.phpを利かすとサイトヘルスの永続オブジェクトキャッシュを使用してくださいを消せる、けどある程度時間経過すると新規投稿画面が開けず重大なエラー発生な不具合になる、sudo rebootで復帰できるところを見るとキャッシュの容量不足なんか？リブートでメモリ開放しとる感ある。

object-cache.phpに.bakとか付けたりして効かんようにするとブログ記事欄が開かん、気持ち悪い動作やな、どないしよ…

このサイトで重大なエラーが発生しま

表向きサイトはいつも通り、しかしログイン画面に入ろうとすると3～40秒くらい待たされて重大なエラー通知が出た。

メールなんて届いてない。

TeraTerm開いてログインしたらアプグレ通知あるからとりあえずapt upgradeしたらなぜか直った、原因なんなん？プラグインは1個だけ、テーマは古いけどデフォルトやからプラグインとテーマでコケるとは考えにくい、PHPメモリ上限かな？最近オブジェクトキャッシュやらページキャッシュらへん触ったからそれかも？

バックアップとリストア作業の備忘録

以下作業中なにしたか思い出しながらの覚書、備忘録ヨシ。多分手順通りではないし忘れてる作業あるから後日修正や加筆する、でもあてにしないで逐一調べてやって。

何が厄介ってサイトのバックアップと復元、バックアップは復元するまでキチンとバックアップ出来てるかわからない、BackWPup使ってたけど確認不足でマルチサイトの復元は無理でシングルサイトでも復元には要課金、…騙したなって思うやん？

慌ててUpdraftplusを入れてバックアップしてみるもマルチサイトは成功しにくい、しかも今回はサバ移行なので復元が有料オプション、やはり世の中金ですかね。BackWPupで700MB以下なら復元できるってなってたけど何故かウチのデータ700MB超えてんすよ、無理やん。

そもそも企業勢でもあるまいし個人でマルチサイト化なんてデメリットデカ過ぎ。マルチサイトのまま移行はできないと判断しシングルサイト化して完全手動復元とする、たまたまブログ以外はページも少なきゃデータも少ないので右クリック保存で対処する。

ひとまず旧WordPressでテーマ、プラグイン、WordPress本体を現PHPで出来るところまで更新。テーマ(themes)、プラグイン(plugins)、画像(uploads)をFTPでダウンロード。

マルチサイト化してる場合、uploadsのツリー最下部にsitesがあって子サイト分の番号フォルダが並び、各子サイト画像がそこに格納されてる、画像データに関してはシングルサイトに復元する際にどのフォルダからuploadsにするかを後から選んだらいいからuploadsフォルダごとダウンロードする。

マルチサイトやとデータベースがほんとに厄介、下記地獄の様子。

phpMyAdmin手動でデータベースダンプさせても復元したらエラーゲロ吐き、原因はまずプラグインを全解除してなかった点、プラグイン全解除で挑むとまたしてもエラー、今度はダンプSQLファイルをnanoで読み進めてWordpress Ping Optimizerがなんか悪さしてるのが発覚、コイツphpエラー原因やったりping連発したりいつもなんか悪さしてるな…

停止してもバックアップに不具合を生むWordpress Ping Optimizerは完全削除の必要がある、ブラウザ内の操作でWordpressから削除してもデータベースのテーブルにゴミを残す、キチンとバックアップするために必ずそっちも削除を。Wordpress Ping Optimizer停止、全摘出を強烈に鬼推奨する、WPO〇ね、ping送るくらいで調子乗んな〇ケが。

phpMyAdminのツリーから以下を見つけだして駆逐！

wp_cbnetpo_ping_optimizer

下記wp_optionテーブルも削除を

cbnetpo_last_ping_time

cbnetpo_options

cbnetpo_ping_num

cbnetpo_ping_optimizer

レンタルサバではひたすらphpMyAdminでの作業になる、滅多に触らんから全然慣れん。慣れてないから使い方消し方逐一検索して作業するしかない、ノリでやると取り返しつかんくなりがちやから要注意。クエリがどうたら本当に実行しますかと聞かれるとビビるし実行した後の返答が返り値が空でした(行数0)とか言われてコイツ会話成り立たんなと思うよね。しかしプラグインのゴミ残り過ぎ、マジでプラグイン嫌いになる。

プラグインのゴミを取り除いてダンプしたSQLファイルを確認、create databaseとかが無かったため、phpMyAdminで再度詳細なオプションで追加してダンプし直し、DBをnano直でテーブル名置換。マルチサイト化してる場合は_旧DB名_2_ってなってるのを単純な_に置換と、_旧DB名_を_に置き換え、この辺は鬼ググった、参考サイト4つくらい同時に見てたな。

そういや移行復元先のWordPress、PHP、MySQLのバージョンを揃えとかないといけない、がMySQLのバージョンだけメジャー一緒でマイナーも近かったからまんま行ったらいけた。

忘れがちな権限あたりもやる。

MySQLでGRANT ALL PRIVILEGES ON 新DB名.* TO ユーザ名@localhost IDENTIFIED BY ‘パスワード’;

nanoから出てsudo chown -R www-data:www-data /var/www/ルートディレクトリ/

今回DB名を変えたのでWordPressがアクセスするDB名も書き換え、wp-config.phpをnanoで、define( ‘DB_NAME’, ‘新DB名’ );に。

移行でドメイン名が変わるならDBの記事データ内のドメイン名も書き換え、サイトURL、home、カスタムフィールド値も書き換え。GUIDや記事タイトルは今回書き換え不要やった。作業は以下文を使用。

sudo mysql
DB選択は下記
use DB名;
UPDATE wp_posts SET post_content=REPLACE (post_content,’http://旧ドメイン名’,’https://新ドメイン名’);

上記文のwp_postsとpost_contentを下記に変えて同じように書き換え

wp_options　(option_value

wp_postmeta　(meta_value

これでようやく復元可能なDB出来上がりかな？まだなんかやってたかな思い出せん…

結論、マルチサイトはDBの復元が地獄。