- バックアップ取得
- PHP 互換性チェック
- PHP アップデート
バックアップ取得
こちらのページの「データベースとファイルのバックアップ」のステップをそのまま行いました。
PHP 互換性チェック
WordPress の案内記事で書かれていた PHP Compatibility Checker で行いました。
PHP アップデート
さくらのレンタルサーバのコントロールパネル > スクリプト設定 > 言語のバージョン設定

Random Notes
こちらのページの「データベースとファイルのバックアップ」のステップをそのまま行いました。
WordPress の案内記事で書かれていた PHP Compatibility Checker で行いました。
さくらのレンタルサーバのコントロールパネル > スクリプト設定 > 言語のバージョン設定
おそらく 2017 年ごろから更新していなかったので 5 年近く WordPress のアップデートを放置していた様です。
その間に WordPress のエディタは Gutenberg へと大きく変わっておりました。
アップデートした方が良いだろうなと思いつつ「更新時に何かエラーが起きたら」と思うと面倒でずっと放置してきたんですが、いよいよ旧バージョンのエディタが不便に思えて仕方がないので更新することにしました。
WordPress の公式ドキュメントも参考にしつつ進めていきます。
まず 2022 年 1 月時点での WordPress の要件を確認しておきます。
PHP | バージョン 7.4 以上 |
データベース | MySQL バージョン 5.7 以上または MariaDB バージョン 10.2 以上 |
SSL | HTTPS対応 |
では上記を確認していきます。
PHP のバージョンはサーバーに ssh でログインして「php –version」を実行して確認。
% php --version PHP 7.4.25 (cli) (built: Nov 11 2021 13:56:22) ( NTS ) Copyright (c) The PHP Group Zend Engine v3.4.0, Copyright (c) Zend Technologies with Zend OPcache v7.4.25, Copyright (c), by Zend Technologies %
PHP 7.4.25 なので用件は満たしています。
続いて MySQL のバージョンを確認します。サーバーに ssh 等でアクセスできる場合は「mysql –version」を実行して確認できます。
% mysql --version mysql Ver 14.14 Distrib 5.5.32, for FreeBSD9.1 (amd64) using 5.2 %
私はさくらのレンタルサーバーを使っていてデータベースのサーバに ssh 接続出来なかったので、コントロールパネルのデータベースタブで確認しました。
こちらも MySQL 5.7 ということで要件を満たしています。
HTTPS 対応に関してもさくらのレンタルサーバのコントロールパネルで確認しました。
「ドメイン/SSL」ページで対象のサイトの SSL を確認します。
上記の画像の通り、データベースとファイルをバックアップするようお勧めされているので従います。
まずはデータベースから。
phpMyAdmin でデータベースを丸ごとエクスポートします。
phpMyAdmin にログインしたら対象のデータベースを開き、全テーブルにチェックを入れ、「With selected:」の欄で「Export」を選択します。
するとエクスポートの画面へ遷移します。
デフォルトだと「Quick」にチェックが入っていますが「Custom」にチェックを入れます。
このままだと全テーブルの CREATE 文が一つの SQL ファイルにまとまってダウンロードされます。
今回はテーブル毎のファイルでダウンロードした方が便利な気がするので「Output」のセクションで「Export tables as separate files」にチェックを入れます。
「Object creation options」のセクションで「Add DROP TABLE / VIEW / PROCEDURE / FUNCTION / EVENT / TRIGGER statement」と「IF NOT EXISTS (less efficient as indexes will be generated during table creation)」にチェックを入れます。
一番下の「Go」をクリックするとダウンロードが始まります。
ダウンロードされた zip ファイルを解凍するとテーブルごとの SQL が入っています。
これでデータベースのバックアップはよしとします(願望)。
サイトのフォルダの一つ上の階層へ移動し、バックアップしておきたいフォルダを丸ごと「cp -r」コマンドでコピーします。
例えば「www」をいうディレクトリの中にある「notemite」というディレクトリ内に、WordPress を含むサイト関連のファイルが全て入っている場合。
「www」ディレクトリで下記のコマンドを実行します。
% cp -r notemite notemite_20220117
これで「www」ディレクトリの中に元々あった「notemite」ディレクトリはそのままの状態で、さらに「notemite_20220117」ディレクトリが作成されました。
これでとりあえずサイト関連のファイルのバックアップも完了です。
意を決して更新します。
するとしばらくして下記のページに切り替わりました。どうやら更新と同時にサイトが見れなくなるような事態は避けられたようです。
サイトにもアクセスしていくつかページを開いてみましたが、パーマリンクなども異常ありませんでした。よかった。
既存記事を開くと下記のように「クラシック」と表記がある場合があります。
この場合、記事が旧形式のままでブロックエディタに対応していないので、ブロックへ変換します。
「クラシック」の部分をクリックすると下記のように「ブロックへ変換」と表示されます。
そして「ブロックへ変換」をクリックすると、少しわかりづらいかもしれませんが下記の様にブロックエディタのツールボックスが表示される様になります。
これでこの記事もブロック形式へ変換されました。
というわけで WordPress のアップデートは一旦以上です!
AMP 対応している WordPress サイトで、不自然な空白が出てしまっていた。
Chrome のデベロッパーツールで確認したところ、該当の箇所に「amp-ad」タグが表出されていたので AdSense 関連のコードだと思い、WordPress のテーマの編集から header.php に入っていたコードを下記の様にコメントアウトしたが、状況は変わらず。
<!--Google AdSense--> <script async src="https://pagead2.googlesyndication.com/pagead/js/adsbygoogle.js?client=ca-pub-XXXXXXXXXXXXXXXX" crossorigin="anonymous"></script> </head>
<!--Google AdSense <script async src="https://pagead2.googlesyndication.com/pagead/js/adsbygoogle.js?client=ca-pub-XXXXXXXXXXXXXXXX" crossorigin="anonymous"></script> </head> -->
AdSense の審査に通っていないまま放置していたサイトだったので、AdWords 管理画面の「サイト」ページで該当のサイトを一旦削除したところ、上記の「amp-ad」タグは表出されなくなった。
さくらのレンタルサーバ スタンダードプランの契約をしている人。FTPサーバーへアクセスが出来る人。
とりあえず独自ドメインの取得からWordPressサイトを解説まで、さくらのレンタルサーバーを使って進めていきます。
8ステップもあって初めてだと少し大変かもしれませんが、なるべく分かりやすい様に画像もたくさんつけているので1つずつやっていきましょう。
今回はみなさんが見ているこのサイト「notemite.jp」の立ち上げを例として進めていきます。
さくらのレンタルサーバ スタンダードのお申込みはこちら(公式ページ)
まずは独自ドメインを取得します。
ドメインとは「〇〇.com」や「〇〇.co.jp」など、ウェブサイトの住所のようなもので、独自ドメインを取得すればその文字列を自分の任意のものに出来ます。このステップで自分のウェブサイトの住所を取得しましょう。
さくらのレンタルサーバー管理画面 > ドメイン/SSL > 独自ドメイン申し込みをクリック。
遷移先のページで「新規追加」をクリックすると、下の画像の様にドメイン検索画面が表示されます。
もしくは下記リンクで直接ドメイン検索画面へ飛べます。
https://secure.sakura.ad.jp/order/domain/
この画面で自分が使いたいドメイン名を検索します。「notemite」で検索すると、notemite.jp や notemite.jp、notemite.org など、検索した文字列が含まれるドメイン名が表示されます。好みのものがあったら「申し込む」をクリックして手続きを進めます。
支払い方法を選択して進みます。私はクレジットカードを選択しました。
「この内容で申し込む」をクリックすると申し込みが送信されます。
申し込みを送信したら下記リンクから管理画面へ戻ります。
https://secure.sakura.ad.jp/menu/top/
「ドメインの確認」をクリックすると契約しているドメインが表示されます。
ドメイン申請後、契約ドメイン画面で有効期限が「新規申込中」となりますが、私の場合は10分ぐらいで下の画像の様に有効期限が表示され使用可能になりました。
上記の様な表示になったらドメインの取得は完了です。次は FTP サーバ上でこのドメインのフォルダを作ります。
ここから FTP クライアントでサーバーにアクセスしますが、Cyberduck を例に説明します。
Cyberduck を開いたら「新規接続」をクリックします。
さくらのレンタルサーバのコントロールパネル内に「FTP情報」を確認します。
サーバ、ユーザ名、パスワードを入力します。
FTPサーバでドメインのディレクトリ(フォルダ)を作成します。FTPサーバーの「www」フォルダにアクセスします。
*今回は notemite.jp のドメインを例として進めていきますので、既に取得している別のドメインのフォルダは黒塗りで隠しています。
使っているツールによって画面が違いますが、私が使っている Cyberduck ではこんな感じ。画面上部に /home/〇〇〇/www とある通り、FTP サーバーの「www」フォルダの中を表示している状態です。
今回はドメイン名そのままで「notemite」というフォルダを作成します。
「www」フォルダの中に「notemite」フォルダが作成されました。これでこのステップは完了です。
このステップでは、取得した独自ドメインをさくらレンタルサーバーの管理画面上で登録します。
さくらのレンタルサーバー管理画面 > ドメイン/SSL > ドメイン新規追加クリック
「Step2.ドメインの追加」の部分で対象のドメインを選択します。
「追加」ボタンをクリックすると、ドメインリストの中に取得したドメイン名が表示されます。
追加したドメインの「設定」ボタンをクリックします。
「マルチドメインとして利用する」を選択し、「Web公開フォルダ」では先ほどFTPサーバー上で作ったフォルダのパスを入力します。
「保存する」ボタンをクリックしてこのステップは完了です。
WordPress サイト上で作成したブログ記事やコメント、その他様々な設定は全てデータベースに保存されます。このステップではそのデータベースを作成します。
さくらレンタルサーバのコントロールパネル > データベース > 新規追加
好みのデータベース名を入力し「作成」をクリックします。
表示されるデータベースホスト(データベースサーバ)、ユーザー名、接続先パスワード、データベース名を後で使うのでメモしておきます。
WordPress に使用するデータベースが作成されました。これでこのステップは完了です。
さて、もうすぐ WordPress のインストールですが、その前にまた FTP サーバに戻って、先ほど作成した「notemite」フォルダ(皆さんはそれぞれ任意のフォルダ)の中にさらに WordPress 用のフォルダを作成します。
ディレクトリ内にWordpress専用のディレクトリ(フォルダを作成)(/wp/)を作成
ここでは好きなフォルダ名を付けていただいて大丈夫ですが、わかりやすく「wp」としておきます。
これで「notemite」フォルダの中に「wp」フォルダが作成されました。次のステップでこのフォルダの中に WordPress の全てがインストールされます。
まず、さくらのレンタルサーバ > サーバコントロールパネル > WordPressインストールを開きます。
すると様々な情報を入力する画面に切り替わります。
「インストールURL」の部分で、WordPress をインストールする場所を指定します。今回、notemite.jp の配下に「wp」フォルダを用意しています。なので下記の様に指定します。「インストール先ディレクトリ」が FTP サーバー上のフォルダと一致しています。
「テーブルの接頭語」は正直なんでも大丈夫ですが、立ち上げるサイトに関係ある言葉だとわかりやすいと思います。後でもう一度出てくるのでメモしておきましょう。
データベース名、ユーザー名、パスワード、ホスト名、テーブル接頭辞の入力を求められますが、これは先ほどさくらレンタルサーバの管理画面でデータベースを作成した時のものを入力します。
次にサイトのタイトル、そしてユーザー名とパスワード、メールアドレスを入力します。「検索エンジンでの表示」のチェックマークは入れずに「WordPressをインストール」をクリックします。
おつかれさまでした。これでWordPressサイトの立ち上げは完了です。
FTPサーバーの WordPress 用フォルダ(今回は「wp」フォルダ)にある index.php と .htaccess ファイルを、サイトのルートディレクトリ(「サイトのアドレス」)へコピーします。
移動ではなくあくまでコピーなので注意してください。
ファイルをコピーできたら、ドメインフォルダの index.php ファイルを開きます。
require から始まり ‘/wp-blog-header.php’; で終わる文があるので次の修正を行ないます。
WordPress 用に作ったフォルダ名「wp」を記述しました。
次は同じドメインフォルダの .htaccess ファイルを開きます。
「RewriteBase」と「RewriteRule」のところに「wp」フォルダの記述があるので削除します。
↑の赤線の部分を削除します。
「wp」フォルダの部分を削除して保存したら .htaccess の設定も完了です。
WordPress > 設定 > 一般設定 > サイトアドレス(URL)をから専用ディレクトリの箇所を消す
上の画像の様に「サイトアドレス(URL)」の部分が WordPress 用フォルダを含んだURLになっていると思いますが、これを削除します。
これでOK。「WordPress アドレス(URL)」の方は触らなくて大丈夫です。
「変更を保存」をクリックでこのステップも完了。お疲れ様でした!
この作業の後で必ず一度 WordPress からログアウトし再度ログインしてください。
私はこれをしなかったせいで設定が完全に反映されず、記事の投稿が上手くできない状態が半日続きました。。。
シェルスクリプトの記事を書く中で、投稿ページには「–」と書いていたのに公開された記事を確認したら「–」と表示されてしまっていた。
WordPress の投稿ページではきちんと「–」になっていました。
ところが、実際に公開されたページをみてみると下記の通り。
なぜか変わってしまっている。
調べてみると、WordPress の「wp-includes」フォルダ内「formatting.php」というファイルに記述されている関数「wptexturize()」が原因でした。
この関数はテキストを自動的に変換する機能で、例えばふつうの引用符をスマート引用符へ変えたり、特定の記号の並びをアポストロフィ、ダッシュ、省略符号(…)、商標記号、乗算記号などへ変えたり等、通常便利であろう変換を行うものです。
下の表はその自動変換がされる一例です。
元のテキスト | 変換されたテキスト | シンボル名 |
“—“ | “—” | em ダッシュ |
” — “ | “—” | em ダッシュ |
“–“ | “–” | en ダッシュ |
” – “ | “–” | en ダッシュ |
“…” | “…” | 省略記号 |
“ | “ | 開始引用符 |
“hello | “hello | 開始引用符 |
‘hello | ‘hello | 開始引用符 |
” | ” | 終了引用符 |
world.” | world.” | 終了引用符 |
world.’ | world.’ | 終了引用符 |
” ™” | ” ™” | 商標記号 |
1234″ | 1234″ | ダブルプライム記号 |
1234′ | 1234′ | プライム記号 |
’99 | ’99 | 西暦の省略表現前のアポストロフィ |
Webster’s | Webster’s | アポストロフィ |
1234×1234 | 1234×1234 | 乗算記号 |
ということですが、remove_filter() 関数を使ってこの自動変換(wptexturize)を止めることができる様なので、早速 function.php の一番下に下記コードを貼り付けます。
/*wptexturize 無効化*/ remove_filter( 'the_content', 'wptexturize' );
すると下の画像の通り、投稿ページで入力した通りの表記(–)が反映されました。
この時点で投稿内容では自動変換が止まりましたが、記事タイトル等に関してはまだ変換が行われる状態なので、もう一行追加します。
/*wptexturize 無効化*/ remove_filter( 'the_content', 'wptexturize' ); remove_filter( 'the_title', 'wptexturize' );
一行目の「the_content」の部分を「the_title」に変えただけです。これで記事タイトルに対しても自動変換がされなくなりました。
使用していたショートコードの処理結果を記事上で非表示にしたい場合、一番基本的なやり方は投稿の編集画面でショートコードの […] の部分を削除する方法。
ただ、複数のページで使用しているショートコードを全て非表示にしたい場合等では、一つ一つのコードを全記事で削除していくわけにはいきません。
(通常)function.php に記載しているショートコードの関数をいじれば一括で管理できますが、関数部分を丸ごとコメントアウトして関数の呼び出しを無効化すると、記事上にshortcodeが残ってしまいます。
上の画像の様にショートコード関連のコード全体をコメントアウトすると確かに処理は行われませんが下の画像の様、投稿の編集画面で記載している [hello] が表出されてしまいます。
ではどうすれば良いのかですが、ショートコード関数の return 文で null を返してあげると綺麗さっぱり無くなります。
一番直感的なのは元の return 文をコメントアウトし、新たに「return null;」をそのまま記述してしまう方法。
上記の様に null を返してあげると、記事上でも綺麗さっぱりショートコードが無かったことになります。
関数のコードが長かったりすると return 文を探すのが大変だったりするので、関数の頭に表示・非表示を切り替えるフラグの様な変数を入れても良いと思います。
上記のコードの場合は、変数 $visible に true を入れれば “hello shortcode” のストリングが返され、false を渡せば null が返されて記事ページ上で非表示となります。
ショートコードは WordPress の投稿や固定ページに自分で定義した PHP の処理を呼び出せる便利な機能です。
例えば、Wordpress の PHP ファイルで「hello shortcode と表出する」コードを記述し、下記の様に記事編集ページで呼び出します。
すると、実際に公開された記事上では下記の様に表出されます。
[hello]
一般的に処理内容は function.php に記述しますが、function.php には他の重要な処理が書かれている為リスクを伴います。より安全で管理もシンプルになる方法がありますので紹介します。
function.php には既に WordPress にとって重要なコードが記述されており、誤った部分を削除、編集してしまったり、追記したコード自体にエラーがあるとサイトが真っ白に表示されてしまったりとリスクを伴います。さらにショートコードが増えてくるとファイルの中身自体が煩雑になりさらにリスクが高くなります。
もちろんバックアップを取りながら慎重にすすめていくこともできますが、少し煩わしい。そういった場合はショートコード管理専用の別ファイルを作ってしまうことをおすすめします。function.php には一行だけ追記で済み、shortcode自体は別ファイルで管理できます。
function.php の一番下に include 文で別ファイルのパスを記述しておけば、あとは別ファイルの方で管理したものがそのまま function.php に読み込まれるようになります。簡単にいうと、shortcode.php の内容も function.php の一部として認識される感じです。
まず、ショートコード用に新規の php ファイルを作成し、その中にショートコードの内容を記載します。この場では shortcode.php としましたが、ファイル名に特に決まりはありません。
そして、function.php には下記の様に include 分で先ほど作ったショートコード用ファイルのパスを記述します。
この方法でコードを編集すると、下記のような状態になります。
function.php の中にショートコード関連の定義が記載されています。
ショートコード関連のサイトのコードを別ファイルにまとめる事で、根幹を担う function.php への変更は最低限に留め、ショートコードの管理も専用ファイルでよりシンプルに行うことができます。
こうしておくと、WordPress テーマを変えたりした時も新しい function.php に include 分の一行を書くだけで済むので管理が断然楽になります。
別ファイルに分けると function.php 上でエラーを起こすリスクは下げられますが、ショートコード用ファイルで間違ったコードを書いてしまうとやはりサイト自体に影響が出てしまいます。
そんな時すぐさま問題を解決出来れば良いのですが、とりあえず function.php の include 文を一旦コメントアウトしてしまうのも一つの方法です。
そうするとショートコードは機能していない状態になりますが、すぐに問題の影響を断ち切ることができます。サイトを稼働させながらショートコード用ファイルの方でじっくり分析、修正を行った後で include 文のコメントアウトを外せば、影響を少なく抑えることができます。