5丁目通信(仮称)

とある5丁目で活動する還暦を過ぎたWebプログラマーの覚え書きです。それとかかってくる迷惑電話や、家業のアパート経営について。

タグ: WordPress

  • さくらインターネットのレンタルサーバーでInternal Server Errorが出る件は、All in One SEO Packを削除したら直ったかも、でもまだ直っていないかも、どちらなの、という話し

    ずっと本ブログサイトで出ていたInternal Server Errorが出る件は、ようやく落ち着いてきました。原因は、All in One SEO Packプラグインのようでした。

    “ようでした”というのは、All in One SEO Packを削除してから、Internal Server Errorが出なくなくなったというだけで、本当にAll in One SEO Packが原因がどうかはわかりません。単純にInternal Server Errorが出るからって、All in One SEO Packを削除すればいいとは限りません。

    どうしてAll in One SEO Packを何でインストールしたかというと、Bing Webmaster Toolsでたくさん

    説明がページのヘッド セクションにありません。

    と怒られたせいで、それで<meta name=’description’ を付けようということになって、面倒なのでAll in One SEO Packプラグインでやってしまえ、ということでインストールしました。後は、キレイにTwitterに投稿した記事を共有できるということです。

    All in One SEO Packプラグインを削除することにすると、<meta name=’description’ を違う方法で付けてあげなければいけません。Twitterの共有については、共有できていればいいだけですので放っておきます。descriptionのほうは、以下のサイトを参考に、Wordpressのfunction.phpでプログラムで生成してあげるようにします。

    そのまま利用するのではなく、適当に本ブログで必要なcontent=””を生成しています。

    しかしながら、All in One SEO Packは重いプラグインと言いながら、これでInternal Server Errorを出すようなさくらインターネットのレンタルサーバーはいかがながものでしょうか?

    さくらインターネットのレンタルサーバは、WordpressのAll in One SEO PackプラグインでSEOをバリバリやるのであれば、使わないほうがいいような気がします。自分のような、適当なブログサイトなら問題ないかもしれません。

    でも、そんなことを言うのなら、もっと金を払ってスペックの高いサーバーを契約しろ、というところでしょうか。

    著:久保田涼子, 著:西原礼奈, 著:阿諏訪聡美
    ¥1,199 (2025/08/29 01:00時点 | Amazon調べ)

    なんやかんやでWordPressのサイト構築で躓くのは、PHPのプログラミングなのでした。

    追記(2020年12月22日)

    相変わらず、まだInternal Server Errorはたまに出ています。All in One SEO Packプラグインが原因ではないのかな? たまにエラーが出るくらいなので、サイトの運用には問題ないレベルだから、放っておいてもいいレベルなのかな?

    その他、WordpressのテーマをTwentyTwenty-oneにしたりキャッシュのプラグインを見直したりで、アクセスがだいぶ速くなったし、よくわからない。さくらインターネットのレンタルサーバーで共有している他のユーザーのサイトに、アクセスが集中しているのだったらしょうがないな。

    昔のことを思い出したけど、Wordpressはさくらインターネットのレンタルサーバーの機能を使ってインストールした覚えがある。これでWordpressのインストールや設定がしくじっているとかだと辛いかもな。

    さくらインターネットから別のレンタルサーバーに移行するのも面倒だし、どうしてものやら・・・。

    続きはこちらから

  • 祭りが終わった、このブログのアクセス数の話し

    WordPressのJetpackにあるサイト統計情報を見て楽しんでします。

    今週は一気にアクセス数が伸びました。こんな感じです。

    何が原因かというと、以下の投稿をたくさん読まれたためでした。

    どうも、該当する迷惑メールが、再度届いているようで、皆さん気になって「商業オファー」で検索してくるようでした。

    何も考えずにメールのリンクをクリックするよりも、一旦気持ちを落ち着けて検索するのはいいことだと思います。間違っても、こんなメールのリンクをクリックしてはいけません。その前に、メールを開けないように削除してしまったほうがいいです。

    しばらくすると、また落ち着いて元のアクセス数に戻ります。アクセス祭りは、すぐに終わります。

    著:一般社団法人 日本ダイレクトメール協会
    ¥3,240 (2025/08/27 22:52時点 | Amazon調べ)
    WAVE出版
    ¥1,530 (2025/08/27 22:53時点 | Amazon調べ)
  • さくらインターネットのレンタルサーバーでInternal Server Errorが出るようになったので、WordPressのテーマをTwenty Twenty-Oneにしてみた話し

    このWordpressで動いているブログにアクセスすると、Internal Server Errorが出るようになってしまいました。必ずInternal Server Errorが出るのではなく、たまに出るのが痛いところ。

    サーバーのエラーログを見てみると、

    End of script output before headers: index.php

    が出ています。これは、index.phpのパーミッションを変更すればいいそうです。

    しかし、これでは解決しませんでした。相変わらず、Internal Server Errorがでます。今回も忘れたときに、たまに出るのは嫌な感じです。

    さくらインターネットのサポートに聞いてもいいのですが、どうせ「ユーザー固有のトラブルだから対応しない。」とか言われそうなので、自力で解決しなければいけません。もし、自力で解決できなければ、他のレンタルサーバーに移るしか手はなさそうです。

    次にやってみたのは、Wordpressのテーマを新しいTwenty Twenty-Oneに変更してみました。現在はTwenty Twentyを使っていますが、最近のWordpressはGutenbergに対応しに行っているので、なるべくGutenbergに対応した新しいテーマをしたほうがよさそうです。そこで、最新のWordpress謹製のテーマであるシンプルなTwenty Twenty-Oneにしてみました。

    Twenty Twenty-Oneは、日本語のサイトにすると、見出しの文字の大きさとか、モバイルのメニューの表示とか、若干気に入らないところがありましたので、CSSを追加して上書きしておきました。シンプルで良さげなテーマです。

    Twenty Twenty-Oneにしたおかげで、サイトのページの表示スピードが早くなりました。およそ、メインのHTMLファイルが1桁ほど速くなっています。今まではキャッシュに入っていても遅かったので、これはTwenty Twenty-Oneにして良い効果です。

    肝心のInternal Server Errorは、今のところ出ていません。しばらく、様子を見ていきます。

    次に調べなければいけないのは、Wordpressのプラグインでしょうね。

    著:久保田涼子, 著:西原礼奈, 著:阿諏訪聡美
    ¥1,199 (2025/08/29 01:00時点 | Amazon調べ)

    なんやかんやでWordPressのサイト構築で躓くのは、PHPのプログラミングなのでした。

    追記(2020年12月19日)

    さくらインターネットのレンタルサーバーのコンソールから、エラーステータスはだいぶ減っているが、依然多い。エラーログでもだいぶ減っている。

    Google Search Consoleで、相変わらずLCP の問題: 4 秒 超(パソコン)が大量出ている。これは、今回のテーマをTwenty Twenty-Oneにして、なくなることを期待している。

    Twenty Twenty-Oneでの表示を最適化するために、CSSを追加しているが、本来ならばSASSでCSSをTwenty Twenty-Oneでは実現しているので、SASSを修正していかなければいけない。しかし、WP-SCSSプラグインではエラーが出てコンパイルできなかった。

    12/19/20 12:36:13: style.scss - function is not a number: line: 96
    12/19/20 12:36:13: style-editor.scss - function is not a number: line: 96

    こちらは原因不明である。でも、SCSSファイルを修正していったほうが楽であるので、なんとかしなければいけないな。

    ローカルでSCSSからCSSへのコンパイルできるようにしなければいけないかもしれない。ただ、Twenty Twenty-OneでのSCSSの@importを使った外部SCSSファイル命名が通常とは違うので、いろいろと厄介そうだ。今のところ、VS Code + Easy SASSでのコンパイル環境では、うまく行っていない。

    今気がついたが、Twenty Twenty-Oneのテーマでは、Wordpressの編集画面で再利用ブロックのタブが表示できてこない。これは致命的なバグである。もしかしたら、自分のところだけか?

    一度、編集画面から抜けて、もう一度編集画面に入ってら、今度は再利用ブロックのタブが表示できるようになった。

    追記(2020年12月19日)

    Twenty Twenty-OneのSCSSのCSSのコンパイルは、Twenty Twenty-Oneのディレクトリにpackage.jsonがあったので、npm iでいろいろインストールが始まってコンパイルの環境が構築できた。npm run start でコンパイルの監視ができるが、いろいろエラーが出力される。エラーが出ても、きちんとSCSSからCSSにコンパイルできたので気にしない。

    さくらインターネットのInternal Server Errorが発生する件だが、相変わらずエラーが出る。たまに、スタイルシートが読み込めないとかになるので、多分さくらインターネット側のサーバーの問題なのだろう。

    さくらインターネットのサポートに問い合わせる前に、All In One SEO Packとか重そうなプラグインを無効にしてみよう。問い合わせは、それからだ。

    追記(2020年12月20日)

    Twenty Twenty-OneテーマのSCSSからCSSにコンパイルするときにchokidarでSCSSファイルの更新を監視しているのだが、こちらのスクリプトでエラーが出ている。

    "build:stylelint": "stylelint **/*.css --fix --config .stylelintrc-css.json"

    .stylelintrc-css.jsonなしのlint:scssのスクリプトであれば、正常に動作して構文チェックをしてくれる。.stylelintrc-css.jsonの設定ファイルが怪しそうである。stylelintは、よくわからないので、package.jsonのscriptsから削除しておく。何かSCSSの構文エラーがあったので、こちらは対応しておく。

    しかしながら、Twenty Twenty-Oneテーマがアップデートされたら、修正したSCSSファイルが上書きされるのだろうな。子テーマで実現しようしたら、子テーマのCSSが読み込めないというトラブルがあったのでやめた。Wordpressの管理画面の外観のCSSの編集で、CSSを上書きするようにしていたけど、SCSSになってglobal.scssにある値を編集してコンパイルされたstyle.cssをアップしたほうがいろいろ変更するには簡単である。何かテーマを編集するのに、最適な方法があるのだろうか?

    続きはこちらから

  • WordPressのバックアッププラグインBackWPup で、「エラー: アップロードされたファイルのサイズとローカルファイルのサイズが一致しません。」が出る件の話し

    ここのブログのWordpressから警告のメールが来た。

    エラー: アップロードされたファイルのサイズとローカルファイルのサイズが一致しません。

    だそうだ。Wordpressの管理画面に入ってBackWPupのログを見てみると、

    となっている。

    そこで、Googleさんに「エラー: アップロードされたファイルのサイズとローカルファイルのサイズが一致しません。」で聞いてみると、出てくる回答は、どれもDropboxの容量が足りないと言っている。

    しかし、Dropboxは既に有料ユーザーの2TBに契約していて、28%しか使っていない。この回答は違っている。

    試しに、一旦DropboxとBackWPupの認証を削除して、再度認証しておく。そしてバックアップの再実行をする。すると、今度は非常に時間がかかったが、今度は正常にバックアップができた。

    実行時間を見てみると1000秒と切りのいい時間になっているので、おそらくDropboxへのファイルを送信しているときに1000秒でタイムアウトしているのではないか。

    これはDropboxとWordpressが動いているサーバーの間だの問題なので改善することはむずかしいかもな。それと、バックアップデータサイズをもっと圧縮するくらいか。

    著:久保田涼子, 著:西原礼奈, 著:阿諏訪聡美
    ¥1,199 (2025/08/29 01:00時点 | Amazon調べ)

    なんやかんやでWordPressのサイト構築で躓くのは、PHPのプログラミングなのでした。

  • ATOKの質問をしようとジャストシステムにしようとしたけど電話しかないのねと、ATOKは文節区切りの色の障害が修正されそうにないから乗り換えようかな、という話し

    ATOKでChromeとかEdgeで漢字変換したときに、変換の文節区切りが表示されない障害というかバグの件、ずっと修正を待っていましたが、全く改善されそうにありません。文字を入力して変換しても、文節区切りがわからないので、一発目の文節の区切り方が失敗するとお手上げです。

    もう、何とかならないかと思ってサポートに連絡しようにも電話しか連絡手段がなさそうです。

    [042605]お問い合わせ窓口について(パッケージ・ダウンロード製品などをご利用のお客様)

    ジャストシステム

    チャットとは言いませんが、メールかWebフォームで受け付けてくれれば、電話で待たされるということもないのではと思います。どうせ、新型コロナの影響で、電話サポート窓口も絞っているかもしれないので、どんどん電話が繋がらないかと察します。

    この障害はFirefoxでは出てません。Firefoxでは正しく色付きで文節の区切りがわかります。皆さん、ATOK+Chrome or Edgeで満足して使っているのでしょうか? もし、私のところだけの問題だったら、解決法を教えて下さい。

    最近は、GmailとかWordpressの記事作成とか、ブラウザで文字入力をすることが多くなっています。ブラウザで正しく文字変換の操作ができないとなると、ATOKをそろそろ使うのをやめる機会かもしれません。

    ATOKは推測候補が便利で使っています。例えば、「ご」と入力したら「ご確認ください」と候補が出てきてShift+Enterで確定できてしまいます。しかし、この機能は、今はGoogle日本語入力でもあるのですね。Google日本語入力が文節区切りが正しく表示されるし、こちらに変えてしまいましょうか。

    ずっとATOKパスポートのプレミアムを契約していましたが、Google日本語入力でできないことといえば、日本語入力しながら辞書が引けなくなることでしょうか。肝心の日本語変換の精度は、誤入力からの訂正や、入力した文字をこちらで思っていた漢字に気持ちよく変換してくれるところは、さすがにATOKのほうが上です。ただし、今回の文節区切りの障害から考えると、Google日本語入力に切り替えたほうがいいかもしれません。

    今は試しにGoogle日本語入力で入力していますが、こちらで問題なければ、このままGoogle日本語入力を使っていきましょう。

    ジャストシステム
    ¥6,146 (2025/08/29 11:40時点 | Amazon調べ)
    ジャストシステム
    ¥3,753 (2025/08/23 17:41時点 | Amazon調べ)

    なんやかんや言いながらも、40年の歴史があるせいか漢字変換はATOKが一番賢い。いつでも最新版(毎年ATOKはバージョンアップにしてくれる)になるので月額課金のATOK PASSPORTにライセンスは集約されている。これ以上、ATOKが重くなくなればいいけど。ATOKが開発終了にならないためにも、皆さんATOKを買っておくれ。

    追記

    ATOKのCtrl+BSで確定後の再変換の機能は、いつの間にか治っていたのね。

    続きはこちらから

  • WordPressの投稿の保存があまりにも遅いのでデータベースの最適化をしてみた話し

    このWordpressのサイトで投稿を保存するときに、たまらなく遅くなってきました。MySQLのデータベースをバージョンアップしても変わりません。

    そこでMySQLに格納されている投稿データを最適化してみることにしました。最適化といっても、投稿のリビジョンを削除するだけです。十数年Wordpressを使っていますが、リビジョンの機能が追加されたのはいつのことでしょうか? 全くリビジョン管理をしていないので、追加しっぱなしになってデータベースが肥大化しています。

    投稿のリビジョンを削除したのは、Optimize Database after Deleting Revisionsというプラグインです。こちらのサイトを参考にして実施してみます。

    WordPressのリビジョンとデータベースを最適化 Optimize Database after Deleting Revisionsの設定と使い方 | ウインドミル

    ここのサイトはこの情報以外に、PDFでの電子証明書についての情報が記載されて有用なサイトであるが、最近更新頻度が落ちているのは残念である。

    SQLを実行してMySQLのデータベースからリビジョンを削除することもできますが、スケジューリングして普段でもリビジョンを削除してくれますので、新しくプラグインを追加することを避けたいのですが、簡単なのでOptimize Database after Deleting Revisionsを導入しました。

    著:久保田涼子, 著:西原礼奈, 著:阿諏訪聡美
    ¥1,199 (2025/08/29 01:00時点 | Amazon調べ)

    なんやかんやでWordPressのサイト構築で躓くのは、PHPのプログラミングなのでした。

    リビジョンを削除した結果なのですが、Optimize Database after Deleting Revisionsでリビジョンを削除する前にOptimizeを実行しておけばよかったのですが忘れてしまいました。データベースのバックアップのサイズの削除前と削除後では、およそ3分の1に減っていました。この位、データベースにリビジョンで埋まっていました。

    さて、肝心の投稿の更新の実行時間ですが、以前とあまり変わらない残念な結果でした。

    その他、対策を考えて行きましょう。最悪は、現在サイトを動かしているさくらインターネットのレンタルサーバーから他のサーバーに移ることでしょうか? 

    最近のさくらインターネットは遅くなっているのかな? サーバー自体かデータベースか、それともインターネットの回線か?

    さくらインターネットのお安いレンタルサーバーの契約ではダメなのかな?

  • しつこくwp-envで試してみたら、WordPressのGutenbergの再利用ブロック一覧は 10個以上表示していたので解決できた話し

    WordPressのGutenbergの再利用ブロック一覧は 10個以上表示されないという障害ですが、気になりだしたら停まらなくなりましたので、しつこくwp-envで試してみました。今度は正常に表示されていました。

    wp-envは、Dockerを使って簡単にWordpressの開発環境を作成できてしまいます。DockerとNode.jsがインストールできていれば、コマンド2発(インストールと起動)でWordpressが起動できます。詳しくはwordpress.orgのサイトを参照ください。

    https://ja.wordpress.org/team/handbook/block-editor/packages/packages-env/

    最初は、wp-envが起動したWordpressのバージョンも一緒なので、何かおかしいかわかりませんでした。気になるのはwp-envでは、Gutenbergのプラグインがインストールされていなくても、編集画面がGutenbergになっていました。そこで、自分のサイトのGutenbergを無効にしてみました。

    すると、何ということでしょう。正常に再利用ブロックが10個以上表示されるようになりました。画面はGutenbergのブロックエディタのままです。これで無事に解決です。解決方法がGutenbergプラグインを削除することなんて全く気が付きませんでした。何てオチなんでしょうか・・・。

    こう再利用ブロックを見てみると、Amazonのアフリエイト広告ブロックばかりですな。

    しかしながら、今はGutenbergのプラグインはインストールして有効にする必要はないのでしょうか? すでにWordpressにGutenbergは組み込まれていると言うことなのでしょうか? Gutenbergがリリースされてから、Gutenbergプラグインをずっとインストールをしていました。

    今度は、記事を書いている間に自動保存が動いて、ずっと更新中になってしまうというのは直っていません。こちらもこれから調べていかなければいけません。

    とりあずの回避策としては、記事を念のため一旦クリップボードにコピーしてブラウザの更新ボタンを押します。ブラウザから「サイトを再読込しますか?」という警告(Chromeの場合)が表示されますが、そのまま「再読込み」ボタンを押します。次に「バックアップから復元」ボタンが左上に出てきますので押せば元に戻ります。

    著:久保田涼子, 著:西原礼奈, 著:阿諏訪聡美
    ¥1,199 (2025/08/29 01:00時点 | Amazon調べ)

    なんやかんやでWordPressのサイト構築で躓くのは、PHPのプログラミングなのでした。

    続きはこちらから

    続きはこちらから(2020年12月23日)

    今は以下のような障害で、Gutenbergプラグインを再度インストールしています。

  • WordPressのGutenbergの再利用ブロック一覧は 10個以上表示されない障害のその後と回避策の話し

    WordPressのGutenbergの再利用ブロック一覧は 10個以上表示されない障害のその後の話しと、とりあえずの回避策の話しです。解決に至っていません。

    あれからGutenbergのソースを追ってみましたけど、10個以上表示しないようにフィルターをかけているなんてしなさそうでした。当たり前だけど。再利用ブロックの一覧を表示しているのは、以下のところでしょうか。

    packages\block-editor\src\components\inserter\hooks\use-block-types-state.js
    packages\block-editor\src\components\inserter\reusable-blocks-tab.js
    packages\block-editor\src\components\block-types-list\index.js

    それにしても、GutenbergはReactで記述されているのすね。ソースを追ってみたと言っても、Reactはあまりわかっていないので、何となくこんなことをやっているなんて感じでソースを追っています。

    今回でわかったのは、再利用ブロックはどこに格納しているかというと、投稿と同じpostのテーブルなんですね。Gutenbergからどうやって取得しているかは、

    select( 'core/block-editor' );

    が何かやっているようでした。そもそもwp.data.を付けずに、select()でどうして動いているかも、まだ理解していません。デバッグ環境を作って追っていければいいのですが、まだそこまでやっていません。

    そもそも、いちいち再利用ブロックが出てくるたびに、データベースを参照するなんてコストが高いと思うのですが、そこのところは上手くやっているのでしょうね。そうではないと、キャッシュ必須になってしまいます。

    また、自分のサイトが悪いのどうか切り分けるため、試しに新しくWordpressのサイトを立てて見ました。今回は簡単にWordpressのDockerイメージで起動します。簡単にテストでサーバーを起動するのはDockerが便利です。Dockerイメージを用意してくれると、とても助かります。

    クィックスタート: Compose と WordPress — Docker-docs-ja 17.06 ドキュメント

    結果は、やはり再利用ブロックの一覧は10個以上表示できませんでした。サイトの固有の問題ではなさそうです。ただ、再利用ブロックのインポートとエクスポートは正しく動いていました。まとめてインポート/エクスポートできないのが仕方ないのでしょうか。

    プラグインもすべて無効にしても変わりません。Gutenbergのブラグインだけでも、再利用ブロック一覧が10個以上表示できない障害が出ています。

    著:久保田涼子, 著:西原礼奈, 著:阿諏訪聡美
    ¥1,199 (2025/08/29 01:00時点 | Amazon調べ)

    なんやかんやでWordPressのサイト構築で躓くのは、PHPのプログラミングなのでした。

    こちらの障害は、Gutenbergの開発コミュニティに報告しなければいけませんかね。いろいろ報告の前段階の説明を読むと、面倒なことが書かれているのですので敷居が高そうです。

    試しに再利用ブロックを非公開したらリストに反映されずに、よく使うブロックを10個までにしておけばいいかと思いましたが、非公開にしてしまうと記事にほうに表示できなくなってしまうのでした。この回避策は使えません。

    もう一つの回避策としては、再利用ブロックのリストは新しく作成した順に10個だけ表示しているので、よく使う再利用ブロックの作成日付を新しい順になるように「すべての再利用ブロックの管理」から変更しておくことです。しかし、新しい順で11番目を使いたいときには、再度日付を更新するという面倒な作業が発生します。

    以上、全くGutenbergの再利用ブロックの一覧が10個しか出てこない問題は解決していません。

    続きはこちらから

  • このサイトのWordPressのデータベースであるMySQLを5.5から5.7にバージョンアップした話し

    どうもこのサイトのWordpressの管理画面が遅くなっているし、Gutenbergでのいろいろ障害が発生するしで、サイトを見直してみる。

    とにかく記事を書いているときに遅いのは問題である。Gutenbergが原因かもしれないが、まずは自分のサイトを疑ってみる。

    今間気になっていたのはWordpressサイトで使っているMySQLのバージョンである。しばらく前からさくらインターネットのレンタルサーバーを使っているが、そのときにインストールしたMySQLは5.5であった。現在のWordpressのMySQLの推奨バージョンは、5.6以上になっていた。

    ということで、MySQLをバージョンアップしてみる。

    さくらインターネットのレンタルサーバーでは、データベースアップグレード機能というのを用意している。最初はこの機能を使ってバージョンアップしてみようと思ったが、処理はスケジューリングされて、今から4時間後になっていたので見送る。その間はデーターベースの更新はしない方がよいとか書かれているので、これではないと思った。

    著:久保田涼子, 著:西原礼奈, 著:阿諏訪聡美
    ¥1,199 (2025/08/29 01:00時点 | Amazon調べ)

    なんやかんやでWordPressのサイト構築で躓くのは、PHPのプログラミングなのでした。

    そこでデーターベースを手作業でやってみる。phpMyAdminでお手軽にエクスポート、インポートをしようとしたけど、インポートできるデータベースのサイズが32MBだったので、こちらは320MBでZIPで圧縮しても32MBをわずかに越えるということで断念した。

    仕方ないので、MySQLのコマンドを叩いて対応することにする。参考にしたのは、以下のサイトである。

    まずは、データベースをバックアップしたSQLファイルを、Webサーバーの適当なところに置く。今回は、WordpressのバックアップするためのプラグインのBackWPupでローカルディスクを指定してバックアップしておく。あとは、SSHでWebサーバーにログインして、データベースに接続して、mysqlのsourceコマンドでSQLファイルを投入する。

    そして、Wordpressの設定ファイルでデータベースの接続先を変更して完了である。sourceコマンドでのSQLファイルの投入に時間がかかったが、問題無くMySQLデータベースのバージョンアップが完了した。

    さて、MySQLデータベースのバージョンアップの結果はというと、Gutenbergの再利用ブロックの挿入は解決したが、利用ブロックの10個以上の一覧表示は解決されなかった。

    しかしながら、まだ投稿の更新が非常に遅い。ただし、ブラウザのネットワークのパフォーマンスを見ると、アクセス時間が半分くらいになっていた。

    再利用ブロックの挿入が解決しただけでも、良しとしましょうか。

    追記

    自動保存で更新待ちになるタイミングが多いので、Gutenbergの自動保存の設定を変更しておいた。更新時間が長いので、延々と更新となってしまう。

    https://www.nxworld.net/wordpress/wp-gutenberg-custom-autosave-interval.html

    デフォルト10秒らしいけど、これって短すぎやしないか?? function.phpを変更させずに設定画面で変更するようにして欲しいわ。

    それと、こんな風に再利用ブロックのタブが出てこないときがある。何回かタブをクリックすると再利用ブロックのタブが出てくる。

    今はどういう訳か再利用ブロックのタブが出てこない。

    まだまだGutenbergは不安定である。

    追記2(2020年10月30日)

    再利用ブロックのタブが出てこないのは、データベースから再利用ブロックの取得が遅いため。しばらく待っていると再利用ブロックのタブが表示されるようになる。待ち時間は5~10秒位。

    続きはこちらから

  • WordPressのGutenbergの再利用ブロック一覧は 10個以上表示されないのね、という話し

    最近、WordpressのGutenbergにある再利用ブロックを気に入って使い出しました。使っているのは、アマゾンのアフリエイトの挿入です。決まったアフリエイトのパターンを再利用ブロックに登録しています。例えば、ネットワークの本のアフリエイトとか、よく使うものを再利用ブロックに登録しています。

    再利用ブロックのよいのは、登録しているアフリエイトを変更したいとき、例えば商品が新しくしたいとか、再利用ブロックを更新しておけば挿入されている投稿もすべて更新されてくれることです。これは、管理されている再利用ブロックがクラス、投稿に挿入された再利用ブロックがオブジェクトとして継承されると考えればわかりやすいでしょう。ブロックに変換すると継承関係がなくなりますので、再利用ブロックを変更しても変換したブロックは変更しません。

    ただし、今のところの大きな問題としては、再利用ブロックを10個以上登録すると、再利用ブロックの一覧に10個しか表示されないことです。これは、Gutenbergの制限でしょうか?

    それと再利用ブロックが挿入できないこともあります。アイコンがぐるぐる回ったままになります。プレビューでは正常に再利用ブロックが挿入されているので、Wordpressの管理画面でのGutenbergが原因か、もしかしたらこのサイト固有の問題でしょうか?

    要は再利用ブロックの機能は、私のサイトの環境ではまだ不安定です。

    著:久保田涼子, 著:西原礼奈, 著:阿諏訪聡美
    ¥1,199 (2025/08/29 01:00時点 | Amazon調べ)

    なんやかんやでWordPressのサイト構築で躓くのは、PHPのプログラミングなのでした。

    続きはこちらから