5丁目通信(仮称)

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

カテゴリー: オープンソース

  • DreamweaverをいつでもやめてもいいようにVisual Studio Codeの環境を作ってみた話し。でも、まだDreamweaverはやめないけどね。

    いつでもDreamweaverをやめてもいいように、その替わりにVisual Studio Codeにできるように環境を作ってみた。でもまだDreamweaverは便利だからやめないけどね。

    現在作業しているサイト更新の案件では、大まかには以下のような流れで利用している。

    1. Redmineでチケットを発行する。
    2. git-flowのブランチで作業開始する。
    3. Dreamweaverで作業する。
    4. テストサイトにアップする。
    5. テストサイトでお客さんに確認してもらう。
    6. git-flowのブランチで作業完了する。
    7. 本番サイトにアップする。

    Redmineは普通にブラウザで行って本番アップも今まで通り、あとはVS Codeで完結したい。今まではDreamweaverのテンプレート機能に依存している作業があったが、それがなくなったのでDreamweaverを使わなくても作業ができるようになった。次の通りにVisual Studioの拡張機能を使ってDreamweaverでの作業の替わりの設定をしてみる。

    Gitは、コマンドを使わずに今までSourceTreeで行っていた。GItはあらかじめVS Codeで用意されているが、もっと便利にGitを使うためにも、以下の拡張機能をインストールしておく。

    ただし、いまメンテナンスをしているサイトのHTMLファイルは、文字コードがUTF-8ではなくシフトJISなのでGitで差分を見ると文字化けしてしまう。これは昔からやっているサイトなのでどうしようもない。UTF-8にしようと提案したけど、あえなく却下された。だってページがとても多いからコストがかかるからだってさ。

    git-flowも簡単に行うために次の拡張機能を利用する。同じ名前の拡張機能がいくつかあるので注意。

    結局はSource Treeのほうがわかりやすくて便利なことが確かである。Gitの作業はどれでやってもやることは同じなのであまり気にしないようにする。本当に難しい作業は、Gitのコマンドを叩かなければいけない。

    DreamweaverでもリアルタイムにプレビューしながらHTMLファイルを作成していくので、次の拡張機能をインストールしておく。

    HTMLファイルのプレビューの拡張機能はたくさんあるけど、こちらがよさそうだった。ただし、作業しているサイトのHTMLファイルは、共通のヘッダやメニュー、フッダにSSIを使っているので、SSIをサポートされていないので完璧にはプレビューできない。何か他によいプレビューの拡張機能があったら紹介して欲しい。でも、いまどきSSIで作っているという、とても古いサイトなのである。

    テストサイトのアップは、次のSFTPの拡張機能を使っている。

    Dreamweaverに合わせてアップロードのショートカットキーは、Ctrl+Shift+uに設定しておく。ショートカットキーを揃えるのは、マクロキーボードを使っているからである。このショートカットをキー一つに登録できるマクロキーボードは便利である。

    テストサイトにアップした後、すぐにテストサイトをプレビューできるように以下の拡張機能をインストールしておく。テストサイトのページのURLをお客さんに伝える必要あるので、すぐにテストサイトにアクセスできてアドレスをコピペできることが重要である。この拡張機能が見つからなかったら、自分で作るしかないかと思っていた。Visual Studio Codeの拡張機能はたくさんあるので目的のものはあるもんだなと思った。

    こちらもブラウザプレビューのショートカットキーとしてDreamweaverにあわせてF12にしておく。設定ファイルを次のようにすると、HTMLファイルの編集ウィンドウでF12を押せばChromeが起動して、テストサーバーにアップされたページが表示される。HTML Previewでできなかった細かい確認はここで行う。Chromeのアドレスに表示されたテストページのURLをお客さんに伝えて確認してもらう。

    {
      "open-php-html-js-in-browser.selectedBrowser": "Chrome",
      "open-php-html-js-in-browser.urlToOpen": "custom",
      "open-php-html-js-in-browser.documentRootFolder": "C:/<ドキュメントルート>",
      "open-php-html-js-in-browser.customUrlToOpen": "https://<テストサイトのドメイン>/${relativeDirnameDocumentRoot}/${fileBasename}"
    }

    以上で、Dreamweaverの代替でVS Codeで使うようにする設定は完了。

    しかし、Dreamweaverは、まだまだHTMLファイルの作成にとても楽だから、まだまだ使っていくつもりである。リンクのアドレスとか、テーブルの処理とか、最終更新日の自動記入とか、まだまだ細かいHTMLは断然Dreamweaverのほうが使い勝手がよい。この辺りのHTMLエディタとしては、Visual Studio Codeは頑張っても勝てない。

    アドビ税とかアンチでDreamweaverを嫌っている尖った人たちが何だが多いけど、便利なものはお金を支払っても使っていこうと思う。ちなみに、Dreamweaverは単体で契約している。あとPhotoShopも単体で契約している。

    追記(2021年5月11日)

    DreamweaverとPhotoshopを単体で契約していたけど、アマゾンでAdobe Creative Cloud コンプリートが安かったので買ってしまった。単体と200円も毎月違わなかったから即買いだった。

    追記(2021年6月3日)

    SFTPでファイルのアップロードがNo such fileのエラーでできなくなっていた。対処方法を調べてみると、行き当たったのはこちらのサイト。

    このサイトの記事通りにsftp.jsに一行追加したらアップロードできるようになった。

  • 致命的なエラーになるので、とりあえずWordPressのAMPプラグインを無効にしておいた話し

    Google Search Consoleのエラーをチェックしていたら、WordpressのAMPプラグインを有効にしてサイトにアクセスしたときに ?amp=1 を付けると、次のような致命的なエラーとなっていた。

    Fatal error: Unknown: Cannot use output buffering in output buffering display handlers in Unknown on line 0

    この件をGoogleさんに聞いても解決策が見つからないので、とりあえずAMPプラグインを無効にしておいた。AMP対応は一旦停止となります。

    今までAMPプラグインで対応できていたけど、Wordpress本体かプラグインのバージョンアップで不具合が出たのかしらね。

    著:久保田涼子, 著:西原礼奈, 著:阿諏訪聡美
    ¥2,399 (2025/03/28 17:08時点 | Amazon調べ)

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

  • さくらインターネットのサーバーかWordPressが原因かわからないけど、再利用ブロックが原因不明でGutenbergで呼び出しができなくなってしまっている話し

    以前でも再利用ブロックがGutenbergが呼び出しができなくなってしまったと書きましたが、再度この障害が出ています。自分のところだけの問題でしょうか? それとも、調子に乗って、たくさん再利用ブロックを作成してのが悪いのでしょうか?

    プラグインをすべて無効にしても、テーマを純粋のTwentyTwenty-Oneに戻してみても、何をやっても変わりありません。最近、Gutengergプラグインが何回か短期間に繰り返しアップデートになっていたので、それが原因かもしれません。

    あと怪しいのは、現在運用しているさくらインターネットのレンタルサーバーです。こちらは別のサーバーで、このWordpressのブログサイトを動かしてみて切り分けてみる必要があるかもしれません。他に500のサーバーエラーが出やすくなっているとか、たまに記事を公開すると

    更新に失敗しました。 返答が正しい JSON レスポンスではありません。

    で失敗するとか、さくらインターネットのサーバーがおかしな挙動をしているので、さくらインターネットのサーバーから別のサーバーに移行しなければいけないかもです。さくらインターネットのサーバーでWordpressサイトを動かすと遅いという噂(本当かな?)がありますので、どこが原因なのかは、まだ未確定です。

    いずれにしても、さくらインターネッのサーバーから別のサーバーに移行するするのは大変で、できるならやりたくないのです。メールアドレスをレンタルサーバーに設定してしまっていますので、メール専用のサーバーに設定しておけばよかったと後悔するばかりです。

    そして気になるのは、Chromeのコンソールで見ると、以下のWordpressのREST APIのURLにアクセスしているようですが、

    https://www.5cho-me.com/wp-json/wp/v2/blocks?per_page=100&context=edit&_locale=user

    結果が、次のようなエラーになっていることでしょうか。

    {
      code: "rest_forbidden_context",
      message: "この投稿タイプの投稿を編集する権限がありません。",
      data: {
        status: 401
      }
    }

    権限と言われても、再利用ブロックの一覧表示以外は正常に動いていますので、何だかわかりません。Wordpressをやめて他のCMSに移行することも考えましたが、何せ数千の記事を作ってしまいましたので、ちょっとやそっとではWordpressから離れられません。

    今のところ、Gutenbergから再利用ブロックを選択して挿入できないので、

    <!-- wp:block {"ref":xxxxx} -->

    という再利用ブロックのHTMLコード(xxxxはブロックのID)を貼り付ける方法くらいしか思い付きません。でも、この方法はちょっと面倒です。Gutenbergが正常に対応してくれること望みます。

    著:久保田涼子, 著:西原礼奈, 著:阿諏訪聡美
    ¥2,399 (2025/03/28 17:08時点 | Amazon調べ)

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

    追記(2021年2月6日)

    Gutenbergが昨日9.9.0に更新されたせいかはわかりませんが、たまに再利用ブロックの一覧を表示できるようになりました。たまに表示できるくらいですので、今も半分くらいは表示ができません。もし再利用ブロックの一覧が表示できない場合は、ブラウザの更新を実行すると表示してくれることがあります。それと

    更新に失敗しました。 返答が正しい JSON レスポンスではありません。

    もたまに出ます。

    相変わらず、よくわかりません。

    続きはこちらから

    今回の不具合が一挙に解決した話しはこちらから。

  • WordPressのTwenty Twenty-Oneテーマの子テーマをダークモードに対応させた話し

    WordPressのTwenty Twenty-Oneテーマを子テーマに対応させた話しの続きの話しです。ダークモードに対応させてみました。

    しかし、Wordpressの管理画面でダークモードをOnにすると、子テーマのstyle.cssの前に親テーマのstyle.cssが出現してデザインが元に戻ってしまいます。他に親テーマのstyle.cssが登録しているところが見つかりませんので、おかしな動作です。

    おかしいとも言ってられないので、親テーマのstyle.cssの後に子テーマのstyle.cssが来るようにします。こちらのサイトを参考にしました。

    変更したのはfunction.phpのところです。

    function theme_enqueue_styles() {
    	wp_enqueue_style( 'child-style',
    		get_stylesheet_directory_uri() . '/style.css', array( 'twenty-twenty-one-style' ) 
    	);
    	wp_enqueue_style( 'child-dark-style',
    	get_stylesheet_directory_uri() . '/assets/css/style-dark-mode.css', array( 'tt1-dark-mode' ) 
    	);
    }
    add_action( 'wp_enqueue_scripts', 'theme_enqueue_styles' );

    最初のwp_enqueue_style()の第3引数に親テーマのIDを指定して、style.cssの順番を明示的に指定しています。2番めのwp_enqueue_style()がダークモードのCSSです。

    これで、ダークモードに対応できましたが、本来ならば親テーマのstyle.cssは必要ないので読み込むのも無駄ですし、どうして最初に動かなかったかは不明です。

    著:久保田涼子, 著:西原礼奈, 著:阿諏訪聡美
    ¥2,399 (2025/03/28 17:08時点 | Amazon調べ)

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

  • WordPressのTwenty Twenty-Oneのテーマのページナビゲーションの翻訳がおかしいので修正した話し

    気になると修正箇所が出てくるWordpressのTwenty Twenty-Oneのテーマですが、ページナビゲーションの表示がとてもおかしいので修正してみます。

    こんな感じでページ番号の頭に「固定ページ」が追加されて表示されてしまっています。

    「固定ページ」って何でしょうか? このページナビゲーションを表示しているファイルは、/inc/template-tags.phpのようです。以下のthe_posts_pagination()で表示しています。

    the_posts_pagination(
      array(
        /* translators: There is a space after page. */
        'before_page_number' => esc_html__( 'Page ', 'twentytwentyone' ),
        'mid_size'           => 0,
        'prev_text'          => sprintf(

    しかし、’before_page_number’プロパティの’Page’が「固定ページ」と翻訳ファイルとリンクされているようで、おかしな表示になっています。

    そこで、’before_page_number’プロパティを削除して、シンプルにページ番号で表示させるようにします。ついでに、前後のページ番号を3つ表示するように変更してしまいます。修正した結果は以下のようになります。

    the_posts_pagination(
      array(
        /* translators: There is a space after page. */
        'mid_size'           => 3,
        'prev_text'          => sprintf(

    最初、子テーマに変更した/inc/template-tags.phpを作ってあげても、その変更は反映されませんでした。いろいろ探ってみると、行き着いたのは以下のサイトです。

    the_posts_pagination()を定義している関数twenty_twenty_one_the_posts_navigation() をfunction.phpに追加してあげればいいようです。function.phpに追加した結果は、以下の通りとなりました。

    以上のように、まともで見やすいページナビゲーションとなりました。

    著:久保田涼子, 著:西原礼奈, 著:阿諏訪聡美
    ¥2,399 (2025/03/28 17:08時点 | Amazon調べ)

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

  • WordPressのTwenty Twenty-Oneテーマを子テーマに対応させた話し

    このブログはWordpressのTwenty Twenty-Oneのテーマを使っています。Twenty Twenty-Oneのテーマは見出しが異常に大きいとか、細かい所で惜しいバグがあるとかありますので、いろいろとカスタマイズしています。

    最初は、子テーマでの対応の方法がわからなくて、外観のCSS編集でCSSの上書きをしましたが、いろいろ大変で心が折れました。次にTwenty Twenty-OneテーマのSCSSを直接修正していましたが、Twenty Twenty-Oneテーマがアップデートするたびに元に戻ってしまいます。そこで、何とか子テーマでの対応をしてみました。

    最初に参考にしたサイトは、次のサイトです。

    そのものずばりのタイトルなのですが、このままコピペしてみると、親テーマのTwenty Twenty-Oneテーマのstyle.cssが優先になって子テーマのほうのstyle.cssを適用してくれません。

    今回は、親テーマのTwenty Twenty-OneテーマのSCSSを子テーマにコピーし、そのSCSSを編集してstyle.cssを生成していきますので、親テーマのTwenty Twenty-Oneテーマのstyle.cssは不要となります。

    そこで、親テーマのTwenty Twenty-Oneテーマのfunction.phpにある

    wp_enqueue_style( 'twenty-twenty-one-style', get_template_directory_uri() . '/style.css', array(), wp_get_theme()->get( 'Version' ) );
    

    を無効にしなければいけません。この文をコメントアウトすればいいのですが、これではwenty Twenty-Oneテーマがアップデートしたときに、また元に戻ってしまいます。

    おそらく、CSSの適用はWordpressではキューに入れてからまとめで、HTMLファイルに出力しているようですので、だったらキューから該当するCSSを登録しているキューから削除してしまえ、ということと勝手に理解しました。

    そこで、wp_enqueue_style()関数の反対の動作をする関数を探します。

    関数リファレンスの関連項目からwp dequeue script()という関数を目星をつけます。

    しかし、単純に

    wp_dequeue_style( 'twenty-twenty-one-style');

    とやっても、Twenty Twenty-Oneテーマのstyle.cssが追加されたままです。いろいろ調べてみると、次に見つけたサイトは以下のサイトです。

    イベントを実行するキューには当たり前ですが順番があります。キューを実行する優先順位を指定してあげないといけないようです。

    最後に、以下のようなコードをfunction.phpに書いてあげると、親テーマのTwenty Twenty-Oneテーマのstyle.cssを出力せずに子テーマのstyle.cssだけをHTMLの<head>に書き出してくれるようになりました。

    function theme_enqueue_styles() {
      wp_enqueue_style( 'child-style',
        get_stylesheet_directory_uri() . '/style.css'
      );}
    add_action( 'wp_enqueue_scripts', 'theme_enqueue_styles' );
    
    function remove_enqueue_parent_style() {
      $name = 'twenty-twenty-one-style';
      if( wp_style_is( $name ) ) { wp_dequeue_style( $name ); }}
    add_action( 'wp_enqueue_scripts', 'remove_enqueue_parent_style', 11);

    add_action()の第3パラメータの”11”が今回の記事の肝です。このパラメータが優先度で、デフォルトが”10”ですので、優先度が低くなりますのでこちらが最後に実行されます。デフォルトのwp_enqueue_scriptsイベントより早く実行されると、上書きされて追加されたままになります。

    これで、親テーマのTwenty Twenty-Oneテーマがアップデートされても、子テーマを適用している本ブログには影響がなくなりました。

    著:久保田涼子, 著:西原礼奈, 著:阿諏訪聡美
    ¥2,399 (2025/03/28 17:08時点 | Amazon調べ)

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

    続きはこちらから

  • WordPressのグーテンベルクの再利用ブロックが、ブロック追加でたまに表示できなくなった話し。今は解決している話し。

    現在、さくらインターネットで本ブログを運用していますが、いろいろ障害が出ています。

    障害というのは、必ず発生するのであれば原因を特定しようがあるのですが、たまに発生するというのは意外と厄介です。出るときと出ないときがあって、特にたまたま出るというのは何ともしがたいのです。

    たまにInternal Server Errorが出ると、ずっと言ってきて、ああでもないこうでもないと対策を取ってきましたが、なかなか解決はしません。今度は、Gurtengergの編集画面で、再利用ブロックが表示できなくなっていました。

    正常ならば、左上のブロック追加の+アイコンを押すと、再利用可能というタブが出てくるのですが、いくら待っても出てこないことがあります。

    正常な状態。だけど、Wordpressのアイコンが表示していないのもおかしい

    何回かブラウザで更新をしてあげると、再利用ブロックのタブが出てくれることがあります。何回かというのも定かではありません。これは気まぐれです。

    もし、既に再利用ブロックが記事内に挿入されているのであれば、うまく再利用ブロックのプレビューが表示できていません。

    こんな感じで再利用ブロックが真っ白なままです。こちらも、何回かブラウザの更新をしてあげると、まともにプレビューをしてくれることがあるので更新ボタンを繰り返し押します。

    おそらくサーバーのメモリが足りないとかの原因だとは思いますが、さくらインターネットのサーバーが悪いのか、こちらのWordpressのサイトが悪いのか、はたまたこちらのネットワークが悪いのか、今のところ断定ができません。断定できないとなると、さくらインターネットのサポートに連絡して手間をかけることもできません。

    とりあえず、しつこくブラウザの更新をすればサーバーが機嫌が良ければ治る、という曖昧な回避策があるので何とかやっているのですが、さてこれからどうしましょうか???

    著:久保田涼子, 著:西原礼奈, 著:阿諏訪聡美
    ¥2,399 (2025/03/28 17:08時点 | Amazon調べ)

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

    追記

    ChromeのConsoleを見ると、エラー出ています。この辺りが怪しいかもしれません。

    エラーの内容からWordpressのサイトにログインしているけど、ログインできていないようなエラーのような気がします。ログインできていないから、再利用ブロックの取得ができないということかもしれません。

    いずれにしても、今のところ解決策はありません。

    追記2

    今インストールしているWordpressのプラグインを無効にしたり有効にしたりしましたが解決せず、もしかしたらということで、Gurtengergのプラグインをインストールしてみました。Gurtengergプラグインをアンインストールしたのは、再利用ブロックが10個以上表示できなかったのでアンインストールしていました。

    Gurtengergのプラグインをインストールしたところ、再利用ブロックが表示できるようになりました。だけど、必ず再利用ブロックが表示できるとは限らないというものも痛いところです。まだまだ、Gurtengergは不安定なところが残っているのでしょうか?

    しかも、再利用ブロックは正常に10個以上表示できていますGurtengergのプラグインをインストールしていなくても、今までどうしてGurtengergが使えていたのは、今となってはわかりません。

    何だかWordpressというCMSは、よくわからなくなりました。

    追記3(2021年2月3日)

    最近になって、また再利用ブロックが表示しなくなった。今度は確実に再利用ブロックが表示できない。

    この記事を書いた間にGurtengergのバージョンが何度かアップされたので、それが原因なのか、それともさくらインターネットのサーバーが原因なのか?

    さくらインターネットのコンソールからエラーログを見ると、

    End of script output before headers: index.php

    というエラーが出ていた。

    End of script output before headers さくら WordPress

    でGoogleさんに聞いてみると、ファイルのパーミションを確認しろと出てくるが、確認しても問題ない。

    今のところ原因不明である。おそらくサーバーだな。

    追記4(2021年11月30日)

    最近になって再利用ブロックが表示しなくなることが多くなった。ブラウザで再読み込みをすると直ったけど、今は全く直らない。

    また再度Googleさんに聞くと、こんな情報が上がっていた。

    https://soublog-goodluck.com/teach-how-to-solve-problem-of-wordpress/

    別のブラウザを使ってみるか、ブラウザの履歴を削除すると直るらしい。そんな単純なことで直るの? って思って試してみた。

    普段使っているのはChromeだけど、Edgeで試しみた。何と、再利用ブロックが表示できた。なんとことだろう・・・。

    次にChromeの履歴を削除してみた。履歴を削除すると再ログインしなければいけないサービスがあるから面倒くさいからやりたくないけどやってみた。なんと、再利用ブロックが表示できるようになった。

    そんなことで今まで悩んでいたことが解決した。対処方法は意外と簡単なことなのね。

    追記5(2021年12月1日)

    今日になって再利用ブロックを記事に追加したいと思っても表示できなかった。Chromeで再利用ブロックの挿入はできないみたい。いちいちブラウザの履歴を削除したくない。Edgeだと再利用ブロックの表示ができるので、WordPressで記事を書くときはChromeではなくてEdgeで書かなくてはいけないな。

    Chromeでの再利用ブロックのトラブルの話題は、そんなに聞かないので、自分のところだけのトラブルかもしれないな。

    追記6(2022年3月30日)

    あれから1年以上経っていますが、現在はChromeだろうがEdgeだろうが再利用ブロックの一覧を取得できません。本当にたまに表示してくれます。履歴をクリアしてもダメです。

    しかも、カテゴリー一覧が表示してくれないとか、タグも一覧表示してくれないとかもあります。こちらは表示してくれるほうが多いので、まだ致命的な障害にはなっていません。

    おそらくさくらインターネットのデータベースサーバー周りと睨んでいますが、確証はありません。そろそろさくらインターネットの新しいサーバーがはじまるようなので、こちらに期待してもし改善されなければ移行を考えなければいけません。

    追記7(2022年7月13日)

    こちらの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をバリバリやるのであれば、使わないほうがいいような気がします。自分のような、適当なブログサイトなら問題ないかもしれません。

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

    著:久保田涼子, 著:西原礼奈, 著:阿諏訪聡美
    ¥2,399 (2025/03/28 17:08時点 | Amazon調べ)

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

    追記(2020年12月22日)

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

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

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

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

    続きはこちらから

  • FreeNASが動いているHPのMicro Serverにメモリを増設した話し

    こちらの話しの続き。

    FreeNASが動いているHPのMicro Serverのメモリが、表示4GBで心もとないので増設した。

    メモリ増設前
    メモリ増設前

    4GBだと、ほぼ空きエリアはない状態である。システムと同じくらいにZFSをメモリを使っていることがわかる。

    購入したメモリは、下記のこれである。HPのMicro Serverは、4GBという制限があるらしいけど、DDR3なら動くという情報もあるので、大丈夫だろうと楽観的に考えた。

    メモリの交換方法は、下記のサイトと参考にする。以前にHPのMicro Serverのマザーボードを取り出したことがあるけど、そんなに頻繁にやるようなことではないので忘れた。

    メモリを交換して無事に認識できて、空きエリアはこのようになった。

    メモリ増設後
    メモリ増設後

    だいぶメモリの空きが増えた。

    SambaをLinuxサーバーのインストールしてファイルサーバーとして動かすよりも、サクッとQNAPを入れてしまったほうが簡単、安心、便利でおすすめ。ファイルサーバーだけではなくてIntelのCPUのQNAPなら、Dockerでいろいろとコンテナを設定してサーバーをたくさん立てられるしね。

  • FreeNAS 12.0へののアップデートに失敗して、USBメモリの作成からインストールのやり直しをした話し

    FreeNAS 12.0へののアップデートに失敗して、USBメモリの作成からインストールのやり直しをした話し

    HPのMicro ServerにインストールしていたFreeNASのアップデートをした。アップデートをさぼっていたので、少し古くてアップデート前のバージョンは11.1だった。

    そこで一気に12.0に上げたのが大間違い。Webの管理画面にログインできなくなった。下記のように「Connecting to TrueNAS…Make sure the TrueNASシステムの電源が入り、ネットワークに接続されています。」とかいう、日本語意味不明なわけわからないメッセージが表示されてしまう。

    FreeNASはTrueNASに12から吸収されたことを知った。名前が変わるとアップデートにいろいろ障害が出ることが経験上よくあること。

    Googleさんに聞いてみると、本家TrueNASのフォーラムでもこの障害が議題になっていた。この問題の解決はなさそうである。

    FreeNASがインストールされているサーバーに普段つながっていないキーボードとディスプレイをつなげて確認する。正常に起動されているが、FreeNASのいつものメニューが表示されていない。普通のFreeBSDのログイン画面だった。FreeNASがうまく起動されていないみたい。実は、うまく起動されているかもわからない。

    ここから正常にFreeNASを起動していく設定を行うのは、自分のスキル的に難しいので、FreeNASの起動USBメモリを作り直してしまう。zfsで動いているストレージプールが壊れていなければ儲けものである。

    ここで問題が発生した。なんとPCに接続する書き込み可能なCD-ROMドライブ(実際は書込み可能なブルーレイドライブ)が動かない。しかも、1台だけではない。よく使っていたバッファローの外部のCD-ROMドライブも動かない。別のPCのCD-ROMドライブも動かない。自分でよく使っているPCの最近買ったCD-ROMドライブがどう言う訳かつながらなかった。こちらは、ケーブルの接続を見直して、何とか認識できた。

    CD-ROMなんてほぼ使わなくなったので、動いていることさえ気を付けていない。こういったインストールするときに、ようやく認識するくらいである。おかげでCD-Rなんて、ちいとも在庫が減らないから、10年前買ったものが大量に残っている。ずいぶん昔は、データをCD-Rに焼いて送ったものだけど、今はネット経由で送れてしまう。

    設定ファイルのバックアップファイルを真面目に作っていたので、設定ファイルに合致したFreeNASのイメージファイル(ISOファイル)をダウンロードしてCD-ROMに書き込んだ。FreeNASの設定バックアップを採っておくことは、とても大事であることを後で知ることになる。

    自分のPCでFreeNASの起動CD-ROMからUSBメモリにインストールするのはリスクがあるので(万が一Windowws10のディスクに書き込んでしまうとか)、使っていない古いサーバーがCD-ROMドライブが生きていたので、こちらのサーバーからUSBメモリにFreeNASをインストールする。そのとき「Boot via BIOS」を選択すること。「Boot via UEFI」だと、HP Micro Serverは起動できなかった措置である。

    後は作成したUSBメモリでHP Micro Serverを起動すると、正常にFreeNASが起動されるのが確認できた。このままでは、FreeNASのサーバーのIPアドレスがDHCPで変わってしまっているので、コンソールに表示されているIPアドレスでWebブラウザからアクセスする必要がある。

    アクセスできることを確認できたら、「システム」ー「全般」から「設定ファイルをアップロード」で設定ファイルをアップロードしてしまえば、HP Micro ServerのIPアドレスもユーザー設定諸々も元通りになって、ストレージのプールも認識できるようになった。これでほぼ復旧は完了である。やはり、

    FreeNASの設定ファイルは、保存しておけ

    ということが、今回とても重要なことであった。

    SambaをLinuxサーバーのインストールしてファイルサーバーとして動かすよりも、サクッとQNAPを入れてしまったほうが簡単、安心、便利でおすすめ。ファイルサーバーだけではなくてIntelのCPUのQNAPなら、Dockerでいろいろとコンテナを設定してサーバーをたくさん立てられるしね。

    次に、FreeNASをアップデートする。今度は、一気ではなく一つづつアップデートを行っていく。まずは、11.1から11.2、そして11.2から11.3。TrueNASの12.0へは、まだ怖いのでやめておく。いつかTrueNASにアップデートしなければいけないのだろう。

    FreeNASを11.3にすると、Poolをアップデートしろという警告が出るので、Poolのアップデートは怖そうだけどやっておく。こちらのサイトを参考に実施する。

    https://fefcc.net/archives/783

    「ストレージ」ー「プール」でプールを選択して歯車マークからアップデートを選択して、プールのアップデートを実行する。

    以上で無事にFreeNASを11.3までアップデートできた。管理画面が格好良くなっている。設定ファイルを保存して完了である。

    今はHP Micro Serverのメモリが4GBしかないので、もっとメモリを増やした方がいいかもしれない。インストールするときに、「8GB以上ではないとダメだけど、本当にいいの?」と怒られていた。

    続きはこちらから