8/1から2つのサイトでiftttとwordpressがつながらなくなった。

iftttの管理画面で見てみると、認証エラーの模様。作り直してもNG。同じアカウントでログインはできる。

古い情報ばかりなのでWEBはあてにならず、Xにもこれと言って情報もない。

気になるのは、日本人ばかりがでてくること。世界中で使っているのだから誰かしら影響が出ていて困ってそうだが・・・・

ちなみにこのサイトでは使っていないので関係はない。

さてどうするか。

どうもこんにちは、[sampei1]

先日これが出て、対処した時のことを書いておきます。

恐らくこれを見ている方は多分に焦っているかと思いますが、少しお付き合いください。大丈夫、治りますから。

「サイトに技術的な問題が発生しています」とは

ざっくり書くと２つのパターンがあると思います

①自分のブログを見ようとして（或いは編集）、ブラウザ上で出会う

保存し損ねた＆再現させることがちょっと難しいので画像は載せられませんが、ベージュっぽい画面で、中央上に「技術的云々」の文字が書かれている画面です

②突然メールが届く

こんな感じのもの（ところどころ白で消してあります）

これらに共通して言えるのは、「サーバー自体は生きているが、ページが表示できない」状態であるということ。そもそもサーバ全体が止まってしまっていれば、WEBで技術的云々と表示させることもできませんし、メールも出てきません。

なので原因を突き止めて対応すれば十分復旧させることは可能なんです。不幸中の幸いってやつですね。

対処

アラートメールで答えは書いててくれています。

→”今回の場合”に続く部分でエラーの原因が書かれています。ここではLazyLoadのプラグインが原因のようです。

流れ上このまま書きますが、なんでこうなったか、という確実な原因は言えませんが、十中八九これだとおもいます（↓）

●直前の4:50にプラグインの自動アップデートが走ったようなのですが（WPの機能ではなくレンタルサーバー側のもの）、正常に完了したといいつつ、更新情報欄には何も書かれていないメールが届いていました。

●そして5時になってJetpackがサイトの異常を知らせてくれています

ここから想定されるのは、サーバー側のおせっかいな自動アップデート機能の動作時に、プラグインのファイルが壊れてしまい、サイト全体を表示不可に追い込んでしまった、という感じ。

●サーバーのコントロールパネルに入り、ファイルマネージャを開きます。そこから問題のプラグのインストールフォルダを探します
※FTPツールを使われているならそちらでどうぞ

プラグインが原因なわけですから、システム側から読めなくすれば動くはずです。

上記は変更前のものですが、 rocket-lazy-load → _rocket-lazy-load　でフォルダの名前にアンダーバーをつけてしまえば、サーバー側からは別物と認識されるので読み込まない→回復します。

●このあと仕事に行ったのですぐにはいろいろできませんでしたが、帰宅後に管理画面からプラグインを一度無効化にしておき、対象プラグインのファイルをフォルダごと消して、再度同じものを入れましたが異常はなく、動作してくれています。

●その後、サーバー側の自動アップデート機能は切り、作業終了です。

まとめ

「サイトに技術的な問題が発生しています」が出たら、落ち着いて原因を特定し、ファイル名を変えるなりすれば急場はしのげます。そのあとゆっくり対策を考えましょう。

本当に怖いのは、何のお知らせもなく、サーバーが沈黙してしまうことです。どこに原因があるか、わかったもんじゃない。

簡単にすんで、良かったと喜びましょう。ではまた。

どうもこんにちは、さんぺい（@3pei_tw）です。

以前こんなことを書いてました。

どちらもこのBlog構築用アプリケーション／WordPressの基本機能である”WP-CRON（通称：ワードプレス用なんちゃってCRON）”に関係したものでした。

当時（約2年前）は月1000円ちょっと払ってVPSで運用してたんですが、その後紆余曲折ありまして、今では”core server”っていうレンタルサーバーを利用させてもらっています。

それ以降はあんまり記事を書くこともなく、どこにアピールすることもなく、細々とやってきたんですが、やっぱりWEB上で書き物をしている以上、検索に出てきてなんぼだろう、という意識の変化がありまして、ここ数日いじっておりました。

で、わかったことが

・記事を書いてもブログランキングサイトに更新状況が通知されていなかった
（俗に言う、PINGが飛ばない、っていうやつ）

・上記については、ランキングサイト側で無理やり疑似PINGを打って、更新した内容を強制的に反映させる方法があるんですが、それすら動かなかった

という状況です。

ちょっと前に、広告が出ない、と騒いだことがあったんですが、

あれと同じく、たぶんプラグインの何かが悪さをしているんだとは思ってますが、何が悪いのかつかみ切れていません

（ちょっと前に、ログイン時のMFAを可能とするプラグインをいれまして、そいつがWAFとか動かしてたのでそいつだろうと思って止めても変化なかったんです。。）

で、まずは何ができないのか見極めるために、手を加えている予約投稿を実行してみようかな、と。

問題がなければ、明日（2021年11月27日AM07:00）に自動投稿されると思いますが、さてどうなるか・・・・・。

どうもこんにちは、[sampei1]

毎日寒いしずっと家の中にいるし、新しいことにはなかなか出会えないんですが、それでも頑張って生きてます。

管理画面でウィジェット表示が変になった！

正直語りつくされた古いネタなのかもしれませんが、先日来気になっていたことが自力で解消できたのでご紹介させていただきます。

だって検索むずくて、ほしい情報がなかったんだもん云々

もともとはこんな感じの表示でした。

左側にパーツが並び、右側に実際のメニュー項目が並ぶやつ。

これはこれでパーツが増えて下に伸びてきたときにドラッグドロップするのがちょっと大変だったりしますが、多くの人がこれに慣れてると思います。

で、最近変わって出てきたのがこれ

縦にずらーっと項目が並んで、項目を探して編集するタイプ。

たしかVersion5.5の時に導入されたものかと思いますが、正直馴染みません。

新しいものは大好きなので、何か見つけるとすぐさま飛びつく人なんですが、この場合は全く新しいものではなく既存システムの改修版じゃないですか。

操作性が良くなったとか画期的な機能が導入されたとかっていうなら頑張って使い続けるんですが（ちゃんと使えばあるんだとは思うけど）、こういう見た感じだけの変更で「さあ、使えお前たちよ」的な提供物って、「えっ、ちょっと・・・」ってなりませんか？

しかも作りがイマイチ。例えば

これ。インデントの設定が甘くて、行番号と既存の文字がかぶってる。しかも編集ができない。これを見て「戻そう」と決心しました（ブラウザ要因じゃね？って気もするけど）。

これ上のほうにあるサイドバーとかは大丈夫で、下のほうにある部分だけ変な表示になってるような気がします（普段閉じられてて開く部分）。

且つ展開直後は真っ白で、エリア内をクリックするとおもむろに文字が出てくる。。。

原因：これ

「グーテンベルグ」という、Wordpress5.5あたりから提供され始めた機能。こいつがONになってるとWidget表示が変わっちゃう。

てっきりこの機能は投稿編集画面だけに影響してると思い込んでて、他には影響してないと思ってONのままにしていたのが原因。

※投稿画面は”ClassicEditor”ってプラグインで旧インタフェースに戻してた

よってOFFにして元通り。ふう。よかったよかった。

まとめ

WordPressで最近ウィジェット編集の形が変わっちゃって困ってるんだよねー

という場合は

”Gutenberg”プラグインをOFFにしましょう。

これで幸せになれます。たぶん。

どうもこんにちは、さんぺいです。

先日件名のエラーが出て、対応したので残しておきたいと思います。

どんな時に出るの？

WordPressで作成されたサイトに、大きいファイルをUPした時に出ることがあります。

例えば、ものすごく解像度が高くて且つサイズが大きい画像とか。

FTPで上げたときではなく、WEBブラウザからUPした時に出てくると思います。

どうして出るの？

WordPressに限らず、WEBで動いているシステムには大抵制限が設けられています。

無制限にすることで巨大なファイルを上げられて回線がパンクしたり、サーバの動作がおかしくなったり。

そうならないよう、制限値を設定しておきます。それに引っかかった状態がこれです。

まるでWindowsパソコンでブルースクリーンが出たときだったり、WPでも入力ミスって画面真っ白になったり、それと近いものはありますね。

まぁ、「戻る」で戻るだけでとりあえずこの場は脱出できるんですが。

何が原因なの？

想定される原因については大きく分けて2パターンあります。

①php.iniで制限がかけられている（サーバ全体／default値：2M）

②.htaccessで制限がかけられている（ディレクトリ毎／設定がなければ上記①の値が適用される）

どうやって治すの？

対処方法には大きく分けて2パターンあります。

①php.iniの該当箇所の値を変える

②.htaccessの該当箇所の値を変える

一般的にiniファイルをいじれるのは管理者くらいなんで、大半の方が②のみの確認でOKです。

また、②で設定すると①よりも優先されます。逆を言えば、①を変えても②があるとそちらが優先されてしまう、ということです。ややこしいですね。

ということで①は飛ばして②のみの説明をさせていただきますね。

.htaccessの該当箇所の値を変える

htaccessっつーのは強力でして、書き方をちょっと間違えただけで、そのディレクトリ配下が全滅してしまうこともあります。修正時は注意をして作業してください。

①.htaccessを探す

探すとは言ってもwordpressの場合はこのファイルが自動作成されていると思います。その場所はコンフィグファイルなどがあるディレクトリです。

●定番のFTPソフト、ffftpで見た感じ

通常はこれをローカルに転送して編集、その後再度サーバにUPしてできあがりなんですが、今ではレンタルサーバ側で準備した環境で、GUIで編集できる場合もあるようですね。

②変更内容を.htaccessに追記する

ここが重要です。

①で出てきたphp.iniはサーバ全体を通して設定する値なので、複数人で使うレンタルサーバのようなものの場合はいじれません。

レンタルサーバがいうなれば集合住宅全体のルール、htaccessはその全体のルールを自分用にアレンジして、自分の住まいにのみ適用することができるものです。

俺ルールなので基本的に他の入居者への影響はありませんが、例えばミスをすることでCPUがあがり、全体に影響を与えてしまった、とかトラフィックが急増して他の方のレスポンスが悪くなった、とか絶対にないとは言い切れませんので、注意して直すようにしましょう。
※まぁ各住戸への上限値設定はあるでしょうからそうそうおかしなことにはならないと思いますが・・・。

では変更内容です。.htaccessのどこらへんでもいいので以下の文を入れてください。

php_value upload_max_filesize 30M

※phpとvalueは”_”でつながっています。半角開けて、同じくupload,max,filesizeも”_”でつながっています。半角の後の数値はお好みで。デフォルトは確か2Mだったと思いますが、20メガ、30メガあたりが妥当じゃないでしょうか。

ちなみにphp.iniで言うと頭の”php_value”が取れた項目がそのまま入っています。

同じように設定するもので”post_max_size”とか”memory_limit”がありますが、これも同じ要領でhtaccessにて設定が可能です。

参考）変更前の.htaccess

変更後の.htaccess

※説明書きにもあるように、BIGIN~ENDの間はいじらないでください。ここを下手にいじるとWP再インストールとかになる可能性があります。

※慣れないうちは必ずいじる前にバックアップをとっておいてください。
失敗して画面真っ白とか500番台のエラーが出たときは、とりあえずの復旧措置として何もいじっていないファイルを上げなおすのが一番早いです。

編集が終わったら保存してFTPでサーバにUPして完了です。変更はUPするだけで適用されます。

■改善した・・・お疲れさまでした。こういう作業を繰り返すことで慣れるし楽しくなってくると思います。WP沼にようこそ！

■こわれた・・・まずは元に戻しましょう。戻せたら、そこからなんでダメだったかじっくり考えましょう。実は失敗して悩んだほうが上達が早かったりします。困ったらコメント欄からご相談ください。少しは力になれるかもです。

以上、Wordpressでアップロード制限を拡張する方法でした。

最後までお付き合いいただきありがとうございました。