ラベル Wordpress の投稿を表示しています。 すべての投稿を表示
ラベル Wordpress の投稿を表示しています。 すべての投稿を表示

2022/03/01

Wordpressのサイトを別ブログ(Blogger)にリダイレクトするTips

WordPressからBloggerへ移行した際のリダイレクトの覚え書き。

最初はドメインごと移転で何とかなるかと思っていのだが、Bloggerは投稿エントリに年月のディレクトリが含まれるので結局1エントリー毎に転送処理を書く羽目に…

WordPressがインストールされてディレクトリに .htaccessファイルを設置し以下のように記述。

<IfModule mod_rewrite.c>
	RewriteEngine On
	RewriteCond %{HTTPS} off
	RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]
	RewriteRule ^【転送元パーマリンク】/$  【転送先URL】 [R=301,L]
        ~この間、転送元→転送先の処理をひたすら書く~
</IfModule>

つまり移行した記事は96あるので、「 RewriteRule ^【転送元パーマリンク】/$ 【転送先URL】 [R=301,L]」が96行続くという…

で、問題のサイトのトップ画面。
移行といっても急いでBloggerにHTMLソースをコピペしただけなので、画像ファイル等は元のサーバーから呼び出している状況。

ここでRewriteRuleでやろうとすると画像までリダイレクト処理され、リダイレクト先には当然何もないので404Not Found。他の記事の画像まで表示されなくなる。

画像のリダイレクト処理も書けばいいのだろうが、Bloggerに再アップロードするのが面倒だし、画像URLも記事内に貼り付けなければ出てこないのでやろうとすると凄まじく面倒くさい、というか素直にBloggerに上げて貼り付け直したほうが明らかに楽。

結果、WordPressがインストールされているディレクトリにindex.htmlのHTMLファイルを置いてリダイレクトさせるのが一番楽そうだと判断。

試してみたところ、Wordpressが残っていてもHTMLファイルの方が優先されたのでこれでいくことに。

<html lang="ja">
<head>
<meta charset="utf-8">
<meta http-equiv="refresh" content="5; url=【移転先URL】" />
<title>【ページタイトル】</title> </head> <body> <h2>【ページタイトル】</h2>
<p>このブログは下記に移転しました<br>自動的に切り替わらない場合は下記のリンクを選択してください</p> <p><a href="【移転先URL】" target="_blank">【移転先URL】</a></p>
</body> </html>

画像は少しずつBloggerの方に上げて貼り直しますかね…

参考リンク

リダイレクトと Google 検索 | Google 検索セントラル  |  Google Developers
https://developers.google.com/search/docs/advanced/crawling/301-redirects?hl=ja

ワードプレスで使えるHTACCESSのリダイレクト技8選 | ワードプレスドクター
https://wp-doctor.jp/blog/2019/02/13/ワードプレスで使えるhtaccessのリダイレクト技8選/

2022/02/21

最近のコメントスパム事情(2022/2)

ここ数日、着弾するコメントスパムの量が急増し100件/日を越え、サーバー負荷やログ周りが心配になってきたのでその対策メモ。

普段は.htaccessで欧州方面のクラウドサービスやホスティングサーバーからのアクセスを弾いているのもあってか多くても10件程度なので、これはちょっと心臓に悪い。

↑普段1ヶ月放置しても20くらいなのに1週間でこれはちょっと…(コメント数に関しては察してください)

幸い全てのスパムはAkismetによってフィルタングされているのでコメント欄が悲惨なことにはなっていないものの、この状態が続くとサーバー屋から電子お手紙を頂きそうなので可能な限りの対策は打っておきたいところ。

当方の管理サイトはここ2、3年のコメントの投稿数は年数件なので、とりあえずメール投稿フォームが機能していればそこまで支障はなさそうなので、サイト・ブログ共にコメント欄全閉鎖でひとまず応急措置。

で、問題のログをひとかたまり抜粋

torproject.org - - [14/Feb/2022:14:37:55 +0900] "POST /wp-comments-post.php HTTP/1.1" 200 - "-" "Mozilla/5.0 (Windows NT 6.1; rv:60.0) Gecko/20100101 Firefox/60.0"
insight.firstnetwork.cf - - [14/Feb/2022:14:42:33 +0900] "POST /wp-comments-post.php HTTP/1.1" 302 - "-" "Mozilla/5.0 (Windows NT 6.1; rv:60.0) Gecko/20100101 Firefox/60.0"
ny1.exit.tor.alkyl.eu.org - - [14/Feb/2022:14:49:22 +0900] "POST /wp-comments-post.php HTTP/1.1" 302 - "-" "Mozilla/5.0 (Windows NT 6.1; rv:60.0) Gecko/20100101 Firefox/60.0"
pinga.lsd.cat - - [14/Feb/2022:14:52:27 +0900] "POST /wp-comments-post.php HTTP/1.1" 200 - "-" "Mozilla/5.0 (Windows NT 6.1; rv:60.0) Gecko/20100101 Firefox/60.0"
185-220-102-244.torservers.net - - [14/Feb/2022:14:57:36 +0900] "POST /wp-comments-post.php HTTP/1.1" 200 - "-" "Mozilla/5.0 (Windows NT 6.1; rv:60.0) Gecko/20100101 Firefox/60.0"
5.tor-exit.neelc.org - - [14/Feb/2022:15:02:42 +0900] "POST /wp-comments-post.php HTTP/1.1" 200 - "-" "Mozilla/5.0 (Windows NT 6.1; rv:60.0) Gecko/20100101 Firefox/60.0"
5.183.209.217 - - [14/Feb/2022:15:06:16 +0900] "POST /wp-comments-post.php HTTP/1.1" 200 - "-" "Mozilla/5.0 (Windows NT 6.1; rv:60.0) Gecko/20100101 Firefox/60.0"
torproject.org - - [14/Feb/2022:15:09:36 +0900] "POST /wp-comments-post.php HTTP/1.1" 200 - "-" "Mozilla/5.0 (Windows NT 6.1; rv:60.0) Gecko/20100101 Firefox/60.0"
45.153.160.134 - - [14/Feb/2022:15:13:52 +0900] "POST /wp-comments-post.php HTTP/1.1" 302 - "-" "Mozilla/5.0 (Windows NT 6.1; rv:60.0) Gecko/20100101 Firefox/60.0"

ログを見た感じ「wp-comments-post.php」を直接叩いてコメントスパムを送り込んでいる感じなのだろうか。

そしてUser Agentがほぼ全て「Mozilla/5.0 (Windows NT 6.1; rv:60.0) Gecko/20100101 Firefox/60.0」(Chrome/90や85もあったが細かいバージョンがバラバラ)
同一組織による行いなのか、このUAのツールが出回っているのかは不明だが…

以下、wp-comments-post.phpにアクセスしてきて上記のUser Agentだったホストを絞り込み。
ホスト名が改竄されているのか、Apacheログの記録がミスっているのかは不明だが、ホスト名として成立していないものも多数あり。

気になる方は以下のテキストファイルからどうぞ(記事に羅列すると流石に長過ぎる…)

📄recent_comment-spam_202202.txt

関連記事

中国聯通(チャイナユニコム China Unicom) IP範囲リスト
https://cytn.info/blog/chu_ip-range/

2021/04/20

WordPressのサムネイルファイルを生成させない方法

 レンタルサーバーのコントロールパネルをふと眺めていて気付いた

「WordPressを3個導入しているとはいえ、何か使用ファイル数が異様に多くないか…?」

ログファイルとかが嵩んでいるのかなとファイルマネージャーで色々と覗いてみたところ…

1画像に対していくつサムネイルや縮小画像を生成してやがるんだこいつ…
(ログファイルの類はそこまでファイル数を消費していなかった)

流石にこんなことで上位プランへの移行はしたくはないので、お掃除開始。
以下のサイトを参考にした。

WordPressでサムネの自動生成機能を完全に停止させる方法 | Fukuro Press
https://fukuro-press.com/wp-stop-thumbnail-generation/

とりあえず画像が少ないcytn.infoから作業を開始。

まずはメディアの設定。
1MB超えの画像をページに貼り付けるのは基本的に避けたいので、大サイズのみ設定。
ここまで軽くなれば後はカスタムサイズで表示サイズを操作すればいい(数が多くなると面倒だけど)

ついでに年月フォルダへの振り分けもオフに。

メディアの設定だけでは全てのサムネイルや縮小画像の生成を防げないので、「https://***.***/wp-admin/options.php」から全てのオプションを表示させる。
「size_h」「size_w」をブラウザのページ検索で引っかかった項目を0にしていく。

lauge_size_hとlauge_size_wは先程設定した大サイズ1024の値が入っているので、これは0にしない。
最後にページ下部の「変更を保存」ボタンで設定反映。

6年近くもサイトを運営していると不要な画像が大量に残っているので、現在生きている記事から画像を落として、uploadsディレクトリ配下の年月フォルダを全消去。そして再アップロード
ページ数と画像ファイル数が少ないから原始的な方法が取れたが、旅行記記事で大量に画像がある方(chiyatani.net)はやり方を考えないといけない。

上限250px(多分メディアライブラリ用のサムネイル)と1024px超えのものだけが生成されるようになった。

左メニューのメディアライブラリは画像が使われている記事が表示される(多分WPのエディタから挿入しないと反映されない)
コントロールパネルのファイルマネージャーやFTP等から操作するとおそらく整合性が取れなくなる可能性が高いと思われる。

ちなみに、メディアライブラリから画像ファイルを削除するとサムネイル・縮小画像群も一緒に消えるので、通常はメディアライブラリからファイル操作を行うべきなのだろう。

また、uploadsディレクトリ配下にファイルマネージャーやFTP等でアップしたメディアファイルはWPのメディアライブラリには認識されない。
サムネイルを一つも生成させたくなければ、メディアライブラリを通さずFTP等でアップロードするのも手か(WordPressのメディアライブラリには表示されなくなるが)。


2021/6/11追記

使用しているテーマや導入プラグインによっては他のサイズが生成されてしまう場合がある。

その場合は各テーマのfunctions.php内のadd_image_sizeコマンドを削除(コメントアウト)する(詳細は上記の参考ブログを参照)。
但し、全ての画像生成を止めると記事サムネイルなどが表示されなくなる場合もあるので注意。

当サイトで利用しているMH Magazine lite及び派生テーマの場合、親テーマのMH Magazine liteのfunctions.phpを編集する。
画像サイズから推測するに678×381は各記事ページのトップ画像、326×245の画像は記事サムネイル、80×60は前後ページのサムネイル画像に利用されているっぽい、他のサイズは不明)
とりあえずこれらを除いて画像生成を止める。

当然数値をいじれば生成サイズの変更も可能だが、意図しない部分が切り出されたり、レイアウトが崩れる可能性もあるのでいじくる場合は注意。

ちなみにMH Magazineシリーズの場合は、includes下にあるMH Magazine lite: mh-custom-functions.php内のmh-magazine-lite-*****をいじると別サイズのサムネイルに置き換えることができる。

こちらもレイアウト崩れの他に、ページサイズや転送量が増加する場合があるのでいじる場合は注意が必要。

2020/05/04

JetpackのWordpress.comアカウントの付け替え

JetpackはWordpress.comのアカウントと連携させて使うプラグインだが、その紐付けているWordpress.comアカウントを変更したい時のメモ。

Wordpressにログインしての左メニューから「Jetpack」→「ダッシュボード」
Jetpackダッシュボード画面をスクロールして下の方に「サイト接続の管理」をクリック

右下の「連携を解除」の赤ボタンをクリックすると連携が解除される。

そのまま承認してしまうと今までのアカウントに再連携してしまうので、「アカウントの切り替え」を選択する。

Wordpress.comの方のログイン画面が出てくる。
ここでWordpress.comのユーザー名→パスワードを入力してログインできればあとは画面の指示に従っていくのみ。
新規アカウントを作成とかの画面になっていたら画面の下の方にある「既存のアカウントにサイトを作成するにはログインしてください。」をクリックしてログイン画面に切り替える。

画面遷移の途中でエラーが出たら一つ上の画面からやり直す。
この時は「承認する」ボタンでOK。

サイト統計情報も無事引き継がれた。

ちなみにブラウザがchromeだと連携ボタンから先に進めなかったのでEDGEを使った。