「サーバー」タグアーカイブ

【解決済】削除に失敗しました: このサイトで重大なエラーが発生しました。WordPressのトラブルシューティングについてはこちらをご覧ください。と出てプラグインが削除できない時の対処法

ワードプレスのプラグインがエラーで削除できない時の対処法

何かのタイミングでWordPressのプラグインが削除できなくなる時がある。

エラーの文言は「削除に失敗しました: このサイトで重大なエラーが発生しました。WordPressのトラブルシューティングについてはこちらをご覧ください。

この時の対処法メモ。

プラグインを強制的に削除したい時(再インストールも同じ手順)

プラグインの管理ページで「削除」ボタンを押しても「削除しています…」と出るだけでページ上部にエラーメッセージが表示されるだけ。

こんな場合は管理画面からの削除は無理なので、サーバーのコントロールパネル又はFTPソフトから削除しよう。


FTPソフトで接続し、wp-content/plugins の中の該当のプラグインをフォルダごと削除してしまう。

なお、削除ではなく、プラグインを強制停止したいだけの場合は、削除ではなくプラグインのフォルダ名を変えてしまえばいい。

これだけで、管理画面からもきれいさっぱり消えてくれる。

【解決済】ロリポップサーバーで、.htaccess等を更新しても反映しない時の対処法

.htaccess でwwwありなし、index.htmlありなし、httpsのURLの正規化をしてもロリポップサーバーで効かない時の対処法

ロリポップサーバーで担当者が蒸発したホームページのSSL化をしてくれと頼まれた。

担当者の蒸発はよくある話なので、マネージドレンタルサーバーの大手のロリポップ、クリック一発でサクッと終わるだろうと思っていたら意外と手こずったのでメモ。

まずはSSL化。クリック一発。ロリポップでSSLは無料なので何の問題もなし。

次に.htaccessで wwwなし。index.htm を表示させない。httpでアクセスした時にhttpsに転送する。
をした。

<IfModule mod_rewrite.c>
RewriteEngine On

#indexなし
RewriteCond %{THE_REQUEST} ^.*/index.(html|htm|php)
RewriteRule ^(.*)index.(html|htm|php)$ https://%{HTTP_HOST}/$1 [R=301,L]

#wwwなし
RewriteCond %{HTTP_HOST} ^www\.(.*) [NC]
RewriteRule ^ https://%1%{REQUEST_URI} [R=301,L]

#https
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]
</IfModule>

いつもの作業なので、これは問題なく終わった。

はずだった….

動作チェックをして、いる時に
http://xxxxx.comhttps://xxxxx.com へリダイレクトされ問題なし!
http://xxxxx.com/index.htmhttps://xxxxx.com へリダイレクトされ問題なし!
https://xxxxx.com/index.htmhttps://xxxxx.com へリダイレクトされ問題なし!

https://www.xxxxx.comhttps://www.xxxxx.com のまま、www無しへリダイレクトされず!
http://www.xxxxx.com/index.htmhttp://www.xxxxx.com/index.htm のまま www無し、index.htm無しへリダイレクトされず!

.htaccess がwwwの時に効いてない。なぜ?

htaccessが効かない理由はロリポップサーバーの仕様のせいだった。

結論的に、www付きのサーバー上の参照ディレクトリと、www無しの参照ディレクトリが違うのが問題だったのだ。
なぜかwww付きはサブドメイン扱いになっている。


ロリポップサーバーにログイン。
「サーバーの管理・設定」→「独自ドメイン設定」を見てみよう。
ドメイン横の「確認・変更」を押すと、変更できる。

http://xxxxx.com の「公開(アップロード)フォルダ」は「xxxxx.com」になっている。
そして「xxxxx.com」フォルダの中に「.htaccess」を入れている。なので問題なくリダイレクトされていたわけだ。

ふむふむ。問題なし。

次に、「サーバーの管理・設定」→サブドメイン設定を見てみよう。

ここではwww付きにアクセスされた時に参照される「公開(アップロード)フォルダ」を設定できる。

今回は、ここでスペルミスをしていたので、別ディレクトリを参照してしまっていて、www有りのURLでは.htaccess が効かなかったわけだ。

前任の担当者が蒸発する前に、何をしていたのか分からないので、なぜディレクトリが別になっていたのか不明だが、今回はwwwありなしを同じディレクトリに設定すると見事に解決した。

単純な事だった。

ロリポップサーバーでURLの正規化ができない、wwwをつけると更新が反映されない時は?

この時も.htaccess の場合と同じで、wwwありの参照ディレクトリと、wwwなしの参照ディレクトリが異なっていて、一方のディレクトリにのみアップロードされているためだ。

WordPressでデータベース接続確立エラーになり、Not enough memory for blob データベースの修復(Repair)もできない時の対処法

データベースエラーになった時の状況確認

データベース接続確率エラーとWordpressで表示される時の状況確認。

・インストール後やサーバー移転後ずっとエラーなのか、ある時急にエラーになったのか
→ 最初からの場合は、データベース名、ホスト名、ユーザー名、パスワード、プリフィックスなど何かしらが間違えている可能性が高い。
まずはwp-config.phpの中のデータベースの設定などを確認。

ある時を境に、急にエラーになった場合は下記確認。

・サーバー側のエラーなのか、データベースのテーブルが壊れているのか
→ サーバーがダウンしている、メンテナンス中などの場合もこのエラーが表示される場合がある。緊急でないなら数時間~1日待ってみる。
国内サーバーなら、ホスティング会社のWebサイトなどに障害状況が掲載される場合が多いのでチェック。
海外サーバーなら、カスタマーサポートにメールかチャットで連絡してみる。

データベースの異常を確認するには、phpMyAdminにログインして、テーブルが「in use」になっているかどうかを確認すれば、データベースが壊れているかはすぐに分かる。

 

phpMyAdminを使いたくない(使い方が分からない)人は?

蛇足だが、phpMyAdminを使いたくない人は、

wp-config.phpのどこかに

define( 'WP_ALLOW_REPAIR', true );

と記述してから

ブログURL/wp-admin/ にアクセスしてみてWordPressからDBの修復を試みる事ができる。

これで修復できればいいが、できない場合は下記へ。
 

phpMyAdminからのデータベース修復

サーバーの管理画面などからphpMyAdminへログイン。

該当のデータベースを開くと

テーブルで「in use」となっているものがあり、「in use」は、破損を意味している。
今回は、wp_options が死んでいる。
あと他にも、wp_commentmeta もよく死ぬ。

壊れているテーブルの左のチェックボックスを選択してから上のメニューで「Repair table」を選ぶ。

日本語版だったら「テーブルの修復」かな?

上に緑で「Your SQL query has been executed successfully」って出たので、やった!成功だ!と思いきやエラーでした。

「Not enough memory for blob at 64384 (need 16862691..」

need xxxxx の部分の数字が途方もなく大きいので、これはもうまともな手法では直せないなと理解。

このエラーが出た時は 修復(repair)では直せない。

ちなみに、シェルアクセスでコマンドを打っても同じ、当然WordPressのdefine( ‘WP_ALLOW_REPAIR’, true );で、管理画面からリペアを試みても無理だ。
 

データベースのバックアップの復元、それが無いならサーバー管理会社にお願いしてリストア(ロールバック)してもらう。

自分で定期的なバックアップをとっていればそれをリストアしてもいい。

データベースのバックアップなんかしてねーって場合は、サーバーの運営会社(ホスティング会社)に連絡して最新のデータベースのバックアップへ復元してもらうしかない。