MR.HARIKIRI-INSIGHTS

カテゴリー: WordPress

  • [WordPress] DOMが多いと，PageSpeed Insightsが言うんだけど。 どうすんのよ? → 新しいテーマとこれまでの遺産コードを捨てる!![2023/11/12]

    [WordPress] DOMが多いと，PageSpeed Insightsが言うんだけど。 どうすんのよ? → 新しいテーマとこれまでの遺産コードを捨てる!![2023/11/12]

    Post Views: 181

    はじめに

    blogサイトの速度を測定してくれる「PageSpeed Insights」というWebツールがあります．サイトのレスポンスを改善するためにAMP化した時などの評価に使用しますが，DOMが多いとか注意を受けてしまいす．どうしましょうか．

    どうやら「DOM」について良く知らないと，解決策を提示されても理解ができません．まずは，知識の補充から．

    DOM

    DOMとは，「Document Object Model」の略号です．webページの表示についてあれこれ操作する場合に，JavaScriptが使用されているのですが，このプログラミング言語は，オブジェクトを扱えるようですね．とっかかりとしては何となくわかった感じです．

    参考文献には，「DOM はページの HTML の構造を表すものであり、JavaScript と CSS がページの構造とコンテンツにアクセスできるようにします。」と説明しています．

    DOM サイズの大きいことがインタラクティビティに及ぼす影響と対処方法 -web.dev-

    https://web.dev/articles/dom-size-and-interactivity?hl=ja

    Webページの構造

    Webページは，html文で書かれているのですが，<html>…</html>という構造です．これをタグ文字といいます．そのほか，この<html>…</html>の構成要素には，<head>…</head>, <body>…</body>，　その他，背景色，改行，文字種・色・大きさなど，様々な文字や表示体裁を操作するもの，CSSで定義している場合は，その新たな構造も追加されDOMが増加します．

    文字の大きさは，<h1></h1>, <h2></h2>…などです．アンダーラインは，<u></u>です．CSSでは，これらの表現様式を新たに定義できますが，DOMが増えます．

    以上が，DOMを構成する構成要因たちの概要です．

    余談ですが，

    30年も40年も前の大昔は，これらのタグ文字によりhtml文を待て入力でコーディングしていたました．そのご，Home Page BuilderなるものがIBMから出たのでそれを使用して，これまでより楽にページを作れるようになりました．当時は，Webサーバーとの連携というよりは，自分の仕事のまとめとして，リンクを張ったりして，普通の文書を作るように活用していました．必要な内容はリンクで繋げてやるとナレッジが膨らんでいくという作り方です．

    そして，現在はWebサーバーとの連携を前提にしていますが，「WordPress」という無料のページ作成アプリ(?)があります．MRHARIKIRIがWordPressを知ったのは2018年でした．IO-DATAのおもちゃのNASからSynology NASに乗り換えることを考えていたころです．すごいですね．浦島太郎の気分でした．

    解決の糸口

    DOM treeという概念も知識として必要です．例えば，<html></html>の内部に<h1>，<h2>などがありプレーンテキストとして<p>があるとして，これら全ての要素が，tree(ツリー, 木)の構成要素になり得ます．改行など構成要素になっていまうので，そうならないような記述の仕方がありす．それを採用すれば，DOM数を多少は少なくすることも可能です．

    例えば以下の2つの例で考えてみます．以下の(1)1行で書く，(2)見やすく書くのそれぞれで使用されているDOM数にカウントされるタグは，同じ数になっています．しかし，書き方(コーディング)でDOM数に違いがでてます．

    • 1行で書く
      • <html><head>…</head><body><h1>Title</h1><br><h2>Section</h2><br></body></htm>
    • 見やすく書く
      • <html>
      • <head>…</head>
      • <body>
      • <h1> Title </h1>
      • <br>
      • <h2> Sectoin </h2>
      • <br>
      • <body>
      • </html>

    (1)1行で書く場合と(2)見やすく書く場合でDOM数は，見やすく書く場合の方が多くなります．改行がDOM数にカウントされるためです．

    DOM数の違いは，

    • <head>…</head>に沢山の情報を埋め込むとDOS数は増える
    • 1行で書くよりも，見やすく書くの方が，改行した分だけ増える．

    ふむ．なんとなくわかってきた-^;

    ということは，DOMを二次元で考えればいいことになりますね．同レベルの要素が(横の相に, 例えばh1, h2…)増えると1次元目のDOMは増える．そのレベルに属する要素が(下層に，例えば)増えると2次元目のDOMが増える．このよなイメージでDOMが増えていくというわけです．それをTreeといっている訳です．

    効果的なのは

    やはり効果的なのは，CSSの整理であると思います．実践はこれからなので，予想ですが．

    方針

    DOMを少なくする方針が見えてきました．

    1. 改行もDOMに含まれるらしいので，改行させないhtmlの書き方を貫く(整えてくれるプラグインを導入する)．
    2. 不必要・不用意な文字種の変更をしないコーディング．
    3. 表示系のプラグインを増やすと，その分の新たなタグ(CSS)もDOS数増加の原因になるので，プラグインはやたらと増やさない．
    4. 表示系のプラグインを無暗に追加せず，現状で多ければ減らす．

    具体策の実施と結果

    これから，長い試行錯誤がはじまる予感 ! (2023/10/27, MRHARIKIRI)

    2023/11/12,
    WordPressのテーマを変えることにした．今日までTwenty Twentyを使ってきたが，Twenty Twenty-Twoの軽量版であるTwenty Twenty-Threeに変更した．Twenty Twentyは，長年の運用過程で，content.phpへのコードの修正追加や，function.phpへの追加コード，style.cssのコード追加など，DOMが増加する要因は沢山あった．

    思い切って，昔の遺物を捨て去って一転新規にテーマをTwenty Twenty-Threeに選定してみた．

    具体的には，

    1. Twenty Twenty-Threeのインストール
    2. 小テーマの作成 : 小テーマ用フォルダ作成，そこへ，小テーマ用Style.css作為せと保管，screenshot.pngの保管，従来のfunction.phpの保管．
    3. function.phpには，google analyticsのためのコードやgoogle adsをheaderに配置するフックコードが記述されており，軽量化はせずそのまま使用．

    その結果，PageSpeed Insightsの測定では，DOMに関する注意はできなくった．あっけなかった．従来のテーマ Twenty Twentyのstyle.cssには，小テーマ用の記述以外に，見出し文字の再定義など，多数のコードを記述していた．それがまるっきりなくなり軽量化されたこと，content.phpの修正追加コードが全くなくなったこと，によりDOMが縮小したと考えられる．当然か!

    これからは，Twenty Twenty-Threeをベースに，慎重にコード追加に励みたいと思っていする．

    JavaScript基本編 (DOMの解説) -TCD-

    全13回で解説されています．

    https://tcd-theme.com/2021/05/javascript-dom.html

    編集履歴

    2023/10/27, Mr.HARIKIRI
    2023/10/28, 追記(Webページの構造，DOM数の違いは，効果的なのは，具体策の実施と結果(の予告))
    2023/11/12, 追記(新しく軽量テーマに変更するとともに，これまで追加してきたコードを全て捨てたことでDMOは解決)

  • [WP] WordPressをアップデートした途端にエラーを吐いてダウン，SnapShot Replicationを使用して瞬時に復元! パーミッションの設定方法[2023/09/23]

    [WP] WordPressをアップデートした途端にエラーを吐いてダウン，SnapShot Replicationを使用して瞬時に復元! パーミッションの設定方法[2023/09/23]

    Post Views: 274

    はじめに

    WordPressは，以下のようなファイル群で成り立っています．WordPressのバックアップは，それぞれのファイルのバックアップがされているなら、問題が生じて復元が必要となった場合，問題となったファイル群の復元によりWordPressを元にもどせます．

    1. データベース (MariaDB 10)
    2. WordPressのシステム(PHPファイル)

    WordPressがSynology NASに置かれているなら，プラグインを使用せずとも，PHPファイルの復元はSynology NASの標準機能を使って簡単に行うことができます．

    WordPress更新でスタック

    WordPressの新しいバージョンが出た時にアップデートすることになる訳ですが，例えば，WordPress 6.0や6.2など(x.0やx.x)の場合，細かなバグがまだ少なからず含まれている場合があります．そういった時に少なからず起こるのが，「WordPressの更新をした途端にWordPressがダウンする」ことです．

    また，最近知った情報では，WordPressなど関連するフォルダの権限設定について，WordPressのインストーラが厳格になったことで，以前のバージョンから新しいバージョンへの更新が途中で止まることが多々あるようです．フォルダのパーミッションの設定で以前にいじった記憶があり，それが原因として今回，何度目かのWordPress のバージョン更新で顕在化してしまったようです．現在，WordPress 6.2および，しばらく待った6.3も更新の途中でエラー表示を多数吐きながら，そのまま沈黙してしまいます(2023/08/19)．そうなると，もはや，サイトへの閲覧・アクセスは完全に閉ざされます．

    バックアップと復元

    このようなケースに対するWordPressの復旧は，データベース(MariaDB 10)の復元に関しては基本的に必要ではなく，プログラム自体であるPHPファイルなどのWordPressのシステムファイル群の復元を行うことで可能です．

    同様に，プラグインのインストールや更新においても、WordPressが問題を起こした場合の基本的な対策は，データベースを復元するのではなく、PHPファイル群の復元を行うこととなります．

    以下，これらPHPファイル群の復元に関して説明します．

    復元方法の概要

    データベース(MariaDB 10)のバックアップについては説明しません．

    当サイトでは，データベースのバックアップには，とりあえずインストールしたプラグインで対応しています．でも，復元に使用したことはありません．あまり，信じていないからですが．

    Synology NASでWordPressを構築しているのに，WordPressのバックアップ・アプリを使用することは，少し滑稽ですね．レンタルサーバーを使用してWordPressを構築している場合は，当然，WordPressのプラグインのバックアップ・アプリを使用してください．

    今回説明するPHPファイル群の復元では，Synology NASのバックアップ・アプリ: 「SnapShot Replication」を使います．SnapShot Replicationを使用するということは，その他色々なファイルに対して適応可能なシステム用バックアップツールであり，PHPファイルやWordPressに限定されないし，信頼性が高いと思っています．

    SnapShot Replicationは，指定した時間間隔毎に自動的に指定フォルダをバックアップし続けます．何世代までを残すのかの設定をしていれば，容量に困ることは少なくなります．

    もしも，WordPressの更新によりWordPressがダウンしてしまっても，Synology NASのDMSにログインして，SnapShot Replicationから直近で複製されたファイル群を復元してやればよいのです．でも，更新などを実行する場合は，SnapShot Replicationから事前にReplicationしておくのが上等です．

    以下，SnapShot ReplicationによるReplication(複製)とRestor(復元)の手順を示します．

    事前の状態のバックアップ

    WordPressの更新やプラグインの更新の前に，下図のようにSnapShot Replicationを起動して，”Replication -> Action -> Sync”を実行しシステム変更直前の状態を保持します．

    リストア(復元)

    更新作業を実行したものの失敗に終わり，サイトの閲覧・アクセスが完全に閉ざされた時は，以下の手順で事前に取った複製を使って復元します．

    1. DMSにログイン
    2. SnapShot Replicationを起動
    3. 左画面の復元(Recovery)をクリック
    4. 主画面にある複製リストを選択(例では，Web – Replicated)
    5. 復元(Recovery)をクリック
    6. 複製リストが現れる(例では，Recover – web)
    7. WordPressの更新(など)でWordPressがダウンする前，且つ最も新しい複製リストを選択する
    8. (因みに，Browseをクリックすると，複製されたフォルダ/ファイルが表示される．
    9. Action > Restore to this snapshot (復元)をクリックする
    10. (複製するスケジュール間隔が短くて，変更されたファイル数が少ない場合は，瞬時に復元は完了します)
    11. 復元完了
    12. 以上

    Ver.6.2.2でもダメ

    WordPress 6.1.3から6.2.2に更新してもWarnningを吐いてしまう．その後，WordPressは起動しなくなってしまった．

    Warnningはフォルダーの権限(パーミッション)設定にあるとのメッセージです．このメッセージが170余り続きます．どうやら173行面のfilesystem関連のようです．

    Warning: chmod(): Operation not permitted in /volume1/web/myblog/wp-admin/includes/class-wp-filesystem-direct.php on line 173

    以下に示したサイト*1の内容を参考に修正してから，もう一度WordPressの更新を行おうと考えている．今日(7/9)はここまで．

    *1, WordPressのパーミッション設定決定版

    (d/f) rwx rwx rwx
    r: read, w: write, x: execute

    https://qiita.com/hirai-11/items/f4d81f27886b623c5ef0

    備忘記録

    WordPressの更新プログラムの適用には，個人ユーザーで割り当てるのではないため，以下の設定は更新プログラムの適用には，基本的に関係がない．ただし，この設定の目的は，セキュリティを高めることである．

    – そもそものパーミッション設定値は

    ググった結果，一般的な値は以下の通り．環境によっても違った最適な値があると考えられるので，現状はこれで設定しても良いがが，最適値を知るには調査を継続して，塾講が必要である．それが専門家の一歩．

    パーミッション(permission; 権限)は，(所有者-グループ-その他)の並びでそれぞれ十進数では，一桁の0~7の数字で構成されている．差更に0~7は二進数では，三桁(rwx)で表される．r: read, w: write, x: executeの意味．r, wおよび xは，0または1であり，1の場合に権限がある．

    具体的な数値の意味としては，7は，フルアクセスであり，6の意味はread & writeとなる．

    以上の意味から，基本的に7, 5, 1は，めったに設定されない．

    1. .htaccess : 606 or 604
      • 606の左から6は所有者(owner)，0はグループ(group)，6はその他のユーザー
    2. wp-config.php : 400
    3. ディレクトリ : 705
    4. その他ファイル : 604

    NASでの作業 (コマンド編)

    パーミッション設定作業は，DSMではできない(?)か，当初は理解不足だったのでsshでログインしてコマンド操作で実施したが，それでもWordPressのUpdateはできなかった．おそらく，トップの「web」フォルダーを含めた設定が必要ではないかと考えられた．sshでのコマンドについて備忘記録をここに残しておく．

    <備忘記録>

    1. Login: ssh “<NAS IP Address>” -p “<port>”
    2. Command : sudo chmod 604 .htaccess
    3. command : sudo chmod 400 wp-config.php
    4. Command : sudo find . -type d -print|xargs|sudo chmod 705
    5. Comamnd : sudo find . -type f -print|xargs|sudo chmod 604

    NASでの作業(DMS編)

    そもそも，パーミッションの(所有者-グループ-その他)についてFileStationからプロパティを開いて，そのパーミッションにおけるパラメータとの対応がよくわからない．パーミッションの「所有者」とは? 「グループ」とは?

    例えば，そのパーミッション設定には，User or Groupとい設定項目がある．これは，(所有者-グループ-その他ユーザー)におけるどのことを示しているのか不明だ．User or Groupで「http」を指定したパーミッションは，いったい(所有者-グループ-その他)のどれにあたるのか?

    所有者/グループの見極めの答えは，こうだ．

    1. httpが所有者か，グループか，その他ユーザーかは，コントロールパネルのユーザー設定で判断できる．httpは，グループにあるので，httpはグループと判断できる．
    2. 同様に，httpsはグループである．

    以下のSynologyサイトにパーミッションの設定方法が記載されている．sshは，セキュリティ的にあまり使いたくないので，DMSのFileStationでパーミッションの設定ができるように，設定方法を調査した．

    トップの「web」フォルダーのパーミッションの設定は以下の通り，readまたはread & writeに設定する．

    1. webのプロパティー(properties)から
    2. Permission Editorを開く
    3. User or Groupを「http」に
    4. Inherit (継承) from を「<none>」のまま
    5. Typeを「Allow」に
    6. Apply toを「All」に
    7. Read，またはReadとWriteにチェック．

    以上の結果，機能しなくなっていたSiteGuard(以下に説明した)のCAPTCHAが表示できるようになった．

    How should I set access permissions to folders used for hosting websites?

    https://kb.synology.com/en-ca/DSM/tutorial/What_should_I_set_permissions_to_folders_for_websites

    Read設定では機能しないプラグイン

    SiteGuardというWordPressへのログイン制限が可能となるプラグインでは，ReadとWriteの設定になっていないとCAPTCHAが表示されない．

    Ver.6.3でもダメ

    最近，Version 6.3が出たので，WordPress 6.1.3から6.3に更新してみました．でも，同じように，同様の項目と数のWarnning を吐いて，そのまま沈黙して終了となりました．そこで少しググって，親のフォルダの権限に，「http」のRead権限を設定して，もう一度，Version 6.3で更新してみました．

    その結果，以下のWarnningを吐き沈黙しましたが，今回のWarnningの数は著しく少なくなりました．173行目のfilesystem関連のWarnningは出なくなりました．(実は，もう少し追加の設定が必要なのですが，それは，以下に完結しているので，もう少し読んでみてください)

    試行錯誤でのその他エラー

    試行錯誤してからWordPressの更新をする場合，以下のように表示が出て先に進まない時があります．その場合，データベースにインストールのイベント情報が入力されているため，WordPressのシステムファイルの復元では改善できません．15分間待つしかないようです*2．

    WordPress を更新
別の更新が現在進行中です。

    *2, WordPress「別の更新が現在進行中です」エラーの解決方法

    https://kinsta.com/jp/knowledgebase/wordpress-another-update-is-currently-in-progress/

    結局

    wordperssのupdateを可能にするには，結局，親フォルダでる”Web”へのアクセス権限として，”http”をオーナーを”Full Control: フルコントロール”に設定することで，無事にWordPress 6.3-jpで更新することが出来ました．

    1. 設定対象 : 親フォルダ”Web”
    2. “オーナ” また “http”による”フルコントロール: 管理・読取・書込”権限を設定した (一般的なLinuxのフルコントロールとは，rwxのうちx(実行)が無いため異なると考えられる)
    3. 設定は，FileStationからフォルダのプロパティを開いて行う

    やっぱり，”ホームNW研究所”の観音寺さん*3には，いつも助けられてばかりです．この場を借りて感謝します^^)．

    *3,WordPressの更新に失敗した時の対策
    – ホームNW研究所 –

    webを”フルコントロール: 管理・読取・書込”に設定する．

    https://nw.myds.me/synology/wordpress5-5-update/

    その後

    WordPressのUpdateはできたものの，その後，WordPressにログイン(SiteGuardプラグインから)しようとしたら，その機能てである「ひらがな」のCAPTCHAが表示されなくなっており，ログインができなくなっていたことに気づいた．

    調べてみると，以下のリンクに解決方法があったので，それをヒントに以下を適用した．

    気になる点は，httpのパーミッションがReadのみになっていたフォルダがあったこと．もしかすると，wordpressのUpdateの後処理として処理されている可能性も否定できない．

    1. FileStationから
    2. webフォルダのパーミッションについて
    3. httpを「read, write」をチェックした．
      (この設定は，おそらく，(所有者 – http – その他)において所有者はhttpと考えられるため (6-0-0)と考えることができる．「そもそもパーミッション設定値は」の項で述べた，600に設定されているものと思われる．要は，所有者以外がアクセスできないと理解すれば納得がゆく．
    4. ついでに，httpsにも「read, write」をチェックした．

    ワードプレス　SiteGuard　画像表示されない

    wpcontent -> plunins -> siteguard -> really-simple-captcha」のパーミッションを「777」にする

    https://server-recipe.com/1880/

    結局の設定値

    色々作業して混乱してしまったため，どれをどの順序で実施したのかはもう夢のかなたに行ってしましたが，現状では，以下のことが可能となっている．

    1. 試行錯誤の結果，wordpressのupdateが可能なままなのかは不明となってしまった．今後，wordpressのupdateの際に確認したい．
    2. SiteGuardによるログインは可能
    3. Plaginのupdateは可能

    まとめ

    自前のサーバーにWordPressを置いている場合，特にSynology NASを使用している場合での，WordPressの復元について，実際に生じた問題解決に迫られて実施した内容を解説しました．

    WordPressのバックアップにはデータベース(MariaDB 10)とシステムファイル群(PHP)の二種類が必要ですが，今回は，システムファイル群の復元について取り上げました．

    2018年からSynology NASにWordPressを設置してblogを行ってきましたが，システムファイル(PHP)絡みによるWordPressのダウンを何度か経験しました．

    PHPの復元については，Synology NASの場合，SnapShot Replicatonを使えば簡単に復元が可能です．ここでは，取り上げなかったデータベース(MariaDB 10)の復元についても，Hyper Backupを用いれば可能です．このことは，WordPressのバックアップには，プラグインを使用する必要はなく，NASの機能を使ってシンプルにWordPressを管理することが可能であることを意味します．

    WordPressに負担を掛けずに管理する，すなわち，NASに備わった機能を用いて管理するのは，エコだと思います．

    不具合のあったWordPressの更新バージョンはそっとしておいて，6.2.x (x.xx)がでるまでおとなしく待ち，6.3で更新をしてみましたが，結果は，同様にWarnningを吐いて完全停止になりました．

    バックアップの必要性は，結局問題が生じたときの備えです．今回は，関連フォルダのパーミッション不正によりwordpressのupdateが実行不可となったことで，その必要性を再認識しました．

    話題は転じて，WordPressの親フォルダのぱーミッションの設定に関しては，以下の経緯をたどりました．

    試行錯誤として，最初に「http」にRead(読取)権限を付与しました．その結果，数百に上る多数の173行のエラーはなくなりました．でも，その先の309行目のエラーが1つ現れました．

    更に，ググっていいくと「ホームNW研究所」に直接的な記事がありました．Webフォルダのパーミッションを　”フルコントロール: 管理・読取・書込”に設定するとwordpressのupdateはすんなり実行できました．

    そのご，しばらくしてwordpressにログインしようとした時，セキュリティの向上としてSiteGuardというプラグインを使用してCAPTCHAを表示させるようにしていましたが，そのCAPTCHAが表示されなくなっていました．

    結局は，httdのパーミッションがreadのみになっていたことが原因と結論しました．httdをreadとwriteにチェックを入れると，SiteGuardは正常に機能するようになりました．

    この設定により，最初にwordpressのupdateを可能にできたhttdの設定であるフル設定”フルコントロール: 管理・読取・書込”になっていません．今後，wordpressのバージョンアップがありupdateが必要な時には，この設定のままでupdateをしてみようと思います．

    試行錯誤はまだまだ続く–)

    編集履歴

    2023/04/16 Mr. HARIKIRI
    2023/07/09 追記: Ver.6.2.2-jpでも正常に更新できず，今後はパーミッション設定を中心にした対策を考える
    2023/08/19 追記: やっとこWordPress 6.3-jpで更新完了．Ver.6.3-jpでも同様にエラーで停止した．”http”に”Read”パーミッションを与えて173行のWarnningはやっつけた．でも，309行目のWarnningが出てきた．実は，もっと簡単でした．親フォルダへの”http”での権限設定は，”フルコントロール: 管理・読取・書込”にするとOKです．
    2023/08/20 追記: 備忘記録としてNASへのsshによるログイン，chmodの一括適用方法など．
    2023/09/23 追記: DSMのFileStationから「web」フォルダーのパーミッションを設定する方法．変更: タイトル変更 (パーミッション設定を追加)

  • [WP] 今日は，4つのプラグインを削除してシステムを軽くする [2022/10/22]

    [WP] 今日は，4つのプラグインを削除してシステムを軽くする [2022/10/22]

    Post Views: 229

    シンプルにするぞ

    連絡(コンタクト)は不可にすることとした．連絡は，コメントでもできるしね．それで，以下のプラグインを削除してシステムを軽くすることにしました．

    1. Ultimate Member – reCAPTCHA
    2. WPForm
    3. Contact Form 7
    4. Flamingo

    編集履歴

    2022/10/22 Mr. Harikiri

  • [blog/SNS] OGPとは/アイキャッチ画像 – 記事を複製すると前の記事に使用していたアイキャッチがSNSに表示されてしまう [2022/10/15]

    [blog/SNS] OGPとは/アイキャッチ画像 – 記事を複製すると前の記事に使用していたアイキャッチがSNSに表示されてしまう [2022/10/15]

    Post Views: 226

    OGP

    Open Graph Protcol (OGP)TwitterやFaceBookの投稿における表紙の画像カードのプロトコルらしい．

    WordPressでBlogを複製して新しい記事を作成する場合，アイキャッチ画像が，前の投稿の画像のままでTwitterおよびFaceBookに表示されてしまう．

    原因は，これらSNSでのキャッシュらしく，キャッシュを明示的に削除されば改善するとのこと．

    以下，関連情報を調べたので参考にしてください．

    SNSでシェアされた時のOGP画像キャッシュ更新方法をわかりやすく解説

    各種ツールの説明が充実しています．

    https://unicorn-blog.jp/archives/1963

    「Unable to render Card preview」と出るのは仕様らしい

    公式にはサービスが停止されているらしいが，Twitterでのキャッシャの廃棄は可能のようです．

    「Unable to render Card preview」の表示があったとしても，この処理をすることで，Twitterのキャッシャがフラッシュされるらしい．

    https://www.naporitansushi.com/unable-to-render-card-preview/

    Card Validation – Twitter development tool –

    https://cards-dev.twitter.com/validator

    WordPress FacebookのOGPをプラグインなしで指定する！

    https://usortblog.com/ogpheader/#toc2

    編集履歴

    2022/10/15 Mr. Harikiri

  • [用語] PSI; PageSpeed Insights [WordPress] [2022/09/04]

    [用語] PSI; PageSpeed Insights [WordPress] [2022/09/04]

    Post Views: 230

    PSI; PageSpeed Insights

    1. ホームページの表示速度をスコア化してくれるツール
    2. PageSpeed Insightsで、サイトのアドレスを入力するとサイトのスピードを測ってくれる
    3. モバイル端末とPCに分けて評価される
    4. モバイル端末の評価では，ホームページにAMPを導入しているとスコアが高くなる

    編集履歴

    2022/09/04, Mr. Harikiri
  • [blog] Mr. Harikiri が、blogを書く その簡単なルール [2022/11/06]

    [blog] Mr. Harikiri が、blogを書く その簡単なルール [2022/11/06]

    Post Views: 117

    初めに

    2018年後半から自宅NASにWordPressを構築し、blogを書いています。blogを書くにもNASの構成とは無縁にはできないので、「blogを書く」という内容を述べようと思いますが、NASの構築・設定に関する内容も含まれることをご了承ください。

    blogを書き始めた当初、その表現形式は先人のblogを参照しようとしました。でも、自分のWordPressのシステム環境に合う効率的な方法とマッチしないこともあり、結局は、試行錯誤を続けています。

    現在の「blogの書き方」を以下にまとめてみました(2022年)。

    端末

    iPad

    WordPressにログインする端末は、SIM付きのiPadを使用しています。iPadは画面タッチが基本的な操作ですが、WordPressは、マウス使用を前提にしているので、iPadでの編集作業は、少々窮屈です。それでも、出先で気軽にログインして編集することができるので、大変重宝しています。

    Note PC

    最近、SIM無しのLet’s Noteを手に入れました。Windows Note PCとしては、MicroSoftのSurface Pro 6を持っていましたが画面が小さくて、iPadよりも画面の発色や解像度が悪く、blog編集には使いずらく全然不向きで活用する機会はほとんどありませでした。

    見た目よりも重量があるSurface Pro 6より画面が大きく、当然、結構値が張ったLet’s Noteは、快適にblog編集ができます。ただし、Windows Note PCの画面は、iPadのガラス面とは異なるソフト使用の画面粗面なので発色は劣りますが、Surface Pro 6よりは断然快適です。

    タイトルのルール

    • 記事の管理のし易さのために「タイトル」には工夫しています。自分なりの型を設定して、タイトルを見ただけでどのようなblogもしくは、今では、広告用のページであるか、記事に出てくる「用語」の説明のためのページであるかを判断できるようにしています。
    • タイトルは、[(キーワード)] に続いてタイトルと[(最終更新日]を使用する。キーワードは、自分が理解しやすいテーマ毎に定義した独自のワードです。
    • 具体的には、
      • [キーワード] タイトル文 [2022/11/06] – ID1237
      • キーワードには、基本的にはカテゴリを使用。カテゴリには、たとえば、blog, WordPress, Trip, Health, Life Biologics, などがあります
      • タイトル文は、内容がわかるような文
      • 作成日/更新日として[xxx/xx/xx]の形式で記載
      • 記事のID番号として、IDxxxの形式で記載しています。
      • ブログページのパーマリンクの形式を、「(ドメイン名)/(カテゴリ名)/ページID」としていることで、以上のような形式に落ち着きました。

    イメージ画像

    アイコンなどのデザインは、デザイン素材から拝借も考えましたが、iPadのアプリ:Procreate Proを使用して独自で描いた図を使用することが殆どです。

    アイキャッチ画像は、記事のアイコンに使われるので、記事の内容をイメージできる画像(Procreate Proでデザインした画像や撮りためた写真)を使用するようにしています。

    写真の圧縮

    写真は、圧縮するプラグインとして有料のEWWWを使用しています。フルサイズと中サイズ、サムネイルなども使用可能枚数に含まれるため、画像をアップロードしていくと直ぐに使用可能枚数を超えてしまいます。最近は、スライドショーにできる画像は、iOSの写真でスライドショーの動画に変換し、YouTubeにアップし、blogからリンクする方法を順次進めています。必要でなくなった写真は、WordPressから削除することでEWWWプラグインで使用可能な数を増やさない工夫をしています。

    レスポンスのために

    記事の書き方では無いですが、サイトのレスポンスに関しては、AMPプラグインを使用して、レスポンスアップを図っています。使用しているプラグインの更新を実行すると、AMPに対応していたページ (「検証済みurl」)が古くなります。この状態で何もしないと、日単位か数日単位かで、次第にAMPの「検証済みURL」の数が少なくなって行く現象を確認しています。おそらく、そのままにしておくと最終的には、検証済みURLはゼロになると考えられます。無闇にプラグイン更新をしないようにして、まとめて一括更新を実行し、その後、速やかにAMPの「検証」をまとめて実施するようにしています。詳細なやり方は、以下に示しました。

    AMPページの管理

    1. プラグインの更新を実行した際は、その日の内に「検証済みURL」にリストされている記事について「再検証」を実施しなければなりません。
    2. そうしないと、「検証済みURL」リストからの削除処理が自動的に進みます。
    3. もしも、「検証済みURL」リストに表示されなくなった場合は、そのリストにない記事を特定して、投稿の投稿一覧からその記事を開いて、AMPの検証の処理を行わせなければなりません。
    4. 具体的にには、右上にあるAMPアイコンをクリックします。一旦クリックすれば処理はバックグランドで実行されるので、このページを離れても良いです。具体的には、ブラウザの戻るボタンをクリックして戻ります。一覧に戻ってきたら、同様に次の記事をクリックして表示させます。以上を機械的に繰り返すことができます。検証済みURLにリストされない記事が多くなった場合には、この方法でどんどん再リストしていきます。
    5. でも、この方法では、もしも1000もの記事があれば、1000の記事に対してこの作業を実施する必要があります。この方法に頼らないようにする派に、前述したように、無闇にプラグインを更新しないことと、更新した際には、検証済みURLにリストされている内に、最検証の処理を一括で実施するようにします。

    編集履歴

    2022/03/13, Mr. Harikiri
    2022/05/03, 文言整備、検証済みURLリストに再登録するやり方について文言整備
    2022/11/06, 文言整備および追記(項目「タイトル」の説明を充実化、使用している端末の説明)

  • [WordPress] 投稿の編集ができなくなった致命的エラー [2022/02/08]

    [WordPress] 投稿の編集ができなくなった致命的エラー [2022/02/08]

    Post Views: 290

    はじめに

    ある投稿の編集画面を表示させると以下の致命的エラーが発生しました。

    現状では、対策が不明なので備忘記録として残しておきます。とりあえずの対応は、urlからの表示は可能なので、その内容を別の新規投稿として転記することにしました。

    原因も不明ですが、もしかするとデータベースの内容が壊れたのかもしれません。以前にデータベースをバックアップしているので、そこから該当する投稿を抽出してリストアすればいいのですが、一つだけ投稿を取り出す方法がよく分からないので、前述の方法、すなわち、転記することで復活させようと考えています。

    復活後は、リダイレクト・プラグインで、そのurlを新しいurlに転送する設定をしておきます。

    Fatal error: Allowed memory size of 268435456 bytes exhausted (tried to allocate 69632 bytes) in /volume1/<WordPress Directory>/wp-includes/formatting.php on line 612

    和訳
    致命的なエラー：480行目の/volume1/<WordPress Directory>*/wp-includes/shortcodes.phpで許可されたメモリサイズ268435456バイトが使い果たされました（32768バイトを割り当てようとしました）

    このサイトで重大なエラーが発生しました。対応手順については、サイト管理者のメール受信ボックスを確認してください。

    WordPress のトラブルシューティングについてはこちらをご覧ください。

    * <WordPress Directory> : 便宜上のエイリアス

    編集履歴

    2022/02/08, Mr.Harikiri

  • [WordPress] AMP プラングインの運用 – DS920+のシステムメモリ(4GB)を8GBに増設すると一括検証可能数は、デフォルト「8」から「> 41」に増加 [2022/02/06]

    [WordPress] AMP プラングインの運用 – DS920+のシステムメモリ(4GB)を8GBに増設すると一括検証可能数は、デフォルト「8」から「> 41」に増加 [2022/02/06]

    Post Views: 298

    はじめに

    AMP プラグインを運用していく場合、最も時間がかかる処理は、AMP検証です。AMPプラグインがインストールされている場合、投稿の編集ページの右上に丸印で稲妻マークがあります。これをクリックすると、現在のバージョン(Version : 2.2.1)では、そのページについて再検証が実施されるようになっています。この方法で1つずつページを検証することも可能ですが、1000もページがあるとその作業は、退屈極まりないものになります。

    そこで、AMP->「AMP検証済みURL」ページから以下の作業で効率よく再検証することにします。
    このページを表示されて、表示オプションから表示数を100にすれば、100のページが表示できます。この状態で、左の「URL」のチェックボックスをチェックして表示されている全てのページを選択状態にします。その上に表示されている一括操作を「再検証」にして、その右横に表示されている「適用」ボタンをクリックすれば、一括の再検証が可能です。この機能を効果的に使えば、AMPページの管理はだいぶ楽になります。

    でも、自宅のSynology NASにWordPressを導入している場合、NASのシステム要件によっては、以下に説明したような制約がありました。対応策がやっと発見できたので、以下に解説してみたいと思います。

    AMP検証済みURLの更新

    新しいプラグインを導入したり、プラグインの更新をした場合、それまでのAMP検証済みのページは古くなります。そのため、AMP PluginによるAMP検証が再度必要です。

    以前、WordPressを導入していたNASは、DS918+でした。メモリーは、2つのスロットにアクセスできるので、標準の4GBを取り外し、8GB x 2で合計16GBにアップグレードしていました。その場合、一括して実施できるAMP検証のページ数は、最大「100」が可能でした。

    昨年、WordPressをDS918+からDS920+に載せ替えました。システム構成は、フルスペックとなったDS918+からすると、デフォルのままで、唯一、ストレッジをHDDではなく、4スロットともSSD: 1TB x 4 (slot)にアップグレードしていました。ところが、DS920+では、一括でAMP検証が可能なページ数は、どうしても「8」でした。これでは、全てのページを処理するには同じ操作が結構な回数になります。退屈極まります。

    今回、ふとアイデアが浮かんだので、システムメモリの増加を試みました。メーカー (Synology)が推奨しているメモリ : 4GB 1枚(Synology)を追加 (デフォルトのメモリスロットにはアクセスできない)しました。

    その結果、もう一つの懸案事項として取り組んでいるPageSpeed Insightでのスコアには変化がありませでした。

    しかし、前述で説明したAMP検証が可能なページ数は、少なくとも「40」に増加しました。一括の検証処理の過程でどうしても続行できない場合があるため、全てのページの処理が終わる前の処理の途中で一括の再検証処理が停止してしまうことがあります。その場合、スムースに処理できる予定の可能数よりも少なくなることがあります。40よりも最大可能な一括検証数が多い可能性もまだあるので、今後確認しようと思っています。

    因みに、AMP再検証の処理が継続しているかは、Synology NASのDSMにログインして、リソースモニターを起動して、CPUの稼働状況とネットワーク状況をグラフと数字で確認すれば判断が付きます。処理が終了した場合、CPUの稼働状況(%)、ネットワーク状況(KB/s)も一気に低下します。

    [s-text id=37723]

    [s-text id=37714]

    まとめ

    システムのメモリ容量がAMPプラグインの動作にここまで関係することは意外でした。

    型番仕様タイプ
    D4NESO-2666-4GDDR4-2666 260pinNon-ECC Unbufferd SO-DIMM 4GB
    https://www.synology.com/ja-jp/products/DDR4https://www.synology.com/ja-jp/products/DDR4

    AMP Plugin

    https://ja.wordpress.org/plugins/amp/

    編集履歴

    2022/02/07, Mr.HARIKIRI

  • [WordPress] ページスピード評価に使うPageSpeed Insightsの測定指標について – 少し解説

    [WordPress] ページスピード評価に使うPageSpeed Insightsの測定指標について – 少し解説

    Post Views: 408

    初めに

    2021/12/04
    サイトのスピードを評価するには、GoogleのPage Speed Insights (PSI)が使われます。PSIでは、以下の指標が測定されます。これらの指標の1〜4までは、以下に解説されている順にそのイベントが発生し測定されて行きます。指標5は、1〜4の合計です。指標6は、2021年に追加された画面の表示状態に関する指標で、スピードを直接的に測定するものではなく、「見た目の指標」であることを測定する指標になっています。

    2023/10現在，WordPressを使用しているなら，GoogleのSite Kit プラグインをインストールするとPage SpeedをWordPress内で使用できるようになる．フル機能版のWeb Siteにもリンクが張られるので，アドレスを忘れても問題ない．

    測定すべき重要な指標

    以下の解説は、web.devの解説の和訳ですが、分かりにくい部分があったので少し修正追記しています。

    ユーザーを指標としたパフォーマンス指標 – web.dev –

    https://web.dev/user-centric-performance-metrics/#how-metrics-are-measured
    1. First Contentful Paint (視覚コンテンツの初期表示時間、FCP): この指標は、ページの読み込みが開始されてから、ページのコンテンツのいずれかの部分が画面にレンダリング(が完了)されるまでの時間を測定します。(ラボ環境, 実際のユーザー環境)
    2. Largest Contentful Paint (最大視覚コンテンツの表示時間、LCP): この指標は、ページの読み込みが開始されてから、最もサイズの大きいテキスト ブロックまたは画像要素が画面にレンダリング(が完了)されるまでの時間を測定します。(ラボ環境, 実際のユーザー環境)
    3. First Input Delay (初回入力までの遅延時間、FID): この指標は、ユーザーが最初にサイトを操作したとき (リンクをクリックしたり、ボタンをタップしたり、JavaScript を使用して実装されたカスタム コントロールを使用したりしたとき) から、その操作に実際に応答するまでの時間を測定します。(実際のユーザー環境)
    4. Time to Interactive (操作可能になるまでの時間、TTI): この指標は、ページの読み込みが開始されてから視覚的なレンダリングが完了し、初期スクリプトが (あれば) 読み込まれ、ユーザーの入力に対してすばやく確実に応答できるようになるまでの時間を測定します。(ラボ環境)
    5. Total Blocking Time (合計ブロック時間、TBT): この指標は、長時間に渡りメイン スレッドがブロックされ、入力の応答性が妨げられることで発生する FCP と TTI の間の(各指標の)時間の合計を測定します。(ラボ環境)
    6. Cumulative Layout Shift (累積レイアウト シフト数、CLS): この指標は、ページの読み込みが開始されてからページのライフサイクルの状態が hidden に変わるまでの間に発生した予期しないレイアウト シフトの累積スコアを測定します。(ラボ環境, 実際のユーザー環境)

    編集履歴

    2021/12/04, Mr. Harikiri
    2023/10/08, 追記(WordPress pluginであるGoogle Site Kit)

  • [WP-Plugin] WP-Optimizeのキャッシュ機能はW3 Total Cacheに変更 [2021/10/25]

    [WP-Plugin] WP-Optimizeのキャッシュ機能はW3 Total Cacheに変更 [2021/10/25]

    Post Views: 281

    ID19320

    以下の記事はふるくなっています．当サイトでは，W3 Total Cacheは，プラグインの削減化を進めた結果，使用しなくなりました．

    キャッシュ プラグイン

    サイト読み込みの高速化にはキャッシュを使用することが1つの方法です。約1年前にW3 Total Cache (W3TC)をテストしたことがあります。当時は、Cache pluginの複数をインストールしてテストしていましたが、キャッシュが複数存在するとコンフリクトが生じる可能性があるため良くないようです。そんなことも分からずまま実施したテストの結果は以下の表の通りです。

    コンフリクトするから良くないと言いながらも、W3TCの追加効果は少なからず出ていたので、導入候補としては捨て難いと思っていました。

    当時は、W3TCは開発段階の初期あったせいか動作が安定しなかったため、導入を見送りました。

    W3 TCWP-OptimizeAutoptimizeFlying AnalyticsAMPPSI*1
    (Mobile, PC)    		Memo
    —Enable—Enable—(8, 20)
    —EnableEnableEnable—(20, 50)
    —EnableEnableEnableEnable(50, 95)Good,
    EnableEnable—Enable—(50, 95)Good, AMPプラグイン無しでも。
    Enable——Enable—(20, 50)
    Cache plugin : W3TC, WP-Optimize
    Code minify plugin : Autoptimize, Flying Analytics, AMP
    *1: PSI: Page Speed Insights

    再検討の理由

    今回、cache pluginを再検討することにしました。1年前の当時W3TCのバージョンは、まだ、1になっていない0.XX程度で初期開発段階のものでした。2021/10/25現在では、パージョンも上がり、機能も充実し痒いところに届くCache Pluginとなったようです。

    cache pluginを再検討することになった理由は、永続的なオブジェクト キャッシュ (Persistent Object Cache)が有効化されていないと、WordPressのヘルスチェックでメッセージが出ていることに気がついたためです。まず、このPersisten Object Cacheについて調査したところ、Redis CacheとW3PCが、それに対応していることがわかりました。これら記事の中には、Redis cacheとW3TCの２つを有効化する方法の記事もありましたが、W3TCのみでcache pluginの構成で過不足はありません。

    因みに、Redis cacheでは、Persistent Object cacheのワーニングは出なくなったものの、その他ワーニングが出ました。W3TCでは、そのようなワーニングもなく、しかも、WP-Optimizeのキャッシュ機能と比較して専用に作られていることもあり、痒いところに手が届く機能を搭載したcache pluginとなっています。これまで使用していたWP-OptimizeからW3TCに全面的に変更することにしました。

    W3 Total Cacheの設定方法と使い方 (2021/10)

    https://fox-wp.com/plugins/w3-total-cache/

    永続的なオブジェクトキャッシュは有効化されていません (2021)

    https://arakoki70.com/?p=6475

    編集履歴

    2021/10/26, Mr. Harikiri