MR.HARIKIRI-INSIGHTS

カテゴリー: WordPress

  • [WordPress] 遅延読込プラグイン比較 – (1)Lazy Loader, (2)Lazy Load, (3)a3 Lazy Load (2020) [2020/01/27]

    [WordPress] 遅延読込プラグイン比較 – (1)Lazy Loader, (2)Lazy Load, (3)a3 Lazy Load (2020) [2020/01/27]

    Post Views: 275

    画像遅延プラグインの効果

    以下の3つの画像遅延ローダーをGoogleのPageSpeed Insightsのスコアで比較しました。

    Lazy Loader
    LazyLoad Plugin – Lazy Load Images, Videos, and Iframes
    a3 Lazy Load

    画像遅延処理のPluginの有無でPageSpeed Insightスコアは、以下のように改善できた。

    結論

    結論から言うと今回の結果から、採用したPluginは、 「Lazy Load – Optimize Images Ver.2.3.2」です。

    評価方法

    例えば、以下のアドレスをGoogle Page Speed Insightsに入力して測定します。(https://harikiri.diskstation.me/myblog/wordpress/7804/)

    結果は、モバイル : 40程度　→ 50程度

    少し長文のページのスコアも測定しました。

    結果は、モバイル : 25程度 → 35程度

    比較検討したPluginのバージョン

    • Lazy Loader Ver.5.1.2
    • Lazy Load – Optimize Images Ver.2.3.2
    • a3 Lazy Load Ver 2.2.2

    結果の概要

    Lazy Load と Lazy Loader

    Lazy Load >= Lazy Loaderと、PageSpeed Insightsスコアで若干の差があったが、ほぼ同等。

    ただし、Lazy Loadでは、連続でスコアを測定すると、だんだん良くなる傾向がある。cache関係で相性が良いのかもしれない。

    a3 Lazy Load

    パソコンでのPageSpeed Insightsスコアが高く出る傾向がある。長文の投稿ページでは、スコアの改善が殆どなかった。これからのPage作りは、モバイル・オリエンテッドなどで、パソコンでのスコアは、以下の通り良かったが、採用を見送ることにした。

    ルート(myblog) モバイル

    • モバイル : 35⇨57
    • パソコンで91が最大値。その他のPluginでは、モバイル55が最大/パソコンでは、90を超えない(87程度)

    ルート(myblog) 長文ページ

    • モバイル : 25⇨25
    • パソコン : 65⇨91

    まとめ

    これまでに、Autoptimize プラグインによるCSS, JavaScriptなどの最適化、WP-Optimizeによるcacheのによる最適化、EWWW Image Optimizerによる画像の軽量化を検討してきました。今回は、画像の遅延表示によるPageSpeed Insightsスコアの改善を検討しました。

    1. Autoptimizeプラグイン (Java Script, CSSおよびhtml最適化)
    2. WP-Optimize プラグイン(キャッシュのみ有効化)
    3. EWWW Image Optimizer (画像の縮小化)

    総合改善度

    まとめに記載したように、ごく最近まで速度に関するスコアについて知識がなかったため、関連するプラグインは、何も入れていなかった。そのときのスコアから現在までのスコアの改善度は、以下の通りです。

    まだまだですが、当初のことを思えば、劇的な改善度です。

    PageSpeed Insightsスコア: Plugin導入前からの変遷

    ルート(myblog)

    長文のページ

    • モバイル : 2~3 → 50程度
    • モバイル : (未測定) → 35程度

    以上

  • [WordPress] WP-Optimizeのキャッシュの設定 – Autoptimizeとの併用効果

    [WordPress] WP-Optimizeのキャッシュの設定 – Autoptimizeとの併用効果

    Post Views: 503

    ID14373

    AutoptimizeとWP-Optimizeの併用

    前回のAutoptimizeの設定では、cacheは逆効果でした。

    (当時の記事の補足。原理をよく考えるとわかりますが、キャッシュは複数あるとコンフリクトを起こしてしまうため、複数のキャッシュ・プラグインの使用は避けるべきです。導入した結果がよかったとしても, 2021/10/30 by Mr. Harikiri)

    ページのスピードアップをするには、以下の知識が必要です。この記事の中では、このことを知らずにテストしていた頃の記事なので、以下の知識について先ずは知っておいてください。

    Googleは、モバイル・ファーストとしてAMPという技術/ルールを提唱しています。このルールは、過度なJava, CSSなどのコードをシンプルにするように求めています。それによって、軽量化されてページの読み込みスピードが向上します。AMPに対応させるにはプラグインを使用することができます。その場合、この記事の中で評価しているAutoptimizeプラグインは、使用を避けてください。その理由は、AutoptimizeがAMPに対応していないからです。AutoptimizeもAMPと同様の目的にJava, CSSのコードを軽量化する独自の方法を使っています。おそらくコンフリクトします。blogをAMPに対応させない場合は、Autoptimizeプラグイン、または、その他の同様のプラグインを、AMPに対応させるには、AMPプラグインを使う用にして、それぞで使い分ける必要があります。

    キャッシュ・プラグインは、AMPプラグイン、Autoptimizeプラグインとは異なる原理で動いているので、併用は可能です。その場合、AMPプラグインに適するキャッシュ・プラグインがあるとでしょう。同様に、Autoptimizeプラグインに適したするキャッシャ・プラグインがあるはずです。

    [WordPress] Autoptimize プラグインの威力 – ブログ・サイトのスピード改善対策プラグイン – 更にAMP対応まで進めた結果 [2020/05/15] ID7804

    PageSpeed Insights

    https://pagespeed.web.dev

    WordPressのdatabaseの最適化に、WP-Optimizeをインストールしました。

    このプラグインには、cache機能もあります。cacheをONにしてPageSpeed Insightsで測定しました。

    WP-Optimizeには、画像の遅延読み込み「Lazy Load」機能があるため、EWWW Image Optimizerなどを使っている場合、同じ機能がdefaultで有効になっているので、どちらかを無効に設定します。コンフリクトするとPageSpeed Insights (PSI)のスコアが5ポイント程低下します。

    その他の設定は、前回の記事を継承しています。

    結果

    WP-Optimizeプラグインのcache機能をONにしてSPIモバイル・スコアを測定した結果、更なる速度改善の効果があり、Autoptiizeプラグインとの併用効果が確認できました。

    WP-OptimizeプラグインのPage cachingをしない場合、ページスピードは、モバイル/パソコンそれぞれ40/68でした。

    1E5ED779-BEC4-4081-B65B-E843B42BD4FF
    D9408D1E-0710-40E4-8726-784D7376882B

    WP-OptimizeのPage cachingをONすると、ページスピードは、モバイル/パソコンそれぞれ52/82となり少し速度が改善しました。

    • cache: off – SPIスコア:
      • モバイル : 40
      • パソコン : 68
    • cache: on – SPIスコア:
      • モバイル : 68
      • パソコン : 82

    まとめ

    PageSpeed Insightsによるモバイル・スコアは、cacheをONにすることで、モバイル40→52、パソコン68 → 82にスピードアップしました(2020/01/25現在)。

    編集履歴

    2020/01/25 はりきり(Mr)
2020/05/29 文言整備、追記(まとめ)
2021/11/20,修正(モバイル/パソコンの測定データのソース写真取り違え)
  • Google Search Console – PageSpeed Insightsを使う

    Google Search Console – PageSpeed Insightsを使う

    Post Views: 188

    Google Search Console

    日々のアクセス状況(検索での表示回数、クリック回数、クリック率など)をグラフやテーブルで示してくれます。

    Google Search Consoleへの登録の仕方は、他のBlogerの皆さんに任せて、ここでは述べませんが、最近特に気になっている、ユーザーエクスペリエンスの向上のためのページの反応性の測定です。その測定のために、Google Search Consoleを頻繁に使っています。

    サイトの賑わいは、記事の内容、読み易さ、タイムリー性、あと、表示速度が主に考えられると思います。

    表示速度については、Googleは、スマートフォンを中心にページをデザインすべきであると言っています。どんどんPCではネットサーフィンしなくなり、スマフォかタブレットになっていますね。

    当サイトも、Synology NASにWordPressサーバーを立ち上げて、1年になりますが、GoogleにIndexしてもらうという意味もようやく分かり、この記事を書いています。

    Page Speed Insightの使い方

    まだ試験運用版とのことですが、サイトのペード毎に速度を測定できます。

    方法

    Google Search Consoleに飛び、左タグから「速度(試験運用版)を探しタップすると、「Page Speed Insights」のリンクが現れる。

    入力欄にサイトのページアドレスを入力し、分析をタップする。

    結果の見方

    しばらくすると、円グラフで、ページの総合的な速度評価(速度スコアは、Lighthouseでの測定に基くとあります)が表される。

    下方にスクロールすれば、測定結果と改善可能な問題に対する対策が示されています。自分のサイトの速度的な弱点を客観的に知ることができる。

    • フィールドデータ
    • Origin Summary
    • ラボデータ
      • First Contentful Paint (秒)
      • First Meaningful Paint (秒)
      • 速度インデックス(秒)
      • CPUの初回アイドル(秒)
      • インタラクティブになるまでの時間(秒)
      • 初回入力遅延の最大推定時間(ミリ秒)
      • ページが表示される様子を写真のスナップショットのように左か右へ10枚の画像で表示される(表示が早いと、左側から表示が始まる)
    • 改善できる項目 (改善可能な項目が表示される、短縮できる推定時間)
      • オフスクリーン画像の遅延読み込み(sec)
      • レンダリングを妨げるリソースの除外(sec)
      • 適切なサイズの画像(sec)
      • 使用していないCSSを削除指定ください(sec)
    • 診断 (減らせるデータ量)
      • ウェブフォント読み込み中のテキストの表示 (ms)
      • 静的なアセットと効率的なキャッシュポリシーの配信(ms)
      • メインスレッド処理の最小化(ms)
      • 過大なDOMサイズの回避(値)
      • JavaScriptの実行にかかる時間の低減(sec)
      • クリティカルなリクエストの深さの最小化(ms)
      • リクエストの数を少なく、転送サイズを小さく維持してください(KB)
    • 合格した監査(数)

    当サイトは、Synology NASでWordPressサーバーを個人的に立てているので、管理の行き届いたレンタルサーバーではないため、自分で反応速度などのユーザービリティを調整しないといけません。

    当サイトの反応速度の改善記事は、以下をご参照ください。

    [WP] Autoptimizeの威力 – ブログ・サイトのスピード改善対策プラグイン

    https://harikiri.diskstation.me/myblog/wordpress/7804/
  • [用語] Lighthouse; webサイトのパフォーマンス測定プラグイン

    [用語] Lighthouse; webサイトのパフォーマンス測定プラグイン

    Post Views: 202

    Lighthouseは，Googleが提供するwebサイトのパフォーマンス，アクセシビリティ，SEOなどを測定するツール．WindowsのブラウザChromeの拡張機能として利用できる．

    Lighthouse（ライトハウス）とは？Google公式のSEOチェックツールをご紹介 (2019)

    Lighthouse（ライトハウス）とは？Google公式のSEOチェックツールをご紹介-エムタメ！ (mtame.jp)

    編集履歴

    2020/01/23, MR.HARIKIRI

  • [WordPress] Autoptimize プラグインの威力 – ブログ・サイトのスピード改善対策プラグイン – 更にAMP対応まで進めた結果 [2020/05/15]

    [WordPress] Autoptimize プラグインの威力 – ブログ・サイトのスピード改善対策プラグイン – 更にAMP対応まで進めた結果 [2020/05/15]

    Post Views: 509

    概要

    当サイトのGoogleSpeed Insightsで、サイトのスピードを測定(2020/02)したところ、モバイルでのスピードは、4~5%でした。そこで、サイトスピードを改善するプラグインを検討したところ、「Autoptimize」を基本に、その他キャッシャ関連のプラグインを組み合わせると、10倍程度の劇的な改善(40%程度)が可能でした。

    1. サイトのレスポンス改善プラグインを未導入: モバイル・スコアは4~5%
    2. Autoptimizeプラグイン導入 : モバイル・スコアは40%

    サイトのスピード

    自分のサイトのスピードを知るには、Google Search Consoleを使っているなら、速度(試験運用版: PageSpeed Insights)で測定してくれます。

    お知り合いになっていただいている観音寺さんから、当サイトの速度が遅いことのご指摘を頂き、測定してみたところ、その結果は、4~5%とさんざんでした。

    これでは、誰もみてくれませんね。

    また、Chromeの拡張機能(Windows版)の「Lighthouse」でもサイトの速度を測定してくれます。Lighthouseでは、50%程度の結果でした。
    (Google Search Consoleは、どうやらLighthouseのエンジンを使っているようですが、測定結果は少し異なっているようです)

    そこで、対策としてプラグイン (Plugin)を探してみました。試したのは、

    「Autoptimize」

    です。

    PageSpeed Insightsの測定で、4~5%であった性能が、20~30%に劇的に改善しました。

    その後は、微調整を行いました。キャッシュ(cache)も当然良いのでは無いかと思って、キャッシュ・プラグイン (cache plugin) の併用効果として、

    「WP Fastest Cache」

    で確認しました。当サイトの環境ではこのプラグインでは逆効果でした。

    最後に、Google Analyticsが、時間を食っているのがわかったので、

    「Flying Analytics」

    https://wpspeedmatters.com/how-to-optimize-google-analytics-in-wordpress/

    で、Google Analyticsをミニ化してその改善具合を確認しました。

    詳細は、以下ご覧ください。

    サイトの測定結果の概要

    Autoptimizeの有無での測定概要は、以下の通りです。

    • PageSpeed Insightsでは、モバイルでの速度が4~5%、それが25%に改善　(これでは、まだまだですが、改善度は高いです)
    • Lighthouseでは、50%から90%、更に100%に改善

    さらなるスピードアップには、その他プラスアルファのPluginをリコメンドしてくれています。

    以下は、JavaScript関連、CSS関連、HTML関連について設定の有無で、どれだけ効果があったかをテストしてみました。

    Autoptimizeの効果 – Page Speed Insights測定

    Page Speed Insightsでの測定に際して、Autoptimizeの設定項目は、以下で行った設定検討の結果を元にして決めた項目にて、測定を行いました。

    AP-1 Autoptimizeプラグイン無し – 1回目測定
    AP-2 Autoptimizeプラグイン無し – 2回目測定
    AP-3 Autoptimizeプラグイン有り – 1回目測定
    AP-4 Autoptimizeプラグイン有り – 2回目測定

    図1. Autoptimizeの効果 – PageSpeed Insights測定結果

    Autoptimizeの効果 – Lighthouse測定

    設定項目を、(1)CSS, (2)JavaScriptおよび(3)HTMLの順番で、効果の出そうな順に設定し、Lighthoutsで測定しました。

    Autoptimize無し

    21%のPerformanceしか出ていません。

    図2. Autoptimizer未設定(1) AP-5

    Autoptimize有り

    以下では、Autoptimizeで各設定項目を段階的に有効化したときのLighthouseでの測定結果です。

    連続2回措定しました。cacheが効いているので、2回目の結果は少し良い値が出ています。

    • CSSコードの最適化
    • JavaScriptの最適化
    • HTMLの最適化

    (1) CCSコード設定

    CCSコード最適化を☑️
    Aggregate CSS-files?☑️
    インラインのCSSを連結☑️

    図3. 設定項目 AP-6
    図4. Autoptimizer/CSSセット後(1) AP-7
    図5. Autoptimizer/CSSセット後(2)-cacheが効いている AP-8

    (1+α) CSSコード設定に更に、データを生成:画像をURI化を追加

    CCSコード最適化を☑️
    Aggregate CSS-files?☑️
    インラインのCSSを連結☑️
    データを生成 : 画像をURI化☑️

    図6. AP-9
    図7. Autoptimizer/CSSセット(1)後(1)-初回測定 AP-10
    図8. Autoptimizer/CSSセット(1)後(2)-cacheが効いている AP-11

    以上の結果から、「データを生成 : 画像をURI化」は、あまり効果がなさそうなので、このチェックは外すことにします。

    (2) +α : JavaScript設定

    Aggregate JS-files?☑️

    図9. JavaScriptオプションをセット AP-12
    図10. JavaScriptコードの最適化 AP-13

    JavaScriptコードの最適化の効果はあるようです。

    (3) +α : HTMLオプション – コード最適化

    HTMLコード最適化を☑️

    図11. HTMLオプション AP-14
    図12. +α: HTMLコード最適化 – 初回測定 AP-15
    図13. +α: HTMLコード最適化 – 2回目測定 – cacheが効いている AP-16

    HTMLコードの最適化はそこそこ効果があるようです。

    最終的に設定した内容

    最終的に、以下の通りの設定に落ち着きました。

    • Autoptimize : JavaScript(JS)、CSSの設定のみ(数参照)
    • Cache : WordPress Pluginは不要、DS918+のSSD cacheがワークしているものと思われる
    • Google Analytics : 速度性能にそれほど寄与しないが、しばらくミニGoogle Analyticsを使用してみる
    AP-17
    AP-18
    AP-19
    AP-20
    AP-21

    プラスアルファ

    その他の併用効果

    (1) WP Fastest cache

    キャッシュの併用も試してみました。WP Fastest Cacheです。Fee版でも多数の設定項目があります。色々設定して、Page Speed Insightsで測定してみました。結局、無い方がスコアが高く出ることがわかりました。

    当サイトのWordPressはSynology DS918+に立てています。SSD cacheも追加で積んでいます。WP Fastest cacheの効果が出なかったのは、おそらく、SSD cacheがあるためと考えれます。二重のcacheは必要ないということですね。

    (2) Flying Analytics by WP Speed Matters

    最適な設定の組み合わせを探して、試行錯誤で設定、PageSpeed Insightsで測定を繰り返し、その結果を眺めていると、Google Analyticsが結構じゃましているようなレポートがあるのに気が付きました。

    以下の測定結果は、All in One SEOに、Google Analyticsを設定した条件で測定した結果です。

    以下の測定結果は、All in One SEOに、Google Analyticsを設定した条件で測定した結果です。レペートの診断結果の項目に「第三者のコードの影響・・・」とあります。次の図には、その詳細を示していますが、Google Analyticsが866msも使っています。

    デフォルトのGoogle Analytics
    モバイル AP-22
    パソコン AP-23
    Flying Analyticsを使用しない場合、第三種コードの影響、についてレポートされる　AP-24
    Flying Analyticsを使用しない場合、第三種コードの影響にGoogle Analyticsが866msも関与していることがレポートされた AP-25
    ミニサイズのGoogle Analytics

    以下の測定結果は、All in One SEOから、Google Analyticsを外して、代わりにFlying AnalyticsでミニサイズのGoogle Analyticsを設定した場合の測定結果です。

    Flying Analyticsを使用して、Minimal Analytics(1.4KB)に設定する AP-26
    モバイル AP-27
    パソコン AP-28
    All in One SEO pluginにGoogle アナリティクスを設定しない AP-29
    Flying Analyticsを使用すると、第三種コードの影響、についてレポートされない AP-30

    PageSpeed Insightsによる最終的な速度レポート

    以上の設定を全て組み込んで、PageSpeed Insightsで測定しました。

    当初、1桁だった速度性能が、モバイルで50%程度、今回の取り組み始めには、パソコンでの性能評価は、気にしていなかったため、パソコンの速度性能値は、参考値になりますが、モバイルよりも　高い値のがでます。

    モバイル
    AP-31
    AP-32
    AP-33
    パソコン
    AP-34
    AP-35
    AP-36

    まとめ

    指摘を受けなければ気がつかなかった、サイトの速度でしたが、当初1桁であったのが、50%まで速度性能を改善することができました。約10倍です。

    • JavaScriptの最適化
    • CSSの最適化
    • HTMLの最適化
    • Cacheの設置(Synology NASにSSD搭載のため、プラグインは逆効果)
    • Google Analyticsは、1/10にしたミニ化も少し寄与
    • Google Font: 削除設定で、モバイルが5~10ポイント早くなることを確認。測定毎に約半分の確率でスコア50を超えるようになった(ページの作りも簡素化していることも良い影響がでている)。しばらくこの設定で運用することにした(2020/02/13)

    今後

    更なる速度改善は、以下の項目が考えられますが、個人サイトで出来るものとそうでないものもリストしました。

    • WordPressのDatabase関連 : 最適化でできるらしい
    • 別のCache Plugin : WP Optimizeはすでにためしてみました
    • PHPバージョン : Ver.5よりVer.7が早らいしい
    • Budget.json: よくわからないキーワードですが。
    • DOM : 1500以下に抑えなさいと言われますが、綺麗に見せるstyleにするとトレードオフです。
    • CDN : 個人では無理?
    • インフラ頼み : 5G、今回のこんな苦労は要らなくなるかも

    追記

    その後、いろいと調べていると、Googleは、Mobile Firstであり、モバイルに対して特化したページ作りを求めていることが分かりました。

    既存のページをAMP(Accelerate Mobile Page)という技術で、速度改善を可能にする開発を行なっていることも分かりました。

    結局のところ、現在のページは、今後、生き残らないと判断し、AMP対応ページに移行することにしました。

    2020/2/3からAMPプラグインをインストールして、セッティングを開始しましたが、2ヶ月経過した時点で、広告の表示やページ表示の不具合なども解消できました。

    AMPプラグインにより、ページの表示速度は、GoogleSpeed Insightsのモバイルのスコアで、キャッシュプラグインを有効にしてですが、60~70%にまで改善しました。

    AMP対応にするには、プラグインを使用しますが、これを使うと、「Autoptimize」プラグインの使用は、必要無くなります。

    編集履歴

    2020/01/25 はりきり(Mr)
    2020/02/13 追記 (Google Fontの削除設定)
    2020/02/23 AMPに対応
    2020/04/15 「追記」を追記
    2020/05/15 文言整備

    関連記事

  • [WordPress] 親テーマを変更せずテーマをカスタマイズ – 子テーマを作り変更したを加える – 手始めは、content.phpの編集

    [WordPress] 親テーマを変更せずテーマをカスタマイズ – 子テーマを作り変更したを加える – 手始めは、content.phpの編集

    Post Views: 212

    親テーマと子テーマ

    いつまで続くか分からない当サイトの構築ですが、プラグインやphpファイルの変更など、他のblogerさんの記事を参考にさせてもらっていいます。

    今回は、WordPressテーマ: Twenty Twentyを親テーマとして子テーマを作りました。

    テーマの編集

    作った子テーマが有効になっていれば、「テーマの編集」画面の右上にある「編集するテーマを選択」にその子テーマのリストが出てきます。図1のように、twentytwenty_child (この名前は、実質的にフォルダ名)があるので、このテーマが有効化していれば、表示されます。以下、図1の説明です。

    style.cssの編集

    表示の体裁を変更する場合は、style.cssのコードの変更、コードの追加が必要です。以下のコードは、当サイトの目次の体裁を定義したものです。

    /** 見出し
*/
/* h2
#contentを付けると左端に表示されるのが、幅に従った左端に改善できる
*/

h1,
.heading-size-1 {
	font-size: 3.2rem;
/*	font-weight: 800;
	line-height: 1.138888889;
*/
}

h2 {
	font-weight:600;
	font-size:3.0rem;
	color: #fff;
  background: #2a49a8;
  padding: 15px 30px;
}
h3 {
	font-weight:500;
	font-size:2.8rem;
	/* 見出しの飾り */
  padding: 0.25em 0.5em;
  color: #2a49a8;
  background: transparent;
  border-left: solid 50px #2a49a8;
}
h4 {
	font-weight:500;
	font-size:2.6rem;
/* 見出しの飾り */
	border-bottom: solid 3px black;
	
}
h5 {
	font-weight:500;
	font-size:2.4rem;
/* 見出しの飾り */
	/* border-bottom: solid 3px black; */
	
}

h6 {
	font-weight:500;
	font-size:2.2rem;
/* 見出しの飾り */
	/* border-bottom: solid 3px black; */
	
}

    content.phpの編集

    表示の構造自体を変更する場合は、content.phpのコードの変更、コードの追加が必要です。

    content.phpが、WordPressにおける投稿や固定ページの表示を行っているメインのphpプログラムです。図1の例では、content(org).phpやcontent([番号])が、確認できると思います。

    これは、プログラミングに際し、僕が格闘した結果の残骸です。捨てられずに残しています。content(org).phpは、オリジナルファイルです。元に戻す場合は、このファイルをcontent.phpに名前を変更したして置き替えます。

    基本的に、子テーマでのこれらの修正は、親テーマの上書きになっているようです。

    ファイルの複製や名前の変更は、WordPressからはできません。端末ソフトを使ってサーバーに入り、コマンドにより名前を変更したり、複製したりする必要があります。

    当サイトでは、自宅のSynology NASにWordPressを導入しているので、Synology NASにログインして、DiskStation Managerのもとで、名前の変更、複製をします。その後、WordPressにログインして、「テーマの編集」画面に入れり、該当するするphpファイルのプログラムの内容を修正・追加していきます。

    修正した後は、左下にある更新ボタンで修正内容を保存します。その結果は、直ぐにblogに反映されるので、サイトをSafariやChromeで表示して確認します。

    このcontent.phpでのコードのミスは、即座に表示を崩していまうことを意味しますが、以下に記述したように元のコードに戻したり、追加したコードを削除して元に戻せば表示も元に戻ります。

    画面が崩しれたりした場合、「テーマの編集」画面から、Ctrl + zにより元に戻して、更新ボタンを押せば、元に戻ります。

    WP テーマ編集
    図1. content.phpの編集
    content.phpの編集と言っても、使用しているThemeごとに異なります。当サイトでは、WorpPress version 5以降で公式テーマになっているTwenty Twentyを使っています。標準のcontent.phpでは、表示のが味気ないので、coverタイプ (content-cover.php)をcontent.phpに置き換えています。同じTwenty Twentyのcontentではが、コードを確認してみるとだいぶ作りが異なっていました。

    functions.phpの編集

    オートセーブとリビジョン機能

    親テーマでは、標準で有効となっている編集時のオートセーブ機能とリビジョン機能ですが、子テーマの「functions.php」にコードを追加することで、無効化することが可能です。以下のリンクをご参照ください。

    macoblogさんより

    https://macoblog.com/wp-writing-autosave/

    まとめ

    親テーマと子テーマの関係性が、まだよくわかっていません。

    • 親テーマと子テーマは、themeフォルダに別フォルダで保管される。
      • 今回の場合、元からあった親テーマである「twentytwenty」と今回作ったフォルダとしての子テーマ「twentytwenty_child」を作りました
    • 編集するfunctions.phpやhead.phpなどのファイルを、親テーマからコピペしておく。
      • 同じ定義のものは、親テーマで定義されるので、小テーマでは削除します。ほとんどが削除されたになります。
    • 親テーマと子テーマの関わりをfunctions.phpに記載とておく。
      • 小テーマが使われるように定義 : 参照
    • 子テーマにない定義、値など
      • 親テーマの定義、値などを小テーマが引き継ぐ
    編集情報
ID 7726
2020/01/21 Mr.はりきり
2020/07/23 追記(concent.phpの編集)

    以上

  • [WordPress] プラグイン: GT3 Photo とTooltips は相性が悪い – [2020/01/21]

    [WordPress] プラグイン: GT3 Photo とTooltips は相性が悪い – [2020/01/21]

    Post Views: 194

    プラグインの相性

    GT3 Photo GalleryはGutenberg editorで使用できるGallery pluginです。

    Tooltipsは、日本語と英語の混在でも、単語を適切にサーチして吹き出し化できるpluginです。

    Tooltipsを有効にしてある場合、GT3 Photoで20-30個の写真を投稿に入れると、管理画面からの保存も読み込みも著しくその速度は低下します。Tooltipsを無効にすると快適な速度に戻りました(2020/01現在)。

    2020/04現在は、AMPプラグインによりAMP対応にしました。AMP下、GT3 Photoプラグインは、綺麗に見せることが売りのプラグインであったため、AMPのルールである、JavaScriptの複雑なコードを許さないことから、エラーするコードが多くありました。

    そこで、GT3 Photoプラグインは外すことにしました。Tooltipsプラグインは、使っていませんが、現在は、同様の機能であるEncyclopediaプラグインを導入しています(2020/04現在)。

    2021/01/02, AMP対応を更に進めるために、AMPプラグインが検査してAMPに非対応であるとリストされるプラグインを極力アンインストールしようと思い立ちました。まずは、Encyclopedia(せっかく、有償版を購入したが)をアンインストールすべく、これまでに登録したキーワードを、普通の投稿(post)に置き換える作業を進めています。完了すればEncyclopediaはアンインストールする予定です。

    Encyclopedia / Glossary / Wiki

    改善策は、Encyclopediaを使用することにしました。

    • 日本語・英語の混在でもいずれのワード種でも吹き出しが可能
    • GT3 Photoとの相性は悪くない
    CM Tooltip Glossary
    Glossary
    LuckyWP Glossary

    CM Tooltip Glossary、GlossaryおよびLuckyWP Glossary,は、いずれも、日本語・英語の混在下では、英ワードを認識できない場合があります。具体的には、「is word単語」の場合、wordを認識できません。英語は単語の間に空白があり、日本語には空白がないことが原因だと考えられます。

    編集履歴

    2020/01/21, Mr.Harikiri
    2021/01/02,追記(Encyclopediaをアンインストールすることに決めた)

  • [Synology] NASに装着した新品SSDが1年後にエラーを吐いた – 修復・復旧方法 – △[2020/05/03]

    [Synology] NASに装着した新品SSDが1年後にエラーを吐いた – 修復・復旧方法 – △[2020/05/03]

    Post Views: 540

    ID7504

    SSDがエラーした

    1年前、DS918+にWD製SSDを2枚挿してWrite/Readのキャッシュ(cash)を構築していた。ほぼ1年後の昨日、2枚のうち1枚にエラーがあると、DSMから警告があった。

    ハードウェア的に故障と思ったが、調査の結果、SSDの「復旧」から元に戻すことができた。

    故障日2020/1/18

    SSDキャッシュの再構築

    1. 「ストレージマネージャ」を起動
    2. SSDキャッシュの劣化を確認
    3. 修復ボタンを押して、修復するSSDを選択する
    4. 修復が開始される
    5. SSDキャッシュが再構築されるまで、30~60分程度
    ストレージマネージャ
    ストレージマネージャ SSD-1
    ボリューム - ボリューム1の劣化を確認
    ボリューム – ボリューム1の劣化を確認 SSD-3
    SSD キャッシュ - 2枚のSSDの内、2枚目のSSDが不明となっている
    SSD キャッシュ – 2枚のSSDの内、2枚目のSSDが不明となっている SSD-4
    SSD キャッシュ - 「修復」ボタンをおす
    SSD キャッシュ – 「修復」ボタンをおす SSD-5
    SSDを選択
    SSDを選択 SSD-6
    適用 SSD-7
    確認画面が出る SSD-8
    SSDの修復が開始 SSD-9
    修復完了後の画面 SSD-10
    SSD キャッシュ – 正常 SSD-11

    1年前に2枚のSSDを装着して、すぐに今回とは異なる方のSSDがエラーを吐いた。その時は、WDのサポートに連絡して無償交換(中古らしい)してもらっている。

    しかし、SSDの「復旧」ボタンは試しかは、覚えていないため、本当に故障だったのか不明だ。WDでもそのように返品されてくるSSDが多くあり、それを5年保証の代替として、クレーム先に送り返しているのであろう、と今更に申し訳なく思う。

    今回は、返品せずに済んだ。

    以下の記事は、WDのSSDをSynology DS918+に装着した時の内容と、SSDの返品に関するWDのサポート再生の様子をまとめたもの。

    [Synology] NAS DS918+のcacheとして挿していた2枚のWestern Digital (WD)製SSDの内、1枚が不調になったので交換 ID14317
    [Synology] NASの追加メモリ – WD Black SSD 製品の故障対応はこんな感じでした [2019/07/26] ID1089
    [Synology] DS918+ 初期導入時にはJBOD HDD、その後、メモリ増設・SSDキャッシュ増設・HDD追加でRAID 5によりフルスペック化 — アプリ/ツール構成 [2021/08/28] ID33

    編集履歴

    2020/05/03 文言と体裁整備

  • [WordPress] 用語の説明を吹き出しする「Glossary / Tooltip 」プラグインを導入すべきか [2020/04/20]

    [WordPress] 用語の説明を吹き出しする「Glossary / Tooltip 」プラグインを導入すべきか [2020/04/20]

    Post Views: 505

    ID7146

    はじめに

    blog記事の中で、一般的でない用語について説明した方が読者にとっていいはずです。しかし、読みづらくなるのは本末転倒。手頃なプラグインはあるでしょうか?

    WordPressの投稿にGlossaryまたはTooltipsはあった方がいい

    説明したい用語について、末尾に説明しておき、投稿内でアンカーを貼るのもいい。しかし、記事を読んでいる途中で用語の意味を知りたくてジャンプしてしまうと読書性が低下する。

    それなら、吹き出し式のGlossaryかTooltipsではどうかと考えた。吹き出しなら本文を読みながら、必要な用語の意味を確認が可能であり、今回の目的にマッチする。

    日本語環境で使えるものは?

    4つをテストしてみた。WordPress TooltipsとEncyclopediaが、日本語環境でも使えそうです。

    1. CM Tooltip Glossary : 英語と日本語が混じっている場合、その間に空白がないと英単語を抽出できない
    2. Glossary : 同上
    3. WordPress Tooltips : 英語日本語混じりでも、登録した単語を正確にTooltipしてくれる
    4. Encyclopedia : WordPress Tooltipsと同等の機能を持ってる(ドイツ製)。

    Text Hover

    ワードを登録する形式である。エディタに一括入力する(ex. WP => wordpress)

    Text Hover

    Tooltip CK

    ワードを登録する形式ではない。

    https://wordpress.org/plugins/tooltip-ck

    CM Tooltip Glossary

    ワードを登録する形式である

    CM Tooltip Glossary

    Glossary

    Glossary

    WordPress Tooltips

    ワードを登録する形式である

    WordPress Tooltips

    Enclyclopedia

    ワードを登録する形式である

    Encyclopedia / Glossary / Wiki

    2020/02/23

    結局、Encyclopedia(有料版)を導入することにした。iPhone/iPadを使っていて、Pageにジャンプせず吹き出し表示が可能だったこと、日本語/英語まじり可能なこと、などが決め手になった。

    2020/04/20

    「amp」を登録すると「Sample」が「Sample」となってしまう。この場合、設定を以下のようにすることで、完全な単語にマッチさせることで回避できる。

    Complete words　☑️

    総評

    GlossaryやTooltipsのPluginは、最も古いもので11年前のものが確認できた。3~5年のGlossary Pluginは結構ごろごろあり、忘れ去れている感じだ。

    最近でもUpdateしていてメンテナンスされているものは、5個程度である。

    それでは、なぜ、忘れ去られたものが多数あり、最近のももは少ないのか。全てのGlossary Pluginは、Getenbergエディターには対応していない。旧エディター(Classic)で編集するようになっている。

    GlossaryのWordPress上での原理を考えてみた。投稿を保存する前に、その記事からワードを拾い出し、Glossaryに登録してあれば、リンクや吹き出しコードを付加してから、保存される。

    AMP対応

    2020/04/20

    これらコードは、JavaScriptが用いられているため、ページをAMPに対応して以来、これらのプラグインが正常に動作しなくなりました。

    AMPは、基本的にJavaScriptを許さない。その代わりにAMP版のJavaScriptのサブセットが開発されており、AMPに対応するためには、そのルールに従った前処理が必要です。AMP対応、且つ，吹き出しの機能の付加は、ちょっとハードルが高そうです。現在のところAMPに対応している「吹き出し」プラグインはありません。

  • [WordPress] Gutenbergエディター対応のプラグイン – 2020/01現在で使用していたプラグイン・リスト [2020/01/09]

    [WordPress] Gutenbergエディター対応のプラグイン – 2020/01現在で使用していたプラグイン・リスト [2020/01/09]

    Post Views: 214

    はじめに

    WordPressのテーマ(theme)をTwenty Twenyにしてから、標準のエディタをGutenbergに完全移行した。クラシックのエディタは、iPadで編集している場合、指でのクリックミスの多さに苦しんでいました。

    Ultimate Postを中心に

    Gutenbergはブロックエディタ方式であり、ブロックを追加する形で編集していく。このGutenbergに対応したプラグイン(Plugin)を多数インストールして試用している。

    特に拘っているのが、ポストの表示の美しさ。色々試した挙句、表示はもちろん美しく、設定項目が多数あるUltimate Postを採用した。

    あとは、これに合うように、他の機能について、以下のように選定をすすめ、現在に至っている。

    その他、Gutenberg対応Plugin

    • ポストのグリッド表示: Ultimate Post
    • ソーシャルアイコン: AddToAny
    • トップ&ボトムへスクロール・ボタン: Floating Links
    • Image Gallery: GT3 Photo gallery
    • Google map: Ultimate Addons Block

    今回、ポストをグリッド表示するナイスなPlugin(Ultimate Post)を導入して、それと相性のいい、以下のPluginを選定した。

    Spectra – WordPress Gutenberg Blocks
    AddToAny Share Buttons
    Floating Social Share Icons and Social Share buttons – Next Previous Post Links – FL

    導入Pluginの説明

    Floating Links

    ページのボリュームが多い場合、素早くドップやボトムにスクロールするボタンがあれば助かる。ドップのみにスクロール(あるいはジャンプ)するプラグイン(Plugin)は多数あるが、ボトムへのスクロールにも対応しているのは少ない。Floating Linksは、ドップ、ボトムへのスクロールに対応している。

    AddTo Any

    Floating Linksと相性がいよいソーシャル・アイコン表示pluginは、AddToAny。

    Floating Links(ドップ、ボトムーのスクロールボタン)の表示とAddToAny(ソーシャルアイコン)の表示を重なららいように設置さすることができる。

    更に、ポストをグリッド表示させるPlugin (Ultimate Post)との相性もいい

    投稿(post)をグリッド(grid)表示するPluginを使用している時に、その表示領域(窓)にソーシャルアイコンが表示されて、うるさくなる場合がある。AddToAnyでは、ポストグリッド内に表示されないように設定ができる。

    追記

    Gutenberg用Header & Menu : Sticky Header Pro ($500)

    関連記事