LL・Web

WordPress個人サイトで「永続オブジェクトキャッシュ」とか気にするな

/ LL・Web, コンピュータ

WordPress 6.1 からサイトヘルスステータスに「永続オブジェクトキャッシュ (Persistent Object Cache)」の項目が増えたらしいのだけれど、同じ設定なのに警告が出たり出なかったりするんだよね。

…

WordPress個人サイトで「永続オブジェクトキャッシュ」とか気にするなもっと読む »

DELLのサイトのフォントが変なのは何故？

/ LL・Web, コンピュータ

DELLのすべてのページではないが、買い物やドライバ検索をしていると、汚いというか変な表示に遭遇する（かなり前から）。

そういったページでは、CSS で body にこんな font-family の指定がある：
（実際には1行に押し込んであるので適当にリフォーマットしています）

font-family: Roboto-Regular, Roboto-Light, "Cordia New", 
    "Microsoft Sans Serif", Utsaah, "Devanagari MT", "Nirmala UI", 
    Latha, InaiMathi, Gautami, "Telugu Sangam MN", Tunga, 
    "Kannada Sangam MN", Kartika, "Malayalam Sangam MN", Shruti, 
    "Nirmala UI", "Gujarati MT", "Gujarati Sangam MN", Vrinda, 
    "Bangla Sangam MN", "Meiryo UI Reg", "メイリオ Reg", 
    "MS UI Gothic Reg", "Hiragino Kaku Gothic Reg", "ヒラギノ角ゴ Pro W3 Reg", 
    "Microsoft YaHei", "微软雅黑", "Hiragino Sans GB", "Microsoft JhengHei", 
    "微軟正黑體", "Malgun Gothic", "맑은 고딕", Gulim, AppleGothic, 
    "Apple LiGothic", "LiHei Pro", Osaka, STHeiti, "华文黑体", STXihei, 
    "华文细黑", SimHei, "黑体", "Arial Unicode MS", Arial, sans-serif;

日本語用として、メイリオ等を指定しようとした形跡もあるのだけれど、末尾に Reg が付いているせいでマッチせず、中国語（簡体字）フォントである "Microsoft YaHei" がマッチしてしまう模様。（これ、Windows のシステムフォントで消せない？ので、うまい回避方法が思いつかない。）

ただ、h1 のようなヘッダは別にフォント指定があって、何故か Roboto-Medium しか指定されていない（Roboto 日本語はない）ので、フォントが見つからずデフォルト（最近の Windows の Chrome 等なら Meiryo）になる。最初からこれでいいのでは……。

  • font-family で使える個別フォント名が標準化されてないのが悪い（規格のせい）
  • 日本語用のグリフがない（あるいは中途半端な）フォントが日本語の表示に使われてしまうのが悪い（実装のせい）
  • DELLが悪い（人（ウェブデザイナ？）のせい）

どれ？

wordpress：「プラグインは wp_version_check() を無効化してアップデートを防ぎました。」がプラグインと関係なかった件

/ LL・Web

wordpress（これを書いた時点では 5.4.2）の wp-admin/site-health.php で、

1件の致命的な問題
バックグラウンド更新が想定通りに動作していません　［セキュリティ］

といわれる。セキュリティの致命的な問題だというので早急に対処する。
（自動更新はできてるけどねえ？）
…

wordpress：「プラグインは wp_version_check() を無効化してアップデートを防ぎました。」がプラグインと関係なかった件もっと読む »

ImportError: cannot import name ‘PILLOW_VERSION’ from ‘PIL’

/ LL・Web, コンピュータ

PyTorchというか、torchvisionを使おうとしただけで、こんなエラーが：

ImportError: cannot import name 'PILLOW_VERSION' from 'PIL'

Pillow 7.0.0でPILLOW_VERSIONが削除されたのが原因らしい。

PILLOW_VERSION has been removed. Use __version__ instead.

https://pillow.readthedocs.io/en/stable/releasenotes/7.0.0.html

とはいえ、ライブラリ内で使われているし、いろいろ理由があってライブラリのバージョンを下げたりライブラリを直接修正するのもできない。

で、

import PIL

PIL.PILLOW_VERSION = PIL.__version__

from torchvision import ...

とかいうアレなworkaroundを思いついた（動く）んだけど、これでいいのかPython。

pkgsrc/www/php-nextcloud などが特定条件下で segmentation fault になる件

/ BSD, LL・Web

条件が揃うと、nextcloud の occ status のような単純な処理でも segmentation fault が発生する。

根が深かったのでメモっておく。

概要
php で mysql と curl の extension が両方あり、mysql 5.7 以降と openssl 1.0系（以前）を組み合わせていると不具合が発生する（場合がある）。

pkgsrc（2019年2月頃～）の mysql のデフォルトは 5.7、NetBSD 8.[01] の openssl は 1.0.2k、なので引っ掛かりやすい（はず）。
（NetBSD 9.0 からは openssl 1.1系になるはず……）
…

pkgsrc/www/php-nextcloud などが特定条件下で segmentation fault になる件もっと読む »

WordPress テンプレート Twenty Seventeen の困った点

/ LL・Web

Twenty Seventeen オサレだし、カスタマイズも進歩してるし、日本語フォントなんかもデフォルトで良い感じなのですが、

トップが画面全体を使って画像や動画を置くような形式（以下、勝手に「表紙」と呼ぶ）なのも、用途によるだろうけどいいとして、

その表紙にあるサイト名をクリックすると、ホームへのリンクなので、（当然）表紙が表示されたままなんですね。スクロールさせるか、右下にある（サイト名と比べると目立たない）「↓」を押せばいいんですが、ちょっと不親切な気がする。

それだけならいいんですが、ページ下にあるナビゲーション使うと、またいちいち表紙が表示されるんですね。そこでうっかりサイト名クリックするとトップに戻ってしまう。

で、Twenty Seventeenの子テーマ作って、home_url のフィルタで URL の後ろに #content 足したらいいかなと思ってやってみたものの、今度はナビゲーションのリンクの途中に http://.../#content/page/2 みたいに入ってしまって、リンクとして機能しなくなるのでダメ。このフィルタ、こういう使い方想定してないですかね。

で、このナビゲーションはテーマじゃなくて wp-include/general-template.php で作ってるようなので、そこを見ると paginate_links というフィルタがあるらしい。なので、それを使う。

結果として、子テーマの 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' );
}

add_filter('paginate_links', 'mylink', 1, 1);

function mylink( $link='' ) {
    return $link . '#content';
}
?>

こんな感じに。

んで、home_urlの方はフィルタでいじるのを諦めて、元のテーマの template-parts/header/site-branding.php をコピーして home_url('/') を直接home_url('/#content') へ変更。

もっとうまいやり方がありそうだけど、Wordpress（の中身）もPHPもマトモに触ったことないのでこの辺で妥協。

デフォルトがマシになってくれることを祈る。

WAMP初挑戦

/ LL・Web

Windows+Apache+MySQL+PHPで作られているという社内(?)のシステムのUNIX系OSへの移行作業とその後のメンテを押し付けられ命じられたので中を覗いてみる。
PHPは使ったことがないんだがなー。
DBを軽く見てみると

  • テーブル数個のうち半分くらいしか使ってない
  • 何もかもコード化されていなくて，ユーザやグループをはじめとする名称がそのままキーになっている。
  • 一人のユーザに対応するグループが10個分用意されている。正規化されてない。
  • コンテンツを保持するひとつの項目にplain textとhtmlが混在していて判別のための項目はない。
  • たまに情報がDB内ではなく公開ディレクトリに無造作に置かれたテキストファイルに入ってる。
  • フィールド名の綴りがいろいろ間違っている。

PHPの方を見てみると

  • オブジェクト指向ではなく，別ファイルになっている関数群をまとめたものを require する形式。
  • 関数群をまとめたファイルというのが，ディレクトリ毎に同じ名前の別ファイルとして存在していて，同じ関数が定義してあるが中身が少しずつ違う。
  • 同じような手続きがあちこちにある。
  • 組み込み関数の呼び出し方がいろいろ間違っている。
  • ほとんどのデータを登録・修正・削除するインタフェースがない。
  • 入力値に対するチェックがない。
  • 単純に文字列連結でSQL文を作っている。
  • HTMLのエスケープはほとんどやってない。SQLに追加される文字列のエスケープはまったくやってない。
  • 使ってない（作りかけ）のファイルが多数。

など。
さて，どうやって捨てさせるか…。

POSTされる文字列のencoding問題

/ LL・Web

掲示板などをはじめ，フォームから日本語を入力してsubmitしてサーバ側で処理をさせるような処理を行う場合，大昔のWebブラウザは日本語化が無理矢理だったりした関係で，ブラウザによってPOSTされる文字列のencodingがまちまちだった。このため，多くのブラウザに対応するとなると，受け取る側は自動判定をはじめ小技がいろいろ必要だった。
例えば任意の文字列のEUC-JP/Shift_JISの自動判別を完全に行うことは不可能である。ここでhiddenで適当な文字列を埋め込んで，その文字列を使ってencodingを調べるといった方法もあったが，hiddenと通常の入力フォームでそれぞれ違うencodingで送るブラウザもあったり。User-Agentを見て判定の優先順位を変えるとか涙ぐましい努力をしているものもあったが，新しいブラウザがまた違うパターンだったりしてぶち壊しだったり。
最近のWebブラウザだとだいたいフォームのHTMLのcharsetと同じものを用いるので，下手に自動判定等はしない方がいいようである。
ところで，最近のWebブラウザは英語や日本語以外の多言語を取り扱うことができる。EUC-JPで書かれたHTMLのフォームにEUC-JPにはない(ASCIIにもJISX0208にもない)文字を書くとどうなるか。

…

POSTされる文字列のencoding問題もっと読む »