Number of Site Views Has Increased

7月17日頃から当サイト(www.monomaniacgarage.com)の閲覧回数が突然、増えています。4〜5年前はこんな感じで、一日の閲覧回数は200を超えていました。閲覧者の国別で見ると最も多いのが米国であり、次いで日本になっています。使用された検索エンジンはgoogle.comが最も多く、次にgoogle.co.jpやyahoo。

新コロ騒動が始まった2020年から閲覧回数が激減しており、その原因はCOVID-19に関わるポストが当サイトに少なからずあり、Googleの検索エンジンが当サイトを好ましくないサイトであるとして、検索結果の上位に現れないようにしているためではないかと考えていました。つまり、情報統制です。今もその考えは変わりません。

寅さん暗殺未遂事件の後、世の中の潮目が大きく変わり、寅さん返り咲きとなれば、米国は再びWHOから撤退するのではないかと推測します。寅さんはSARS-CoV-2を中国ウィルスとか武漢ウィルスと言っていた人です。まあ、オペレーション・ワープスピードなどと言いつつ、毒チン開発を加速させたことを自慢してもいましたが。

民主党はHarrisではなくRFK Jr.で挑むべき。そうなれば、世の中は本当にどんでん返しになるかも知れません。

当サイトの閲覧回数に関しては、しばらく様子を見ます。

8月2日追記: 3日ほど前から閲覧回数が急減し、7月17日以前の状態に戻りました。何だったんだろう。

X Blog Updated To 1.3.26

当ブログで使用しているテーマ、X Blogのバージョンを1.3.26に更新しました。使用フォントの種別やサイズをテーマのstyle.cssファイルの手打ちによる上書きでカスタマイズしているので、テーマを更新する度にカスタマイズした変更部分を上書きする必要があります。以下に変更部分と変更内容を備忘録として記しておきます。太字にした部分が変更部分。日本語フォントをHiragino Maru Gothic Proに指定し、フォントサイズを全体的に小さくしています。

加齢と共に物忘れが激しくなってきたので、変更すべきファイル(style.css)がどこにあるのか、記しておきます。

レンタルサーバー上のpublic_html > www.monomaniacgarage.com > wp-content > themes > x-blog > style.css

# Typography


textarea {
color: #404040;
font-family: Hiragino Maru Gothic Pro, “PT Serif”, serif;
font-size: 20px;
font-size: 18px;
font-size: 0.92rem;
line-height: 1.6;
}


h1 {
font-size: 32px;
}
h2 {
font-size: 28px;
}
p {
margin-bottom: 1.5em;
margin-top: 0;
}


blockquote,
.format-quote p {
margin: 0 1.5em 1.5em;
font-size: 15px;
border-left: 5px solid #ccc;
padding-left: 15px;
}


# Header


header.site-header {
padding-top: 20px;
}
.site-title {
font-size: 40px;
margin-bottom: 5px;
text-transform: uppercase;
line-height: 45px;
}
.site-title a {
text-shadow: 3px 4px #ccc;
color: #000;
}
.site-title a:hover {
text-decoration: none;
}
.site-branding {
text-align: center;
}
.site-description {
font-size: 16px;
margin: 14px 0;
color: #555;
}


WordPress 6.1.1 Unable To Edit Posts and Pages

以下、備忘録として、当サイトで発生したWordPressのエラーについて書き留めておきます。ポストもページも編集不可になる深刻な状態です。エラーコードをTextEditにコピーし、問題があるファイルを突き止めて、レンタルサーバーから問題あるファイル2点を削除し、WordPress 6.1.1を再インストールしました。

問題があったファイルは、

  • www.monomaniacgarage.com/wp-includes/js/dist/vendor/react-dom.min.js
  • www.monomaniacgarage.com/wp-includes/js/dist/block-editor.min.js

エラーコードのファイルは実際にはjs:以降に数字を羅列したファイルが合計、13個ありました。

追記: 問題の原因はサーバー上のファイルにあると考えていましたが、ローカルに原因があると考えを改めました。macOS Monterey 12.6.4搭載のMacBookからは編集可能です。Mac miniからは、ブラウザーをSafari以外の別のものに変更しても同じ問題が発生します。

Wishing You All A Happier Than Ever Rabbit Year!

Designed with Apple Pages ©2023 Monomaniac Garage

当サイトのドメイン、monomaniacgarage.com(1年分1,730円)を更新しました。併せてレンタルサーバー、CORE-MINIの契約(1年分2,640円)も更新しました。

現在のレンタルサーバーのディスク使用容量は5,048MBで、最大ディスク容量200GBに対して2.52%しか使っていません。

X-Blog WordPress Theme Updated

備忘録:
テーマをアップデートする度にレンタルサーバー上にあるスタイルシートが上書きされて、初期設定に戻るので、カスタマイズを毎回、やり直しています。

テーマのアップデート後にpublic_html > www.monomaniacgarage.com > wp-content > themes > x-blog > style.cssをTextEditで開き、アップデート前にダウンロードしておいたstyle.cssファイルと照らし合わせながら、カスタマイズする部分を探し、サーバー上のファイルを上書き保存。

主にカスタマイズしているのはフォント指定とフォントの大きさ。font-family: Hiragino Maru Gothic Pro, は欠かせない。

Posting Images on WordPress Blog Sites

2021年6月1日にGoogle Photosが有料化されてから、当ブログサイトでは新たに掲載する画像ファイルはWordPressを設置するレンタルサーバーにアップロードし、ポスト内に表示する方法に変更しました。以下にその手順をまとめておきます。

Photosに取り込んだ画像ファイルの中からブログポストで使用する編集済み画像ファイルにお気に入りマークを付けて、ファイルを選択し、

FileプルダウンメニューからExport > Export Photos…を選び、外付けHDDなど、適当なフォルダーに選択した画像ファイルを書き出す。この時、Location Informationのチェックを外しておくと、撮影場所を公開しなくて済む。

書き出した画像ファイルをWordPressのMediaページにアップロード。Photosからファイルを書き出す際に、JPEG QualityをHigh、SizeをLargeに設定すれば、1MB以内に容量を抑えることが可能。

Migrating From Google Photos

当ブログポストに使用する画像ファイルは、契約するレンタルサーバーのディスク使用容量を節約することを目的に、これまでFlickrやGoogle Photosにリンクを張って表示させていました。来月からGoogle Photosが有料化されるので、ブログで使用する画像ファイルは、レンタルサーバーにアップロードし、そこからWordPress内の自動リンクを張って表示する方法に変更することにしました。

レンタルサーバーも有料ですが、私が契約するプランで使用できるディスク容量がいつの間にか120GBに増えていて、現在はそのうちの1%も使用していない状況です。一枚600KBの画像ファイルであれば、198,000枚の画像ファイルをアップロードすることが可能であり、一日に5枚の600KBの画像をアップロードするとしたら、39,600日(およそ109年)分もの容量になります。私の余命どころか人の平均寿命を遥かに超えている。

iPhone 11で撮影した画像を”Large” (1280 x 960) 、JPEG “High” QualityでPhotos Appから書き出すと、生成される画像ファイルのサイズは600 KB。下の画像参照。

嶋屋本店

画像をタップすれば、1280 x 960のより大きな画像ファイルが開きますが、ブログで表示させる画質としては十分です。

There Has Been A Critical Error On Our Website

2021年3月12日、WordPress運営サイトの管理者にとって最悪の事態が発生しました。10年以上前から契約しているレンタルサーバー(CORE-MINI)のディスク使用容量を節約しようと、過去に閉鎖したサイトのデータベースとサイト設定、ドメイン設定を削除しようとしました。その際に誤って当ブログサイトのデータベースとサイト設定を削除してしまったようです。それで、表題のような危機的エラーメッセージが表示され、WordPressのDashboardにアクセスできなくなりました。

公開済みの4,330の記事とこれまでにいただいた6,442のコメント(内、2,084は私の返信コメント)が一瞬にして消えてしまったと思い、途方に暮れながら何とか復旧させようと、考えられるあらゆる手段を講じました。ローカルのファイルを消してしまったのであれば、Time Machineで復元することが可能です。24時間以内であれば1時間ごとのデータが自動的にバックアップされるように設定しているので、容易に復元できますが、レンタルサーバー上のファイルをバックアップすることはできません。

そもそもの過ちはデータベースの名称にあります。削除しようとした不要なデータベースとブログサイトの大事なデータベースの名称がいずれも、monomaniac_xとなっており、メモ欄にも区別できるような記載をしていなかったこと。そして、phpMyAdminでログインできるのはなぜか同じユーザーになり、ログインしても同じデータベースしか確認できないという事態に陥りました。

どちらのデータベースを削除しようとしているのか、わからない状態だったので、念のために両方のデータベースを削除前にバックアップしました。データベースのバックアップさえサーバーに残っていれば、復元できるはずです。

Everglades Biwako Under Construction

データベースを新規作成し、バックアップからデータを復元させました。しかし、WordPressのサイトを開こうとすると、今度はデータベース接続エラーが表示。サーバーにアップロードしてある”wp-config.php”の”DB_NAME”、”DB_USER”、”DB_PASSWORD”を正しいと思われるものに変更しました。それでもデータベース接続エラーが表示。新たにWordPressのパッケージをFTPソフト(Forklift)を使って、サーバーにアップロードし、何通りかのパターンを試行錯誤しながら”wp-config.php”入力値の変更を続けた結果、昨日、ようやくリカバリーモードでブログサイトが開きました。

Everglades Biwako Under Construction

しかしながら、この状態では過去の記事に使用した画像ファイルが適切に表示されないという問題が発生しました。原因は、”wp-content”ディレクトリです。このディレクトリには過去にレンタルサーバーにアップロードした画像ファイルやWordPressのテーマ、プラグインが入っているはずですが、中身を見ると、デフォルトのまま。幸いにも新たにWordPressのパッケージをサーバーにアップロードする前にForkliftでpublic_html以下のファイルをすべて、ローカルディスクにダウンロードしてありました。このダウンロードした”wp-content”をサーバー上のものと入れ換えることにより、ほぼ完全にサイトの復旧ができました。

WordPressのDashboardにアクセスできるようになったものの、10年以上も前から使い続けているテーマ、Suffusionのスタイルシートを紛失したようで、カスタマイズし放題のSuffusionが走らない。何分、古いテーマなので、Suffusionの新しいパッケージは入手不可。結局、新しいテーマ、”X BLOG”をインストールして、Theme Editorでstyle.cssを編集して、Suffusion風のレイアウトとデザインになるように自分でカスタマイズしました。

Everglades Biwako Under Construction

ここで注意事項が一つ。この新しいテーマ、”X BLOG”は無料版の場合、Dashboardに誠に目障りな広告が多数、表示されます。自前レンタルサーバーにアップロードしたWordPressのダッシュボードに広告はないだろう。何時間もかけて編集したスタイルシートを無駄にはしたくないので、広告表示をブロックするプラグインはないか、探すとありました。”Disable Admin Notices Individually”という長い名称のプラグイン。これを使うと、表示された広告を一瞬にして消すことができます。

CORE-MINI

当ブログのレンタルサーバーとして10年以上も前から使用しているCORESERVERの最安プラン、CORE-MINIの仕様が変更になっていることに気づいたので以下にその基本仕様をまとめておきます。私が関心があるのはサーバーの容量ですが、CORE-MINIは価格据え置きで30GB > 60GB > 120GBと倍増しています。CORESERVERの詳しい機能はこちら

プラン名(V1プラン)CORE-MINI(V1プラン)CORE-A(V2プラン)CORE-X
初期費用無料無料1,500円
月額料金(12ヶ月契約)約198円/月約397円/月480円/月
Web、メール、DB容量120GB240GB300GB
ファイル上限数300,000600,0001,000,000
転送量上限(月)無制限無制限
転送量目安(月)10TB
許容負荷率125%250%

既存ドメインが永久無料となるV2プランのCORE-Xも比較対象とします。永久無料とは言ってもCORE-MINIとの価格差は12ヶ月契約で年間3,384円もあり、ドメイン年間維持費1,430円を考慮すると、いつまで経っても元は取れない計算になります。

2021年6月1日からGoogle Photosが有料化されます。これまでにアップロードした既存画像/動画ファイルは、無料のGoogleアカウントストレージ、15GBにはカウントされないので、過去のファイルが消えることはありません。(flickrでは有料化時に1,000枚を超える画像ファイルが削除されました。)Google Oneからストレージを購入することもできますが、100GBで¥250/月と高額です。これならレンタルサーバー代込みで120GBが¥198/月で運用できるCORE-MINIの方がお得です。

Google Photos Storage

Starting June 1, 2021, all new photos and videos backed up in High quality will count toward the free 15 GB of storage that comes with your Google Account or any additional storage you may have purchased, the same way other Google services like Google Drive and Gmail already do.

“Important update about Google Photos storage”を表題としたメールがGoogleから届きました。今朝、minority318さんからiMessageで情報を得ていたので、察しはつきます。アップロードする画像ファイルを「高品質」に設定していれば、容量無制限で使え、当ブログサイトにも直接リンクを張ることが可能でした。この方針を変更し、2021年6月1日から「高品質」でアップロードできる画像と動画ファイルは一つのGoogle無料アカウントに付き、上限が15GBになるとの知らせです。

All photos and videos you back up in High quality before June 1, 2021 are exempt from this change and will not count toward your Google Account storage. This includes all of your existing content uploaded in High quality.

救いなのは2021年6月1日までに高品質でアップロードした画像と動画に関しては、15GBのキャップに対してカウントされないということです。

Flickrが1,000枚以上の画像アップロードを有料化した時は、それまでにアップロードした、1,000枚を超える過去の画像ファイルが消されることになったので、ブログ記事内に埋め込んだリンクを張り替える作業に追われました。今回はその必要はなさそうですが、来年6月までに埋め込み用URLが生成できる新たな画像保管場所を見つけなければなりません。あるいは画像中心のブログをやめるか。

Safari and Google Photos

8月26日追記:
SafariでGoogle Photosのアルバムページが開かなくなったのは、MacOS Bir Sur 11.0 Beta 5のバグだろうと考えていましたが、本日、確認すると問題なくアルバムページが開きました。どうやらGoogle側の障害だったようです。

MacOS Big Sur 11.0 Beta 5 (Public Beta 2?)をMac mini (2018)にインストールしてから、SafariでGoogle Photosのアルバムページが開かなくなりました。Safariが関係する何らかのバグだと思われますが、この状況では少なくとも次のアップデートまで画像入りのブログポストを書くことができないので、Google Chromeを使った回避策を考えました。

  1. Photos Appに読み込んで編集した画像ファイルをGoogle Photosにアップロードできるよう準備する。
  2. SafariでGoogle Photosのホームページ(”Photos”)を開く。
  3. 準備した画像ファイルをPhotos Appで選び、Safariで開いたGoogle PhotosのホームページにDrag & Dropでアップロードする。
  4. Google Photosホームページ内でアップロードした画像ファイルを選び、+ボタンをクリックして目的とする共有アルバムに追加する。私の場合、目的とする共有アルバムの名称は”For Blog Posts 2020″。
  5. Google Chromeで共有アルバムのページを開き、埋め込む画像を選んでクリック。
  6. Google Chromeで画像ファイルのURLをコピーし、Safariで立ち上げたEmbed Google PhotosのImage URLにペーストして埋め込み用コードを生成する。
  7. ブログポスト内で生成したコードを挿入する。

かなり、面倒な手順を実行する必要がありますが、上の画像はこの手順を実行してGoogle Photosへのリンクを張ったものです。画像上をクリックするとオリジナルサイズの画像を閲覧することができます。

Embed Google Photos (Bryan)

ブログ投稿時にしばらく使っていたBYTENBIT Embed Google Photos Into Websiteで障害が発生したらしく、埋め込み用のURLコードを生成できなくなりました。(現在は復旧しているようです。)そこで、急遽、同様のURLコードを生成してくれるプログラムを公開されているサイトを探したら見つかりました。サイトの名称は、タイトルのEmbed Google Photos (Bryan)。以下にこれまでに使用したサイトの特徴をまとめた後、Embed Google Photos (Bryan) の使い方を説明します。

Embed Google Photos (Digital Inspiration)
URLコードを生成するには毎回、”I’m not a robot”を証明しなければならなくなり、複数のコードを生成するのが非実用的になった。

BYTENBIT Embed Google Photos Into Website
障害から復旧したが、生成したコードをブログポスト内に埋め込んでリンクを張っても、ポスト内の画像と同じ大きさの画像が新しいページに表示される。これではリンクを張る意味がない。(これを理由にこれまで、リンクを張っていなかった。)

Embed Google Photos (Bryan)
Drag & Dropでリンクを生成でき、コード生成前にリサイズが可能。また、複数の画像ファイルへのリンクを一度に生成することができる。

上のスクリーンキャプチャーのようにポストを書く時にSafariで3つのウィンドウを開きます。左上:Google Photosの共有アルバム(サムネール表示画面)、左下:Embed Google Photos (Bryan)、右:WordPressポスト編集画面。

左上のサムネール画像を左下のEmbeddable URL:にDrag & Dropして、URL右の四角いボタンをクリックすると、URLがクリップボードにコピーされます。

画像を埋め込んだ後に、WordPressのリンクボタンをクリックして生成したURLをペーストすれば、リンク先の新しいページには大きな画像が表示されます。コード生成前にリサイズしていない場合、埋め込んだ画像の表示サイズはWordPress側で幅を指定する必要があります。

WPvivid Backup Plugin

当サイトのバックアップ用プラグインを新調しました。以前はレンタルサーバーのダッシュボード(コントロールパネル)からデータベースのバックアップをしていたこともありますが、決して利便性が良いとは言えず、最近ではレンタルサーバーにアクセスするのは契約更新時ぐらいになっていました。

今回、導入したバックアップ用プラグインは非常にわかりやすく、初期設定のまま、”Database + Files”と”Save Backups to Local”を選び、マニュアルバックアップしたら、すぐにレンタルサーバーの…wp-content/wpvividbackupsに合計容量264.92MBのバックアップファイルが生成されました。サイズが大きな画像ファイルや動画ファイルはGoogle PhotosやYouTubeにアップロードし、リンクを張ってサイトに表示させているだけなので、たったこれだけの容量で済んでいるのでしょう。

その後、サーバーからバックアップファイルをローカルディスクにダウンロードしたら、Downloadsフォルダーに”www”と”www-2″の二つのフォルダーが入りました。この時点でサーバーにある容量264.92MBのバックアップファイルはWordPressダッシュボードのWPvivid Backup Pluginの画面から削除できます。

問題が発生したサイトを復元するにはこれら二つのフォルダーをアップロードすれば良い。レンタルサーバーを移転する際も簡単にできそうです。

PHP Version Updated To 73

当ブログサイトがあるレンタルサーバーのPHPバージョンを71から73にアップデートしました。きっかけは使用していないプラグイン、”Simple Lightbox”を最新バージョンの2.8.0にアップデートできなかったことです。サーバーのPHPバージョンをアップデートすれば、サイトの表示スピードが改善されるそうです。