未分類

なぜそんな説明をするのか?

そろそろLuxeritasからの移行を考えているからです。公開した以上どこかでメンテナンスをやめるなら、引き継ぎ可能な状態にしようという意味合いです。

どうして移行したいのか?

改変パッチの配布が面倒だからです。配布物に含まれるコードはGPLなのにminifyしたソースしか含んでいなかったり、各ファイルのライセンスが明確ではありません。通常GPLならminifyする前のソースを要求し、そのソースは再配布も堂々とできるのですが、これだけしっかり配布している中それらソースをどこにも置いていません。サイトを読む限りGPLについても独自の見解をお持ちのようで、弁護士を頼んで云々とあり、正直あんまり関わりたくありません。

本来であればパッチ配布などという形態にしなくても、gitリポジトリごとどこかに置いてもらえば、こちらもフォークして修正して公開できるわけです。あとはプルリクエスト出したりと健全な活動で取り込まれれば私の作業はなくなるし、リジェクトされても他の人がフォークしたものに取り込むのは容易なわけで、いずれにしても私の作業はかなり楽になります。極めつけが先のminifyソースなのですが…これは実際の作業で実感してもらうべきですね。

未分類

前回はConoHa VPSでWordPressを立ち上げました。

今回はこのWord PressにVALUE SERVERで取得したデータを移行します。

未分類

前回はdockerのnginxを使ってhttpsで公開できるようにしました。

今回はdockerを使ってWordPressをhttpsで公開できるようにしてみます。

未分類

事件

今日何気なく記事を編集して、「ああ、そういや過去記事で似たような画像作ったな…作った画像どこだっけ?」って過去記事を探していたところ、どこを探しても見つかりません。

この画像には alt 属性が指定されておらず、ファイル名は image-27-1024x188.png です

あれれ?それもそのはず消えているのです。そう言えばアップロードしたときも↓な感じでメッセージが出てました。

プレビューとかでは見えていたので、「警告かなぁ…まあいいや」と気にしていなかったのですが、実際にアップロードには失敗していた模様。そしてこのファイルこそがsvgだったのです。

なぜ拒否られてたのか?

アップロードできるファイル・タイプがWordPress側で決められているからです。

Uploading Files « WordPress Codex

これはメッセージに出ていたようにセキュリティ上の理由です。

どうすればいいのか?

メッセージから調べたところ、対応方法の記事が以下に見つかりました。

https://www.elegantthemes.com/blog/wordpress/how-to-fix-the-sorry-this-file-type-is-not-permitted-for-security-reasons-error-in-wordpress

大きく分けて、プラグインを使う方法とそうでない方法があるようです。遅くなりそうだからプラグインを使いたくなくて、

3. Use the Upload_Mimes Filter by Editing Your Theme’s functions.php File

の方法にしようと考えました。テーマのファイルをいじるようですが、テーマと言えばLuxeritas、誰かやってないかなぁとググって↓の記事を見つけました。

https://it-blue-collar-dairy.com/svg-upload/

ピッタリですね。読んで見ると、今までインストールはしたものの、面倒だったので使ってこなかった「子テーマ」を使うのがいいようです。

子テーマの適用

よく分からないけどポチっと変えてみたら、、、

『設定が共通化されてない!』

直後からカスタマイズした設定の全てがデフォルトに戻っています。親テーマに戻すと戻るのですが、子テーマに変えるとまたデフォルトに…。どうやら設定が共通化されてないようなのです。ここを分ける意味はあったんでしょうか…。どこかに相互にコピーする機能があるのかもしれませんが、まあいうてそんな変えてないので、ポチポチ再設定して復元しました。凝った設定をしてる方、お気をつけください

functions.phpの編集

どうやら子テーマとは、親テーマを直接いじることなく、テーマのphpファイルを書き換えるなどヘビーな操作をWebから行えるようにした、カスタマイズの申し子のようです。どおりでアップデートの頻度が少ないわけです。↓な感じでサクっと編集できます!

でも、これ書き間違えたら二度と直せないような…要るのかな?…この画面…

ちなみに修正は↓のみ。参考文書ではいろいろ他にも処理していましたが、本家のコードにないことはしたくなかったので…

function my_custom_mime_types( $mimes ) {
	$mimes['svg'] = 'image/svg+xml';
	$mimes['svgz'] = 'image/svg+xml';
	return $mimes;
}
add_filter( 'upload_mimes', 'my_custom_mime_types' );

無事アップロード出来たので問題なし、です。ちなみに↓が投稿した記事内のsvg画像のレスポンスヘッダ。

HTTP/1.1 200 OK
Date: Tue, 04 Feb 2020 22:21:33 GMT
Server: Apache
Last-Modified: Tue, 04 Feb 2020 22:16:33 GMT
ETag: "a3c0204-10b0b-59dc7647855c6"
Accept-Ranges: bytes
Content-Length: 68363
Vary: User-Agent
Connection: close
Content-Type: image/svg+xml

普通に返されてるので、少なくとも私のアップロード操作で、別のファイルタイプと勘違いしているような問題は起きてないように見えます。

未分類

実際このサイトどうせほとんど人来ないんだし、大事なものは何1つ置いてないので、セキュリティとかあまり考える必要もないのですが、放置して踏み台とかになるんだとちょっと困ります。

検討

適当にセキュリティ関連のプラグインでも入れればいいのかなぁとも思うのですが、それも速度面とか気になるし、いうてそんなセキュリティが欲しいわけでもないのです。すごい人が集まっていて、個人情報などを溜め込んでるとか、何か他人様の認証用パスワードなど漏れては困るものがあるとか、そういう事情がないので、何か特別に強化する必要のあるセキュリティがない…Windowsで例えて言えば、 標準的なセキュリティであるWindows Updateがちゃんと当たっていて、乗っ取られさえしなければいいってことです。

方法

というわけで、当サイトでは、

Geekflare WP Security Scanner – Powered by WPScan

を使うことにしました。これはプラグインとかではなく、外部サイトです。セキュリティチェックしたいWordPressサイトのURLを貼って実行するだけで以下のような判定をしてくれます。

結果を信用するなら、少なくとも自分で調べるよりかなり楽できます。

未分類

前回HTML内でJavaScriptを書いてみたらハイライトされなくて、おかしいな〜と調べてたら3件不具合を見つけた。

不具合

HTML内のJavaScriptなどをハイライトできない場合がある

現象

記事内にシンタックスハイライターを単独で置き、HTML内にJavaScriptを記述した上で言語をHTML/XHTMLにしておくと、JavaScriptがハイライトされない。

原因

HTMLのハイライトを行う(prism-)markup.jsとJavaScriptのハイライトを行う(prism-)javascript.jsの読み込み順序が逆であるため。依存されているjsが後に読み込まれる必要がある。

JavaScriptなのにJava用のハイライタまで読み込まれる

現象

読み込みがごくごく僅かに遅くなるだけだが、わざわざ言語別に必要ハイライタだけ読み込んでるからもったいない

原因

言語指定の先頭4文字がjavaかで判断しているため、javascriptまでjavaと勘違いされた

JavaScriptのハイライタが2回読み込まれる場合がある

現象

読み込みがごくごく僅かに遅くなるだけだが、わざわざ言語別に必要ハイライタだけ読み込んでるからもったいない

原因

JavaScript単体で言語指定された場合と、依存言語として他の言語指定から読み込まれる場合に、別の言語指定文字列が使われているため(highlight-javascriptとjavascript)、重複して読み込まれる

対策

パッチを作成した。

diff --git a/inc/load-inline.php b/inc/load-inline.php
index cc707c5..3374c70 100644
--- a/inc/load-inline.php
+++ b/inc/load-inline.php
@@ -51,10 +51,14 @@ function thk_highlighter_load( $loads, $list, $active ) {
 
 		// Javascript
 		foreach( $list as $key => $val ) {
-			if( strpos( $post->post_content, '<code class="language-' . str_replace( 'highlight_', '', $key ) ) !== false ) {
+			if( strpos( $post->post_content, '<code class="language-' . str_replace( 'highlight_', '', $key ) . '"' ) !== false ) {
 				$lang = str_replace( 'highlight_', '', $key );
 
-				if( !isset( $loads[1][$key] ) ) {
+				if( !isset( $loads[1][$lang] ) ) {
+					// 言語ごとの読み込み
+					$loads[0] .= thk_fgc( $jsdir . $lang . '.js' );
+					$loads[1][$lang] = true;
+
 					/*
 					 * 他言語の依存チェック
 					*/
@@ -114,10 +118,6 @@ function thk_highlighter_load( $loads, $list, $active ) {
 						$loads[0] .= thk_fgc( $jsdir . 'sql.js' );
 						$loads[1]['sql'] = true;
 					}
-
-					// 言語ごとの読み込み
-					$loads[0] .= thk_fgc( $jsdir . $lang . '.js' );
-					$loads[1][$key] = true;
 				}
 			}
 		}

保管場所は以下。


Luxeritas作者様に報告させて頂きました。次バージョンで対応して頂けるとのお話なので、個々にパッチを当てる必要はないと思います。


2020年2月2日にリリースされたLuxeritas3.7.8本体で、対応されたことを確認しました。なので以降本件のパッチリリースはありません。


2020年2月3日本パッチには、ほとんどの言語でハイライトできなくなるという重大な不具合が発見されました?。
同日にリリースされたLuxeritas3.7.8.2で作者様が対応してくれております。詳細は↓で。

未分類

UI系JavaScriptの記事なら動かせてもいいなぁと思って実験してみました。

カスタムHTMLブロックを使う

以下のVueのサンプルコードを動かしてみる。

<script src="https://cdn.jsdelivr.net/npm/vue"></script>
<div id="app-5">
  <p>{{ message }}</p>
  <button v-on:click="reverseMessage">Reverse Message</button>
</div>
<script type="text/javascript">
var app5 = new Vue({
  el: '#app-5',
  data: {
    message: 'Hello Vue.js!'
  },
  methods: {
    reverseMessage: function () {
      this.message = this.message.split('').reverse().join('')
    }
  }
})
</script>

これをカスタムHTMLブロックに貼り付けた結果が以下。

{{ message }}

結果

動いてるみたい。

未分類

ここでは、本サイトで実施しているDBのみの手作業移行について解説します。簡単で、用途もデバッグ用なので、方法も適当です。

目的

DBのデータを運用しているサイトからlocalデバッグ環境に移行する

方針

ファイルはgitで管理されているので、DB内のデータのみ移行したいということです。プラグインを使うと、ファイルまで一緒についてきたり、サーバに余計なプラグインを設置しないといけなくなります。ローカルでサーバと同じデータを使ってデバッグ/テストしたいという目的であれば、DBの内容だけ適当にコピーできれば良く、できればコマンド一発で簡単にやりたいというわけです。

mysqlのデータをVALUE SERVER上でファイルに落とす

VALUE SERVER上で以下のスクリプト($HOME/bin/hoge.sh)を使うと、標準出力に、圧縮したWordPress関連のテーブルデータを全て出力できます。

#!/bin/sh
TABLES="wp_commentmeta wp_comments wp_links wp_options wp_postmeta wp_posts wp_term_relationships wp_term_taxonomy wp_termmeta wp_terms wp_usermeta wp_users"
mysqldump --user=$USER -p $USER $TABLES | gzip

実行すると、MySQLのパスワードが聞かれます。このファイルには実行可能属性を付けておきます。

$ chmod u+x $HOME/bin/hoge.sh

なお、使用しているコマンドのmysqldumpはあまり早くない汎用性の高いコマンドです。大量のデータがあって、いつまで経っても終わらない場合は別の方法にすべきです。このサイトは2020年1月23日現在圧縮して1MBに満たないサイズです。

ローカル環境から直接ファイルに落とす

上のスクリプトと、前回整えたsshの公開鍵認証を使って、ローカル環境から直にVALUE SERVER上のMySQLデータをファイルに落とすことができます。以下がそのコマンドです。

$ echo (MySQLパスワード) | ssh xxxxxxxx@xx.valueserver.jp ./bin/hoge.sh > mysqldat.gz

リダイレクトを使うことで、暗号化された経路でコマンドに履歴を残したり、一時ファイルを作成することなく、綺麗にデータを落とすことができています。さらに、VALUE SERVER上のhoge.shすら使用しないローカルスクリプト(export_db.sh)も書いてみました。

#!/bin/sh
SSH_USER="xxxxxxxx"
SSH_SERVER="xx.valueserver.jp"
MYSQL_PASSWD="yyyyyyyyy"
TABLES="wp_commentmeta wp_comments wp_links wp_options wp_postmeta wp_posts wp_term_relationships wp_term_taxonomy wp_termmeta wp_terms wp_usermeta wp_users"
OUTFILE=mysql.dat.gz
echo $MYSQL_PASSWD \
    | ssh $SSH_USER@$SSH_SERVER "mysqldump --user=$SSH_USER -p $SSH_USER $TABLES | gzip" > $OUTFILE

完成したタイミングでVALUE SERVER上のhoge.shは削除しました。sshは痕跡をあまり残さず何でも出来て便利だけど、ここが乗っ取られたら大変なことになることがよく分かります。

落としたファイルをローカルDBに流し込む

今回流し込むローカルDBは以前書いた記事のものを使います。

まずはdockerを起動して

$ docker-compose up

その後、以下のスクリプト(import_db.sh)で取り込みます。

#!/bin/sh
MYSQL_DB="exampledb"
MYSQL_USER="exampleuser"
MYSQL_PASSWD="examplepass"
CONTAINER="docker_db_1"
OUTFILE="mysql.dat.gz"
gzip -dc $OUTFILE | docker exec -i $CONTAINER mysql --default-character-set=utf8 -D $MYSQL_DB -u $MYSQL_USER --password=$MYSQL_PASSWD
docker exec -i $CONTAINER mysql --default-character-set=utf8 -D $MYSQL_DB -u $MYSQL_USER --password=$MYSQL_PASSWD <<EOF
update wp_options set option_value='http://localhost' where option_name in ('siteurl', 'home');
commit;
EOF

実行時にパスワードが引数で渡されることに警告が出ますが、デバッグ用の環境で固有名詞は適当なので、気にしないことにします。

また、取り込んだ後にSQLのUpdate文でWP_OPTIONテーブルを修正していたりもします。しかしその部分も最低限で、リンクなどの修正やその他の細かい変更もしていません。これらは運用サイトの状態をなるべく変えないことを意図しています。

まとめ

dockerが起動していれば、ローカルでexport_db.shとimport_db.shを実行するだけでVALUE SERVERのデータを取り込むことが出来た。

未分類

Google検索向けにサイトマップを置きました。検索エンジンさんにこのサイトの構成などを説明するファイルです。

やったことは、Google XML Sitemapsというプラグインを追加して、

設定リンクを押して、

こんな感じのURL(画像のドメイン部分は自分のドメインに読み替えてください)をコピーして、Google Search Consoleでサイトマップの追加をしただけ。

このサイトに人が来ることがあるのかは分かりませんが、少なくとも表札を立てて住んでますっていう張り紙をしたという話でした。

未分類

今回当サイトにLuxeritasのパッチを置いたら、Chromeなどでダウンロードしたときに警告が出てしまいました。

サイトを作ったことがある人は知っているもののようですが、個人サイトなどでダウンロードできるようにすると、「誰が作った何なのか分からない」ので危険物扱いされてしまうようです。リンク先のサイトの管理人さんは、普通にウィルスチェックして、Googleに再チェックを依頼して事なきを得たそうですが、毎回そんなことするの大変です。

Google Search Consoleで問題指摘された際の詳細を見て、その基準を追ってみると…望ましくないソフトウェアのポリシー | Google – Google というページが見つかります。2020/1/22現在そこには以下のような記述があります(他にも項目があります)。

プログラムには、サイト運営者の検証可能な情報を提示する、コードサイニング機関から発行された有効な検証済みのコード署名が必要です。

ソフトウェアのダウンロードは、ユーザーがラベルで明示されたダウンロード ボタンをクリックしてダウンロードに同意した上で開始される必要があります。

望ましくないソフトウェアのポリシー | Google – Google

多分この辺が問題だと判断されたのかなと思います。ようは直リンクで署名されてないアーカイブを検出した場合に所定の手順でチェックが入るのかと推測しています。信頼された検証済みコードは難しいけど、署名=「誰が」の部分を明確にすることは出来そうです。今回は、Googleのチェックということもあり、GoogleDriveに置くことで、発信元を少なくともGoogleが(他の人もですが…)識別できるようにしてみました。

こうすることで、少なくともChromeなどでダウンロードする際に、危険物扱いをされずに済むようです。