千屋通信所-工作資料站: Web運用

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

2022/03/08

【随時追記】Blogger設定・仕様覚え書き

BloggerはGoogle運営のブログサービスで無料、広告なし、そこそこ高機能とカタログスペックだけを見れば非常に優れたブログサービスに見えます。

しかし、Blogger特有の独自仕様が非常に多いため「何でこんな仕様なの？」「これどうやるの？」といったことが少なくありません。

以下、筆者が引っかかった部分の対処方法を羅列していきます。

ちなみに、ある程度HTMLやCSSを扱えないと対処の仕方が厳しい部分が多いので、解らない方は頑張るか諦めて別のブログサービスの検討をオススメします…

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のリダイレクト技８選 | ワードプレスドクター
https://wp-doctor.jp/blog/2019/02/13/ワードプレスで使えるhtaccessのリダイレクト技８選/

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/

2022/01/05

中国聯通(チャイナユニコム China Unicom) IP範囲リスト

.htaccessの設定用メモ。

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/11/05

Let's Encryptのルート証明書変更の影響について

千屋通信所関連の以下のサイトは(このブログも含めて)バリューサーバーで配信を行っており、SSL証明書としてLet's Encryptを利用しています。

千屋通信所-旅遊情報站 (台湾現地旅行情報まとめ)
https://cytn.info/

chiyatani.net (旅行情報や旅行記ブログ)
https://chiyatani.net/

千屋通信所-工作資料平台(このブログ)
~~https://cytn.info/blog/~~
→https://cytn-blog.blogspot.com/ (Bloggerへ移行したためおそらく影響なし)

Let's EncryptにてSSL 証明書のルート証明書が変更されるため、2021/09/29より一部の環境下でLet's Encryptを利用しているサイトが閲覧できなくなるとのこと。
バリューサーバーでもお知らせが掲載されました。

無料SSL（Let's Encrypt）のルート証明書変更スケジュールについて
https://mainte.value-domain.com/eventview.cgi?host=All&no=667

影響範囲

Android7.1以前の端末(7.1.1とかは大丈夫な模様)

ちなみにiOSは10以降であれば大丈夫っぽいです。
iPhoneだと5以降になるので、まあ流石に大丈夫でしょうか。

iPadは種類が多いのでITmediaの記事を参照してください。

iOS で利用できる信頼されたルート証明書の一覧 - Apple サポート
https://support.apple.com/ja-jp/HT204132

iOS 10 で利用できる信頼されたルート証明書の一覧 - Apple サポート
https://support.apple.com/ja-jp/HT207177
※「ISRG Root X1」がリストにある

iOS 9 で利用できる信頼されたルート証明書の一覧 - Apple サポート
https://support.apple.com/ja-jp/HT205205
※「ISRG Root X1」がリストにない

「iOS 10」の対応端末と新機能まとめ - ITmedia NEWS
https://www.itmedia.co.jp/news/articles/1606/14/news072.html

影響

SSL証明書のエラーが発生するため、以下のような画面が表示され当該サイトの閲覧が不可能になる可能性があります。
(スクリーンショットはAndroid11のChromeで、SSL証明書エラーが発生するその辺に転がっている別のサイトにアクセスして撮影)

「詳細設定」から「〇〇にアクセスする(安全ではありません)」から一応アクセスは可能ではあります(セキュリティ的に推奨できる操作ではありませんが…)

また、敷居は高いですがLet's Encryptの移行先のルート証明書をインストールすることでも解決できる（かもしれません）
証明書は以下からダウンロードできます。

Chain of Trust - Let's Encrypt - フリーな SSL/TLS 証明書
https://letsencrypt.org/ja/certificates/

普通に設定画面から辿って行けば解るとは思いますが、解らない場合は以下のリンク先をご覧ください。

古いandroid端末にLet's Encryptの新しいルート証明書を手動で設定する方法 - えりぴょん
https://www.eripyon.com/mt/2020/08/how_to_install_lets_encrypt_root_certificate.html

2021/2/25追記

猶予期間が2024年初頭までまた伸びたようです…

無料SSL（Let's Encrypt）のルート証明書変更スケジュールについて [最終更新 2021/02/19 13:50]
https://ssl.sakura.ad.jp/column/letsencrypt-root-certificate/

2020/05/04

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

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

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

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

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

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

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

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

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

登録: 投稿 (Atom)

千屋通信所-工作資料站