ある日付( Date オブジェクト)のYYYY-MM-DD HH:MM:SS形式の文字列を得たい
getFullYear()、getMonth()、getDate()、getHours()、getMinutes()、getSeconds()など個別に取得して文字列を構築する方法は、ソースコードが長くなる傾向にあります。

ここでご紹介する方法を使うことで、スマートに取得できます。
Dateオブジェクトの基本操作

レンタルサーバーでワードプレスを簡単にインストールできる一方で、データベースの接続設定など、重要な情報が含まれる「wp-config.php」ファイルも同時に作成されます。このファイルはワードプレスの心臓部であり、攻撃者が狙う主なターゲットの一つです。

https://ドメイン/wp-config.phpでアクセスすることができます。通常phpファイルへのアクセスは、出力が空っぽになります。

普通に運用している際、このwp-config.phpを意識することはありませんが、以下のような事象でwp-config.php編集するタイミングが発生することがあります。

1. ワードプレスの動作がおかしい、デバックモードを有効に。WP_DEBUG
   
2. 自動保存の間隔を長くしたい。AUTOSAVE_INTERVAL
   
3. 投稿のリビジョンを制限したい。WP_POST_REVISIONS
   
4. ワードプレス本体の自動更新をやめたい。AUTOMATIC_UPDATER_DISABLED

この編集操作が、セキュリティに穴を開ける可能性があります。

wp-config.phpにはデータベース情報や重要な設定が含まれているため、もし攻撃者にこのファイルが盗まれると、サイトが完全に乗っ取られるリスクがあります。特にバックアップや一時ファイルが残っている場合、それらが攻撃者に利用されることがあります。エディタで編集した際、自動で保存されるバックアップファイルが狙われています・・・

SQL ServerやMySQL、MariaDBなどサーバー型データベースでは必然的なチューニングですね。SQLiteもチューニングが必要になります。

チューニングのポイントを探る上で最も重要なポイントは、↓これです

1. SQL発行、処理時間等、正確な時間を測定。必要があれば記録を残し、比較する

これがわからないとチューニングの指針が定まりませんね

個人的にSQLiteをよく利用する言語はPHPです。PHPで時間計測は以下のようにします。

$start = microtime(true); 
SQL発行処理();
echo number_format( microtime(true) - $start, 4 ) . PHP_EOL; 

• マイクロ秒で測定できます。（マイクロ秒は、ミリ秒の1/1000です）
• マイクロ秒の現在時刻から記録した処理前時間を引くことで求められます。

要件を満たしているなら遅くてもチューニング不要だと思います。
ただ運用後、登録データ数が増えるテーブルは、遅くなる場合が多いのである程度のチューニングは必要かもしれません。
チューニングのポ・・・・・

一つしかない資源（リソース）へ同時に更新、書き込みが発生する事態は極力避けたいです。FastCGI(nginxやapache）で動作させるPHPでは、同時間に複数のアクセスがあったりするので、一つのリソースに対する排他制御が必要になることがあります。

C#のような言語では、lockステートメントやMonitor.TryEnterなどを利用することで実現できます。PHPではこのようなステートメントや高級な仕組みが用意されていません。

PHP でもコンパイル指定次第でセマフォ（sem_get 、sem_acquire）やMutexが使えます。レンタルサーバー上にあるPHPでは利用できないことが多いですね
セマフォはサーバー上資源を利用する仕組みだと思っています。そのためデットロック等の異常事態が発生した際、復旧にはサーバー管理者権限が必要になったりするので仕方ないと思っています。

セマフォやMutexを利用しない排他制御の手段は、ファイルロック(flock)です。

PHPのnumber_format関数は数字を千の位毎にグループ化してフォーマットする関数です。
数値にカンマをつけたい、そんな場合に利用する関数です。

ただ、小数を含むフォーマットの場合には注意が必要です。number_format関数内で丸め（四捨五入）が働きます。

echo 12339960/1000;

結果は12339.96です。
「12,339.9」と表示させたいのですが、number_formatではうまくいきません。

echo number_format(12339960/1000,1);

結果は12,340.0です。




number_formatの挙動は以下の通り・・・・

SQLite3でテーブルをコピーする方法の一つ、create table as構文にはちょっとした罠があります。
「create table 新しいテーブル名 as select * from 元となるテーブル名」

これで「元となるテーブル」と同じスキーマーの「新しいテーブル」が作成され、さらにデータもコピーできると思い込んでいました。

主キーが設定されたテーブルのcreate table asで作成された「新しいテーブル」には、primary keyが存在しませんでした。

SQLite3ではprimary keyはcreate tableのみ設定することができます。ALTER TABLE構文では対応していません

同一データベースファイル中であれば、ALTER TABLEで名前を変えるのが一番手っ取り早いです。

attach databaseで別のデータベースファイルにあるテーブルのコピー手段として、create table asを使っていました。

この場合の対策案は、2つあります。

1. １ 主キーのあるテーブルは、create table asでコピーしない。
   create table 新しいテーブル( pk primary key ... )
   insert into 新しいテーブル select * from 元となるテーブル
   
   テーブルのスキーマーは、以下SQLで取得できます。
   SELECT sql FROM SQLITE_MASTER WHERE name='元となるテーブル'
   
   
   
2. ２ dumpを使って経由する
   sqlite3 元.sqlite3 .dump 元となるテーブル | sqlite3 運用.sqlite3
   → 元となるテーブルが正しくコピーされます。
   sqlite3 運用.sqlite3 "alter table 元となるテーブル rename to 新しいテーブル"
   
   運用.sqlite3に「元となるテーブル」名と同名がある場合は、上記を応用し、一時的なsqlite3データベースを作成して、経由することで別名を実現可能です。
   

ウェブフォント読み込み中のテキストの表示
警告: オリジンの URL の `font-display` の値を Lighthouse で確認できませんでした。

https://pagespeed.web.dev/ の分析結果で上記のような警告が表示されていました。この警告はフォント読み込めない最中の代替えフォントを指定することで解決できます（https://www.rectus.co.jp/archives/407を読むとなんとなく解決方法がわかります）。

ワードプレスのテーマでいくつかfontawesomeのフォント（font-awesome.min.css?ver=4.5.0）が利用されていました。

問題は以下２点。

• pagespeedで「ウェブフォント読み込み中のテキストの表示」の警告が出る
  
• 表示を確認したところfontawesome利用箇所のフォントが何も表示されていない

実際、どこでfontawesomeのフォントを利用しているのかを調べたところ5種類程度でした。
（「"fa 」で調べる（grep）と比較的簡単にわかります。）

1. ページの先頭に戻るアイコン[fa fa-angle-up]
   
2. カテゴリ [fa fa-folder-open-o]
   
3. タグ [fa fa-tags]
   
4. 更新日 [fa fa-clock-o]
   
5. スマホ用のアコーディオンアイコン [fa fa-bars]
6. その他SNSシェアボタン←これは削除しました

Googleのマテリアルフォントに変更しようかと検討しましたが、そもそも種類少ないのでUTF-8でいいんじゃない？
UTF-8の代替え文字（これに置き換えました）｛その他候補｝

1. （🔝）｛⇪｝ページの先頭に戻るアイコン[fa fa-angle-up]
   
2. （📂）｛📁｝カテゴリ [fa fa-folder-open-o]
   
3. （🏷）タグ [fa fa-tags]
   
4. （🕒）｛🕐🕑🕓｝更新日 [fa fa-clock-o]
   
5. （☰）スマホ用のアコーディオンアイコン [fa fa-bars
   

まとめ：使っている種類が少ないならUTF-8置き換えが簡単です

pageinsigtの指摘に取り組むと、cssやwof（フォントデータ）のpreload対応やfont-display:swap対応などが必要になることがあります。

今回UTF-8に置き換えたことでこの辺りの警告は無くなりました

さくらインターネットのレンタルサーバー（スタンダード）契約しています。sshでログインし、作業することがあります。扱っているソースコード(UTF-8)やログ(UTF-8)の中には全角文字列が含まれることがあります。
この全角文字はcatでは表示できるけど、less、viでは文字化けを起こします。

• cat ログファイル
• less ログファイル →全角文字列が化ける
• vi ログファイル →全角文字列が化ける

扱っている文字コードはUTF-8・・・・

node+puppeteerのプログラムがエラーで動かなくなりました。
↓「Error: spawn Unknown system error -86」で動作しないことがわかります

node:internal/errors:484
    ErrorCaptureStackTrace(err);
    ^

Error: spawn Unknown system error -86
    at ChildProcess.spawn (node:internal/child_process:413:11)
    at Object.spawn (node:child_process:743:9)
    at BrowserRunner.start (/tmp/test/puppeteer/node_modules/
puppeteer/lib/cjs/puppeteer/node/BrowserRunner.js:121:34)
    at ChromeLauncher.launch (/tmp/test/puppeteer/node_modules/
puppeteer/lib/cjs/puppeteer/node/ChromeLauncher.js:76:16)
    at async /tmp/test/puppeteer/a.js:8:18 {
  errno: -86,
  code: 'Unknown system error -86',
  syscall: 'spawn'
}

Node.js v18.8.0

puppeteerは以下で起動しています。

await puppeteer.launch({ 
args: [ "--no-sandbox","--guest"] });

＞＞＞原因は？＜＜＜＜

この記事はさくらインターネットでスタンダードプランを契約中のサーバーでの話です（2022年8月4日時点）。
カテゴリー的には旧サーバーの部類になります。WebサーバーはApache/2.4.54。

ご存じのようにWordPress導入で、.htaccessファイルに以下のような記述が追加されます。

# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>

# END WordPress

1. RewriteRule ^index\.php$ - [L]

   /index.phpの場合、この行で終了する命令です

   
   
2. REQUEST_FILENAMEは、apacheサーバー側で認識したフルパスのファイルです。

   The full local filesystem path to the file or script matching the request, if this has already been determined by the server at the time REQUEST_FILENAME is referenced.
   mod_rewrite

   
   
3. RewriteCond %{REQUEST_FILENAME} !-f

   REQUEST_FILENAMEがファイルだった場合、ここで終了します。

   
   
4. RewriteCond %{REQUEST_FILENAME} !-d

   REQUEST_FILENAMEがディレクトリだった場合、ここで終了します。

   
   
5. RewriteRule . /index.php [L]

   実際のファイルがない、ディレクトリがない、この条件を満たした場合、index.php（WordPress本体）を呼び出し、終了します

   
   
6. WordPressで追加された.htaccessの記述の意味、なんとなくわかった感じですよね。

apacheが判断して格納するREQUEST_FILENAMEはそういう処理だったんですね

WordPressをインストールした/直下には、index.phpのほか、readme.htmlがあるかと思います。

• /index.php
  
• /readme.html
  

https://あなたのドメイン/readme/
でアクセスしてみてください。readme.htmlが表示されます。

a.htmlやb.txtを配置しても同様です。
https://あなたのドメイン/a/→a.htmlが表示される。
https://あなたのドメイン/b/→b.txtが表示される。

c.phpは「要求された URL はこのサーバーで見つかりませんでした。」とエラーになります。
https://あなたのドメイン/c/

https://あなたのドメイン/a/→a.htmlが表示される

REQUEST_URIはaのはずですよね。REQUEST_FILENAMEはaでファイルなしかと思いきやa.htmlが見つかるってことです。

つまり、/a/は、a.html、a.txtを探し、ファイルが存在した場合、REQUEST_FILENAMEに設定されてしまうってことです。

apacheの挙動なので、ユーザーサイドで何かするのは難しいと思います。

まとめ：多分バグかも、見方を変えると何か裏技的な方法に？

nginxを利用したサーバーでは、https://あなたのドメイン/readme/にアクセスしても、wordpressの404ページに遷移してくれます。さくら側の挙動はapacheの不具合だと思われます。

WordPress内で設定するアーカイブやタグ、カテゴリと一致してしまうファイルを置いてしまうと誤動作するってことになると思います（試していません）。要注意ですね。

見方を変えると、これは.htmlを隠してアクセスするちょっとイケてる？公開方法に活用できるかもしれませんね。（不具合が修正された場合、404ページに遷移してしまうリスクあり）