初めてのJavaScript 読書中です

こんにちは、石川さんです。

最近、思うところがあって、JavaScriptの勉強を始めました。今読んでいるのは、そう「初めてのJavaScript 第3版」です。Angularを使い始めたので本来はTypeScriptの勉強、と言いたいところですが、一冊本を読んで、先にJavaScriptだな、という気持ちになったのでした。

いや~、JavaScript、思っていたよりも、色々とできるのですねぇ。テンプレートリテラルとか、クロージャとか、完全にPythonだけのものだと思っていたのですけど、いや、視野が狭かったですね!反省しました。

せっかく勉強しているので、色々と披露したいよねぇ、という気持ちになってきたところで気になりました。そういえばWordPressのこのページ、JavaScriptを使用できるのでしょうか。先日調べたところ、ブロックを選択すればできる、ということがどこかに書かれていましたので、ちょっと試してみましょう。

ブロックの追加

まずは、ブロックを追加します。「カスタムHTML」が選べるので、こちらを選択します。

「ブロックを追加」から「カスタムHTML」を選択

すると、以下のように「HTMLを入力…」となりますので、ここへスクリプトを記載して行きます。「プレビュー」を押すと実行結果のプレビューが表示されます。

HTMLを入力

入力して保存したところ、簡単にできました!

【1つ目】

【2つ目】

できましたね!

簡単でした♪

今回入力したスクリプトは以下の通りです。

まずは【1つ目】です。ほぼこちらのスクリプトをコピペしたものです。Konva.jsという、HTML5 2d canvasのためのJavascriptライブラリを紹介しているホームページです。
HTML要素のidがページ全体にかかわってくるので、idは、container20230303_1に変更しました。(すみません、後で気づきました。調子にのって、他の記事でもcontainerを使ったところ、一覧で見たときにかぶって変なことになってしまいました。。。)

次に【2つ目】のスクリプトです。

<style>
div#container20230303_2 {
  height: 200px;
  width: 116%;
  background-color: ivory;
}
</style>
<div id="container20230303_2"></div>
<script src="https://unpkg.com/konva@8/konva.min.js"></script>
<script>
var height = 200;
var width = window.innerWidth;
      var resourceColor = 'rgb(185, 247, 247)';
      var eventColor = 'rgb(245, 200, 247)';
      var stage = new Konva.Stage({container: 'container20230303_2', width: width, height: height, draggable:true});
      stage.on('contextmenu', function (e) {
        e.evt.preventDefault();
      });
      var layer = new Konva.Layer();
      stage.add(layer);
      function newBox(title, type) {
        return new Konva.Rect({
          cornerRadius: 10,
          fill: type === "resource" ? resourceColor : eventColor,
          stroke: 'black',
          strokeWidth: 1,
          name: 'rect',
          draggable: true,
          sceneFunc: function (context, shape) {
            shape._sceneFunc(context);
            context.beginPath();
            context.moveTo(0,20);
            context.lineTo(shape.getAttr('width'),20);
            context.moveTo(shape.getAttr('width')/2,20);
            context.lineTo(shape.getAttr('width')/2,shape.getAttr('height'));
            context.stroke();
            context.closePath();
            context.font = '12px sans-serif';
            context.fillStyle = "rgb(0, 0, 0)"
            context.fillText(title,25,17);
          }
        });
      };
      var rect1 = newBox("リソース", "resource");
      rect1.setAttrs({x: 60, y: 60, width: 100, height: 90});
      layer.add(rect1);
      var rect2 = newBox("イベント", "event");
      rect2.setAttrs({x: 260, y: 60, width: 100, height: 90});
      layer.add(rect2);
rect2.on('click', (event) => {console.log('clicked!', event);});
</script>

簡単に色々なことができるので、夢が広がりますね!

WordPressファイルアップロードサイズを拡張しました

 今日もに見来てくださって、ありがとうございます。石川さんです。

 先日MX ERGOの画像をアップしようとして、あることに気づきました。そう、なぜかファイルのアップロードサイズ上限が2MBytesに変更されていたのでした。

 そういえば、先日アップロードしたドラッグアンドドロップの短めの動画も、アップロードサイズ上限に引っかかっていました。その時は、動画だからちょっとサイズが大きいのかな、ということで、外部のサービスを使って圧縮しまくって2MBytes以下にしたのでした。上限が変更されたのかも、とはまったく思いもよりませんでした。

 ところが今回は、画像です。これまで画像をアップするときには特に上限を超えたエラーなんて、出たことなかったのですよね。それで以前アップした画像のサイズを調べてみたところ、2MBytesなんて、ぶっちぎってました。同じカメラで撮ったやつです。それで、どうして急に上限を超え始めたのかなぁ、と、考えていて、ふと、思いつきました。そういえば、先日PHPのバージョンアップして、そのせいで、初期値が変わってしまったのでは。確かに、php.iniの設定の上限のせいでアップロードできません、というメッセージもでていました。

 そこで、サーバーにログインして、php.iniを探してみました。

~$ sudo find / -name php.ini -print
/etc/php/7.3/fpm/php.ini
/etc/php/7.3/cli/php.ini
/etc/php/7.3/cgi/php.ini
/etc/php/7.3/apache2/php.ini
/etc/php/7.0/fpm/php.ini
/etc/php/7.0/cli/php.ini
/etc/php/7.0/cgi/php.ini
/etc/php/7.0/apache2/php.ini
/etc/php/7.4/fpm/php.ini
/etc/php/7.4/cli/php.ini
/etc/php/7.4/cgi/php.ini
/etc/php/7.4/apache2/php.ini

 ほら、やっぱりphp.iniがバージョンごとにたくさんありますね。php.iniファイルの中身を調べて、ファイルサイズはupload_max_filesizeらしいというところまで調査。でも、ファイルがいくつかあるので、どのファイルを修正すればよいか、ちょっとわかりません。なのでもうちょっと調べてみましょう。ディレクトリを移動します。

~$ cd /etc/php

 次に、grepコマンドでそれぞれの値を調べてみました。

/etc/php$ grep upload_max_filesize */*/php.ini
7.0/apache2/php.ini:upload_max_filesize = 100M
7.0/cgi/php.ini:upload_max_filesize = 2M
7.0/cli/php.ini:upload_max_filesize = 2M
7.0/fpm/php.ini:upload_max_filesize = 2M
7.3/apache2/php.ini:upload_max_filesize = 2M
7.3/cgi/php.ini:upload_max_filesize = 2M
7.3/cli/php.ini:upload_max_filesize = 2M
7.3/fpm/php.ini:upload_max_filesize = 2M
7.4/apache2/php.ini:upload_max_filesize = 2M
7.4/cgi/php.ini:upload_max_filesize = 2M
7.4/cli/php.ini:upload_max_filesize = 2M
7.4/fpm/php.ini:upload_max_filesize = 2M

 おお、やはり7.0を利用していた時は、100Mバイトだったようです。なので、apache2ディレクトリにあるphp.iniファイルを修正してみましょう。以下のコマンドです。今回は、viエディタを使用して、8Mバイトに修正しました。さすがに100Mバイトは大きすぎですよね。

/etc/php$ sudo vi 7.4/apache2/php.ini

 これだけで完了、と言いたいところでしたが、まだ修正した値が反映されませんでした。先日バージョンアップしたときに確認していました。サーバプロセスの再起動が必要ですね。以下のコマンドを実行しました。

sudo systemctl restart apache2

 はい、ちゃんと上限が修正されました。

8MBにかわりました。

 運用していると、思ってもいないところで、いろいろありますねぇ♪

新型コロナウィルスの影響か!?

 今日も見に来てくださって、ありがとうございます。石川さんです。

 このサイト、誰かの役に立つかどうかもわからないと思いつつ、更新してきました。いちおう、コンセプトとしては、日々の業務で発生することとか、気づいたこととか、気になるトピックを調べて共有する、という風に考えています。誰かの役に立つ記事を書けば、見に来る人が多くなるでしょう、という想定の下、どれくらいのひとが見に来てくれているのかなぁ、というのは気になるところです。なので、よくわからないなりにGoogle Analyticsでサイト訪問の情報を収集していました。

 今週は、何人くらい見に来てくれたのかなぁ、と、何気なくGoogle Analyticsを開いてみたところ、何やら新記録を達成していました。

4月の新記録

 実は、毎月新記録を出していたのですけど、4月は1000人近くということでビックリしたので記事にしてみました。数値的には、以下の感じです。

 1月は64人、2月は122人、3月は485人、4月は993人、という感じで、人数の伸びかたが指数関数的に伸びています。きっと新型コロナウィルスの影響で増えたのでしょう。

 でも、少しは、誰かの役に立っているのでしょうね。と、思いたい。(笑)

PHPのバージョンアップその2

 今日も見に来てくださって、ありがとうございます。石川さんです。

 そうそう、昨日のPHPのバージョンアップ、やっぱりうまくいっていないよねぇ、と、いろいろ調べましたので、記録しておきます。

 いや~、ひどい目にあいましたよ~!

 慌てていろいろやったので、記憶に残っている限りで原因はこれかなぁ、という感じですが、ご参考になれば幸いです。

 最初に、google-fluentdがエラーを出していたのが原因なのかなぁ、と、思ってこちらを調べてみました。こちら、ログを出力するためのサービスだそうです。Googleさまがトラブルシューティングをここに書いておいてくれていました。Google Cloud MarketPlaceからのイメージを使っている場合は、Loggingエージェントが無効になっていて、そのためにエラーが出ているということがわかりました。そうそう、このWordPressのサイトを立ち上げるときに、MarketPlaceからイメージを利用させていただきまして、あっという間に構築したのでした。それで、このLoggingエージェントを有効にする方法もここに記載してくれてあったので、そのとおりに実行するとエラーが出なくなりました。
 が、、、PHPのバージョンは依然として変化ありませんでした。

 PHPのバージョン、7.0.33がまだ動作していると言われているのは、このバージョンのPHPが残っているからだよねぇ、と思ったので、思い切ってアンインストールすることにしました。なんでそんなに思い切っちゃいましたかねぇ。そうそう、こんなコマンドでした。

$ sudo apt-get remove php7.0 php7.0-cli

 そうすると、もう使わなくなったものは、このコマンドで削除できますよ~、と、言ってきたので、調子に乗って、実行してみました。

$ sudo apt autoremove

 そして、ヘルスチェックはこれでどうなったかしらと見に行ったところ、PHPのスクリプトがそのまま出力されてきました。そう、どのページに行っても、全部スクリプトなのです。動かなくなったけど、一歩前進ですね。ちょっぴり後退したようにも思えますが、やったことが影響あったということで、前進したと思いましょう。
 これは、いままで動いていたモジュールがなくなったのが原因でした。ただ最初は原因がわからないので、あちこち調べて、バージョンアップしたり、設定ファイルをいじったり、いろいろとウロウロしてしまいました。

 最終的に、効果があったのは、以下のコマンドだと思います。

$ sudo apt-get install libapache2-mod-php --reinstall   # ←これは必要なかったかも知れない
$ sudo a2enmod php7.4
$ sudo systemctl restart apache2

 最初は、単に.phpのファイルが認識できていなくて、phpが実行できないから、その設定をすればいいのかな、と考えていて、ずっとそっちの路線で調べていたのでした。この「a2enmod」というコマンド、今回初めて発見しました。どうやらapache2のモジュールを有効化するコマンドということだそうです。インストールしたけど、有効になっていなかった、というのが原因だったということなのね。

 ということで、サイトヘルス、良好になりました。

 ふ~、まだまだ知らないことがたくさんあるなぁ、と、思い知らされた事件でした。いやー、バックアップ取って実行していたから、いろいろと思い切ってやることができました。クラウドのサービス、すばらしいですね!
 ということで、これからも精進いたします。

 しばらくたって落ち着いてきたので、PHPのプロセスを確認してみると、php-fpmは7.3が動いているようでした。

$ ps ax | grep php
26168 ?        Ss     0:00 php-fpm: master process (/etc/php/7.3/fpm/php-fpm.conf)
26169 ?        S      0:00 php-fpm: pool www
26170 ?        S      0:00 php-fpm: pool www
29794 pts/0    S+     0:00 grep php
$ 

 他のは7.4になっていたので、これもバージョンアップしておこうと、以下のコマンドを実行しました。

$ sudo a2enconf php7.4-fpm

 よく見ると、上記コマンド実行時のログにこんな風に出力されていました。

NOTICE: Not enabling PHP 7.4 FPM by default.
NOTICE: To enable PHP 7.4 FPM in Apache2 do:
NOTICE: a2enmod proxy_fcgi setenvif
NOTICE: a2enconf php7.4-fpm
NOTICE: You are seeing this message because you have apache2 package installed.

 はい、ちゃんと、書いてあったのですねぇ。まだデフォルトで使えるようになってないですよ。使えるようにするには、コマンド実行してね、って。

そして、a2enconf php7.4-fpmを実行したら、次にやることがちゃんと出ていました。

Enabling conf php7.4-fpm.
To activate the new configuration, you need to run:
  systemctl reload apache2

apache2をリロードして完了です。もしかしたら、昨日のコマンド実行時にもNOTICEが出ていたのかもしれないなぁ、ということで、ログをちゃんと見てれば回避できたかもしれないトラブルでしたね。

PHPのバージョンアップ

 今日も見に来てくださってありがとうございます。石川さんです。

 このサイト、WordPressで作られています。管理画面にダッシュボードというのがあるのですけど、使っているプラグインやテーマが古くなると、更新してください、と教えてくれる優れものです。先日も更新してください、と言われましたので、しゅるっと更新しました。更新についても何か書こうと思いましたが、簡単すぎて記憶に残っていません。

 更新後、ダッシュボードを見ていて、ふと、気づきましたが、何やら問題がありそうです。

サイトヘルスステータスに「改善が必要」と出てきました。

 まったく意味が分かりませんが、5項目ほど改善が必要な項目があるそうです。見てみましょう。左下の「サイトヘルス画面」をクリックしてみます。

サイトヘルス画面

 なんと、WordPressさん、こんな機能まであるのですね!すばらしい。おすすめの改善はいいとしても、致命的な問題は捨て置けませんね。ということで、サイトのPHPのバージョンアップ、したいと思います。

 しかし、どうやるのでしょうかねぇ。ぼくのサイト、GoogleさまのGoogle Cloud Platform (GCP)のCompute Engineというサービスを利用していまして、もう一年以上前にセットアップしたので記憶が、、、薄いなぁ。確か、MarketPlaceに用意されていたWordPress用のイメージをVMのインスタンスとしてDeploy、みたいな感じだったような。当時よくわからず、セットアップしたら、Googleさまの方で勝手に最新版に更新してくれるなんてすごいよねぇ、と、勘違いしておりました。いや、自分でやんなきゃね。

 ということで、手順は以下の通り進めていきましょう。

  • まず、自分の使っているサーバーのOSを調べる。わからなければ調べ方を調べる。
  • そのOSのPHPの更新方法を調べる。
  • 更新する前にバックアップを取得。そのためにバックアップの取り方を調べる。
  • PHPを最新版にアップデートする。
  • 動作確認。正常に動作していれば、バックアップを削除して完了。
  • 正常に動作していなければ、バックアップを戻して、ふりだしに戻る。

 と、いう感じでしょうか。計画通りにうまく行くといいのですけど。

サーバーOSの確認~バックアップ

 とりあえず、GCPのダッシュボードを見てみましょう。そこからCOMPUTE ENGINEに移動して、このサイト用のVMインスタンスの情報を見てみます。ええと、OSのバージョンは特に記載されていませんでしたね。と、いうことでSSHを使ってログインしましょう。Linuxマシンですので、バージョン確認方法をGoogle先生に教えてもらいましょう。このサイトが出てきました。最初に三つのやり方が示されていましたので、簡単に一つ目を実行してみました。

prompt $ cat /etc/os-release 
PRETTY_NAME="Debian GNU/Linux 9 (stretch)"
NAME="Debian GNU/Linux"
VERSION_ID="9"
VERSION="9 (stretch)"
ID=debian
HOME_URL="https://www.debian.org/"
SUPPORT_URL="https://www.debian.org/support"
BUG_REPORT_URL="https://bugs.debian.org/"
prompt $ 

 OSは、Debian 9ということですね。
 そして、次はPHPのバージョンアップですが、今のバージョンを調べるコマンドは、php -vということですので実行してみます。

prompt $ php -v
PHP 7.0.33-0+deb9u7 (cli) (built: Feb 16 2020 15:11:40) ( NTS )
Copyright (c) 1997-2017 The PHP Group
Zend Engine v3.0.0, Copyright (c) 1998-2017 Zend Technologies
    with Zend OPcache v7.0.33-0+deb9u7, Copyright (c) 1999-2017, by Zend Technologies
prompt $ 

 PHPのバージョンは、7.0.33-0+deb9u7ということだそうです。アップグレードの前にバックアップを取ろう。Google Cloud Platformは、スナップショットという機能で、バックアップできるようです。Compute Engineでスナップショットを選択して、スナップショットの作成をクリックします。

スナップショットの作成

 ソースディスクにWordPressのVMを選択して、作成クリックすれば簡単にできそうですね。ソースディスクを選ぶとソースディスクのロケーションに基づいて、勝手にロケーションが決まりました。たくさん管理している人は、ラベルを追加するようですが、ぼくはこのサイトだけしか管理していないので、そのままで「作成」をクリックします。しばらく時間がかかって、スナップショットが出来上がりました。スナップショットはバックアップ目的で、スケジューリングして定期的に実行することが推奨されているようですね。初めて知りました。最新の状態が残っていれば大丈夫、と、思っていたので深く調べてはいなかったのですが、基幹システムを運用する場合などは、必須ですね。

 1~2分ほどでしょうか、文章を書いているうちに30GBytesのバックアップ終了しました。さすがGCP、早いですねぇ!

PHPのバージョンアップ

 このページを参考に、バージョンアップを実行していきます。SSHで接続して、以下のコマンドを順番に実行していきます。

For Debian:

$ sudo apt install apt-transport-https lsb-release

$ sudo wget -O /etc/apt/trusted.gpg.d/php.gpg https://packages.sury.org/php/apt.gpg # Download the signing key

$ sudo sh -c 'echo "deb https://packages.sury.org/php/ $(lsb_release -sc) main" > /etc/apt/sources.list.d/php.list' # Add Ondrej's repo to sources list.

$ sudo apt update

$ sudo apt-get install php7.3

はい、無事にバージョンが変更されました。

$ php -v
PHP 7.3.16-1+0~20200320.56+debian9~1.gbp370a75 (cli) (built: Mar 20 2020 14:36:13) ( NTS )
Copyright (c) 1997-2018 The PHP Group
Zend Engine v3.3.16, Copyright (c) 1998-2018 Zend Technologies
    with Zend OPcache v7.3.16-1+0~20200320.56+debian9~1.gbp370a75, Copyright (c) 1999-2018, by Zend Technologies

 しかし、WordPressのヘルスチェックでは、まだバージョンが更新されていませんね。再起動すれば、更新されるかな。GCPのコンソール画面からリセットを実行してみます。

  おお、リセットを押したら、警告メッセージが!

 なんと恐ろしいメッセージでしょう。「停止」の方がいいのかな。キャンセルして「停止」してみます。

 恐ろしさはあんまり変わりませんねぇ。ま、仕方ありませんね。停止して、開始しましょう。無事に停止できましたので、起動しました。起動時には以下のようなメッセージが表示されます。いったい料金はいくら請求されるのでしょうか。ビビります。

 さて、ヘルスチェックは、、、あらら、変わってませんね。いや、よく見ると違います。

 コマンドを調べてみると、どうやらphp-cgiのバージョンのようです。

prompt $ php-cgi -v
PHP 7.0.33-26+0~20200320.33+debian9~1.gbp746b8e (cgi-fcgi) (built: Mar 20 2020 14:33:44)
Copyright (c) 1997-2017 The PHP Group
Zend Engine v3.0.0, Copyright (c) 1998-2017 Zend Technologies
    with Zend OPcache v7.0.33-26+0~20200320.33+debian9~1.gbp746b8e, Copyright (c) 1999-2017, by Zend Technologies
prompt $ 

 と、いうことで今度はこのページを参考にしてアップデートを実行してみます。ちょっと長いですが、以下の通り実行しました。

sudo apt-get install php7.3 php7.3-cli php7.3-cgi php7.3-fpm php7.3-gd php7.3-mysql php7.3-imap php7.3-curl php7.3-intl php7.3-pspell php7.3-recode php7.3-sqlite3 php7.3-tidy php7.3-xmlrpc php7.3-xsl php7.3-zip php7.3-mbstring php7.3-soap php7.3-opcache php7.3-common php7.3-json php7.3-readline php7.3-xml

 すでにインストールされているものはスキップしてインストールできたようです。google-fluentdでエラーが起きたと言っていますが、まあ、よいでしょう。

prompt $ php-cgi -v
PHP 7.3.16-1+0~20200320.56+debian9~1.gbp370a75 (cgi-fcgi) (built: Mar 20 2020 14:36:13)
Copyright (c) 1997-2018 The PHP Group
Zend Engine v3.3.16, Copyright (c) 1998-2018 Zend Technologies
    with Zend OPcache v7.3.16-1+0~20200320.56+debian9~1.gbp370a75, Copyright (c) 1999-2018, by Zend Technologies
prompt $ 

 バージョン上がりました!しかし、ヘルスチェックのバージョンは変わっておりません。再起動しましょうかねぇ。

 と、いうことで再起動しましたが、状況が変わりません。ログを見ていると、google-fluentdというサービスかプロセスがエラーを出力していましたので、その関係でしょうか。とりあえず、今日は力尽きました。やっぱりサーバーのセットアップとかは、苦手分野だなぁ。誰か知ってる人、教えてくださーい!

WordPress予約公開の仕方

 今日も見に来てくださって、ありがとうございます。

 ブログの文章、何度も書いていると、少しずつですが、だんだんと文章を早くなってきた気がします。やっぱり継続は大事ですね。ずっと書くのが苦手だったのですよね。ずいぶん前にたまたま余裕があって一日に記事を二つ書いたことがあったのですけど、下書きのままにしておいて、翌日公開するというのもとてもおっくうなので、その時はすぐに公開しちゃいました。何日分も前もって書いておくのはぼくにはムリだなぁ、と、思っていましたのです。

 でもそれが、簡単に予約しておくことができることがわかりました。そんな機能があるとは夢にも思っていなかったので、昨日まで知らなかったのでした。

 そう、いつもは、記事を書き終わったら、編集画面の右上にあるボタンの「公開する」を押して、公開していました。そう、このボタンです。

「公開する」ボタン

 書いている途中で中断する時は、「下書きとして保存」 を、途中で仕上がりを確認するときには、「プレビュー」を押して確認する、それくらいしか使ってなかったのですよねぇ。

 とりあえず、「公開する」を押してみます。すると、次のように「公開してもよいですか?」と、聞いてきます。

「公開する」ボタンを押したところ

 で、いつもは、この「公開:今すぐ」のところをクリックして、カレンダーが出てくるので、時刻だけ00:00に修正してました。日にちは確認したことがなかったのでした。いつも過去の日付が出てくるので、このカレンダーは作ったタイミングで決まるのかなぁ、というくらいには思っていたのですけど。で、時刻を修正すると、過去の日付の00:00に設定されることになるので、今すぐに公開されるのですよね。当たり前ですよね。

いつも変更するのは時刻だけでした

 昨日は、なぜか日にちも変えてみよう、って、思って変更したのですよね。ちょっとやってみます。未来の日付、3月24日を選択しました。

「予約投稿」になった!

 すると、ごらんください!「公開」ボタンだったところが、なんと「予約投稿」に替わったのです。いや~、予約投稿なんてできたのですね!しかも、こんなに簡単に♪
 偶然とは言え、自分の知らない機能を発見して、ちょっとうれしい今日この頃です。この記事はこのままにして今日の夜に公開します!
 どんどん書いて、どんどん予約投稿、、、できるといいなぁ。(笑)

追記

 …と、いうことで、朝起きて確認してみましたが、なんと、まだ公開されていません。そういえば何となく気になっていました。日付と時刻、なんかずれてるような気がしてたのですよねぇ。試しに新規追加して作成された日時を確認してみます。

 おお、現在2020年3月24日の6時48分なのに、23日の12時48分の日時で作成されてしまいました。これは、、、完全にずれてますね。

 設定を確認してみたところ、ありました。「タイムゾーン」ですね。

タイムゾーンの設定

 同じタイムゾーンの都市またはUTC、、、ということで、ありました「アジア」から「東京」が選べるようです。選択して保存しました。再度、この文章を保存、あ、ボタンは「予約投稿」になってますが、、、これでどうでしょう。。。

予約投稿の失敗

 ははは、予約投稿の失敗だそうです。まあ、予約してた時間よりタイムゾーンが早くなりましたので、そりゃそうか、という感じで仕方ありませんね。でも、失敗もちゃんと考慮されてあって、WordPressってすごいですね!

 気を取り直してこの後の7時10分に予約投稿してみます。今度はどうかな。はい、今度はちゃんと予約済みになっていました!

 そして、無事、公開されてますね。ホッ。

WordPressリンク切れの原因

 今日も見に来てくださって、ありがとうございます。桜の花が咲き始めましたね。

今日は、WordPressの話題です。WordPressを使い始めたころ、「石川さん、リンクが切れてますよ」と、リンク切れを教えてもらいました。フツーに文章を書いて、そのまま公開すると、そんなことが起きます。この文章もおそらくそうなると思いますので、ちょっと途中ですが、この状態で公開してみます。

 投稿の編集画面の右上の「公開する」ボタンを押すと、「公開しました。」というメッセージが出てきますので、「投稿を表示」をクリックします。

はい、でました。こんな感じです。

 サイトのトップページに行くと、記事はちゃんと見えているので、しばらく謎だったのですよね。いろいろと調べてみてわかった原因は、これでした。

URLをご覧ください。日本語になっています。

 ここのURLに日本語(マルチバイト文字)がセットされるとなぜか表示されない、ということがわかりました。どこでこれを修正するかというと、こちらです。(他に、投稿一覧から「クイック編集」を選択して「URLスラッグ」を修正することもできます。

文書-パーマリンクーURLスラッグ

ここを英数字と半角記号だけに修正すれば、正しくリンクをたどっていくことができるようになります。修正すると「投稿を表示」のURLが変更されて、正しく修正されたことを確認できます。では、修正してみましょう。

wordpressーcause-of-missing-linkに修正

 さて、どうでしょうか。うまくいくと思いますか?「更新」ボタンを押してから「投稿を表示」の部分をクリックしてみます。

またしても、失敗!今度は、なぜ?

 ぼくは、これでずいぶんと悩みました。と言っても30分くらいですけど。他のはこれでうまいこといったのに、どうしてできないのでしょうか。。。

 正解は、ハイフンが半角英数字のハイフンではなくて、マルチバイト文字になっていたからでした。ここの「wordpressーcause-of-missing-link」ひとつめのハイフンと、ふたつめからよっつめのハイフンとは、微妙に長さが違いますよね。わかりますか?

 そう、自分で入力したのですけど、日本語を削除してアルファベットを入力するときに、ひとつめだけハイフンの代わりに半角カタカナの長音の記号を入れてしまっていた、ということが原因でした。フォントが違えばすぐにわかるのでしょうけど、ブラウザだとほとんどわかりませんね。誰かのお役にたてるとうれしいです。

WordPressでMarkdownを使うには

International Arrivals

 今日も見に来てくださって、ありがとうございます。今日は、Markdownについてです。

 先日Google Colaboratoryを発見した、という記事を書きました。Pythonのスクリプトを実行したり、簡単なドキュメントをMarkdown形式で記載できるツールです。これまでにこのブログを書いている中で、スクリプトとか、もうちょっと書きやすくならないかなぁ、と不便を感じていました。Colaboratoryでは、Markdownで美しく書くことができていいなぁ、そういえば、WordPressはいろんなプラグインを入れられるから、もしかしたらMarkdownも使えるようにできるかも、と、調べてみました。
 ちなみに、Markdownとは、テキストだけでHTMLを出力できるように考えられた記法のことです。例えば、行の先頭に「# 」と記載することで、HTMLの見出しである<H1>タイトル</H1>を表現します。これらの記法を少し学べばテキストだけで美しい文章が作れ、テキストだけ見ても何となく構成がわかる、というのが特徴です。

 で、Google先生に聞いてみました。なんと、ぼくの環境では、Gutenbergが入っているので、すでに使えるようになっているそうです。早速やってみます。

# タイトル

 ええと、見出しになりませんねぇ。(汗)(Markdown記法では、先頭に「# 」が付いた行はHTMLで言うところのH1の見出しになります。「## 」「### 」と、個数が増えると順に小さくなっていきます。)さらにGoogle先生に聞いてみます。。。おお、シャープを入力した後にスペースを入力せよ、と書いてありました。実際にやってみましたが、なぜかできない。いろいろ試した結果、やっとできました。シャープ1個の時は、ダメで、2個以上だと動作するようです。

はい、こんな感じです。できました!

そして、バッククオートを三つ書いてエンターキーを押すと「```」
このような、コードを入力モードになりました。
  • 「- 」とスペースで箇条書きがスタートします。
  • エンターで次の箇条書きになります。

 なるほど、ブロック単位で設定していくようです。コードブロックは先頭行で「``` 」だし、箇条書きは先頭行で「- 」という感じですね。ただ、ブロック毎に変換されるので、これは、編集中に出てくるボタンを使ってやるのとあんまり変わりませんね。文章の編集にGutenbergを使っていると、Markdownはうまく使えないようです。編集効率を上げるためにMarkdown形式をバッチリ使いたいなら、他の方法を検討しないとダメですね。Markdownが使えると何となくエンジニアっぽい気がするので、Markdownのプラグインを探してきて(あれば)入れてみますかねぇ。。。

【追記】Markdownで記載したものをコピペすると、いい具合に使えることがわかりました。ただ、そうすると、テキストと記事を二重管理することになりそうだなぁ、と、いうことでやっぱりプラグインかな、と、思っています。

reCAPTCHA来ました!

 せっかくreCAPTCHAの設定を実施してBOT対策したので、本当に役に立っているのかどうか、ときどきチェックしていました。とうとうやってきましたよ。念願のBOTが。

 ま、だから何なんだよ、と、言われたら、ぐうの音もでないのですけど、BOTから送られてきていると思われる変なメールも届いていません♪
 ごらんの通り、この1週間、ほとんどアクセスがないのに、BOTからのアクセスでメールが来るとか、本来ならイラッとするところですが、今回は「キター!」という感じになりましたよ。やっぱり対策しておくといいですねぇ。まんぞくしました。

WordPressの更新作業

 このページはWordPressで作成されているということを以前お伝えしたと思いますが、今回は使っていてちょっと気になったことを解決したいと思います。

 実はWordPress、セキュリティの向上とか機能追加とか不具合対応とか処理速度向上とかちょっとした改善とか、いろんな理由で更新されています。サイトを立ち上げてからこれまでに、もう2回ほど更新がありました。どんどん良くなっていって、大変ありがたいことです。で、何が問題かといいいますと、ぼくは、WordPressのテーマの一部を変更していて、更新するとその内容が元に戻ってしまう、ということです。今回は、これを何とかしたいと思います。

 「注」に書いてありますね、そうそう、テーマに加えたカスタマイズがすべて失われるのですよ。そして「テーマを修正する場合、子テーマの利用を検討してみてください。」と、書いてありますね。子テーマをクリックしてよく読んでみます。

 子テーマを使うと、テーマを更新したときにもカスタマイズした内容が失われなくなる、ということが書いてありました。さらに、子テーマの作り方もそのページに書いてありました。まず、子テーマのディレクトリを作成して、ファイルを二つ(style.css と functions.php)作ります。それだけで、子テーマの作成自体は完了だそうです。あとは、cssに要素を追加するか、テーマが持っていたファイルをコピーして修正すれば、反映される、ということだそうです。
 では、やってみましょう。まずは、ディレクトリを作成するためにVMインスタンスに接続します。

 SSHをクリックすると以下のような画面が表示され、接続されます。フツーのLinuxの端末と同じですね。

 子テーマディレクトリは、「wp-content/themes ディレクトリ下に作成」ということですので、rootユーザに切り替えて、検索してみます。

sudo su -
find / -name themes -print

 すると、/var/www/html/wp-content/themesが見つかりましたので、ここにディレクトリを作成します。

mkdir twentyseventeen-child
chown www-data:www-data twentyseventeen-child

 そして、style.cssを作成します。決まったルールがあるようですが、ルールに従うと以下のようになります。

/*
  Theme Name:   Twenty Seventeen Child
  Theme URI:    http://www.ishikawasekkei.com/twenty-seventeen-child/
  Description:  Twenty Seventeen Child Theme
  Author:       Mitsunori Ishikawa
  Author URI:   http://www.ishikawasekkei.com
  Template:     twentyseventeen
  Version:      1.0.0
  License:      GNU General Public License v2 or later
  License URI:  http://www.gnu.org/licenses/gpl-2.0.html
  Tags:         light, dark, two-columns, right-sidebar, responsive-layout, accessibility-ready
  Text Domain:  twenty-seventeen-child
 */

 特に必要なのは、「Template」で、親のテンプレート名を正しく設定する必要があります。あとは、「Theme Name」ですね、こちらは一覧に表示されます。そして、functions.phpは以下の通りです。

<?php
add_action( 'wp_enqueue_scripts', 'theme_enqueue_styles' );
function theme_enqueue_styles() {
    wp_enqueue_style( 'parent-style', get_template_directory_uri() . '/style.css' );
    wp_enqueue_style( 'child-style', get_stylesheet_directory_uri() . '/style.css', array('parent-style') );
}
?>

 これだけで、親子の依存関係がセットされて、子テーマが使えるようになる、ということだそうです。
 ぼくがすでに変更していたファイルはテンプレートディレクトリの下にある「template-parts/footer/site-info.php」ファイルだったので、今回作成した「twentyseventeen-child」ディレクトリの下に同じディレクトリ構成を作成して、コピーします。そして、WordPressメニューの「外観」を確認してみます。

 画像をマウスでポイントすると、「有効化」ボタンが現れました。

 「有効化」ボタンをクリックして、子テーマを有効化します。これでやりたかったことは完了しました。親のテーマを最新化してもぼくが修正した内容は生きたままになっていました。これで、カスタマイズし放題ですね♪

 あとでわかりましたが、子テーマを有効化したら、メニュー (外観→メニュー or 外観→カスタマイズ→メニュー) とテーマのオプション (背景やヘッダイメージ) を保存し直す必要がありました。