ダミー

石造文化財のマップ用アイコン「長慶（Chokei）」

石造文化財アイコン「長慶（Chokei）」

みなさんの普段通る道に、お地蔵さまや古い道標などの石造物はありませんか？
実はあるけど、普段気にしていないから目に入らないだけかも知れません。
そんな街角の石造物を調査している団体やグループがあります。
この度、歴史と地図に特化したIT開発を手がけている Code for History さまのご依頼を請けて石造物の位置をマップ上にマーキングするアイコンを制作しました。
石仏情報学会

石造物アイコン

「石造文化財アイコン 長慶(Chokei)」としてオープンデータで公開されました！

Code for History さまによって石造文化財アイコン 長慶(Chokei)としてオープンデータで公開されています。必要な方はルールに則ってご利用ください。
https://github.com/code4history/IconForStoneAssets
プロジェクト名「長慶(Chokei)」は奈良に多くの石造物を残した奇豪、「吉村長慶」から採ったものです。

11月29日プレスリリースが発行されました

歴史と地図に特化したIT開発を手がけているCode for Historyが、石造文化財をアイコンとして表示できる「長慶（Chokei）」を11月11日に公開
https://www.value-press.com/pressrelease/308926

利用例1：令和館林石造物悉皆調査

館林には50年前の有志によって調査された、市内石造物の準悉皆調査があります。石造物の種別、年代、サイズなどだけでなく、刻銘なども判読された貴重なデータなのですが、反面、写真や正確な位置などはなく、現況との突合せは不可能な状況です。加えて、デジタル化もされておらず、統計/集計操作などもできない状況です。このまま現況との突き合わせがなされず、さらに将来になって突き合わせが困難になれば、せっかくの調査が死に体のデータとなってしまいます。そのため現況とのつきあわせ調査を行い、それをオープンデータ化するためのプロジェクトを始めました。

https://code4history.dev/TatebayashiStones/

利用例2：奈良地蔵プロジェクト

奈良市の道端の地蔵堂や小祠、石仏などをオープンデータ化するプロジェクトです。奈良市では、街角の小さな祠や石仏ですら、1300年、700年といった歴史を持ち、さらに マンションの土台にすら、地蔵の置き場が設計の上組み込まれるほど、現代にまで信仰が根付いています。都会のコンビニ以上の密度で存在する、小さく身近な信仰の場にあふれているのですが、残念ながら奈良市民には身近すぎるためかその魅力に気付いておらず、平城宮や世界遺産は宣伝しても、こういった身近な魅力を宣伝したり、外国人に説明しアピールしたり活動はありません。そこで、奈良市の祠、石仏をリストアップして紹介し、誰もが使えるオープンデータとして提供することで、新たな教育や街づくり、観光ビジネスの可能性に繋がると考え、2016年活動を開始しました。

https://code4history.dev/JizoProject/

インストールして月日がたったWordPressをメンテナンスしようとしたとき、このプラグイン何？誰が入れたの？前から入ってた？私は入れてないけど…なんてことにならないように、プリグインリストは必ず作るようにしています。

一方、レンタルサーバー各社は、「簡単インストール」「クイックインストール」などの呼称で、誰でも簡単にWordPressのインストールができるツールを準備しています。最近ではデータベースを触らなくても自動的にWordPress用にテーブルを作ってくれたりして、インストールのハードルがますます下がっていますね。それに伴い、自動的インストールされるプラグインもあります。そこで、サーバー会社のツールを使ってWordPressをインストールしたときに、自動的に入るプラグインの一覧を作りました。WordPress

さくらインターネット（調査時期：2022年8月）

  • Akismet Anti-Spam (アンチスパム)
  • All In One WP Security
  • Autoptimize
  • Classic Editor
  • Disable Google Fonts
  • Hello Dolly
  • ImageMagick エンジン
  • Protect Uploads
  • TS Webfonts for SAKURA RS
  • WP Multibyte Patch
  • WP Super Cache

けっこういろんなプラグインが入りますね。
TS Webfonts for SAKURA RSは、モリサワ社のWebフォントが使えるサービスです。さくらインターネット社がモリサワ社と契約をしていて、さくらインターネットユーザーがモリサワフォントを使えます。

GMO―ロリポップ、ヘテムル（調査時期：2022年6月）

  • Akismet Anti-Spam (アンチスパム)
  • Hello Dolly
  • WP Multibyte Patch
  • Site Kit by Google
  • SiteGuard WP Plugin

必要そうなプラグインがいい感じで選択されていますね。

X-server（調査時期：2022年10月）

  • Akismet Anti-Spam (アンチスパム)
  • Hello Dolly
  • TypeSquare Webfonts for エックスサーバー

シンプルです。余計なプラグインは何も入らないようです。
TypeSquare Webfonts for エックスサーバーは、モリサワ社のWebフォントが使えるサービスです。X-server社がモリサワ社と契約をしていて、X-serverユーザーがモリサワフォントを使えます。

まとめ

クイックインストール/簡単インストール などのツールを使ってWordPressをインストールしたときは、まずどんなプラグインが自動的にインストールされているかを確認し、そのサイトに不要であれば削除してから、必要なプラグインをインストールしましょう。

cssの@importの廃止が近づき、やっと@useに移行しようと考えてる方も多いでしょう。ここではVSCodeの拡張機能で多くの人に使われているLive Sass Compilerを使ってコンパイルします。難しいことは他のサイトに任せて、まずはごく簡単な_test.scssというscssを作ってテストしてみましょう。

.hoge{
  .red{
    color: #F00;
  }
}

これをstyle.scssに@useで読み込んでみます。@useではパーシャルscssのファイル名の「_」と、拡張子を省略します。
なので、style.scssはこんな感じです。

@use 'test';

そして保存すると、自動的にjsonで設定しておいたフォルダにstyle.cssが書き出されている…はず。

Success

「Success」も出てますよね。
確かにstyle.cssが出力されています。
早速、style.cssの内容をみてみましょう。

@use 'test';

え？ナニコレ？コンパイルされてない。こんなシンプルなscssが！？
Successって出てたのに、どうして…？
@importならコンパイルできていたのに。
調べたところ、そのPCに古いバージョンのLive Sass Compilerが入っていました。
ｖ3.0.0は@useをコンパイルできません。

現時点の最新はｖ5.4.0です。

これからLive Sass Compilerをインストールする方もご注意ください。検索で複数出てきます。

MW WP Form はウェブサイトにフォームを設置するWordPressのプラグインです。入力画面 > 確認画面 > サンクス画面 と遷移するので人気があります。Google reCAPTCHA にも対応しています。今回はこの MW WP Form を使ったお問い合わせフォームが突然画面遷移しなくなくなる不具合について解消法をご紹介します。

当記事の環境：WordPress 5.8、MW WP Form 4.4.0、WP Fastest Cache 0.9.3

現象の確認

複数の環境で確認したところ
・スマホはiPhone、Android共に問題はない
・AさんのWindows+Chromeでは正常、BさんのMac+Safariでは正常、それ以外の組み合わせで入力後確認画面に遷移しない
・テストサーバーに移設すると正常
つまり、本番サーバーでかつ特定のOS、特定のブラウザのときに不具合が起ることがわかりました。

フォームのページを WP Fastest Cacheの対象から除外する

調査を進めるうちにキャッシュが影響していると思われたので、フォームページをキャッシュから除外することにしました。当該サイトではキャッシュコントロールのプラグインとして WP Fastest Cache を使っていましたので、以下はWP Fastest Cache での方法となります。

「WP Fastest Cache の設定」の「除外する」タブから、除外するページにルールを追加します。特定のページを除外する場合は「Is Equal To」とそのページのスラッグ（例：contact など）を指定します。確認画面、サンクス画面がある場合はそれらも除外しましょう。

WP Fastest Cache

動作にばらつきがあったワケ

Webのお仕事をしていると「スマホでうまくいかない」「WindowsのIEだけうまくいかない」「Mac Safariだけうまくいかない」ということがよく起こります。
ところが、今回は不具合が起こる組合せがすぐにわからずプチパニックになりましたが、それにはちゃんとワケがあったのです。
落ち着いて WP Fastest Cache の設定を見ると以下のように
「ログインユーザーに対してキャッシュを表示しない」
「モバイルユーザーにデスクトップ版のキャッシュを表示しない」
にチェックを入れています。

例えば特定のブラウザだけ不具合が起こらなかったのは、そのブラウザでWordPressにログインした状態で送信していたから。
スマートフォンで不具合が起こらなかったのはモバイルユーザーにキャッシュを表示しない設定になっていたから。
つまり不具合が起こらなかった環境では元々キャッシュを表示しない設定だったのです。

また、設置したときに送信テストしても、その時点ではキャッシュが効いてないので問題は起こりません。

WP Fastest Cache

参照サイト

当記事では以下のサイト参照いたしました。制作者に感謝いたします。
MW WP Form FAQ

BackWPup はWordPressのバックアップを取るプラグインです。手動バックアップのほか、時間を指定して自動でのバックアップも可能です。眠っている間に自動的にバックアップがされているので便利で安心です。バックアップ毎にログ（記録）も保存されています。今回はログを調べていたときエラーを発見しました。

当記事の環境：WordPress 5.8、MW WP Form 4.4.0、BackWPup 3.10.0

BackWPup のエラー

BackWPup › ログ の画面でステータスに「1件の警告」と表示されているジョブがあります。

BackWPup

ジョブ名をクリックするとログの内容が表示されます。警告は黄色い背景で表示されます。
警告を読んでみます。
「警告: ファイル名 “.tmb/xxxxx.png” は長すぎて TarGz アーカイブへ正しく保存できません !」
実際のxxxxxは100桁を超すランダムな文字列です。拡張子はpngだから、画像かと推測できます。
それにしても、こんなディレクトリもファイルも以前は無かったし、こんな長いファイル名誰もつけないし、そして
.tmbって何！？

BackWPup

自動生成されたディレクトリ

WordPressをインストールしたディレクトリに.tmb と.quarantine という2つのディレクトリが自動的に生成されたようです。.tmbはいかにも一時ファイル的なお名前で上記のようにpngファイルがいくつか入っています。
一方.quarantineは空です。
これは何だ？何故できたのか？削除してもいいのか？
「削除してもいい」という記事を見つけ削除してみました。何も起こりません。問題なさそうです。
バックアップをしてみると正常終了しました！
.tmb（の中のファイル）がエラーの原因だったようです。
今しばらくようすを見ています。変化があれば報告します。「大きな画像をアップロードすると.tmb ができる」という記事も散見され、実際当該サイトは運営ご担当者様が大きな画像を何枚もアップロードされていました。
一般の方からすれば大きい方が画質がきれいだし、アップロードするときに何もメッセージが出なかったので、どうしてダメなの？という感じかも知れません。

BackWPup

参照サイト

当記事では以下のサイト参照いたしました。制作者に感謝いたします。
tmb gets in the way of backup

おすすめ記事